Re: subgraph/entailment

Enrico Franconi wrote:
> On 5 Sep 2005, at 21:15, Seaborne, Andy wrote:
> 
>>It seems to me that there are three elements;
>>
>>        query + entailment rules + data
>>
>>One way to associate things is to put a declaration of the  
>>entailment in the query such as:
>>
>>    ENTAILMENT <http://www.w3.org/TR/rdf-mt/#rdf_entail>
>>
>>then the definition of basic pattern match would use "entailment".   
>>This is viewing the allocation of responsibilities as "( query +  
>>entailment ) + data".
>>
>>[[Being aware that systems often do not provide full entailment,  
>>just a set of rules that give finite results and also a possible  
>>rules working group (the one being currently discussed or some  
>>future one) we should be designing for arbitrary rule sets, not  
>>just one of a fixed number.  So ENTAILMENT needs to be something  
>>more general - maybe PARAM]]
> 
> 
> "Entailment" (like PH cleanly explained to the semweb people) is a  
> *semantic* notion. And RDF-MT defines the semantics of 3 different  
> entailment s(simple, RDF, RDFS), but we may have also the well  
> semantically defined OWL-DL/Lite/Full entailment, and possibly we may  
> have other *well semantically defined* entailments defined by the  
> community. Given a semantic definition of entailment, people may  
> implement a sound and/or complete version of it, or it just may  
> implement somenting which does not relate to anything well founded  
> semantically. So, if we go with this option, I suggest to specify  
> ENTAILMENT and COMPLETENESS keywords. ENTAILMENT can be simple, RDF,  
> RDFS, OWL etc (and should be defined with a precise semantics  
> somewhere). COMPLETENESS can be sound, complete, sound-and-complete,  
> incomparable (only coupled with simple entailment).
> Moreover, I believe that according to the charter SPARQL should only  
> consider as normative the cases of simple and RDF with sound-and- 
> complete entailment.
> 
> 
>>There is a different approach : where the entailment capability is  
>>a feature of the service being queried.  This is "query +  
>>( entailment + data )".  The query executes over the entailed graph  
>>formed by the entailment rules and the input data.  Basic pattern  
>>matching is by "subgraph" of the entailed graph.
> 
> 
> No, it does not work in the notable cases where the "entailed" graph  
> is not finite or entailment is not characterised by being a subgraph  
> of 'something'. RDFS with reification is an example of the former,  
> OWL-DL/Lite is an example of the latter. So, we can not really leave  
> "subgraph", even though this is written in the very first paragraph  
> of the charter. By letting "subgraph" in the text, the whole  
> community of OWL, OWL-DL, F-Logic, RDFS with reification will be  
> immediately outside the normave SPARQL, and I personally wouldn't see  
> any use of it.
> 
> 
>>This fits with the service paradigm and the use of the SPARQL  
>>protocol.  It is the service being queried that determines the  
>>entailment capability.  If the application wants a particular  
>>degree of the entailment, it needs to find the right service.  It's  
>>the application responsibility to choose the right service -  
>>services will advertise their capabilities by some web service means.
> 
> 
> It is a nice paradigm. It is up to the service to advertise its  
> capabilities.
> 
> 
>>The current text in rq23 is based on the second paradigm.  Would it  
>>help to add text that explains that the subgraph is the subgraph of  
>>the entailed graph, not the ground data?
> 
> 
> No, as I said it does not work in important cases.

[Dan has already asked for examples]

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

	Andy

> 
> cheers
> --e.

Received on Tuesday, 6 September 2005 11:15:19 UTC