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.

Hmm, I wonder why. This has seemed kind of obvious since early in the 
entire RDF process, surely? BTW, have you tried talking to people who 
are familiar with SQL querying?

>>>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.

Well, if y'all can do so, good luck. It has to be able to handle 
things like the constraints on literals, remember. Right now Im 
sceptical, but lets see what you guys come up with. I shouldn't 
comment further until Ive seen the proposal, I guess.

>>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 ones who want it to have OWL semantics have a lot more work to 
do. BTW, I take it that when you say "use with X semantics" what you 
mean is that you want it to be the case that a query Q succeeds 
against a graph G when G X-entails Q, right? Because if all you mean 
is that G might contain some X content, and SPARQL will reproduce 
this content at least to the extent of not distorting it, then I 
would claim that SPARQL works correctly right now for all these 
languages. (Well, let me modify this. We could do a better job on RDF 
collections, maybe. But that isnt the point being argued in these 
threads.) Of course, if you want to use SPARQL to query an OWL-RDF 
graph, then you had better know OWL-RDF syntax and conventions, and 
be prepared to do some OWL-savvy work on the answers you get back in 
order to have them make OWL sense. But then, surely you should not 
expect otherwise: SPARQL is an RDF query language, not an OWL query 
language.

>The implementors I've talked with of query engines for the more 
>expressive languages have been rather at a loss.

If they want to have an engine perform OWL inferences, it is up to 
them to decide how to do this and also how to interface their design 
with SPARQL. (One thing they should not do, by the way, is expect 
SPARQL disjunction to map into OWL or logical disjunction: it 
doesn't, and for any reasonably expressive language it never will, 
for the reasons illustrated by Enrico's little-house example. There 
is no way to convey a logical disjunction across a query interface in 
RDF, other than encoding it explicitly in some RDF-encoded syntax: 
and then the behavior of the query engine has to be hostage to the 
semantics of the encoded language, not that of RDF. In other words, 
that goes outside SPARQL.)

>  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)

Ah, there we differ. I see it as central. The primary purpose of 
SPARQL is to help get RDF deployed in real applications. Most of the 
people working on these applications will not be using more 
expressive languages in any depth, and are not interested in 
inference or entailment. If SPARQL gets used for a few years and then 
a completely different protocol is developed for 'logical' querying, 
I will be quite happy: it will have done its job. If SPARQL is warped 
or delayed just to provide it with a logically clean extension path, 
that warping or delay is doing far more harm than good, IMO.

>  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.

I would like to know what this phrase "works for ... language" means. 
SPARQL is an RDF query language, or if you prefer, an RDF-graph query 
language. Why would one ask it to 'work' for some other language? 
What does it mean for a query language for language A to 'work for' 
language B?

>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

Look, we can all swap anecdotes about people who we have chatted 
with. Such talk is pointless. For myself, apart from the small group 
of logic police, whose objections I can script in advance, *nobody* I 
have chatted with has evinced the slightest interest in any formal 
semantic issues at all. They tend to regard such matters as arcane 
academic baloney. (See for example 
http://www.shirky.com/writings/semantic_syllogism.html for a typical 
attitude, or http://www.disobey.com/detergent/2002/sw123/ for a more 
enthusiastic one. Both among the first 20 hits on 'semantic web' .)

>). A virtual graph approach, suitably described, might work as well 
>for these audience. But the current document is *not* adequate on 
>this front.

I wish to know why, and in what regard, it is inadequate. All the 
objections I have read so far have been to the effect that there MUST 
be a semantic story which makes querying into a species of 
entailment-checking: and this view is, IMO, both wrong and (in the 
SPARQL context) wrong-headed. It is false for SQL, probably the most 
widely used query language ever. So I am not very inclined to agree 
with a simple assertion that the current approach is 'not adequate', 
no matter how much emphasis it is given, unless an argument is given 
to say what exactly is inadequate about it.

>  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 :)

I don't feel overmedicated yet, personally.  :-)

Pat

>
>Cheers,
>Bijan.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Monday, 19 September 2005 21:33:14 UTC