- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Mon, 8 Mar 2010 19:59:33 +0000
- To: Dan Connolly <connolly@w3.org>
- Cc: public-sparql-dev <public-sparql-dev@w3.org>, public-rdfa <public-rdfa@w3.org>
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