- From: Sandro Hawke <sandro@w3.org>
- Date: Tue, 20 Jul 2010 17:37:48 -0400
- To: Gregory Williams <greg@evilfunhouse.com>
- Cc: Birte Glimm <birte.glimm@comlab.ox.ac.uk>, SPARQL Working Group <public-rdf-dawg@w3.org>
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