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.
