Re: Inverses of RDF and RDFS predicates

Hi Richard,

I largely agree with you (and David Wood), and will expand on that in a
separate message.  But I wanted to clarify a few things below, because I
think you may have slightly misunderstood the use case that I was
expressing . . . 

On Thu, 2012-05-03 at 12:05 +0100, Richard Cyganiak wrote:
> Hi David,
> 
> (This is a personal response, not necessarily representing WG opinion.)
> 
> I think that introducing inverse properties would be a bad idea here,
> because it leads to an unnecessary proliferation of redundant
> vocabulary terms and makes querying and generally working with the
> data much harder.
> 
> Avoiding “incoming” arcs to an RDF node, and wanting only having
> “outgoing” arcs, is a common reflex in the community. This is very
> unfortunate IMO. Both kinds of arcs are equally important and
> essential. 

But that depends on the application.  Some applications will want both
ingoing and outgoing arcs for all subjects, some will not.  The
usefulness that I was trying to illustrate was the ability to
*distinguish* between the ingoing and outgoing arcs, so that one could
conveniently be selective in expressing which ones were wanted.  In
other words, if one only wants certain arcs, then *those* arcs could be
expressed as outgoing arcs *instead* of expressing them as incoming
arcs.  That way the application can easily ask the store for all
*outgoing* arcs for a subject, and it would get on the arcs that were
wanted.

> We need *graphs* not trees.
> 
> I'm not convinced by the reasons you state for introducing inverses.
> See below.
> 
> On 30 Apr 2012, at 15:40, David Booth wrote:
> > 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/
> 
> The answer is right in this document: Symmetric CBDs.
> 
> > It is a common approach taken for DESCRIBE queries in SPARQL.
> 
> Generally the DESCRIBE behaviour can be configured in the RDF store to SCBDs.

That's fine if that's what you want, but my point was that the
asymmetric behavior is useful also.

> 
> > 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.
> 
> Why would you want to put them into a different graph? 

As a way to distinguish one set of arcs (the outgoing arcs) from another
set of arcs (the incoming arcs).

> Just put them into the same graph.
> 
> > 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.  
> 
> Use two hash tables, one for incoming and one for outgoing triples.
> Now you can represent nodes in a graph, rather than just nodes in a
> tree.

Yes, that can certainly be done.  But now you have two hash tables to
deal with, and you've doubled your indexes.  That was part of my point.

David

> 
> > In essence, the ability to use the inverse property gives the author
> > more flexibility in writing RDF.  
> 
> It gives flexibility for RDF authors, but creates headaches for users
> of the data, and asks vocabulary maintainers to do lots of redundant
> extra work.
> 
> All the best,
> Richard
> 
> 
> 
> 
> > 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.
> > 
> > 
> 
> 
> 

-- 
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 Thursday, 3 May 2012 15:57:25 UTC