Re: ready to exit CR?

Fred,

Fred Zemke wrote:
> Andy Seaborne wrote
>> 
>> Maybe we could see where we are on the road to CR exit.
>> 
> 
> I am strongly opposed to exiting CR because of the issues
> I have raised with the specification, which I regard as serious
> and fatal.

I didn't advocate we should exit CR.  Kendall asked for comments on the
agenda; I suggested that we see where we are in the process to exiting CR.  CR 
exit requires a number of deliverables.  There are things that need to be done 
as well as working on the query language spec.

> In my view the purpose of a specification is to specify.
> Examples do not constitute a normative specification. 
> The document (both the CR and rq24) fails to specify in the following
> important ways:
> 
> 1. There is no bridge from the concrete syntax to the abstract
> semantics.  Consequently the document can not actually be said
> to specify the language at all, except that A.7 "Grammar" really
> does specify the syntax.

See rq24 - there is the start of this.  There are grammar rules quoted in the 
main section of the document.  I am open to feedback on this approach or to 
suggestions of an alternative approach.

> 
> 2. The scope of blank node identifiers has not been stated clearly.
> The consensus in an email thread appears to be that the scope
> is a FilteredBasicGraphPattern (rule [21]) but the definitions in
> 2.5.1 "General framework" do not support this and need to be
> rewritten.

Blank node identifiers are syntactic and there is a section devoted to them in 
rq24:

3.1.4 Syntax for Blank Nodes

"""
Blank node labels are written as "_:a" for a blank node with label "a" and the 
label is scoped to the basic graph pattern.
"""

Mention of blank node labels would not appear in the section about the 
semantics.  There are a couple of places where the phrase "blank node names" 
appears but there is consensus from the original contributors of that material 
that it should "blank nodes".

http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html#BGPgeneral

> 
> 3. The abstract semantics does not pay attention to the critical
> issue of the domain of solutions.  Consequently the notion of
> "solution" is not well-defined.
> 
> 4. The preceding problems are perhaps at their worst in the
> case of optional graph patterns.  The grammar does not indicate
> what the first operand of a graph pattern is,  and there is no
 > discursive text on the subject either.  Thus there is no bridge from
 > the syntax to the abstract semantics.

See

http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0175.html

As there has been no comment on this message, I have been taking it that we 
are in agreement as per your previous statement that anything you don't reply 
to, you agree to.  [On a personal note, I would find it easier if you did 
reply with agreement because I don't know how long the timeout should be.]

> As for the abstract semantics,
> the definition of OPT(A,B) appears to reduce to just solving A
> with no role for B. 

"""
S is a solution of optional graph pattern if S is a pattern solution of A and 
of B otherwise if S is a solution to A, but not to A and B.
"""

That involves B.  Logically, the truth value of OPT(A,B) only depends on A; 
the solutions associated with the matching do depend on B.

> 5. It is not clear whether UNION requires an implementation to
> count duplicate solutions precisely, which I personally advocate,
> though I could live with the alternative of stating explicitly that
> it is implementation-defined or -dependent how many duplicates
> are returned.

Counting is postponed so not stating it is quite reasonable.  Not stating 
anything is making it an implementation issue.

One of the requirements for CR is implementation feedback.  It would be an 
option to include that as a question in the implementation report.

If we did specify it, I would prefer counted duplicate solutions, which is 
what ARQ implements (switching to set semantics would be quite easy (ojne line 
of code to add a duplicate supression wrapper IIRC) - it costs memory but not 
streaming in terms of needing to surpress duplicates somewhere).  However, 
it's all built on BGP matching so that is the primary issue.

As a general point, this is the first SPARQL specification; we have a charter, 
we have a WG members, and we have a timescale; so we do the best we can within 
those bounds.  That will mean that not all possible features get done.  There 
can be another working group.

> 
> Fred
> 

	Andy

Received on Tuesday, 1 August 2006 09:51:52 UTC