Re: query review, part 1 (ACTION-546)

More editorial changes.

	Andy

>>> === Section 16.2.1
>>>
>>> "The use of variable x in the template, which in this example will be
>>> bound to blank nodes with labels _:a and _:b in the data, causes
>>> different blank node labels (_:v1 and _:v2) in the resulting RDF graph."
>>> This isn't required, correct? The resulting RDF graph *could* use the
>>> same blank node labels as are present in the RDF Dataset.

"The resulting RDF graph" is something sent out over the protocol (the 
only standard way to get results) so I prefer not to change this.

>>>
>>> === Section 16.2.2
>>>
>>> Doesn't the use of an extension function in the second example
>>> needlessly comlicate the example?

I tend to agree with you but it's SPARQL 1.0 text so my preference is 
not to change it.  Not a strong preference.

>>>
>>> === Section 16.3
>>>
>>> The query results should probably be "true" and "false", not "yes"
>>> and "no" (unless we're catering to objective-c programmers :)

(memories of discussions past :-)

One-upon-a-time it was "true" and "false" IIRC but issues were raised 
what what it mean to be "true".  "Yes" means " it matched, a more 
syntactic concept.

>>> === Section 16.4
>>>
>>> This section is marked as informative, but there seems to be
>>> information here which isn't just informative. The text specifically
>>> calls out parts that aren't normative ("this data is not prescribed
>>> by a SPARQL query"). With this section being non-normative, there's
>>> no text beyond the grammar that talks normatively about how DESCRIBE
>>> is handled.

Yes - that is what DAWG decided.

The behavior of DESCRIBE is not changed for SPARQL 1.1 so while I'm 
sympathetic to the comment, I'm not sure what can be done without 
reopening DESCRIBE.

>>> I also notice there's no discussion about the allowable forms of the
>>> DESCRIBE form. For example, what does "DESCRIBE *" (without a graph
>>> pattern) mean?

"The syntax DESCRIBE *
is an abbreviation that describes all of the variables in a query.
"
There are no variables.

c.f. SELECT * {}

>>> === Section 16.4.3
>>>
>>> "The RDF returned is determined by the information publisher."
>>>
>>> This seems to imply that "the information publisher" == "the SPARQL
>>> query processor" (as described in 16.4).

Not really - the person who configured the system.

>>> "It is the useful information the service has about a resource."
>>>
>>> This seems to prescribe what data is/should be returned for a
>>> DESCRIBE query (contradicting earlier text).

This is informative text so I think that the text is acceptable.

That said, if there are suggestions for change, then let's discuss this 
further.

>>> If we're going to use the foaf:mbox_sha1sum property in the example
>>> RDF, should we at least use a lexical form that's actually valid for
>>> SHA1?

changes to

bee135d3af1e418104bc42904596fe148e90f033

(which is a real, valid SHA1 of a mailto: URL.  I leave you to work out 
which what that is).

>>>
>>> "For a vocabulary such as FOAF, where the resources are typically
>>> blank nodes..."
>>> Is this true anymore? Does it matter?

For a lot of FOAF I guess it is still true.

>>> "WHERE" should be in tt text in "In the example, the match to the
>>> WHERE clause was returned, but this is not required."

Done

>>>
>>> === Section 17
>>>
>>> The section number in the link text "11.2.2 Effective Boolean Value"
>>> is wrong. It should be "17.2.2".
>>
>> Fixed.
>>
>>> The section number in the link text "section 11.3" is wrong. It
>>> should be "17.3".
>>
>> Fixed.
>>
>>> The section number in the link text "section 11.5" is wrong. It
>>> should be "17.5".
>>
>> Fixed.
>>
>>> "Operators introduced by this specification are indicated with the
>>> SPARQLoperator class."
>>> It took me some time to figure out that 'SPARQLoperator' was a class
>>> name being used in the underlying HTML, and that what this meant was
>>> that such operators are shown in the same styling (yellow background)
>>> as the text "SPARQLoperator class".

Eric is using the fact that "SPARQLoperator class" is styled by 
SPARQLoperator (which probably does not help on paper).

Removed and reformatted para.

>>> The SPARQLoperator styling seems to be used inconsistently. It is
>>> sometimes applies to "logical-or" and "logical-and", but not always.

N/A from previously

(BTW: I see it as yellow on hover fairly consistently using FF)

>>>
>>> === Section 17.2
>>>
>>> The section number in the text "EBV rules in section 11.2.2" is
>>> wrong. It should be "17.2.2".
>>
>> Fixed.
>>
>>> "Apart from BOUND, NOT EXISTS and EXISTS, all functions and operators
>>> operate on RDF Terms and will produce a type error if any arguments
>>> are unbound."
>>> I assume this list should include COALESCE?
>>
>> Fixed.
>>
>>> "Any expression other than logical-or (||) or logical-and (&&) that
>>> encounters an error will produce that error."
>>> Again regarding COALESCE.
>>
>> Not quite, the situation with COALESCE is a bit more complex. The word
>> "encounters" is vague enough that it covers that I think.
>>
>>> === Section 17.2.2
>>>
>>> "If the argument is a typed literal with a datatype of xsd:boolean,
>>> the EBV is the value of that argument."
>>> Since this comes immediately after the text says the EBV is false if
>>> the lexical form is invalid, I think this should be: "If the argument
>>> is a typed literal with a datatype of xsd:boolean and a valid lexical
>>> form, the EBV is the value of that argument." Similarly for the
>>> subsequent rule regarding numeric types.

Done but I think it already says that because the first bullet does not 
say the literal is of the datatype, ony it has a type.  To be of the 
datatype means the lexical form must be valid, so bullets 2 and 3 
already say it indirectly.

>>>
>>> === Section 17.3
>>>
>>> The section number in the link text "section 11.4" is wrong. It
>>> should be "17.4".
>>
>> Fixed.
>>
>>> === Section 17.3.1
>>>
>>> "The consequence of this rule is that SPARQL extensions will produce
>>> at least the same solutions as an unextended implementation, and may,
>>> for some queries, produce more solutions."
>>> Is this always true? I want to say that with negation there are
>>> probably examples where changing a type error into a result could
>>> yield fewer results.

The text is certainly not ideal for SPARQL 1.1.  It is true for the 
filerting step though (which may be inverted by negation).

Is this
"""
The consequence of this rule is that SPARQL FILTERs will produce at 
least the same intermediate bindings after applying a FILTER as an 
unextended implementation.
"""

OK?

>>>
>>> === Section 17.4.1.2
>>>
>>> "Only one of expression2 and expression3 is evaluated."
>>> This contradicts section 17.2.1 which indicates that argument
>>> expressions are evaluated before the function or operator is invoked.

It's har dto see but it's correct because IF is a "Functional Form" (aka 
"special forms") not a function. It looks like function but isn't - 
there was only one in SPARQL 1.0 (BOUND).

But it's confusing.



"""
SPARQL defines a syntax for invoking functions on a list of arguments.
Unless otherwise noted, , these are invoked as follows:

and

"""
There are also "functional forms" which have different evaluation rules 
to functions
       as specified by each such form.
"""


>>>
>>> === Section 17.4.1.4
>>>
>>> Why does 'exists' appear in both lower and uppercase, and both quoted
>>> and unquoted in this section?

Fixed.

>>>
>>> "Variables in the pattern pat that are not bound in the current
>>> solution mapping take part in pattern matching."
>>> There is no pattern 'pat'. This should read "Variables in the pattern
>>> ..." with 'pattern' in tt text.

Fixed.

>>>
>>> === Section 17.4.1.5
>>>
>>> The section number in the text "section 11.2, Filter Evaluation" is
>>> wrong. It should be "17.2".
>>
>> Fixed.
>>
>>> === Section 17.4.1.6
>>>
>>> The section number in the text "section 11.2, Filter Evaluation" is
>>> wrong. It should be "17.2".
>>
>> Fixed.
>>
>>> === Section 17.4.1.7
>>>
>>> The footnote link is broken.

xmlspec-ism.  fixed.


>>> I  was able to read the footnote text in
>>> the document source, but was confused that the footnote text only
>>> describes the case of custom datatyped literals, not any literal as
>>> the document text discusses. Neither the text or the footnote
>>> discusses explicitly the case of comparing two non-equal literals in
>>> *supported* datatypes (e.g. xsd:integer).

I'm not sure it should - "supported" datatypes should not get to 
RDFterm-equal by operator dispatch of "=".

>>> "In this query for documents that were annotated on New Year's Day
>>> (2004 or 2005) ..."
>>> I find this text confusing, as the query is about a single, specific
>>> dateTime, not two different dates. The datetime with "2004" in its
>>> lexical value does *not* represent "New Year's Day" of 2004.

Changed to:

"""
In this query for documents that were annotated at a specific date and 
time (New Year's Day 2005, measured in timezone +00:00), the RDF terms 
are not the same
"""

Other suggestions?

>>> === Section 17.4.1.9
>>>
>>> "Errors in comparisons cause the IN expression to raise an error if
>>> the RDF term being tested is not found elsewhere in the list of terms."
>>> This contradicts section 17.2.1 which indicates that if the
>>> evaluation of any argument results in an error, the entire invocation
>>> generates an error.

As above, which hopefully correct that - this is in the functional forms 
section.

>>> === Section 17.4.2.2
>>>
>>> s/foaf:knows/dc:creator/
>>
>> Fixed.
>>
>>> === Section 17.4.2.5
>>>
>>> Should the example REGEX be escaping the dot in "@work.example" pattern?
>>
>> Possibly, yes, but maybe it should also have a $?

Changed.

"@work\\.example$"

>>
>>> === Section 17.4.2.6
>>>
>>> The new working draft of turtle allows mixed-case language tags, but
>>> the current turtle spec only allows lowercase languages. Also, RDF
>>> Concepts  says literals have an optional language tag "normalized to
>>> lowercase" (I'm not sure if this means LANG() should *always* return
>>> lower-case values). I suggest the example in this section be changed
>>> to use lowercase language tags.

Done (RDF Concepts disagrees with the RFC rules for canonical language 
tags - fortunately, the canonical form of @es is @es)

>>> === Section 17.4.2.7
>>>
>>> Need an "at risk" note talking about rdf:langString's relationship to
>>> the RDF WG.

Done

>>>
>>> === Section 17.4.2.8
>>>
>>> "Passing any RDF term other than a simple literal or an IRI is an
>>> error."
>>> This contradicts the function signature as accepting xsd:string
>>> literals.
>>
>> Added xsd:string to the text.
>>
>>> === Section 17.4.2.9
>>>
>>> Why not merge this with 17.4.2.8, just as isURI() is part of the
>>> section for isIRI?

Done.

>>> === Section 17.4.2.10
>>>
>>> Why not accept xsd:string arguments, as with IRI()?
>>
>> It should probably list all the option, but RDF WG is about to make
>> this redundant anyway.

Added.

>>
>>> Why not allow language-tagged literals? It would seem very burdensome
>>> to jump through the necessary hoops to get "foo", "foo"@en and
>>> "foo"@es to produce different bnodes using this function…
>>
>> Yes, they probably should take anything string-y, but why not accept
>> numerical/datetime literals too?

Left as is.  Don't want to get into whether "foo" and "foo"@en produce 
same or different bnodes given that other operations just take the 
lexical part.

>>> === Section 17.4.2.11
>>>
>>> Should there be any mention of what happens (or should happen) if an
>>> invalid lexical form is used with STRDT() for a known/supported
>>> datatype?

Changed to "and type".

That implies illegal lexical forms are OK (which is goign to be ture for 
unknown forms anyway).

It's a constructor for RDF terms.  If anything, the name should be 
different but I have no better suggestion.


>>>
>>> === Section 17.4.2.12
>>>
>>> Should there be any mention of the language tag conforming to RFC-3066?

Prefer not.  We didn't in SPARQL 1.0 for lang().

>>>
>>> === Section 17.4.3.1.1
>>>
>>> s/fucntion/function/
>>
>> Fixed.
>>
>>> === Section 17.4.3.2
>>>
>>> Should this section mention the impact of Unicode normalization on
>>> the return value of STRLEN? For example, the difference between
>>> "\u0075\u0308" (strlen 2) and its normalized equivalent "\u00fc"
>>> (strlen 1).

It defers to fn:string-length.

The "length in characters" should be enough (same as fn:string-length)

>>>
>>> === Section 17.4.3.14
>>>
>>> The text describing REGEX should mention the flags argument.
>>
>> I think that's handled well enough by F&O. No point repeating bits of
>> that doc.
>>
>>> === Section 17.4.3.15
>>>
>>> "It replaces each non-overlapping occurence of the regular express
>>> 'pattern' with ..."
>>> s/express/expression/
>>
>> Fixed.
>>
>>> s/'pattern'/pattern/ in tt text
>>
>> Not sure about that one, Andy?

Done.
(too much wiki text?)

>>
>>> === Section 17.4.4.1
>>>
>>> Can ABS() produce an invalid lexical form (e.g. for
>>> xsd:negativeInteger)?

ABS does not return a it's input type - it wil be one of xs:float, 
xs:double, xs:decimal or xs:integer

(see fn:abs)

>>>
>>> === Section 17.4.6.1–17.4.6.5
>>>
>>> "Hex digits should be in lower case."
>>> Should "should" be RFC2119-emphasized?
>>
>> Agreed, fixed.
>>
>>> === Section 19.5
>>>
>>> s/must be conform/must conform/
>>
>> Fixed.
>>
>>> === Section 19.8
>>>
>>> s/covering the the/covering the/
>>> s/which syntactically a/which is syntactically a/
>>
>> Fixed.
>>
>>> The anchor link in note 14 (link text "function call") is missing the
>>> '#' character to make it a link to a fragment id.
>>
>> Fixed.
>>
>>> === Section 20
>>>
>>> "This specification is intended for use in conjunction with..."
>>> The JSON and CSV/TSV documents should be listed along with protocol
>>> and SPARQL/XML.

JSON added.  Not CSV/TSV as it's a NOTE.

References added/fixed.

>>> "Note that the SPARQL protocol describes an abstract interface as
>>> well as a network protocol, and the abstract interface may apply to
>>> APIs as well as network interfaces."
>>> This isn't true anymore.

Suggested text from an editor of the protocol doc? :-)

"""
Note that the SPARQL protocol describes a means for conveying SPARQL 
queries to an SPARQL query processing service and returning the query 
results to the entity that requested them.
"""

>>>
>>> === Section A
>>>
>>> The protocol document citation will need to change whenever there's a
>>> FPWD of the 1.1 protocol document.

Partially fixed.

Received on Thursday, 24 November 2011 15:48:34 UTC