- From: David Wood <david@3roundstones.com>
- Date: Thu, 3 May 2012 07:27:36 -0400
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: David Booth <david@dbooth.org>, public-rdf-comments@w3.org
Hi David, This is also a personal response, since the WG has not yet discussed the issue. We have implemented support for reverse link traversal in Callimachus specifically to avoid the need for materializing additional triples. Other systems have similar functionality. Thus, I am in agreement with Richard that the *standardization* of inverse predicates may be detrimental in that it may constitute an encouragement for materialization over other traversal mechanisms. In my opinion, those mechanisms are best left to implementors. Regards, Dave On May 3, 2012, at 07:05, 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. 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. > >> 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? 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. > >> 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. >> >> >
Received on Thursday, 3 May 2012 11:28:06 UTC