Re: Review of Query 1.1

A couple of short replies below...
Birte

>> 1.1 Document Outline
>> ...This section of the document, *S*ection 1, ...
>
> It's not the start of a sentence.

It is still typically written upper case and you do that for sections
6, 7, and 8, which also don't start a sentence. Anyway, just be
consistent and treat 1 as you treat 6, 7, and 8 or the other way
around.

>> In 1.2.3 it says that not all variables have to be bound, but in 2.2
>> it says that all variables must be bound in every solution. Maybe add
>> in 2.2 that since non of the variables occurs in an optional pattern,
>> they must be bound.
>
>> 1.2.3 Result Descriptions
>> ... Variables are not required to be bound in a solution.
>> but
>> 2.2 Multiple Matches
>> ...all the variables used in the query pattern must be bound in every
>> solution.
>
> It says:
> """
> This is a basic graph pattern match; all the variables used in the query
> pattern must be bound in every solution.
> """
> In a BGP, all variables are bound so I think the text does make sense.

It is not wrong as it is. I just suggested that as a helpful reminder
to readers, but it is not required.

>> 8.3 Mapping from Abstract Syntax to Algebra
>> ...
>> Example:
>> example should have courir font (<code>  or<codeeg>)
>
> I see monospace here (via div styling) - what is the problem?

It is just that in the first sentence NOT EXISTS and EXISTS has a
different font than in the third sentence and I can't see any
systematics behind that. Is that intended and if so, what is the
difference between the Courir (NOT) EXISTS and the monospace (NOT)
EXISTS?

>> 15.3.1
>> Definition: Pattern Instance Mapping
>> P(x) = μ(σ(x))<- Can we make this more explicit in this spec? E.g.,
>> by saying "For x a BGP, P(x) denotes the result of replacing blank
>> nodes b in x for which sigma is defined with sigma(b) and all
>> variables v in x for which mu is defined with mu(v).
>
> I've added this text just after the definition thinmking of it as "errata".
>  As the definition is not chnaging for SPARQL 1.1, I'm loath to change the
> definition box itself.

I would prefer to actually fix it because the definition does not
define what x actually is and even if readers are clever enough to
guess that x is a BGP, then sigma and mu are not defined for BGPs, so
readers also have to guess that in this case mu and sigma replace the
variables and blank nodes respectively in this case. This leaves a lot
for readers to figure out themselves and it is quite an essential
definition. In this case, the definition does not have to be changed
(the intended behaviour so to say), but it needs further clarification
IMO.

> If you want to integrate it, then we ought to pull this topic out and get
> the WG to agree it as it is outside the new features.

I don't see it as a new feature (as said above the definition does
still define the same thing), but as a clarification. I'll ask
Axel/Lee whether it is possible to put it on tomorrow's agenda.

Birte

Received on Monday, 4 January 2010 14:43:45 UTC