SEMICeu / DCAT-AP

This is the issue tracker for the maintenance of DCAT-AP
https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
74 stars 24 forks source link

Incorrect @type for textual values in JSON-LD context #129

Closed jakubklimek closed 4 years ago

jakubklimek commented 4 years ago

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 the rdf:langString datatype and no language tag.

I would, therefore, suggest one of two approaches:

  1. Remove @type from the JSON-LD context, which allows users to add @language to produce language tagged literals
  2. Change the textual properties to language maps, explicitly promoting multilinguality.
bertvannuffelen commented 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.

jakubklimek commented 4 years ago

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