Re: subgraph/entailment

On Sep 19, 2005, at 5:32 PM, Pat Hayes wrote:

>> On Sep 19, 2005, at 2:55 PM, Enrico Franconi wrote:
>>>> From: Pat Hayes <>
>>>> 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?

Perhaps not.

>  BTW, have you tried talking to people who are familiar with SQL  
> querying?

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

Well, some variant of that, yes. Typically, a query Q succeeds against  
a graph G when G X-entails a substitution of Q (that substitution is  
the binding).

I think that for SPARQL a kind of two level approach is in the offing,  
where graph patterns and solutions are specified in terms of entailment  
and then the rest of SPARQL is treated like an alegbra on the results  
sets. Since results sets are more like tables and the things sparql can  
do are pretty expressive (and a tad hairy) I'm feeling pretty  
comfortable with this approach.

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

I am somewhat concerned with people who are manipulating OWL documents  
in various ways.

>  But then, surely you should not expect otherwise: SPARQL is an RDF  
> query language, not an OWL query language.

I don't find that satisfactory. I'm prepared for their to be limits,  
but I would like the extensions to be straightforward where reasonable  
and not artifical when impossible. Just as RDF (sorta almost) plays the  
role of a "data", "assetional", "abox" language for OWL-DL, so too  
SPARQL should be able to query that aspect of OWL-DL documents and be  
correct wrt the OWL-DL semantics.

Even if the working group isn't taking the complete specification of  
this in this round, every discussion I've had with members (except this  
email exchange) has indicated that it was on the list for the next  
round and that SPARQL is intended to be foward compatible.

Point for point is perhaps not the happiest at this point as it gets  
tiresome for onlookers. I've read your message and am prepared to  
discuss it tomorrow.

There is one additional bit I wish to respond to in this reply though.
>> 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.

And yet you go on to talk such talk.

> For myself, apart from the small group of logic police,

I hope that you will be more judicious with your words while you are  

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

Pat, I have users and I have colleagues and I have collaborators. I  
represent an organization that pays fees to be a member in the W3C and  
supports semantic web work with an enormous amount of time and effort  
at many levels. We have priorities and mandates and desires. My job is  
to represent them in this group. When I talk to implementors like Boris  
Motik (Kaon2) whose system I am expected to evaluate for my users, and  
he, a very capable query person, is baffled and repelled by the  
specification, my job is harder. I don't *care* if that opens us up for  
sneering. Let whomever wants to sneer, sneer and jeer and leer away.

> (See for example  
> for a typical  
> attitude,

Too bad that that article is a complete and total joke. I do not mean  
the attitude, I mean the content.

> or for a more  
> enthusiastic one. Both among the first 20 hits on 'semantic web' .)

Er...yes? This is "I like RDF and dislike RDF/XML and had trouble  
getting into RDF because of RDF/XML". That's fine. I don't see it as  
anti-more expressiveness. Oh I see. He doesn't mention inference et al.  

In either case, neither of those people pay me or fund my organization.  
The ones that do are interested in inference, often to Jim's dismay ;)  
(He got over can too!)

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

For a set of people who are reasonably to be considered both interested  
and capable (in a general way) and who are likely to implemented  
interesting query languages, the current spec produces a lot of  
confusion. Enrico is a good example. I'm another (I had to have a  
conversation or two with you!) Evren Sirin is another (I just explained  
the virtual graph bit to him).

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

That's not my point. My point if you are going to *not* do that, it  
would be helpful to be *clearer* about how the current approach works  
and how it is, or is not, going to apply to more expressive languages.

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

If you had had time to go through the thread, you would have seen me  
articulate this point in detail a couple of times I believe, e.g.,: 

Now you can counter wtih SQL SQL SQL, but it's not like Enrico or I or  
lots of similar folks are unfamilar with SQL (and the relational model,  
calculus, and algebra).

(In that message I think I overstate the confusingness a bit, partially  
because I was in a middle of a long thread with Enrico who, after all,  
has spent a lot of time in this space and wasn't catching what I was  
saying. However, if we can smooth this out with some text so such  
people *aren't* confused, then I think it is worth the effort.)

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

Don't worry, be happy, pop another tab.


Received on Tuesday, 20 September 2005 02:36:09 UTC