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

>On Sep 26, 2005, at 8:41 AM, Seaborne, Andy wrote:
>
>>Bijan Parsia wrote:
>>>On Sep 22, 2005, at 6:03 PM, Pat Hayes wrote:
>>. . .
>>>>2a. The question arose: if SPARQL can be used (perhaps in the 
>>>>future, but let us look ahead) with various notions of 
>>>>entailment, should a query be able, or be required, to specify 
>>>>the kind of entailment intended? Although this was discussed only 
>>>>briefly, there was a consensus that it would be acceptable for 
>>>>the entailment in use to be specified as part of the 'service', 
>>>>identified by the URI currently used to name the target graph.
>>>While I think that is a reasonable point in the design space, I 
>>>talk with Jim and he flat out rejected it. So there's still play 
>>>here. (I myself don't think it's the best design but do think it's 
>>>workable.)
>>
>>[Bijan-
>>I'm assuming that Jim's issue is wanting to query the same graph 
>>under different semantics as discussed below.  If there other 
>>concerns, could you say what they are?

Better still, could Jim say what they are?

>>]
>
>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. This is rather important, as this is an 
enabling point of approval. To do anything that goes beyond using the 
URI (endpoint) to specify entailment requires major and IMO 
unworkable changes to the overall design. 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.

>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. Bear in mind that we would be requiring *all* conforming 
SPARQL engines to offer these intricacies, which seems to me (I speak 
here personally, not with the voice of the WG) to be quite 
inappropriate, given the SPARQL charter.

Pat

>
>>>>We are indebted to Enrico for making this point vividly clear 
>>>>with the 'little-house' (aka 'worker') example.
>>>>
>>>>(I would suggest, and this is purely my own personal view, that 
>>>>we can adopt a compromise here, in which SPARQL in its current 
>>>>release will refer to simple entailment; the issue is pointed 
>>>>out; the actual spec. refers to virtual graphs identified by 
>>>>URIs, and refers to the RDF and RDFS closure lemmas; and the 
>>>>possibility of using URIs to identify services which offer other 
>>>>kinds of entailment is pointed out as a future extension path.
>>>Hmm. Doesn't this bias things against Jim's desire for one and the 
>>>same URI identified graph to be queried under different semantics? 
>>>In other words, does this close discussion on that protocol design 
>>>decision before alternatives have been considered?
>>
>>This seems to be a different matter.
>>
>>The protocol paradigm is service-centric, not graph-centric (this 
>>was after some debate so I think we have considered it, may be not 
>>exactly as described).
>
>Yes, sorry. I mean that how I, a server, offer different semantics 
>for the graphs I query over.
>
>>It is the combination of graph (by parameter) + service + query 
>>that gives the results.  Querying the same graph under different 
>>semantics is asking a different service unless we change the 
>>service-centric emphasis of the protocol.
>
>Yes, so the only question I see at the moment is whether one wants 
>to force a distinct call (to a distinct endpoint) in the following 
>situations:
>
>A server knows it can reasonably handle with OWL-DL Ontologies A and 
>B, but it can't deal with C and D except with RDFS (even though they 
>species validate as OWL-DL). I cannot query over these services with 
>the maximal semantics the server handles in one call. (I have to 
>query C and D on the rdfs endpoint and A and B on the OWL-DL 
>endpoint).
>
>Actually, all the other situations are variants of this. I don't 
>know if this is what jim has in mind.
>
>>A hybrid would be to have a protocol argument (or query clause) 
>>which is influencing the service.
>
>Yes. So I might like on a per query basis the pattern of semantics 
>for graphs offered by the service.
>
>>  Some might say this is getting away from the service-centric protocol.
>
>Doesn't seem more so than the various graph selection operations.
>
>>I would not like to enumerate all the possible values of this 
>>argument (mentioning some well-known cases is OK) in rq23 or the 
>>protocol doc because of uses of subsets of OWL/RDFS entailment for 
>>tuned performance.  [This would also for rules].
>
>I would like distinguished designators for the current set of 
>defined entailment relations with extensbility (for new variants). 
>There are certainly a billion subsets and extensions of OWL alone 
>which people might want to indicate. However, I think having the 
>gross distinctions of: simple, rdf, rdfs, owl-lite, owl-dl, and 
>owl-full is a useful base, matches the existing specs, and maps to 
>behavior of e.g., webont (for their test cases) and software 
>(species validators). (Swoop, for example distinguishes species 
>validation (values supported by the w3c) and expressivity (wihich is 
>more fine grained)).
>[snip]
>>>There is a charter prohibition, but I would propose altering that 
>>>as it all comes out so nice.
>>>One question worth answering is whether there will be implementor 
>>>support at this time. I believe I can pledge that Pellet will 
>>>support SPARQL over OWL DL. Indeed, if Jena's SPARQL 
>>>implementation separates the graph matching and the rest of the 
>>>algebra, I believe it's a tiny hookup for us.
>>
>>Indeed it does.
>>
>>ARQ works over graphs so you can have your own graph implementation 
>>but here it would be better to override the ARQ implementation of 
>>basic pattern matching to add your own.  This has been done for 
>>writing queries to legacy SQL databases so has been tried out.
>
>Great!
>
>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 Tuesday, 27 September 2005 04:42:16 UTC