W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > March 2006

Re: Comments on Feb 20 Working Draft of SPARQL [CLOSED]

From: Reto Krummenacher <reto.krummenacher@deri.org>
Date: Tue, 14 Mar 2006 17:55:55 +0100
Message-ID: <4416F59B.4090307@deri.org>
To: andy.seaborne@hp.com, public-rdf-dawg-comments@w3.org



Seaborne, Andy wrote:
> 
> 
> On Fri, Feb 24, 2006 at 05:40:55PM +0100, Reto Krummenacher wrote:
>>
>> Dear editors,
>>
>> I have another set of minor comments on the SPARQL Query Language for RDF
>> working draft. Most of them are solely of editorial matter:
>>
>> * first paragraph section 2: Combining tripleS gives a basic graph...
> 
> "Combining triple" => "Combining triple patterns"
> 
>>
>> * I would suggest to exchange 2.1.7 and 2.1.6. In my opinion
>> the query syntax is based on the data format used and not vice versa.
> 
> The previous sections (2.1.1-2.1.5) are about query syntax so it seem
> natural to conclude query syntax.  Also, the data syntax is just for
> this document so downplaying seems appropriate.
> 
>>
>> * 2.9 should probably start with "RDF defines A reification
> vocabulary..."
> 
> It reads right as it is to me, it does read as saying it is the only
> vocabulary.  But as it has caused confusion to you, I have changed it.
> 
>>
>> * 5.4 should probably say "...; or it passes all solutions without
> adding any
>> additional bindings." The 'any solutions' seems wrong to me.
> 
> Matching is defined per-solution so I changed it to: "the solution".
> 
>>
>> * Still 5.4 end: should OPTIONAL not be capitalized in the syntactic
> form example.
> 
> Yes - fixed.
> 
>>
>> * 5.5 the second sentence of paragraph one is very confusing to read.
> Doesnt it
>> say exactly the same as the next sentence: "The outer optional graph
>> pattern..."? Could it may be make sense to mention that this basically
> means
>> that all varialbes in the outer graph patterns have to be bounded,
> doesnt it?
> 
> Deleted that sentence.
> 
>>
>> * End 5.5: the conclusion of the example is that the optional part is
> only
>> reached if there is a vcard:N predicate. Shouldnt it not also include
> a matching
>> vcard:Given predicate, as it ?vc vcard:Given ?gname is also part of
> the outer
>> graph pattern?
> 
> Changed to:
> """
> By nesting the optional pattern involving vcard:Family, the query only
> matches these if there are appropriate vcard:N and vcard:Given triples
> in the data.
> ""
> 
>> Small wording question: "the query only reaches these..." should IMHO be
>> "...reaches this...", as it refers to the optional graph pattern.
> 
> used "matches"
> 
>>
>> * Could it make sense to mention in 10.1.1 that projection is
> basically the
>> sequence modifier applied in all SELECT queries presented so far in the
>> document. Projection is basically the default modifier of SELECT, isnt
> it?
> 
> In 10.2 (SELECT) is does tie SELECT queries to projection.
> 
>> * In 10.4.3 first sentence you mention that the output of DESCRIBE
>> is determined by the information publisher. Who or what is the
>> information provider? Is it the query service that provides the
> information > to a user or rather the entity that actually published the
> information.
>> If I publish my foaf file and it is accessed over a SPARQL interface
>> I would expect that I am the publisher, however in my
>> opinion it is not clear how I could influence the DESCRIBE output
>> besides using the same blank node as subject of related
>> statements (cf. CBD)
> 
> The "information provider" is a term to express the whole collection of
> issues that go along with the provision and deployment of a SPARQL
> service.  It may well be that the people providing the data are
> different from the people running the service platform and they'll need
> to work together to get the service running but from the client's point
> of view it's what is avilable at the interface that matters.  Your
> example of your foaf file is a good one from the point of view of you
> making your foaf file available - it would take you and the service
> platform to do that.
> 
>> * In 11: is there a reason why xsd:dateTime is in another font than
> the other
>> datatypes?
> 
> No. This has been fixed. Thank you.
> 
>> * In the listing of 11.2 there is twice a redundant "will return" for
> logical or
>> and logical and
> 
> Also fixed.
> 
>> * in 11.3 for example XPath is written as xpath.
> 
> Also fixed.
> 
>>                                                  i also observed that
> sometimes
>> cannot is written in two words.
> 
> Both are, I believe, acceptable, but I have changed
> [[
> complete structures can not be assumed in all RDF graphs
> ]]
> to
> [[
> complete structures cannot be assumed in all RDF graphs
> ]]
> 
>>
>> Thank you very much for reading, I hope it helps a bit to finalize the
> working
>> draft.
> 
> Indeed it does. Thank you kindly for your assistance.
> 
> Please respond indicating whether you are or are not satisfied with
> this response. If you are, you can help our issue tracking system by
> prefixing the subject of your response with [CLOSED] (where this
> subject has [OK?]).
> -- 
>     Andy

-- 
dipl.ing.EPFL
Reto Krummenacher, Project Assistant

Digital Enterprise Research Institute (DERI)
University of Innsbruck

Phone: +43 (0)512 507 6452
Fax:   +43 (0)512 507 9872

reto.krummenacher@deri.org
http://members.deri.at/~retok
Received on Tuesday, 14 March 2006 16:56:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:50 GMT