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

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?
]

. . .

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

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.

A hybrid would be to have a protocol argument (or query clause) which is 
influencing the service.  Some might say this is getting away from the 
service-centric protocol.

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

> 
> 
>>This allows conforming implementations which support only simple 
>>matching and perform no inferences, and it allows more advanced 
>>implementations certainly up to RDFS and perhaps OWL lite, and has a 
>>very simple and straightforward extension path to the use of SPARQL 
>>with more sophisticated OWL engines simply by rewriting part of the 
>>text of the spec, without requiring changes to the actual SPARQL 
>>language or protocol.)
> 
> [snip]
> Isn't this the same as what I want above? I'm fine with the current 
> draft only covering RDF (3 sorts of entailment), but would prefer that 
> at least RDFS gets in. However, I see no technical reason not to grab 
> the whole bag.
> 
> 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.

	Andy

 > Ian can speak about Manchester intentions. I believe
> Boris would support at least the core query bits (if not all the XQuery 
> bits). The racer folks have a rather different implementation, I 
> believe, so I don't know what they'd do. I could take an action to 
> investigate this, if the group so desires.
> 
> I'll note that this does meet, afaict, the needs of the OWL community 
> for an ABox query language. TBox ("schema") query (a la the DIG 
> protocol) is left for future work (as is appropriate). In RDF and RDFS, 
> both sorts of query are answered by the virtual graph like approach.
> 
> Cheers,
> Bijan.
> 
>

Received on Monday, 26 September 2005 12:44:20 UTC