Re: subgraph/entailment

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