- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 29 Sep 2005 16:47:53 -0500
- 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 UTC