W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2006

[Fwd: Re: my take on the formal semantics of SPARQL]

From: Fred Zemke <fred.zemke@oracle.com>
Date: Tue, 20 Jun 2006 12:03:30 -0700
Message-ID: <44984682.7000605@oracle.com>
To: public-rdf-dawg@w3.org
Attached is my draft on the formal semantics of SPARQL, circulated
to AndyS, PatH and EricP privately, and now posted to this site.

Please note that the attached paper is not a personal statement of
what the formal semantics should be, nor is it a corporate position of 
It is merely my attempt to clarify what the document currently says.

The following list tries to categorize to what extent this paper addresses
my comments on the current CR.

editorial comments on CR dated 6 april 2006
-- editorial, I may have incidentally fixed some of these but that was
not my objective in this exercise.

Comments on 2.5.1 "General framework" in CR dated 6 April 2006
-- addressed by my paper, section 3.9 "Changes to 2.5.1 General framework"

comment on A.7 "Grammar"
-- not addressed by my paper

comment on CR 10.1 "solution sequences and result forms"
Re: comment on CR 10.1 "solution sequences and result forms"
-- not addressed, I did not get to the section on result forms.

Re: Draft response to: Re: major technical: blank nodes
Comments on 2.1.4 "Syntax for blank nodes" in 6 April 2006 CR
-- addressed by section 3.2 "Changes to 2.1.4 Syntax for blank nodes",
section 3.13 "Changes to 2.8.3 Blank nodes", and various examples of
queries containing blank node identifiers throughout the paper.

Comments on UNION matching (CR 6 Apr 2006)
-- partially addressed by my paper, section 3.19 "Changes to 6.2 UNION 
matching -
formal definition". 
first part, asking for an exampe of a solution with cardinality greater 
than 1:
my paper does not provide such an example
second part is technically addressed, in that my proposal does provide
an answer to the question.  My paper actually gives a different answer
from the one requested by the comment.  I wrote my paper this way because
it seemed like the most literal interpretation of the existing 
I believe both answers are defensible; this is just a matter that needs 
to be
discussed and decided.  As I said, my paper is not staking out a
personal or corporate position.

Comments on 10.1 "Solution sequences and result forms" (CR 6 Apr 2006)
-- not addressed yet (I did not get as far as the result forms in my

Comments on optional pattern matching (CR 6 apr 2006)
-- first part, proposing the word "widen" instead of "add": my
proposal did not touch this.  This is kind of editorial rather than
second part, that the current definition is logically equivalent to
just finding the matches of the first pattern: addressed in my paper
section 3.18 "Changes to 5.4 Optional matching - formal definition"

General problem with cardinality of results in CR 6 April 2006
-- addressed by my paper, which introduces the notion of cardinality
and defines the cardinality of all solutions.

Comments on 2.6 "Multiple Matches" (CR 6 Apr 2006)
-- addressed by my paper, by introducing the notion of cardinality
of a solution (3.5 "New section 2.n, Introduction to graph pattern 
and by defining the cardinality for all possible queries in each section.
The solutions of the empty pattern are specifically addressed in section 
"Changes to 3.3 Value constraints - definition", last few paragraphs.

Comment on 11.2 "filter evaluation" (CR 6 Apr 2006)
-- not addressed

Comments on the proper domain for solutions (CR 6 Apr 2006)
-- addressed by my paper, section 3.3 "changes to 2.1.8 Result descriptions
used in this document", and section 3.5 "New section 2.n, Introduction 
to graph
pattern semantics".

Comments on 9 "Specifying RDF datasets" (CR 6 Apr 2006)
-- handled by my paper in sections 3.21 "specifying RDF datsets"
through 3.24 "Combining FROM and FROM NAMED".

Comment on 4.1 "Group graph patterns" (CR 6 Apr 2006)
-- Addressed by my paper section 3.14 "Changes to 3.3 Value constraints -
definition" at the bottom of page 11, with the paragraph that says
"In terms of the technique to solve simple entailments by binding both 
and blank node identifiers, one must note that the bindings of blank node
identifiers are not global in scope; their scope is always confined to a 
BlockOfTriples."  As I look at this, I think it would be helpful to move 
paragraph to the end of SPARQL 2.5.2 "SPARQL basic graph pattern
matching" for more visibility.

However, I am not personally happy with this outcome; I wrote this
paragraph only because the logic of the document seems to compel it.
The question posed by
the comment is that the entailment definition of basic graph pattern 
implies that the scope of a blank node identifier is a BlockOfTriples, and
consequently one cannot erase curly braces from { ?x <v1> _:a } { ?x 
<v2> _:a },
obtaining  ?x <v1> _:a . ?x <v2> _:a , and have the same semantics, because
the blank node identifier _:a in the unerased group graph pattern represents
two separate existentially quantified variables (in math logic terms) 
it represents a single existentially quantified variable in the pattern 
with no braces. 
In contrast, the existing paragraph in the current specification
that describes the semantics of simple entailment as finding a
function from variables and blank node identifiers to RDF terms can be 
as saying that the blank node identifier _:a must be mapped to the same
RDF term in each subpattern, in which case the erasure is semantically 
In my proposal, I opted to decide in favor of the "two scope"
interpretation since that seems to be implied by the general framework for
entailment and basic graph pattern matching.  However,
I personally think that the ordinary user will find it non-intuitive 
that he cannot
erase the curly braces in the first expression without changing the 
Perhaps the DAWG has already looked at this issue and has an agreed
answer.  If so, that is fine; I am just pointing it out as an issue to be
highlighted in the specification.


Received on Tuesday, 20 June 2006 19:03:56 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:51 UTC