Using SKOS RDF vocabulary in RDFS

We have been looking into using the SKOS RDF vocabulary 
( with RDFS-enabled tools, and 
have found some anomalies that make it difficult to understand how SKOS 
is intended to be used.  In particular, we have loaded the vocabulary 
into SWOOP, Protege and RDF Gateway.  When we first did this, we thought 
we must have found bugs in these tools, because of the strange results 
that we got.  But when we looked into core.rdf, it seems that these 
things are part of SKOS itself.

Here's an example. 

 From core.rdf, we see:
  <rdf:Property rdf:ID="subjectIndicator">
    <rdfs:label xml:lang="en">subject indicator</rdfs:label>
    <rdfs:domain rdf:resource="&skos;Concept"/>
    <rdfs:range rdf:resource="&foaf;Document"/>

that is, subjectIndicator has Concept in its domain.

Now, in the definition of Concept we see

  <rdfs:Class rdf:ID="Concept">
    <rdfs:label xml:lang="en">Concept</rdfs:label>

which means that Concept appears as the subject of a triple whose 
predicate is subjectIndicator.

Now, the rules of RDFS (e.g., imply that Concept rdf:type 
Concept.  Now, there is nothing logically wrong with this (well, except 
in an OWL-DL sense), but it is a bit counter-intuitive. 

Furthermore, since subjectIndicator is quite commonly used in core.rdf 
(in fact, it is used for every class and property definition), this 
implies that every property and every class in SKOS is an instance of 

SWOOP is the most widely available tool that shows this; when you set 
SWOOP to "Pellet" reasoning, you find that all the properties are now 
instances (as well). *

Why is this important?  After all, RDFS doesn't disallow properties from 
beings instances as well (or Classes, for that matter).  But if you are 
writing an application that will do something, say, with all the 
concepts (e.g., provide a list of them for a user to select from in an 
annotation), the resulting list (including properties and classes) is 
not very understandable. 


*We tried this with Protege as well, but the OWL plugin reported errors 
while reading it, so we weren't able to make any further headway.

Received on Sunday, 1 May 2005 19:11:58 UTC