Answer to: semantics are poorly specified

The main points of the comment <http://lists.w3.org/Archives/Public/ 
public-rdf-dawg-comments/2006Jan/0063.html> are as follows:

1) Semantics is not clearly stated, mainly because the three main  
components -- discursive text, formal definitions, and BNF  
specification -- are not well integrated among themselves. Section 7,  
"RDF dataset", is a notable example.

Unfortunately, I don't find that we fully addressed this point. We  
are on track with fixing the semantics of the language, as BGP are in  
place and algebra is on its way. We'll fix the  formal definitions as  
well as the surrounding informal explanation; however, there is no  
precise linking with the BNF syntax. Do we have to answer that the  
BNF is there just for the benefit checking the actual syntax? I think  
that we should try to lay down the connections between the parse tree  
of a query and its semantics, otherwise we wont be sure that there  
aren't any "grey areas".

2) Sections 2.4 and 2.5 are not as clear as they could be.

Answer: These sections have been completely rewritten in the latest  
version of the document (see http://www.w3.org/2001/sw/DataAccess/ 
rq23/). Major effort has been spent in clarifying the basics of  
SPARQL as detailed in these two sections.

3) Appendix D, "Collected formal definitions", is missing from the  
main document.

Answer: "Appendix D" is a link to an external automatically generated  
document containing just the formal definitions of the main document.
( For the WG: Is it going to be included in the main document once  
reached the stability)

I'll wait for feedback from the WG before answering to the author;  
especially w.r.t. the first part.

Cheers,
--sergio

On 12 Jan 2006 13:34:41 -0800, Fred Zemke <fred.zemke@oracle.com> wrote:

> The semantics are poorly specified.  In general terms, the  
> specification
> can be characterized as consisting of three disjoint (though  
> interleaved)
> styles of presentation: the EBNF in Appendix A, the formal definitions
> enclosed in boxes, and the discursive text outside the boxes.  The
> problem is that there is almost no attempt to relate these three  
> things
> to one another.  Instead, it is left to the reader to deduce that
> a particular term in the informal English refers to the same thing
> as a particular syntactic element, and that these things correlate  
> with
> particular symbols in the formal semantics.
>
> For example, section 7, "RDF dataset".
> It seems that the second definition, RDF dataset graph pattern, is
> intended to be the formal semantic definition of the GRAPH clause
> presented in section 8, "Querying the dataset".  However, there is
> no text connecting this definition with that syntax (nor, indeed,  
> is there
> any explicit connection between that section and rule [23]
> GraphGraphPattern,
> aside from the keyword GRAPH in the examples) .  What is needed
> is some definition that starts with syntax (the rules of Appendix A)
> and maps the syntactic
> elements to the symbols you use in the definition.  For example, there
> is no
> text connecting the formal symbol { G, (<u1>, G1), ... } with the
> FROM clause.  Presumably what happens is that the RDF merge of all
> graphs specified by rule [10] DefaultGraphClause is G,
> and for each rule [11] NamedGraphClause, the IRI becomes a <ui> and
> the graph that it identifies is Gi.
>
> As a somewhat related problem, the discursive sections are not always
> carefully written.  For example, section 2.4 "Pattern solutions".
> It says "How a particular graph pattern matches a dataset is described
> for each kind of graph pattern below".  However, the following  
> sections
> are not careful to rigorously define the word "match".  In particular,
> section 2.5 "Basic graph pattern" seems to take "match" as a primitive
> concept.  Thus we read in that section "For a basic graph pattern
> to match some dataset, there must be a solution where each of the
> triple patterns matches the dataset with that solution".  In this  
> sentence,
> the first occurrence of "match" is defined in terms of the second
> occurrence, but the second occurrence is not defined.
> It seems that the most primitive concept is a match of a triple  
> pattern.
> I think the definition is "If S is a pattern solution, then S is a
> match for a triple pattern TP if S(TP) is a member of the dataset."
> This refers the definition to the mathematically understood primitive
> notion of membership.  After defining a match of a triple pattern,
> the definition of a match of a basic graph pattern (ie, a set of
> triple patterns) is "If S is a pattern solution, then S is a match
> for a basic graph pattern BGP if, for every triple pattern TP in BGP,
> S is a match for TP."  And so forth, all varieties of match can be
> formally defined.
>
> I will also note here that Appendix D, "Collected formal definitions",
> is missing, which makes it hard for me to assure myself that the
> formal definitions are complete and correct.  It certainly seems  
> that the
> formal definitions for "match" are incomplete.
>
> Fred Zemke

Received on Sunday, 29 January 2006 14:33:26 UTC