Re: subgraph/entailment

Dan Connolly wrote:
> On Tue, 2005-09-06 at 14:53 +0200, Enrico Franconi wrote:
[snip]
>> 
>> Let me re-consider the example I gave in <<http://lists.w3.org/ 
>> Archives/Public/public-rdf-dawg/2004JulSep/0069>. Allow me to be
>> sloppy in the syntax.
>> 
>> OWL-Lite ontology, expressed in some RDF-based formalism: the class
>> WORKER is declared equivalent to the union of the classes EMPLOYEE
>> and MANAGER: WORKER = EMPLOYEE \or MANAGER
>> 
>> RDF data: Paul rdf:type WORKER Andrea rdf:type WORKER Simon
>> rdf:type EMPLOYEE Caroline rdf:type MANAGER Paul ns:has-friend
>> Andrea Paul ns:has-friend Simon Simon ns:has-friend Andrea Andrea
>> ns:has-friend Caroline
>> 
>> The query: Tell me the workers having a friend which is an
>> employee, which in turn should have a friend which is a manager. 
>> q(X) :- worker(X), has-friend(X,Y), employee(Y), has-friend(Y,Z),
>>  manager(Z).
>> 
>> The answer is the set {Paul}.
>> 
>> There is *no* way to complete the ontology+data in some graph so
>> that the answer to the query would come out from that completion
>> (as a subgraph), since there is reasoning by cases going on.
> 
> 
> Right.
> 
> You seem to be advocating a requirement that SPARQL QL should 
> accomodate various entailment relationships, including at least RDFS
> and OWL-DL.
> 
> Does anybody else find that requirement, or something like it
> appealing?

The way I read this argument is not so much that we actively endorse
OWL-DL reasoning but rather "do not stand in the way". I find that
notion appealing, under the proviso that it does not overly complicate
or obfuscate things in the spec.

 From what I can tell, that is not the case: the rewording is relatively
simple IMHO, and a bit of text to clarify what entailment means can make
it much more explicit that in fact, yes, it is not enough to look at
query+data to determine the outcome of a query, you need to know the
service's reasoning capabilities.

AFAICT Enrico has presented an interesting use case (albeit out of
scope) in favor of changing this. It does not seem to break anything if
we do change it. So pending any counterarguments that show this to break
all sort of things, I'd support a change to make this possible.

[snip]

> I don't understand how the designs would work if we leave the 
> entailment relationship used to satisfy graph pattern matches 
> implementation-defined.

But it is implementation-defined now as well: we need to know how the
service determines the full (closure) graph before we can say if a graph
pattern matches it.

If we change the definition to use entailment, we are, for simple
reasoning and RDF reasoning and whatever kind of reasoning, in the same
situation that we are now: the service advertises it does RDF(S)
reasoning and by that token, we know what set of answers to expect for
certain queries.

Cheers,

Jeen

Received on Tuesday, 6 September 2005 14:26:14 UTC