Re: subgraph/entailment

Jeen Broekstra wrote:
> 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.


I agree with the objective of "do not stand in the way" - that is a good 
decision criterion. We are at the intersection of several communities - we 
have to reflect all concerns.

The formalisation of SPARQL proposed makes various changes (e.g. no bNodes in 
results) which have implications beyond the subgraph/entailment wording as 
does the use of non-distiguished variables in query patterns - these would 
seem to have interactions with the algebra of the SPARQL operators but I 
haven't got that clear yet. I noted a proposal to change OPTIONAL but I 
haven't worked through whether this is a separable change or linked.

It is not clear to me that we have scoped the changes yet but it is evident 
they extend beyond just s/subgraph/entailment/.  If it were just that, and if 
the previous concerns about the use of "entailment" debate were met, then fine.

	Andy

> 
> [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 17:51:31 UTC