- From: Dan Brickley <danbri@danbri.org>
- Date: Fri, 08 May 2009 09:48:47 +0200
- To: Toby A Inkster <tai@g5n.co.uk>
- CC: Peter DeVries <pete.devries@gmail.com>, "public-lod@w3.org" <public-lod@w3.org>
On 8/5/09 09:14, Toby A Inkster wrote: > On 8 May 2009, at 01:30, Peter DeVries wrote: > >> With the except of the predicates speciesHasGallery, galleryHasSpecies. > > In <http://dig.csail.mit.edu/breadcrumbs/node/72> Tim Berners-Lee writes: > >> On the other hand, also one should not encourage people having to >> declare both a property and its inverse, which would simply double the >> number of definitions out there, and give one more axis of arbitrary >> variation in the way information is expressed. >> > > In other words, there isn't really a need to define both > speciesHasGallery *and* galleryHasSpecies. You only need one of them. > I've fallen into the trap of defining inverse properties before and when > it comes to actually working with the data (e.g. performing SPARQL > queries), it ends up complicating things. Yep. Historically, the asymetric nature of the RDF/XML serialization made inverses somewhat necessary, at least when aesthetic considerations were relevant to adoption. In fact some graphs (containing bnodes) couldn't be written in pre-RDFCore RDF/XML, until we added rdf:nodeID to the syntax. Even today, with rev="..." threatened in the HTML5 (re RDFa) world, that issue hasn't quite gone away. This is why FOAF has foaf:depiction and foaf:depicts, fwiw: some data is very image centric, and mentions of a person are an "in passing" matter. Other data is very person centric, and mention of images they're in is also something you do "in passing". So we had a fair amount of pushback when the RDF/XML required a whole separate top level element rather than a sub-element. You're right it makes more work for aggregators though. I've often thought of hacks like canonicalising on load, eg. by chosing the alphabetically 1st one of the two inverses. But then I get to thinking, ... couldn't the SPARQL engine just handle that. So ... what's the state of play w.r.t. SPARQL systems having the smarts to understand OWL inverse properties? Dan
Received on Friday, 8 May 2009 07:49:23 UTC