- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Mon, 19 Sep 2005 15:15:27 -0400
- To: Enrico Franconi <franconi@inf.unibz.it>
- Cc: Dan Connolly <connolly@w3.org>, Ian Horrocks <horrocks@cs.man.ac.uk>, "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, Pat Hayes <phayes@ihmc.us>, public-rdf-dawg-comments@w3.org
On Sep 19, 2005, at 2:55 PM, Enrico Franconi wrote: >> From: Pat Hayes <phayes@ihmc.us> >> >> If one wishes to offer a query-answering service that does check >> entailments, then the appropriate thing to do within the SPARQL >> framework is to declare that one is matching queries against a >> 'virtual graph' which is some kind of logical closure of the graph, >> rather than the graph itself. But these are different graphs, note. > > Sure, we clearly understand that. Though it took some work to get there. I've been testing this account with various people who are actively concerned with querying, albeit typically against more expressive languages such as OWL. *Serious* confusion ensues. >> SPARQL does not require queries to be evaluated only against graphs >> which are closed under some notion of entailment: it is >> entailment-neutral (except, as noted above, regarding simple >> entailment, which follows in effect as a structural consequence of >> the very act of matching itself.) This is not an error or an >> omission, I would emphasize, but a design decision. > > Fine, we want just give a nice semantics to it, which characterises > the current design decisions, but that also scales up to have general > entailment based query answering. Our proposal accommodates the > current "syntactic-driven" behaviour of SPARQL *and* an entailment > based one. [snip] And so, I hope, give some evidence that it is entailment-neutral in fact and in practice. I have users who would like to use SPARQL to query documents understood with "told", simple, RDF, RDFS, and OWL semantics. The implementors I've talked with of query engines for the more expressive languages have been rather at a loss. While I understand that the charter rules out specification of the more expressive bits (though, frankly, I could junk that; I don't see that it's a *useful* constraint), I believe the design *intent* was that SPARQL could be straightforwardly extended (or "used", if it's truly entailment neutral) to these more expressive languages. Thus, we do need to be clear that the design *does* work for those languages and that it's reasonably clear to the community that it *does* work. I don't feel that the current spec does that. An entailment based account could help (and has the advantage of being familiar to the implementors I've chatted with for those more expressive languages). A virtual graph approach, suitably described, might work as well for these audience. But the current document is *not* adequate on this front. I trust we can come up with language or a document which will be adequate and happy all around! Oh dear, perhaps that was *too* much medication :) Cheers, Bijan.
Received on Monday, 19 September 2005 19:18:51 UTC