Regarding Multilingual Aspects described at section 10 of draft 2 v0.03 It may be useful to clarify that it is a frequent best practice to always include an rdfs:label for which the language tag in not indicated, corresponding to the "default" language for the property/vocabulary.
A short example on how to label multilingual properties may also be useful.
Component
DocumentationCategory
improvement
Login or
create an account to comment.
Comments
Carlos, I do not understand your proposal. I have not heard of this frequent best practice. Do you have examples?
As to the use of rdfs:label. this is not specified for any class in the current spec (as it is not in DCAT proper). Names are implemented as dct:title. Are you suggesting we make rdfs:label mandatory for all classes?
How would the "default" language for a property/vocabulary be determined? Do you suggest the application profile would specify that language?
See https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html#multilingual-… and http://www.weso.es/app/webroot/MLODPatterns/Labels_without_language_tag… for example. I was pretending to use label here in its general meaning (But wrote rdf:label instead. No surprise you were confused. Ssorry) so this may apply to any property as in the example of the second reference:
Carlos, I note that in http://www.weso.es/app/webroot/MLODPatterns/Labels_without_language_tag.html, right under the Professor example, a warning is included:
Although this practice facilitates SPARQL queries, it is controversial and can be also considered to be an anti-pattern. (my emphasis)
For instance, in which language should the literal without language tag be written? That would depend on the language spoken by the majority of the linked data users. In most cases it could be English but in other contexts it could be quite a different language.
I just don't see how having the DCAT-AP data provider use whatever they want will help interoperability? It seems to me that duplicating the information as in the example that you give puts more requirements on a data provider for little gain.
Yes, as per almost every RDF and Semantic Web issue this is also controversial. As said this is made mainly to facilitate querying in general but may also be considered bad practise by others, it depens on the camp you are. Your are right it doesn't improve interoperability (neither harm it) and I don't think we should encourage any given default language. So maybe it is better to let this go and avoid opening a new can or worms.
OK. I will make no change.