Hello all<br><br>I&#39;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 <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>. Among those are dcterms:language and dcterms:subject. I will let the former for a further message, and focus here on the latter.<br>
<br>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<br>
<br>dcterms:subject    rdfs:range    skos:Concept<br><br>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.<br>So I&#39;ve came to the following idea, which I would be happy to discuss here. Since we don&#39;t know how the RDF landscape will evolve, we certainly don&#39;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 :<br>
<br>dcterms:subject    rdfs:range   _:b<br>skos:Concept    rdfs:subClassOf   _:b<br><br>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. <br>
<br>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&#39;t construct this using the interface, and the import is not very successful either ...<br>
<br>Can we proceed from this to something understandable by specification human readers, and tractable by current RDF tools?<br><br>Best<br><br>Bernard<br>