W3C home > Mailing lists > Public > public-rdfa@w3.org > March 2010

Re: rev and the costs of inverses/aliases in SPARQL

From: Dan Connolly <connolly@w3.org>
Date: Mon, 08 Mar 2010 13:20:54 -0600
To: Bijan Parsia <bparsia@cs.man.ac.uk>
Cc: public-sparql-dev <public-sparql-dev@w3.org>, public-rdfa <public-rdfa@w3.org>
Message-ID: <1268076054.3952.6047.camel@pav.lan>
On Mon, 2010-03-08 at 18:47 +0000, Bijan Parsia wrote:
> On 8 Mar 2010, at 17:36, Dan Connolly wrote:
> > One project I worked on used forward chaining in virtuoso, so
> > it increased the storage costs (doubled the storage for statements
> > with properties that have inverses)...
> You could normalize them at load time...that's basically what you do  
> with rev (which isn't a true inverse operator since it doesn't appear  
> in any class expressions...it's "just syntax"; well, having two  
> spellings is "just syntax" as well; you could always add magic syntax  
> inside rel).
> > I'm not sure about the
> > impact on query run time,
> I'd be surprised if it were non-negligible....well, ok, if you really  
> put both directions in manually and then union them back...eww.
> But, ahem, may I suggest that this is clearly not a remotely optimal,  
> or even sensible, approach :)

I'll have to take another look at why we did forward chaining.
(the decision happened before I got involved in the project.)

In #swig today, I see:

<MacTed> Virtuoso now handles owl:equivalentClass,
owl:equivalentProperty, owl:inverseOf, owl:SymmetricProperty, and
owl:TransitiveProperty ... and possibly some I'm forgetting off the top
of my head
<MacTed> cost-based optimizer works over both SQL and SPARQL

<MacTed> yep.  backward-chaining.  Virtuoso's preference.
<MacTed> forward-chaining (materializing inferred triples) is supported
but discouraged.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Monday, 8 March 2010 19:20:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:45 UTC