Re: subgraph/entailment

On Tue, 2005-09-06 at 14:53 +0200, Enrico Franconi wrote:
> On 6 Sep 2005, at 13:13, Seaborne, Andy wrote:
> >> I don't see why we need to maintain in the document the wording   
> >> "subgraph of"; we could write "entailed by" and say that the type  
> >> of  entailment is decided by the service.
> >> Why not?
> >
> > I am advised, by PatH, that subgraph is sufficient (he did actually  
> > draft this definition in rq23).  In previous discussions in the  
> > working group, using "entails" just begged the question of what  
> > sort of entailment so it left a gap in the definition of SPARQL  
> > that was subject to implementation interpretation.
> 
> Well, PatH is plain wrong.
> 
> 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?

We discussed various forms of an "Additional Semantic Information"
design objective; we didn't actually decide anything one way
or another about it. We just eventually removed it for lack
of support after discussion in Bristol...

"Discussion of objective 4.6 showed support for the ontology editor
use-case, but not much support for any paticular objective."
  http://www.w3.org/2001/sw/DataAccess/ftf3-brs#obj564

Since we didn't actually resolve the matter one way or another,
we don't need new information to reconsider it.

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

Also, this sort of thing seems to be out of scope by charter.

"The principal task of the RDF Data Access Working Group is to gather
requirements and to define an HTTP and/or SOAP-based protocol for
selecting instances of subgraphs from an RDF graph."
 -- http://www.w3.org/2003/12/swa/dawg-charter#scope

and more under
http://www.w3.org/2003/12/swa/dawg-charter#derivedGraphs

>  See my  
> original email for a technical explanation. Quoting the conclusion of  
> that email:
> "The main thing that this simple example shows is that it is  
> impossible to find a unique completion (a unique deductive closure)  
> over which the query can be evaluated. There are *three* incompatible  
> completions, i.e., none of them is minimal (i.e., none of them is  
> included in all the others)."
> 
> So, if you want to allow SPARQL to handle in the future such (simple)  
> cases like this, where you have (simple) RDF-based ontologies  
> together with plain RDF data, you have to drop the notion of subgraph  
> and resort to entailment. Please note that these cases are already  
> well understood, implemented, and tools are available. By limiting  
> SPARQL now, we will tell the ontology community to use another query  
> language for anything than RDF (and possibly RDFS), while SPARQL  
> would be a natural candidate for any RDF-based ontology language  
> (like, e.g., OWL-DL).
> 
> cheers
> --e.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Tuesday, 6 September 2005 13:51:47 UTC