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

Hi Greg,

On 26/11/11 22:11, Gregory Williams wrote:
> I haven't had time to review section 18 yet, but modulo the followup below, I'm satisfied that all my other issues have been addressed.
>
>
>
> On Nov 24, 2011, at 10:48 AM, Andy Seaborne wrote:
>
>>>>> === 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.
>
> I don't see how we can seriously split hairs about the word choice when the SPARQL XML format (used immediately after the "yes" an "no" examples in this section) uses "true" an "false".

OK - change made.

>
>
>>>>> === 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.
>
> Understood, but I'm not happy about what seems like a problem with
> the 1.0 text meaning we have to keep the problem around in 1.1. I
> understand that we don't want to define what algorithm is used to
> construct the data to return. However, with no normative text for
> DESCRIBE, I don't think there's any text to say that the graph
> pattern in a DESCRIBE is meant to be evaluated agains the dataset,
> and the solution set from that evaluation used to construct the set
> of resources meant to be described. There's simply nothing normative
> here, and I think there should be: everything up to the point where
> an implementation gets to determine *how* to describe the set of
> resources should be defined in this document.

If the chairs wish to open discussion about DESCRIBE, I'm happy for 
that.  But without suggested text, I don't think I can address you 
comment in any other way.

You seem to be asking for the editor to write a replacement section, or 
at least the first part, which does not fall under "editorial".

>>>>> 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 * {}
>
> OK. I don't think the text for this is ideal, but I'm not sure how it could be made better, either.
>
>
>>>>> === 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.
>
> That's only true if the system allows the person doing the configuration to choose how DESCRIBE works. This isn't true for all systems.

I'd have thought choosing the system to use was a relevant choice.  The 
important point is that the information publisher is involved.

>>>>> "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.
>
> "It may be information the service deems relevant to the resources being described." ? (With an emphasis on using "may").

Done.

>
>
>>>>> === 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?
>
> I'm still not convinced, since "inverted by negation" may happen *in* the filtering step using 1.0-style negation by optional+filter.

Example?

>>>>> 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.
>
> OK. I'm not particularly happy about this, but won't object to the decision.
>
>
>>>>> === 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)
>
> OK. I tried to follow the definitions down into F&O (where maybe I just missed the answer), but got lost in the link to the XQuery Formal Semantics...

http://www.w3.org/TR/xpath-functions/#func-abs
[[
If type of $arg is one of the four numeric types xs:float, xs:double, 
xs:decimal or xs:integer the type of the result is the same as the type 
of $arg. If the type of $arg is a type derived from one of the numeric 
types, the result is an instance of the base numeric type.
]]

so only base numeric types are possible: xs:float, xs:double, xs:decimal 
or xs:integer can be returned (this is consistent with evaluation 
elsewhere in F&O; xs:byte + xs:byte is xs:integer)

	Andy

Received on Saturday, 26 November 2011 22:37:35 UTC