Re: ACTION: LeeF ... to review XML results set format. - Resend

On Fri, 2005-07-22 at 16:29 -0400, Lee Feigenbaum wrote:
> Please forgive the duplicate message. I'm fixing that attrociously
> bad-behaved line-wrapping behavior of the previous message.
> Mea culpa.
> 
> ------------
> 
> Greetings,
> 
> Review comments on the current Query Results XML Format working draft:
> 
> 1. Introduction
> 
> The SPARQL QL link goes to the April 19, draft. This should be updated
> to the more general URL: http://www.w3.org/TR/rdf-sparql-query/ . This
> is true of other links to the QL draft throughout the Query Results
> draft. A grep for 20050419 should find all these links.

I prefer to point to dated entries in the doc, as the section titles and
numbers sometimes change.  I've updated to the 20050721 version.

> ASIDE: The DAWG homepage suggests that the SPARQL QL draft linked to
> is still the April 19, 2005, draft when rather it is now the July 21,
> 2005, last call draft.
> 
> 
> 2. Definition
> 
> s/SPARQL Query/SPARQL Query Language/

Fixed.

> This sentence:
> 
> << 
> SPARQL Query defines several query result forms (SPARQL Query section
> 10) and this document defines an XML serialisation to encode variable
> bindings Query Results from SELECT (SPARQL Query section 10.2). and
> returning a boolean result from ASK (SPARQL Query section 10.5)
> >>
> 
> confuses me. At the very least, the period needs to move to the end
> rather than the middle of the sentence. I think it would read more
> clearly as:
> 
> <<
> ...to encode variable binding query results from SELECT queries
> (SPARQL Query section 10.2) and boolean query results from ASK queries
> (SPARQL Query section 10.5).
> >>
> 
> (Note that I also suggest changing "bindings" to "binding" to be
> consistent with the usage in the rest of the draft.)

I've reworded this already after Jeen's comments. I've updated it
further to use something combining both of your comments:

  The SPARQL Query Language defines several query result forms (SPARQL  
  Query section 10) and this document defines an XML serialisation to  
  encode the variable binding Query Results from SELECT queries (SPARQL 
  Query section 10.2). and boolean query results from ASK queries  
  (SPARQL Query section 10.5)

(I didn't want to repeat SPARQL Query Language 4 times, so just expanded
it out in the first mention)

> 
> 2.1 Document Element
> 
> The first sentence is confusing. Perhaps:
> 
> << 
> The Query Results XML Format begins with a <code>sparql</code>
> document element in the...
> >>

Changed to that phrasing.

> 2.2 Header
> 
> "the order of the variable names given to the argument of the SELECT
> statement in the SPARQL query"
> 
> might be better as:
> 
> "the order of the variable names as given in the projection section of
> the SELECT query"

I prefer not to use the term "projection" as it is not as simple as just
saying the order of variables given in SELECT.  Projection is only
explained in SPARQL Query way down in section 10 long after sequences of
variables have been used.

The SPARQL query language doesn't tend to call the parts sections, the
nearest I can see it called is Solution Modifiers; although in 10.1 it's
called "Solution Sequence Modifier".  Sigh.  It's not a sequence before
ORDER is done.

But I'm digressing...  I don't propose to change this wording.

> 
> 
> Is there any harm in allowing multiple <link> elements? If that's to
> be the main extensibility point for further information on the query
> results, I feel that it's better to allow a broader range of metadata
> by allowing multiple links. In either case, the example here uses a
> relative href ("metadata.rdf") and it's not specified how a consumer
> of the XML document is to interpret such a relative URI. 

No real harm so I'll change the schema to allow multiple <link>s
I've added a sentence about the relative URI.  Here's the change:

  For any query result, head may also contain link child elements with 
  an href attribute containing a relative URI that provides a link to
  some additional metadata about the query results. The relative URI is
  resolved against the in-scope base URI which is usually the query
  results format document URI. link elements must appear after any
  variable elements that are present.

> 
> 2.3 Results
> 
> s/is empty/are empty/

Fixed

> 2.3.1 Variable Binding Results
> 
> A couple of comments on the explanation of the 'ordered' and
> 'distinct' attributes:
> 
> + The wording: "The ordered attribute indicates [etc.]" indicates to
> me that the very presence of the attribute implies [etc.], whereas we
> mean that a true value for the attribute implies [etc.]. Suggestion:
> "The ordered attribute indicates whether or not [etc.]". 

changed to "indicates whether or not"

> + The wording: "...such as given by a SPARQL query containing ORDER
> BY" suggests to me that there are cases in which a SPARQL query does
> NOT contain ORDER BY and yet the results format document contains
> ordered=true. Is this by design?  Similarly for the distinct case. If
> this is by design, I think it's worth stating explicitly that servers
> may specify ordered=true or distinct=true even when the SPARQL query
> did not explicitly request these properties.

(Aside: I wouldn't use mention implementation terms (servers) as you
don't need one to implement the query results spec.)

There might not even be a sparql query, which is one reason I use "such
as given by a SPARQL query" for both ordered and distinct.

These flags are properties of the query results, not the query.  As long
as the orderedness and distinctiveness of the query results matches the
flags in the ordered and distinct flags, it's OK.

I'm not sure what to change here.

> + It might be worth mentioning that ordered=false does not guarantee
> that the results are NOT ordered and that distinct=false does not
> guarantee that there are duplicates. (Though I can't think of a
> use-case that would try to exploit such potential mistaken
> impressions.)

Neither can I.  I don't see much point in adding this semi-disclaimer.
If the flags are mis-used, the application is broken.

> + s/that the results have are distinct/that the results are distinct/

already fixed after Jeen's comment

> <<
> Each result element corresponds to one Query Solution in a result and
> contains child elements for each Query Variable that appears in the
> solution (ordered the same as the variable child elements of head) and
> used to record how the query variable binds to an RDF Term (SPARQL
> Query section 4).
> >>
> 
> The sentence is talking about the full set of variable bindings, and
> therefore the end of the sentence should probably be:
> 
> <<
> ...and used to record how the query variables bind to RDF Terms
> (SPARQL Query section 4).
> >>

yes, fixed.

> 
> << 
> The value of query variable binding which is either an RDF Term or
> unbound is written as the content of the binding as follows:
> >> 
> 
> is better as:
> 
> <<
> The value of a query variable binding, which is either an RDF Term or
> unbound, is included as the content of the binding as follows:
> >>

yes, fixed

> 
> A typed literal can also specify a language, so that might be worth
> including as its own case or mentioning in a note below the examples.

No it can't.  RDF typed literals have only a literal form and a datatype
URI.

> 
> 3.2 Boolean Results Examples
> 
> Strike "following the definition in section 2"

OK, I guess that's obvious.  deleted

> 
> 4. XML Schemas
> 
> Both the RELAX NG and the XML Schema schemas say that the <sparql> and
> <result> elemants can contain an xml:lang attribute (in addition to
> the <literal> element), but the rest of the draft never mentions such
> uses of xml:lang or what such uses would mean.

True.  I'll remove it from the schema for now.  This might have to
return with a proper explanation and use the XML Infoset terms like
in-scope xml language.

Changes made to CVS 1.35 of
http://www.w3.org/2001/sw/DataAccess/rf1/

Thanks

Dave

Received on Monday, 25 July 2005 11:15:44 UTC