W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2011

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

From: Gregory Williams <greg@evilfunhouse.com>
Date: Sat, 26 Nov 2011 17:11:42 -0500
Cc: public-rdf-dawg@w3.org
Message-Id: <0FD2E2B6-FF58-476F-9FF9-B31321C67301@evilfunhouse.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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".

>>>> === 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.

>>>> 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.

>>>> "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").

>>>> === 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.

>>>> 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
>>>> 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...

>>>> "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.
> """

That works for me.

Received on Saturday, 26 November 2011 22:12:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:05 UTC