- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Thu, 29 Sep 2005 15:24:27 -0400
- To: Pat Hayes <phayes@ihmc.us>
- Cc: public-rdf-dawg@w3.org
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 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. 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.
Received on Thursday, 29 September 2005 19:25:05 UTC