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
