Re: Signalling entailment in queries

It sounds you and I are in agreement on this, except perhaps for my
wanting to allow the entailment regime to be specified down in the graph
pattern, after the GRAPH keyword.   Honestly, I don't understand that
part of SPARQL very well, so let me ask instead: how could you query for
ONLY the RDFS-entailed triples of a graph <g1>?

Here's a rough stab at it:

        SELECT ?s ?p ?o 
        WHERE {
      GRAPH <g1> ENTAILS USING ent:RDFS { ?s ?p ?o }
      MINUS 
      GRAPH <g1> { ?s ?p ?o }
    }

Do you at least see what I'm getting at, and why I want the be able to
signal entailment inside the graph pattern, not just up at the top? 

Also, I really don't see anything non-declarative about this kind of
structuring.  The question raised by the "ENTAILS" line about whether a
particular graph entails (via some regime) a particular graph pattern --
isn't that a perfectly mathematical/logical/declarative question?

     -- Sandro


On Tue, 2010-07-20 at 21:16 -0400, Chimezie Ogbuji wrote:
> Sandro, a few comments below (it seems like there are at least 3 threads in
> the issue we discussed in today's telecon - I'll try to tease them out).
> 
> On 7/20/10 2:22 PM, "Sandro Hawke" <sandro@w3.org> wrote:
> > The basic problem I have is this: I think people will be very confused
> > if SPARQL end points start to quietly do inference.
> 
> I can sympathize with this and (if I understand
> 
> > This confusion will
> > result in software doing the wrong thing, with possibly serious results.
> > Some of the blame will, rightly, land on "SPARQL inference".
> > Alternatively, for fear of this, public end points will just not do
> > inference.
> 
> I can completely sympathize with this concern and think Souri as well as
> others echo this concern as well.  Hopefully, I think we are better informed
> about why this is important than we were when we chose not to support the
> ability for the user to specify the entailment regime in the query and if we
> are willing to revisit the conversation about LET after deciding it was out
> of scope (for instance), then we should consider the same with this issue if
> there is critical mass.
> 
> At a minimum, a query should be able to specify (by entailment regime URI)
> the entailment regime to use.  I can imagine scenarios where - despite the
> fact that the service indicates a particular regime for its data -  the user
> might prefer a different regime for one reason or another.  Since we support
> an order of precedence in determining which dataset is used for a query
> (either it is specified in the query, or in the protocol) I don't see why we
> can't do the same for the entailment regime to use in determining answers
> beyond simple graph matching via a simple extension to the syntax, some
> backward compatible pragmas, or some other light weight mechanism.
> 
> > What we've got so far is the idea that folks should look at the service
> > description.   I think this is probably too "quiet".
> 
> Not just too quiet but it also (unnecessarily) handicaps how entailment is
> used in SPARQL.
> 
> > ..snip .. 
> > Listening to
> > folks in the meeting talk about it, I thought of this:
> > 
> >         SELECT * FROM NAMED <g1>
> >         WHERE { GRAPH <g1> ENTAILS { ?x rdfs:subClassOf ?y } }
> > 
> > Here, the system making the query is explicitly asking for inference, so
> > no harm can be done by the end-point suddenly turning on inference, as
> > long as it still allows querying of the pre-inference graph.
> 
> So this is where I think your issues may be tangled up.  If issue (1) is the
> need to indicate an entailment regime to use for answers to a query, then
> this example also includes an issue (2).  I'm not sure what to call it, but
> it seems you are interested in explicitly relating the scoping graph (which
> exists in the dataset) with another graph that it entails (rather than
> simply indicating an appropriate entailment regime alone).
> 
> This seems to be a procedural interpretation of entailment and entailment is
> a purely declarative thing - i.e., it says *what* should follow from what
> you have and some axioms, but not *how* it is calculated (and there are a
> number of ways it can be calculated).
> 
> By requiring that entailment be 'written down' in this way it seems that you
> are assuming a particular reasoning strategy (forward-chaining) which is
> completely independent from the entailments.
> 
> So, I agree that the query should be able to indicate an entailment regime,
> but I don't agree with the mechanism you suggest above, which seems to make
> assumptions about entailment that are counter-intuitive to their declarative
> nature.  The query should instead be.
> 
> SELECT * FROM NAMED <g1>
> USING <http://www.w3.org/ns/entailment/RDFS>
> WHERE { GRAPH <g1> { ?x rdfs:subClassOf ?y } }
> 
> >..snip...
> > In this design, the kind of entailment would be specified in the SD.
> 
> I think the query should be able to specify the kind of entailment (as well
> as the SD) and that should be all it needs to specify.  So if you think of
> querying as the evaluation of a function, the entailment regime is just
> another parameter:
> 
> queryEvalation(query, dataset = ..specified in SD.., entailmentRegime =
> ..specified in SD..)
> 
> Where the default dataset and entailment regime are those specified in the
> SD if they aren't given in the arguments to the query.
>  
> > It's tempting to also allow parameterization of the entailment regime,
> > perhaps like this:
> >  
> >     PREFIX ent <http://www.w3.org/ns/entailment/>
> >         SELECT * FROM NAMED <g1>
> >         WHERE { GRAPH <g1> ENTAILS BY ent:RDFS { ?x
> >         rdfs:subClassOf ?y } }
> 
> This is what I prefer, but with the difference I mentioned above.
>  
> > I understand this parameterization is similar to the out-of-scope
> > "Parameterized Inference" feature [1], but perhaps if it's really as
> > simple as this, it's okay to do anyway.
> 
> I think it is rather simple.  We have every thing in place to simply take
> advantage of a straight forward in-query syntax to indicate the entailment
> regime. 
> 
> > Finally, I wanted to thank folks for reminding me of the incorrectness
> > of thinking of the entailments of a graph as another graph.  Under
> > entailment regime E, graph G will entail graphs G0, G1, ... Gn, rather
> > than a single graph GE.  In many simple cases, the merge of G0...Gn is
> > also entailed and can be used as the single graph-of-all-entailments,
> 
> It still does seem that conceptually thinking of *having* a single graph of
> all entailments (a procedural interpretation of entailment) is a motivation
> underlying your suggestions.
> 
> -- Chime
> 
> 
> ===================================
> 
> P Please consider the environment before printing this e-mail
> 
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S.News & World Report (2009).  
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> 
> 
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
> 
>

Received on Wednesday, 21 July 2010 01:49:26 UTC