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

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

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

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

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

>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? Is it because of an implicit 
(intuitive) notion that a URI ought to resolve to something 
document-like? 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, graphs which exist only for a fraction of a second, etc..

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

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


>I do not believe that proposal was ever ruled *out of scope*, so I 
>believe it is in scope for the working group.

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

Received on Thursday, 29 September 2005 21:48:12 UTC