 |
 |
Oops, hit the "send" button by mistake. Complete message below, please ignore the previous one. As promised, some foolow-up on the rdfs:range of dcterms:language, and RDF representation of languages. First some background. As some of you might be aware, I've explored for quite a while the notion of languages as resources, allowing rich (and of course multilingual) RDF descriptions and use in the linked data universe. One can track this quest back to the OASIS Published Subjects Technical Committee, and the set of "PSI" published in 2003 in this TC, still available at [1]. Some more recent work and exchanges can be found on the ESW Wiki at [2], where with Jakob Voss (in cc) we explored some paths. This is almost 3 years old now, and is certainly worth revisiting. Default any authoritative source I'd eventually, about 2 years ago, set up the model and data found at [3]. Since, the linked data cloud has quite inflated, and many different sources have defined their own URIs for languages. See e.g. [4] for 17 different but equivalent (?) URIs for the French language. Since the main (but not unique) use of such URIs in the linked data universe is to provide values of dcterms:language, and the range of this property is declared as dcterms:LinguisticSystem, all those URIs can be inferred to be instances of this class. Well, maybe once again it's not exactly the intended behavior of DC terms users. Granted, inferring the class of all values of dcterms:language to be dcterms:LinguisticSystem will eventually populate this class with a zoo of more or less trustable resources. I guess that's not what one can expect from a standard recommandation. Should DC recommend an authoritative enumerated list of classes/instances for the Linguistic System class? Should DC recommend even more restrictively the Linguistic System class to be limited to the values in a given skos:ConceptScheme? For example, since LoC is about to deliver a skos:ConceptScheme and a list of skos:Concept for ISO-639-2 codes (according to Rebecca Guenther in cc), one could imagine the range of dcterms language restricted to concepts in such an authoritative Concept Scheme. this can be defined formally using an owl:equivalentClass such as the following (URI of the Concept Scheme is fictional here) dcterms:language rdfs:range dcterms:LinguisticSystem dcterms:LinguisticSystem owl:equivalentClass _:b _:b a owl:Restriction _:b owl:onProperty skos:inScheme _:b owl:allValuesFrom http://id.loc.gov/authorities/iso-639-2/ A side effect, given the domain of skos:inScheme, is that dcterms:LinguisticSystem is a subclass of skos:Concept There are at least three things to consider there - Do we want to see OWL constructs enter DCAM? - Do we want such a restrictive recommendation? - In an open world, the range can be interpreted as above : any value of dcterms:language could be inferred to belong to the said id.loc ConceptScheme. Which brings back to an old question: how to set limits to a ConceptScheme? Thoughts? [1] http://psi.oasis-open.org/geolang/iso639/ [2] http://esw.w3.org/topic/Languages_as_RDF_Resources [3] http://www.lingvoj.org [4] http://sameas.org/html?uri=http%3A%2F%2Fdbpedia.org%2Fresource%2FFrench_language -- Bernard Vatant Senior Consultant Vocabulary & Data Engineering Tel: +33 (0) 971 488 459 Mail: [log in to unmask] ---------------------------------------------------- Mondeca 3, cité Nollez 75018 Paris France Web: http://www.mondeca.com Blog: http://mondeca.wordpress.com ----------------------------------------------------