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).

Ah, this is maybe where we differ. I strongly believe that this isn't 
going to be workable, and would not be desirable even if it could be 
made to work. It can't work for the OWLs because there isn't anything 
in the vocabulary that can distinguish between OWL-Lite, OWL-DL and 
OWL-Full. More practically, I don't think that the use of a piece of 
OWL vocabulary should be obliged to be interpreted as a sign that any 
of the OWL semantic frameworks are being assumed. There are many 
interesting things happening in what might be called the sub-OWL 
area, eg the intensional semantics for OWL being developed by Herman 
ter Horst. These use the OWL vocabulary, but interpret it slightly 
differently (and in my view more usefully). These will all be 
OWL-valid, of course, which is really all that matters for 
interoperability: but they can nevertheless fail to conform strictly 
to the OWL semantics (and hence OWL entailments) in the specs. As an 
actual use case, I would cite the use of owl:functionalProperty in 
FOAF, in what is otherwise pure RDFS. It would be crazy to presume, 
from this use alone, that FOAF queries were obliged to be understood 
using the entire OWL entailment conditions.

>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.).

The evidence so far seems to indicate that these 'deviations' are 
more widely used than the published notions of OWL entailment. They 
are not merely pragmatic: things like detecting and distinguishing 
bnode matches from URI matches can often be used to discover 
important information about the actual content stored in the RDF 
graph, if one knows a little about the data storage formats being 
used. Even if these formats and conventions go beyond the published 
RDF model theory, as they may well do, it is important to emphasize 
that such usage of RDF does not in itself violate the RDF spec. OWL 
is not the only possible semantic extension of RDF: there can be 
others in use which are incompatible with OWL. Seen from an OWLish 
perspective, RDF might seem like a rather odd first step along a 
yellow brick road to higher logical things, but seen from its own 
perspective it is more like a simple general-purpose tool that can be 
used for all kinds of purposes, OWL being one of them.

>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.

I think we all wish for this.

>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.

That seems like an orthogonal issue to the one being discussed, and 
not the business of this WG.

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

What?!!? Surely, Bijan, the ability to distinguish a graph from its 
logical closure is exactly what you have been arguing so vehemently 
AGAINST? Bear in mind that they have exactly the same entailments, so 
if queries are based on entailment then these difference will be 
invisible. So why are you cheering a decision to make them visible? 
Are we on the same side after all?

Pat

>
>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 19:06:49 UTC