W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > September 2005

Re: [Fwd: Comments on SPARQL] (entailment, soundness, completeness)

From: Dan Connolly <connolly@w3.org>
Date: Fri, 09 Sep 2005 16:59:16 -0500
To: Ian Horrocks <horrocks@cs.man.ac.uk>, public-rdf-dawg-comments@w3.org
Message-Id: <1126303156.4430.350.camel@dirk>

On Fri, 2005-09-09 at 15:39 -0500, Dan Connolly wrote:
> Copying this to public-rdf-dawg comments for tracking purposes.
> Follow-up discussion should happen there...
> email message attachment, "Forwarded message - Comments on SPARQL"
> On Fri, 2005-09-09 at 15:39 -0500, Dan Connolly wrote:
> > Two comments/questions:
> > 
> > Firstly, I strongly support the suggestion to define query answers in 
> > terms of entailment rather than subgraph. Using an entailment based 
> > definition has numerous advantages, and no disadvantages that I can 
> > see.
> > 
> > Entailment based definition:
> > 
> > - is widely used and very well understood
> > - is concise, clear and unambiguous
> > - builds on existing semantic definitions
> > - can deal with a wide variety of languages, including RDF, RDFS, OWL, 
> > SWRL and FOL, simply by referring to the existing entailment semantics 
> > for the relevant language

I'm not clear on what you mean by that. Do you mean that there's one
definition of entailment that SPARQL can use that simultaneously
accommodates RDF, RDF, OWL, SWRL, and FOL?

I understand that each of those languages has a clear and unambiguous
definition of entailment, but I don't understand how to apply all of
them to SPARQL.

Are you suggesting that SPARQL should have some parameterized version
of entailment? I can imagine how that might work, though I'm not
aware of much implementation experience with designs like that.

Bijan provided a quick review of various relevant implementations...

OWL editors and their underlying toolkits (triples or other)

I have only begun to look into those.

If you have any particular designs to recommend, please let us know.

> > Subgraph based definition:
> > 
> > - is not widely used, not well understood, and not *known* to work at 
> > all (at least not for more expressive languages)
> > - is verbose, obfuscated (it seems capable of confusing even expert 
> > logicians), and may even be ambiguous
> > - ignores existing semantic definitions
> > - cannot easily deal with more expressive languages, and may even be 
> > incapable of doing so
> > 
> > Can someone please explain to me why the subgraph based definition has 
> > been preferred?

The WG as a whole hasn't expressed a preference directly, but in
drafting the definitions and considering simple test cases, the
details of subgraph seemed to work out and the details of entailment
seemed not to. For example, here's part of one message from 09 Jun 2005

The difference is observable from an approved*** test

 :x :p :v1 .
 :x :p :v2 .

WHERE { :x ?p ?q . }

By the simple-entailment definition, there are solutions that bind
?p to _:foo, but there are no such results in the test results.
I suppose it's possible that the spec could prune the results
down to the ones in the test suite some other way, but I can't
think of any other straightforward way just now.
 -- Re: Restructure definition of Basic Graph Pattern and pattern match (sec 2.4)

> > Secondly, IMHO, the minimum requirement for a query language standard 
> > is that, independently of the features and capabilities of any given 
> > implementation, it should define what would constitute a sound and 
> > complete answer for a given language, dataset and query. It is not at 
> > all clear that, in its current form, SPARQL satisfies this requirement.
> >
> > Am I missing something?

I don't believe you are missing anything; the WG has not looked
very deeply at such a requirement. Yours is one of several
recent comment that asks that we do so.

Due to the volume of comments received, it may be some weeks before
we have a reply in substance. Please stand by.

Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
Received on Friday, 9 September 2005 21:59:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:21 UTC