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

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

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 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 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. 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. The 
possibility of having "entailment negotiation" (esp. in the face of 
timeouts) is also appealing to me.

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 
	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. I do not believe that proposal was ever ruled *out of scope*, 
so I believe it is in scope for the working group.


Received on Thursday, 29 September 2005 19:25:05 UTC