Re: Signalling entailment in queries

On Tue, 2010-07-20 at 17:13 -0400, Gregory Williams wrote:
> On Jul 20, 2010, at 4:28 PM, Sandro Hawke wrote:
> 
> >> SELECT * FROM NAMED <g1>
> >> USING <http://www.w3.org/ns/entailment/RDFS>
> >> WHERE { GRAPH <g1> { ?x rdfs:subClassOf ?y } }
> >> 
> >> or shorter with prefix with a query for the default graph:
> >> 
> >> PREFIX ent: <http://www.w3.org/ns/entailment/>
> >> SELECT * USING ent:RDFS WHERE { ?x rdfs:subClassOf ?y }
> > 
> > Those are nice.   I wonder if we can come up with a common syntax for
> > both the name-graph and default-graph case.    I suppose this could
> > work:
> > 
> >        SELECT * FROM NAMED <g1>
> >        WHERE { GRAPH <g1> USING ent:RDFS { ?x rdfs:subClassOf ?y } }
> 
> Was this meant to include something relating entailment to the default graph? Also, are you suggesting that this syntax would be required of all queries (including those using ent:Simple)? This seems to break backwards compatibility with any existing implementation that supports entailment, though since such support is based on SPARQL 1.0's extension mechanism, I'm not sure if that's as serious a problem as breaking compatibility with plain (simple entailment) implementations.
> 
> I've always considered it a feature that an endpoint could use entailment on the underlying data and the user would use the same query syntax. I'd be very hesitant about a syntax that requires the user to specify an entailment regime to use, especially if the system only supports one entailment regime and will throw an error if you request others. I don't want to be in the position of trying to submit a query by hand and having to guess the supported entailment repeatedly or having to download the service description and pick through it to figure out what entailment regime the endpoint supports.

I think I don't understand how you expect inference to be used in
SPARQL.  Can you give me a quick sketch or two?

For myself, I see a tension between the KR world where there's always
inference going on (where you try to isolate the users from what it
might be), and current SPARQL world where there's no inference, not even
really Simple Entailment (as I understand it); it's just a graph
database.  

I want to make sure the graph-data world sees inference as something
useful and not as something unknown, unpredictable, and to be avoided.
I think the KR folks know that SPARQL doesn't really support them in a
standard way yet, so they can be a lot more flexible.   Of course I
don't want to cause any unnecessary hassles for anyone, etc, too.

One other thought: I think it's always fine for arbitrary processing to
be done under the covers, behind the scenes, in producing "the graph"
that folks see via RDF/XML, SPARQL, or whatever.  In situations where
the entailment just produces a single, bigger graph, that's always an
option.   For situations where entailment does NOT produce a single,
bigger graph, then we need this kind of explicit ENTAILS/USING thing in
the query language.  And it's useful for when clients want control of
it.

As for needing trial-and-error to find the right entailment -- (1)
that's exactly what SD is for, right? and (2) that's why I want
un-parameterized entailment -- for the case where the end point has
exactly one logic it's happy with.

    -- Sandro

Received on Tuesday, 20 July 2010 21:37:58 UTC