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: Bijan Parsia <bparsia@isr.umd.edu>
Date: Thu, 29 Sep 2005 08:57:02 -0400
Message-Id: <e5fe69f7e38040e980d3b89bf7ba2516@isr.umd.edu>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
To: Steve Harris <S.W.Harris@ecs.soton.ac.uk>

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 

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!

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:36 UTC