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

On 8 Mar 2010, at 19:20, Dan Connolly wrote:
[snip]
> 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.

	http://www.w3.org/TR/2009/REC-owl2-profiles-20091027/#OWL_2_QL

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.

Consider:
	http://www.comlab.ox.ac.uk/people/ian.horrocks/Publications/download/ 
2009/PeMH09a.pdf
	http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/ 
Vol-477/paper_32.pdf
	http://web.ing.puc.cl/~jperez/talks/eswc07.pdf

Cheers,
Bijan.

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