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

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