A question about representing class expressions in RDF.
The paper you referenced today gives an example using a class
expression.
<rdfs:Class rdf:ID="herbivore">
<rdf:type
rdf:resource="http://www.ontoknowledge.org/oil/rdfs-schema/#DefinedClass"/>
<rdfs:subClassOf rdf:resource="#animal"/>
<rdfs:subClassOf>
<oil:NOT>
<oil:hasOperand rdf:resource="#carnivore"/>
</oil:NOT>
</rdfs:subClassOf>
</rdfs:Class>
This will result in model which includes (I leave out unnecessary detail)
([#herbivore], [rdfs:subClassOf], [anon:cexpr])
([anon:cexpr], [rdf:type], [oil:not])
([anon:cexpr], [oil:hasOperand], [#carnivore])
I'm feeling uncomfortable with this, though I'm not sure
I understand exactly why yet. Maybe I can just prod the
discomfort and someone might help me understand.
Part of it is that herbivore is defined to be a subclass of
a class expression. I would have expected it to be a subclass
of the value of that expression.
Further, the class of which herbivore is a subclass is of type
oil:not. Herbivore is also a subclass of oil:not.
Intuitively, that feels very odd.
I've only got a contrived example to illustrate this one. The
class not carnivore is also the conjunction of not (carnivores
with legs) and not (carnivores without legs). This might be modelled
([#herbivore], [rdfs:subClassOf], [anon:cexpr])
([anon:cexpr], [rdf:type], [oil:and])
([anon:cexpr], [oil:hasOperand], [cexpr2])
([anon:cexpr], [oil:hasOperand], [cexpr3])
.
.
.
where cexpr2 and cexpr3 have further statements to define them
as not (carnivores with legs), and not (carnivores without legs)
respectively.
If we combine these two sets of statements, which an RDF processor
is quite free to do as these are all statements about the same
resource [cexpr] then we get:
([#herbivore], [rdfs:subClassOf], [anon:cexpr])
([anon:cexpr], [rdf:type], [oil:not])
([anon:cexpr], [oil:hasOperand], [#carnivore])
([#herbivore], [rdfs:subClassOf], [anon:cexpr])
([anon:cexpr], [rdf:type], [oil:and])
([anon:cexpr], [oil:hasOperand], [cexpr1])
([anon:cexpr], [oil:hasOperand], [cexpr2])
But now, we don't know which operand goes with with which operator.
Basically, I'm concerned that the way class expressions have been
coded in RDF is such that they might be messed up by an RDF
processor which doesn't have the appropriate logic processing.
If expressions were represented as, for example:
([#herbivore], [rdfs:subClassOf], [anon:class])
([anon:cexpr], [oil:hasValue], [anon:class])
([anon:cexpr], [oil:hasOperator], [oil:not])
([anon:cexpr], [oil:hasOperand], [#carnivore])
then expressions could be combined at the RDF level and
things would have their intuitively appealing types.
Brian McBride
HPLabs