 |
 |
Hello all I've had last week private exchanges with Tom Baker about the definition of the range of a certain number of dcterms properties, which are currently let open in the specification document at http://dublincore.org/documents/dcmi-terms/. Among those are dcterms:language and dcterms:subject. I will let the former for a further message, and focus here on the latter. Now that the SKOS specification has been cast in stone by W3C, it seems that instances of skos:Concept should be natural candidates for being values of dcterms:subject, but it is too restrictive to have in the specification something like the following dcterms:subject rdfs:range skos:Concept Nevertheless, it would be a good idea to express that instances of the class skos:Concept are among the ones that can be used as values of dcterms:subject. So I've came to the following idea, which I would be happy to discuss here. Since we don't know how the RDF landscape will evolve, we certainly don't want to specify the range of dcterms:subject beyond the fact that it contains skos:Concept. The way to do this is as following : dcterms:subject rdfs:range _:b skos:Concept rdfs:subClassOf _:b The semantics of rdfs:range and rdfs:subClassOf entails that the blank node _:b is of type rdfs:Class, but the two above statements keep agnostic on the extension or any description of this class, beyond the fact that it is a superclass of skos:Concept. Note that those statements, although apparently perfectly valid and capturing the intended semantics, are not well handled by out-of-the-shelf ontology editors. Having a class declared only as the object of predicates, with no description, and morever no URI, does not make Protégé and Swoop very happy (not tried others). You can't construct this using the interface, and the import is not very successful either ... Can we proceed from this to something understandable by specification human readers, and tractable by current RDF tools? Best Bernard