Re: Inverses of RDF and RDFS predicates

Sure.  The main driver I have run into is when I want to be able to
express a particular set of information about a particular thing as
subject.  This means that I need to be able write my triples with that
thing in the *subject* position of the triple -- not the object
position.

As a concrete example, I want to be able to talk about the members
of a particular class :C.  If I only have rdf:type then I must write:

  :x rdf:type :C .
  :y rdf:type :C .
  :z rdf:type :C .

and the subjects of those statements are :x, :y and :z -- not :C.  If I
could instead write:

  :C rdf:isTypeOf :x .
  :C rdf:isTypeOf :y .
  :C rdf:isTypeOf :z .

then the *subject* of those statements is :C, which is what I want.

There are a couple of reasons for wanting to do this:

1. It allows one to conveniently distinguish those statements from other
statements in which :C appears in the object position of the triple.
This is what is done in computing the Concise Bounded Description:
http://www.w3.org/Submission/CBD/
It is a common approach taken for DESCRIBE queries in SPARQL.
One could reasonably argue that instead you should put those statements
in a separate graph if you wish to distinguish them from statements in
which :C appears as in the object position of the triple.  Indeed, one
could, but that adds complexity.  And the fact is, it is convenient to
be able to do it this way.

2. It allows one to use certain optimizations that are asymmetric.  In
particular, if I represent my RDF triples using a hash table for each
subject, then I can very quickly and easily lookup the members of
class :C by using rdf:isTypeOf as the hash table index.  

For example, in Perl if $s is a hash table reference for triples in
which class :C is the subject, and $p is property rdf:isTypeOf, then I
can easily lookup all members of class :C with the following generic
statement:

  @values = $s->{$p};

I.e., @values would then be a list containing :x, :y and :z.  Note that
this simple line of code works for obtaining the values of multi-valued
properties for triples of *any* subject $s and property $p -- not merely
the :C example.  In contrast, if I could only put :C in the *object*
position of the triple, then I would have to special-case my code to
store the members of a class differently than all other multiple-valued
statements are stored.  To avoid that, I instead made up my own inverse
for rdf:type, which is unfortunate, because its semantics are so
fundamental.

In essence, the ability to use the inverse property gives the author
more flexibility in writing RDF.  This can be helpful both as a
convenience for the author and to simplify downstream code that
processes that RDF.

Let me know if further clarification would help.

Thanks!
David

On Mon, 2012-04-30 at 08:20 -0400, David Wood wrote:
> Hi David,
> 
> Can you please articulate one or more use cases to accompany this
> feature request?  Thanks.
> 
> Regards,
> Dave
> 
> 
> 
> 
> On Apr 29, 2012, at 19:43, David Booth wrote:
> 
> > If this has already been considered and rejected by the WG then please
> > ignore, but . . . 
> > 
> > It would be helpful if the RDF and RDFS specs defined inverses for the
> > properties that they define.  For example, if
> > 
> >  :x  rdf:type  :C .
> > 
> > then one might write:
> > 
> >  :C rdf:isTypeOf :x .
> > 
> > and similarly for other properties.
> > 
> > I have resorted to defining my own inverse properties for some of these,
> > but it seems silly to do so, rather than standardizing them, especially
> > since it wouldn't add anything significant to the semantics.
> > 
> > 
> > -- 
> > David Booth, Ph.D.
> > http://dbooth.org/
> > 
> > Opinions expressed herein are those of the author and do not necessarily
> > reflect those of his employer.
> > 
> > 
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Monday, 30 April 2012 14:41:32 UTC