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

On Sep 29, 2005, at 4:13 AM, Steve Harris wrote:

> On Tue, Sep 27, 2005 at 11:03:15 -0400, Bijan Parsia wrote:
>>> In earlier WG discussions, DanC point out that a graph and its RDFS
>>> closure are not the same and would be expected to have different URIs
>>> as graphs to query.
>>
>> That's another reasoner for me to prefer an entailment view. The graph
>> queried under rdf entailment and rdfs entailment *are* the same,
>> although the answers they give are different. I have no desire to have
>> a URI for the closures of any kind of any document.
>
> I'm absolutly not qualified to talk about the logical issues here, but
> from a practical point of view, both as a user and developer its very
> useful to be able to distinguish a graph as fetched from the web and 
> any
> entailments from it.

I agree....but I don't know if you agree with how this affects the 
protocol design. I have a preference for "one graph/dataset; several 
parameters" requestable by the client and controlled by the server. 
This is in part because I think there is a strong natural bias in 
documents toward a particular entailment relation based on their 
logical vocabulary (e.g., if you use rdf:subClassOf, the natural thing 
to do is publish it "under" RDFS entailment). Using other modes 
(including told-bnode redundancy) seem to be special (and useful) 
deviations (e.g., when you are interested in the syntax of the graph 
rather than strictly its informational content; or if the server can't 
handle that level of entailment in sufficient time, etc.).

This means that this information has to be recoverable somehow. E.g., I 
suspect that there should be a metadata field in the results format 
where I can stuff such information (perhaps this only matters in the 
SOAP binding where the initiator of the request and the receiver of the 
results might be very different; but then we have soap headers to help 
out...)

I like to minimize the number of exchanges necessary to achieve 
reasonably common effects.

Also, I don't *mind* having URIs for all these things so long as their 
are reasonably "generatable", e.g., like the various XPointer schemes 
floating about. Just having bare, coined uris and having to do a 
whoooooole lotta discovery sees rather burdensome.

> Pre-SPARQL versions of 3store did not seperate them (as far as the user
> could tell), and it caused confusion.

Now it does? Excellent!

Cheers,
Bijan.

Received on Thursday, 29 September 2005 12:57:08 UTC