Re: subgraph/entailment

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.

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?

cheers
--e.

Received on Monday, 5 September 2005 22:20:20 UTC