Re: subgraph/entailment

Enrico Franconi wrote:
> 
> 1) On 2 Sep 2005, at 12:58, Seaborne, Andy wrote
> <http://www.w3.org/mid/43183071.1070508@hp.com>:
> 
>  > = subgraph / entailment
>  >
>  > The RDF MT defines three kinds of entailment - simple, RDF and RDFS.
>  > RDF and RDFS are examples of vocabulary entailment.
>  >
>  > SPARQL basic patterns are defined to match by subgraph - the graph
>  > being matched against contains RDF and can have some level of
>  > entailment applied or not.  Your first example misses this because
>  > you show the data, without a declaration of the entailment to be
>  > applied.  The SPARQL query can execute against a simple entailed
>  > version or RDF entailed version (or "zero entailment").
> 
> OK, then it is necessary to change:
> 
> s/subgraph of/entailed by/ in defn of basic pattern
> (we have noticed that this change has been done already twice...)
> 
> and somewhere there should be the ability to declare the type of
> entailment (simple, RDF, RDFS - as defined in RDF-MT).
> 
> ======

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


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.

The local case has one other situation where the entailment capability is 
determined by the environment, not the query nor the data graph.  Again, it is 
not a feature of the query language.


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.


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?

	Andy


<much useful material removed/>

Received on Monday, 5 September 2005 19:15:44 UTC