Re: Properties in OWL

On 2003-12-16, Xie Guotong uttered:

>rdf:Property is an instance of rdfs:Class. From RDFS specification, we
>know that "The rdfs:domain of rdfs:subClassOf is rdfs:Class. The
>rdfs:range of rdfs:subClassOf is rdfs:Class." Then why we can not use
>rdfs:subClassOf in definition of a Property.

First, because that confuses classes with their instances. We know that
rdf:Property is an instance of rdfs:Class. If you now state that :love is
an instance of rdf:Property, it does *not* follow that :love is an
instance of rdfs:Class. rdfs:subClassOf and rdfs:subPropertyOf do work
this way -- they are transitive -- but rdf:type is different. This means
that you cannot use :love as the object of rdfs:range or rdfs:domain.
(rdf:Property is permissible, of course, since it *is* an rdfs:Class.)

Second, you actually *can* use rdfs:subClassOf to define classes of
properties (as I've done e.g. in
http://www.iki.fi/~decoy/shared/meta/relations), but each of those classes
is still just a class of properties, not *a* property. You cannot in good
conscience use such classes as predicates in statements, for example. You
can also annotate the classes with your own properties all you want, but
that won't buy you *statements* with annotations (which is what you really
want to do). Statements are a different thing, and they cannot be
annotated in RDF.

>	<owl:ObjectProperty rdf:ID="hasRelationship">
>		<rdfs:domain rdf:resource="#Love"/>
>		<rdfs:range rdf:resource="#LoveType"/>
>	</owl:ObjectProperty>

This does not work because #love is not an rdfs:Class, but an
rdf:Property. If you want something like this, you'll have to construct
(by enumeration) an rdfs:Class which has just one member, #love, and use
that with rdfs:domain. However...

>	<People rdf:ID="Tom">
>		<Love rdf:resource="#Jerry">
>			<hasRelationship rdf:resource="#Enemy"/>
>		</Love>
>	</People>

This is doubly confusing. I think I know what you want, but it's simply
undoable in RDF.

It was already noted that in OWL Full (and RDFS), it's possible for a
property to be a class as well. After that you can refer to it in
rdfs:domain and rdfs:range. But this doesn't really help you get what you
want. For example, if you have

rdfs:Class is rdf:type of :love, :Person , :LoveType :.
:Person is rdf:type of :Tom, :Jerry .
:love is rdf:type of :Me .
:LoveType is rdf:type of :Enemy .
rdf:Property is rdf:type of :love, :hasRelationship .
:love rdfs:range :Person ; rdfs:domain :Person .
:hasRelationship rdfs:range :LoveType ; rdfs:domain :love .

RDF's triple model still won't allow you to assert anything like

:Tom :love(which-by-the-way-also :hasRelationship :Enemy .) :Jerry .

What you *can* say is

:Tom :love :Jerry
:Me :hasRelationship :Enemy .

but then the {:hasRelationship :Enemy} part attaches to :Me (which is an
instance of :love), *not* to the first statement with :love as the
predicate. In other words, we now have :Tom related to :Jerry via :love,
:Me is a :love , and :Me has a relationship :Enemy -- :love works as a
relation between people but there's also this thing called :Me which isn't
a relation, but is an instance of something which is an instance of a
relation, with a relation to :Enemy. It makes little sense, ontologically
speaking.

This fact is a basic feature of RDF and you cannot circumvent it without
changing RDF's data model. Only binary, named relations can be expressed
in pure RDF. Higher arity can only be modelled as a bunch of binary
relations. UML, TopicMaps and relational databases are all capable of
higher arity (a UML association is a ternary relation between two classes
and an association class; an RDB table with n>=2 columns represents an
n-ary relation; TopicMaps allow associations between a variable number of
topics, a single association type and a single role for each of the
participants in an association -- it's twice as complicated), so if you
want to map their data models into RDF, all higher arity relations will
have to be broken down somehow.

As Guus noted, the standard way of doing this is to define an intermediate
object, with the participants in your original relation hanging off it. In
this case it would look something like

:Tom :love [:loved :Jerry ; :hasRelationship :Enemy] .

or if we want to be really pedantic and make the representation as regular
and akin to a relational database row as possible, we get

_:a a :LoveRelation ;
    :lover :Tom ;
    :loved :Jerry ;
    :hasRelationship :Enemy .

If we take the TopicMap view and treat this as a free-form association,
and the relations are symmetric as well (who made you think love is a
symmetric relation, btw? ;) with respect to some subset of the
participants, we can do even better:

_:b a :LoveRelation ;
    :lover :Tom ;
    :lover :Jerry ;
    :hasRelationship :Enemy .

<stream-of-consciousness>

A further, different way to express the same thing is to use reification:

:Tom :love :Jerry .
_:c a rdf:Statement ;
    rdf:subject :Tom ;
    rdf:predicate :love ;
    rdf:object :Jerry ;
    :hasRelationship :Enemy .

The last form prompts two amusing observations. First, when we model
higher arity relations using our own terms, we're defining what are
essentially reifications of the relations when viewed from the perspective
of pure RDF. If you look at the first two of the above three forms, it's
easy to see that a pure RDF reasoner won't understand that Tom loves
Jerry, unless it has some extra data at its disposal. In the third, the
reasoner won't understand what enemies have to do with it. (We could also
assert :Tom :hasRelationship :Enemy and make its reification :love :Jerry,
or even switch :Tom and :Jerry in the last. It's all a matter of notation,
but it will change what is asserted in pure RDF and what is not.) It's
much like saying

{:Tom :love :Jerry .} a log:Truth .

in CWM's flavor of N3 -- you have to understand the semantics before you
can figure it out, but after you do, it'll simply assert something.

I think this point constitutes a good reason to settle on a single, shared
vocabulary for the representations of higher arity relations. Even if
current RDF tools/languages do not get the idea of higher arity relations
natively, later tools might. I mean, the representation is common enough.
It's not even wholly inconceivable that someone might want to use
relational database languages to query tables represented in RDF, and
there is certainly a wealth of database and data warehouse related
software which was built for n-ary relations from the start. If there was
a commonly accepted way of representing n-ary relations and/or variable
arity associations, I think that would help in adapting existing tools and
data formats to RDF.

Furthermore, since all the inferences one can make from such associations
can be duplicated at the RDF level with a little bit of predicate logic,
this would also make it a lot easier for RDF reasoners to accommodate
higher arity relations -- you'd just need a single set of axioms to deal
with the rudiments of relations/associations, instead of one for each
variation on the theme.

Second, if we look at RDF reification, it shows pretty clearly what RDF
is: it's a language describing a ternary relation between resources.
Higher arity simply forces us to layer semantics on top of that, but from
the viewpoint of RDF reified triples and represented higher arity
relations seem the same. Just as representations of higher arity relations
are dark as far as pure RDF goes, so are reified triples proper;
subjects/predicates/objects aren't that different from
relation/association members, either. It's just that in a framework which
understands the layering, higher arity is on par with the binary, named
relations RDF can represent natively. In a semantically rich environment
both can become asserted, even if pure RDF doesn't recognize them as such.
For example,

:Tom :love :Jerry .
_:c a rdf:Statement ;
    rdf:subject :Tom ;
    rdf:predicate :love ;
    rdf:object :Jerry ;
    :hasRelationship :Enemy .

is equivalent to

_:c a rdf:Statement ;
    rdf:subject :Tom ;
    rdf:predicate :love ;
    rdf:object :Jerry ;
    :hasRelationship :Enemy ;
    a log:Truth .

and closely parallels the hypothetical

_:c a rdf-ext:Relation ; # rdf-ext:Relation rdfs:subClassOf rdf:Seq .
    rdf:_1 :Tom ;
    rdf:_2 :love ;
    rdf:_3 :Jerry ;
    rdf:_4 :Enemy ;
    a log:Truth .

The symmetry sorta makes me want to argue that all dark triples should be
represented via the standard reification mechanism, and that the latter
should be made a subconstruct of a standard way of representing higher
arity relations. Reification ain't concise, of course, but it works. For
example, contexts (CWM-like or otherwise) should probably be exchanged in
reified form. For example,

{:Tom :love :Jerry .} a log:Truth .

would become

_:d a cwm:Context ;
    cwm:asserts _:e ;
    a log:Truth .

_:e a rdf:Statement ;
    rdf:subject :Tom ;
    rdf:predicate :love ;
    rdf:object :Jerry .

while brevity would probably forbid multiple reifications:

{{:Tom :love :Jerry .} a log:Truth .} a log:Truth .

would get across as

_:f a cwm:Context ;
    cwm:asserts _:g ;
    a log:Truth .

_:g a cwm:Context ;
    cwm:asserts _:h ;
    a log:Truth .

_:h a rdf:Statement ;
    rdf:subject :Tom ;
    rdf:predicate :love ;
    rdf:object :Jerry .

rdf:Statement would then become a subclass of rdf-ext:Relation (which
would be a subclass of rdf-ext:Association), and would have restrictions
on its properties which more general relations wouldn't. If this analogy
is carried just a little bit further, we might also require asserted
higher arity relations/associations to be accompanied by contexts which
explicitly assert them -- after this the different orders of reification
of all rdf-ext:Association's would look the same. And if we reinterpreted
normal RDF assertions as a common shorthand for a reified triple asserted
to be a log:Truth, even the asserted forms would be precisely analogous...

</stream-of-consciousness>
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Tuesday, 16 December 2003 19:07:59 UTC