- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 09 Jun 2005 12:05:13 -0500
- To: Jeen Broekstra <jeen@aduna.biz>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On Thu, 2005-06-09 at 14:54 +0200, Jeen Broekstra wrote:
> SPARQL language editor's draft rev 1.379
> http://www.w3.org/2001/sw/DataAccess/rq23/
>
> In section 2.4 the terms 'Pattern Solution', 'Query Solution' and
> 'Basic Graph Pattern' are defined,
>
> The definition of Basic Graph Pattern includes what it means to match
> against a graph. It would be better to create a separate definition
> for this, called 'Graph Pattern Match'. The definition of 'Basic Graph
> Pattern' can then be moved to the start of the section, and in any
> case I think an explicit definition of pattern match, that links graph
> patterns to solutions, is a lot clearer.
>
> Also, the current definition of a match is imprecise. It uses the
> notion 'entails' without specifying what that means. Is that simple
> entailment, RDF(S) entailment, or an entirely different, more loose
> form of entailment? I request instead using the notion of 'subgraph'
> for defining a match.
I was under the impression that simple entailment and subgraph
meant the same thing, but I just double-checked, and not so...
"A subgraph of an RDF graph is a subset of the triples in the graph."
the lemma that relates them also includes the notion of instance...
"The main result for simple RDF inference is:
Interpolation Lemma. S entails a graph E if and only if a subgraph of S
is an instance of E."
-- http://www.w3.org/TR/2004/REC-rdf-mt-20040210/#entail
The difference is observable from an approved*** test
http://www.w3.org/2001/sw/DataAccess/tests/#dawg-triple-pattern-001
input:
:x :p :v1 .
:x :p :v2 .
query:
SELECT *
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.
> Suggested definitions:
>
> Definition: *Basic Graph Pattern*
>
> A /basic graph pattern/ is a set of Triple Patterns.
>
> Definition: *Graph Pattern Match*
>
> A graph pattern /matches/ on a graph G with pattern solution S iff
> S(GP) is a non-empty subgraph of G.
Yes, but... why non-empty? Consider:
SELECT * where {}.
In the case of the empty solution (i.e. empty set of bindings),
S(GP) is just GP, which is empty. We want that to be a match,
right? i.e. ASK where {} always gives yes, right?
Hmm... I think all solutions work at this point, but they all
get projected down to the one solution with no bindings. Yes...
The syntax SELECT * is shorthand for "select all the named variables".
Hmm... that's defined syntactically... is the syntactic case of
no variables allowed by the grammar? No...
'SELECT' ( 'DISTINCT' )? ( ( Var )+ | '*' )
So the semantics of SELECT * in the case of no vars should be
explicitly specified:
The syntax SELECT * is shorthand for "select all the named variables".
In the case no variables are named in the query, the set of variables
is empty.
*** I had to do quite a bit of spelunking to find the record of our
decision to approve this test; I thought the manifests had links
to meeting records, or at least approval dates. It would be nice
if they did, going forward. It would be even nicer if I could
follow links from the HTML test cover page to the meeting records.
We made the relevant decision on 2004-11-30:
ACCEPTED simple test cases (1-4) with the correction of
foaf:knowns=>foaf:knows
Abstained: Kendall (has not read them)
http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0394.html
though we later amended the test case per punctuationSyntax
on 15 March
http://lists.w3.org/Archives/Public/public-rdf-dawg/2005JanMar/0358.html
--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Thursday, 9 June 2005 17:05:16 UTC