Re: comments on section 12 (and a little more)

First pass - editorial.

Only specific comments mentioned here because it seems that many of the 
changes have already been done.

Pat Hayes wrote:
> Overall comment (important).
> 
> There is a disconnect between the ideas of 
> dataset and graph, which I think needs to be 
> fixed. Section 8 discusses datasets in great 
> detail with many examples, but it nowhere 
> actually defines explicitly which RDF graph is 
> determined to be the one that BGPs are required 
> to match against. Section 12.3.2 defines matching 
> for BGPs, but speaks of matching to a dataset 
> (mia culpa). Section 12.5 finally introduces and 
> uses the terminology "active graph", but it does 
> not formally define this notion or say how it is 
> computed. (See detailed comments of 12.5 below) 
> In any case, it is far too late in the document 
> for this idea to be defined.
> 
> "Active graph" is a basic concept which should be 
> defined in section 8, which should give clear 
> criteria for how to determine it given a query 
> and a dataset. Then 12.3.2 should use this term 
> when defining BGP matching, and the references in 
> 12.3.2 and 12.5 should have internal links to the 
> definition in section 8.
> 
> --------
> Comments on Section 12
> 
> "query as as string" -> "query as a string"
> "abstract query comprises operators" -> "abstract query comprising operators"

Already done in the version I'm looking at.

> "this can then be evaluated"  Should we only say 
> 'can' here? Suggest "this is then evaluated".
> 
> "This section defines the correct behavior for 
> evaluation of graph patterns and solution 
> modifiers, given a query string and an RDF 
> dataset.  "

"""
This section defines the correct behavior for evaluation of graph patterns and 
solution modifiers, given a query string and an RDF dataset. It does not imply 
a SPARQL implementation must use the process defined here.
"""

> 
> But you just said we would cover the process 
> starting with the abstract syntax, not the 
> string. Correct one of these statements.
> 
> This whole process seems awfully complicated and 
> unmotivated. Can you give some guidelines on what 
> the differences are between abstract syntax and 
> abstract query and SPARQL algebra (?) . This 
> whole topic of converting form one form to 
> another isn't mentioned again until 12.2, and 
> none of the intervening definitions in 12.1 seem 
> to be relevant to it.

12.1 puts all the basic definitions in one place.

How about:
1/ Move BGP defn to 12.1
2/ Remove 12.1.5 (Graph patterns) as they are not needed (the definitions go 
via the algebra operations),
3/ Remove current "SPARQL Query" (more emphasis on the query string removes 
the need for this)
4/ "SPARQL abstract query" becomes "SPARQL Query"

Swapping 12.1. and 12.2 is possible but 12.2 uses some of the defined terms 
like triple pattern.

Not swapped for the moment.

> 
> In fact, I would suggest switching sections 12.1 
> and 12.2, and maybe merging 12.1 with 12.3.
> 
> 12.1.1
> 
> "IRIs, a subset of RDF URI References that omits 
> spaces." Is that *really* the definition of an 
> IRI? Suggest provide a link to the IRI 
> publication.

Added ref to [RFC3987]

> 
> The link on the word 'updated' is to 
> http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref. 
> Is this the most appropriate link?

Isn't this where "RDF URI Reference" is defined in the RDF core specs?  It's 
not in MT at all.

(err - MT uses "URI references" which is different again yet says they are 
resolved by that point. Rat hole.)

> 
> First definition: et -> Let
> 
> 12.1.2
> "each <ui> is an IRI. Each <ui> is distinct."  -> 
> "each  <ui> is a distinct IRI."
> 
> The notation used here seems odd to me. Usually, 
> ordered pairs are indicated using <> as brackets. 
> Why do you need them round the IRI names? Wouldnt 
> it make sense to write this in this way
> "An RDF dataset is a set:
> {G, <u1, G1>, ...}..."

URIs/IRIs are written with <> as delimiters.  These <> are being used to 
indicate IRIs.  Conflict of conventions :-)

> 
> 12.1.3
> "...is a member of an infinite set V which is disjoint from RDF-T. "
> 
> You don't give a definition for BGP (its a set of 
> triple patterns, yes?) I suggest it should be 
> between 12.1.4 and 12.1.5. Right now there is no 
> connection between the material up to 12.1.4 and 
> the stuff starting at 12.1.5. Also, the internal 
> link 
> http://www.w3.org/2001/sw/DataAccess/rq23/rq25.html#rBasicGraphPattern
> is broken.

BGP defined in 12.3.1 - moved to 12.1.4.

> 
> 12.1.5 seems a bit bare. Where do we find out 
> more about these various kinds of pattern?  Can 
> you provide links? (As you do in 12.1.7)

Section removed as no longer needed.  It all goes via algebra expressions in 
the definition of SPARQL.

> 
> 12.1.6. (Question about terminology. Is *every* 
> such mapping a "solution" mapping? Or only the 
> ones which actually are solutions? Right now we 
> say the first, which seems a bit odd to me, 
> because a solution mapping might not be a 
> solution. (Later. Was it me who suggested this 
> terminology? If I did, mia culpa again.))
> 
> No need to say from V to T since these are globally fixed.
> -> "A solution mapping É  is a partial function É  : V -> T"

Done.

> 
> The note about multisets seems out of place here, 
> since we havnt mentioned matching graph patterns 
> yet, and nothing has been said about there being 
> multiple answers. Suggest moving this to 12.2, 
> and omitting the last sentence "It is 
> described..." which reads like an implementation 
> suggestion and seems out of place. Readers will 
> likely know what a bag is in any case, right?

Moved but retained the definition as set+cardinality function.  That is what a 
  a multiset is - and we use that form in the work later on so worth 
mentioning it.

http://planetmath.org/encyclopedia/Multiset.html
http://en.wikipedia.org/wiki/Multiset

> 
> 12.1.7 What is a solution sequence, that we can 
> have a modifier of it? Is there a missing 
> definition of 'solution sequence' ?

Added but all it says is a "solution sequence" is a sequence of solutions.

"A solution sequence is a list of solutions, possibly unordered."

Better suggestions?

(The main article of wikipedia for Sequence is the mathematical definition and 
all other uses are qualified in someway !!).

Got to stop here for now,

	Andy

Received on Monday, 19 March 2007 13:46:55 UTC