Re: Protocol specification of entailment level (was Re: The Entailment bit (was Re: thoughts from Tuesday telecon))

On Sep 29, 2005, at 5:47 PM, Pat Hayes wrote:

>> Not replying point by point.
> But replying here point by point.


>> Why I am in favor of 3Store having multiple entailment modes?
>> 	Because I think people want to and have reason to interact with data 
>> under various semantics. The most obvious pair is "told/asserted" vs. 
>> "with 'maximal' entailment". 3Store used to support only the latter.
> Fine, except that 'told/asserted' isn't ANY kind of entailment. If it 
> were, this whole debate would never have got off the ground. And that 
> is the core issue here: why must query results be described *only* in 
> terms of entailment?

Fine, but even if grant this, I want to know what the query results 
should be in the presence of the standardized set of semantics at the 

>> Does this mean I'm on the same side as Pat?
>> 	Well, on something, yes. However, I, at the moment, think that 
>> having a per query settable bit
> bit? We already need maybe 3 bits just to cover the semantics in the 
> standards.

I was being loose. "Bit" as in "bit of the message".

>> for the entailment "level" to evaluate a request with is a reasonable 
>> and perhaps preferable design. I think it's perfectly service centric 
>> (though I don't see why servicecentricness is a virtue, or even 
>> exactly what it means). I prefer it, at the moment, to a randomly 
>> coined uri
> Just for clarification, nobody has ever suggested 'random coining' of 
> URIs. I had in mind that services might use (and publish) their own 
> conventions, for example (emulating Google) 
> Since web services like Google already do this stuff very 
> successfully, why do we need to legislate how to do it?

There is a question as to whether standardized methods would be useful 
and worth doing as part of the protocol. I tend to think it is worth 
doing. Others clearly don't. I think it enhances interoperabilty.

One reason is that it's not really a user defined set of capabilities, 
but a common set of capabilities. There will also be userdefined ones 
and a desire to "hide" some things behind other urls..but *that's* 
already available. What isn't is a common convention.

>> per dataset/graph-entailment level pair, though, I need to think 
>> through all aspects of the design first. From this point of view, I'm 
>> not on the same side as Pat.
>> What did you mean by "natural level" of entailment?
>> 	All I meant is that there seem to be a wide range of cases where the 
>> publisher knows what semantics was intended. I do not mean that it is 
>> automatically determinable from examining the document, just that 
>> people write with an intended semantic (however fuzzily) in mind.
> Assume this is all true (and Im sure it is) how does it relate to 
> anything technical?

You denied it. I mobilized it in favor of a certain way of doing things 
I think is more natural. We are arguing taste at this point, but I 
don't believe my taste threatens to break what is already in the 
protocol. I share with steve a preferene for it to be in the query 
language but that *would* break our current spec. I might suggest it if 
we have to go to last call again anyway.

>> I think it is also a common use case to want to inspect the syntax of 
>> a document even when one is concerned with the "proper" informational 
>> content. This suggests to me that having two uris for that graph 
>> isn't really what's wanted instead of a parameterized query 
>> operation.
> But WHY does it suggest that to you?

Because it's like two views of "the same" thing. Because in Swoop I 
turn on an off different reasonrs that modify the display of *the* 
ontology (or rdf document) rather than loading a new thing with a 
distinct URL.

> Is it because of an implicit (intuitive) notion that a URI ought to 
> resolve to something document-like?

Not really. I just think that much of the time, here, they do and that 
it's reasonable to think that way.

> Let me suggest in response that you need to be able to think about RDF 
> graphs more loosely, and let the syntax go a little. There could be 
> graphs which are never realized as documents,


> virtual graphs,

What's a virtual graph?

> graphs which exist only for a fraction of a second, etc..

Even if so? If the graph at a uri is changing rapidely (e.g., it's a 
streaming datastore over a sensor), do two uris help me? That 
seems a STRONGER argument for one URI/two views.

>> The possibility of having "entailment negotiation" (esp. in the face 
>> of timeouts) is also appealing to me.
> Supporting such stuff seems way beyond the chartered tasks for SPARQL, 
> IMO.

How so? Point me to the part of the charter which says, "The protocol 
must eschew all aspects of negotiation" or the like.

Also, *that* part could be future work, but I'd like to lay the 
groundwork now.

>> Don't these amount to the same thing in some sense?
>> 	Yes, with somewhat different affordances.
>> Why did you mention "URI construction" and is it in the scope of this 
>> WG?
>> 	Bryan Thompson had an early protocol proposal (which he, with 
>> kendall and myself developed a bit further) for "server side 
>> xpointer" which would make it fairly easy to build URIs (or rather 
>> URIRefs) that were essentially parameterizable. This seems to have 
>> the best of both worlds.
> Agreed (provisionally), but this seems compatible with the current 
> design, no? That is, nothing rules this out?

Nope, don't think so. In fact, I think my view is a proper superset of 
the "one semantics per URI" view, since you could always advert only 
one semantics for each URI.

Again, I'm not entirely settled. I've not put forth a proposal. I've 
just articulated a part of the design space that has some attractive 
features, I think. First thing is to get the query results definition 


Received on Thursday, 29 September 2005 22:05:53 UTC