W3C home > Mailing lists > Public > public-sparql-dev@w3.org > January to March 2010

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

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Mon, 8 Mar 2010 19:59:33 +0000
Message-Id: <56984A90-CD71-472B-8926-BA0A20CA3052@cs.man.ac.uk>
Cc: public-sparql-dev <public-sparql-dev@w3.org>, public-rdfa <public-rdfa@w3.org>
To: Dan Connolly <connolly@w3.org>
On 8 Mar 2010, at 19:20, Dan Connolly wrote:
> I'll have to take another look at why we did forward chaining.
> (the decision happened before I got involved in the project.)

The usual reasons I suspect: it's conceptually and implementationally  
easier (esp, for termination) and perceived query time performance.

For simple stuff like this, it's almost always a bad idea from a cost/ 
benefit perspective as you scale up.

> 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.

I wish we'd ban "backwards" and "forward" chaining as terminology :)

Inverse can be handled by query expansion (backward chaining?  
but...there's no chain!) through OWL QL at least.


For something like OWL RL, I'd use some sort of semi-naive evaluation  
with magic sets (i.e., on-demand, focused forward chaining).

That's a very (academically, at least) conventional choice.


Received on Monday, 8 March 2010 19:59:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:15:50 UTC