W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2005

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

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 29 Sep 2005 16:47:53 -0500
Message-Id: <p0623090fbf6204389cf6@[10.100.0.2]>
To: Bijan Parsia <bparsia@isr.umd.edu>
Cc: public-rdf-dawg@w3.org

>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) 
http://www.askMe.com/thisgraph/entail=RDFS&answer=ordered
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?

Pat

>I do not believe that proposal was ever ruled *out of scope*, so I 
>believe it is in scope for the working group.
>
>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 Thursday, 29 September 2005 21:48:12 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT