Re: The Entailment bit (was Re: thoughts from Tuesday telecon)

On Sep 27, 2005, at 12:41 AM, Pat Hayes wrote:

>> On Sep 26, 2005, at 8:41 AM, Seaborne, Andy wrote:
[snip]
>> As I understand it, the idea is that reasoning level is set on per 
>> endpoint basis. Endpoints provide access to 1 or more number of 
>> graphs (i.e., a dataset). Each endpoint has its own URI. If I 
>> understand the proposal, this would necessitate a distinct endpoint 
>> for each semantics offered by the service and the semantics must 
>> be(?) uniform over the dataset.
>
> That was my understanding from the informal telecon last week, and my 
> understanding also was that this idea was approved by all parties, 
> albeit in rather a rush.

Well, at least twice I tried to make clear that  I regarded the 
specifying what the query answers were relative to a particular 
semantics issue as distinct from the issue about how to specify which 
semantics were in force for a particular query. I did agree that the 
endpoint-per-semantics was a workable solution, but didn't want commit 
to endorsing it.

>  This is rather important, as this is an enabling point of approval.

Really?

> To do anything that goes beyond using the URI (endpoint) to specify 
> entailment requires major and IMO unworkable changes to the overall 
> design.

I don't see that. More complex examples, yes. But, for example, it's 
hard to see why a flag in the request indicated preferred level of 
entailment is a major design change with deep ramification. For current 
implementations, it might be as little as rejecting all queries that do 
not flag a certain particular value.

> The conclusion, reached tentatively at the telecon, that a useful 
> acceptable compromise was possible depended, in my understanding, on 
> the universal acceptance of the entailment-specified-by-URI 
> arrangement. To do otherwise would require the SPARQL protocol to be 
> re-designed, which is not acceptable at this stage.

My recollection of the protocol discussions I sat in on (e.g., at the 
tech plenary) was that the issue of specifying the semantics queried 
against was punted for the moment (e.g., waiting for SADDL). That just 
means that the protocol is unfinished overall, but we knew that. Again, 
it's orthoganal.

>> I don't think that's the most useful only configuration (e.g., I 
>> might want the background graph to be with RDFS semantics containing 
>> info about the possible semantics offered by component graphs; a 
>> different issue would be being willing to drop down in the presence 
>> of a timeout, e.g., I accept OWL-DL results, then RDFS but prefer 
>> OWL-DL (similarly to connegging); if you timeout or are in danger of 
>> timing out with OWL-DL, just send the RDFS).
>
> I do not think that these kind of complexities justify the effort of 
> providing for standards to specify them; and no use cases have been 
> suggested.

FWIW, I was just explicating another point in the design space. As for 
use cases, I don't see that I couldn't come up with several if it came 
to that. (Though, take the timeout like thing...are *use* cases 
appropriate? The point is to avoid certain client code complexity. 
E.g., send a request to the OWL-DL endpoint get a timeout, resend the 
request to the RDFS or DL-LIte endpoint. I don't know how common this 
would be, but it's not implausible that it'd be reasonably common and 
important where it was.

> Bear in mind that we would be requiring *all* conforming SPARQL 
> engines to offer these intricacies,

Only if they offered the full range of semantics. (This is a wrinkle 
that was also discussed way back went. You can't assume that if a 
service offers RDFS, that it also offers only RDF or simple etc. See 
3Store as an example. In description of the service, you need to 
specify the specify levels.) Even then, it is just inspecting a list of 
uris (or other tokens) with a simple resolution mechanism.

> which seems to me (I speak here personally, not with the voice of the 
> WG) to be quite inappropriate, given the SPARQL charter.

Now the more elaborate design I mentioned (where you can turn semantics 
off and on for individual graphs per request) would be more natural in 
the query language but still possible in the protocol. But I wasn't 
proposing that, just articulating some possibilities (there).

Cheers,
Bijan.

Received on Tuesday, 27 September 2005 05:21:45 UTC