Closed jakubklimek closed 4 years ago
According to the DCAT-AP specification, the usages of language-aware strings is not enforced, but rather indicated as an intended practice.
See e.g. the wording of the usage note for description:
This property contains a free-text account of the Dataset. This property can be repeated for parallel language versions of the description.
For the bugfix release, I will remove the xsd:string type setting. And add an additional context file in which all properties that are subject to multilingualism in the language maps format. In a later release we might enforce this. But note that in the case of language maps only one value per language can be given. That is a limitation of the JSON structure, but which will suit most cases.
But note that in the case of language maps only one value per language can be given. That is a limitation of the JSON structure, but which will suit most cases.
@bertvannuffelen JSON-LD spec allows multiple values in language maps: https://www.w3.org/TR/json-ld11/#language-indexing
There is an issue with textual values in the JSON-LD context. They use
@type: "xsd:string"
, e.g. for title, but the same goes for description, version notes, etc.Those strings are, however, typically in some natural language (Czech, English, German, etc.) and therefore, in RDF 1.1, would need to be of the type
rdf:langString
.However, changing the type to
rdf:langString
in the @context actually does not help. When adding"@language": "cs"
to the JSON-LD context, the current JSON-LD implementations (e.g. JSON-LD Playground or RDF Translator app) produce a literal with therdf:langString
datatype and no language tag.I would, therefore, suggest one of two approaches:
@type
from the JSON-LD context, which allows users to add@language
to produce language tagged literals