W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > October 2010

Re: Feedback to some SPARQL 1.1 Working Drafts

From: Axel Polleres <axel.polleres@deri.org>
Date: Thu, 14 Oct 2010 18:16:14 -0300
Message-Id: <9F22B970-5852-4CFC-B148-2A4E46A4604D@deri.org>
Cc: public-rdf-dawg-comments@w3.org
To: Reto Krummenacher <reto.krummenacher@sti2.at>
Dear Reto,

Apologies for the delayed reply and thanks for your comments, which we tried to address as far as possible in the current round of drafts published on 2010-10-14. We'd appreciate further comments on these new drafts, to be found at

http://www.w3.org/TR/2010/WD-sparql11-query-20101014/
http://www.w3.org/TR/2010/WD-sparql11-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-entailment-20101014/
http://www.w3.org/TR/2010/WD-sparql11-update-20101014/
http://www.w3.org/TR/2010/WD-sparql11-service-description-20101014/
Note that we didn't yet publish a new version of the protocol document, so your comments on the protocol will be considered in a future publication cycle.

best regards, 

Axel, on behalf od the SPARQL Working group.


> From: Reto Krummenacher <reto.krummenacher@sti2.at> 
> Date: Tue, 03 Aug 2010 14:33:53 +0200
> Message-ID: <4C580CB1.4020308@sti2.at> 
> To: public-rdf-dawg-comments@w3.org 
> Dear editors,
> 
> Below I send you some feedback, thoughts and observations that I made while
> reading the working drafts of SPARQL 1.1. Apologies for stating obvious things
> that might already have been discovered or reported. I did not check the mailing
> list for previous reactions.
> 
> Kind regards,
> Reto
> 
> ----------------------------------------------------------------------------
> 
> SPARQL 1.1 Update
> -----------------
> 
> 3.2.1 : A DELETE operation may indeed remove entailed statements, but it might
> also lead to the removal of statements that caused the entailment. Do you refer
> to this state as being inconsistent; i.e., entailed statements that could no
> longer be entailed cause the inconsistencies? Wouldn't thus any store that does
> not perform consistency checking actually violate the knowledge state? And, is
> it really enough to only raise an exception? Shouldn't there be at least an
> option to have the store make sure that such now wrongly entailed statements are
> also removed?
> 
> 4 : I do not understand the claim that operations of a request are exectuted in
> lexical order.
> 
> 4.1.2 : the second example has two PREFIX statements, one before the DELETE, the
> other before the INSERT. All other examples do not seem to require the two
> PREFIXes.
> 
> 4.1.4 / 4.1.6 : both sections contain the exact same example. As there is a
> dedicated section 4.1.6 on DELETE WHERE, the example could be removed in 4.1.4.
> 
> 4.2.1 : Why should stores that do not allow empty graphs always return SUCCESS,
> although the empty graph was definitively not created?
> 
> SPARQL 1.1 HTTP Protocol
> ------------------------
> 
> 1 : a(?) SPARQL Update
> 
> 4.2 : an(?) RDF graph representation
> 
> 5.3 : "... that the origin server incorporateS the RDF,..."
> 
> 5.3 : in the box there are two need, "need need to know"
> 
> 5.3 : there might be need for a link to the Service Description document from
> within the box.
> 
> SPARQL 1.1 Federation
> ---------------------
> 
> 2 : "For instance, an eNdpoint which..."
> 
> 2 : The part about WSDL: a link to the WSDL document and section would improve
> the document.
> 
> 2 : "according TO the SPARQL alGebra"
> 
> 3 : Could it make sense to take the same syntactical approach to BINDING
> clauses, as was taken to FILTER clauses; i.e. BINDING become part of the WHERE
> clause and are not a third type of clause: SELECT WHERE{FILTER} BINDING, but
> rather SELECT WHERE{FILTER BINDING}?
> 
> SPARQL 1.1 Service Description
> ------------------------------
> 
> 3.2.2 : give examples of language instances, and point to the corresponding
> sections in the document.
> 
> 3.2.4 : sd:Aggregate vs. sd:AggregateFunction. Being a function, wouldn't it be
> useful to define sd:AggregateFunction as a subclass of sd:Function. Or, are
> aggregate operations to be used in SPARQL HAVING clauses not considered to be
> functions according to 3.2.3?
> 
> 3.3.4 : adding internal references would help I think; e.g., a direct link to
> sd:feature
> 
> 3.4.1 : Assuming this is the URL of the SPARQL service that accepts HTTP calls
> according to the SPARQL 1.1 Protocol, I think this would be a good spot to link
> to the corresponding sections in the protocol document. Yes, I think this is an
> appropriate at this point.
> 
> 3.4.2 : list shortly and point back to the defined instances
> 
> 3.4.3 / 3.4.4 : "Relates an instance..."
> 
> 3.4.5 : "Relates a named graph...". Could this not also be used with sd:Graph
> instead of only with sd:NamedGraph?
> 
> 3.4.8 : The range is missing, I would assume that extensions should also be of
> type sd:Language, shouldn't it?
> 
> 3.4.8 / 3.4.9 / 3.4.10 / 3.4.11 / 3.4.12 : "Relates an instance..."
> 
> 3.4.9 / 3.2.2 : Subset is indeed a bit confusing. Considering the instances of
> sd:Language I would rather opt for something like SPARQL language version, or
> SPARQL language variance. While sd:SPARQL11Query and sd:SPARQL11Update could be
> considered subsets of SPARQL11, sd:SPARQL10Query does not really share any
> common super-set.
> 
> 3.4.10 : What is the difference between a supported feature (sd:feature) and an
> implemented feature (sd:propertyFeature)? Are there any examples that could be
> given for a named property?
> 
> 3.4.13 : As the example in Section 4 shows, there is some overlap with VoID.
> Would it make sense to relate to the suggestion of using dc:format according to
> VoID in the context of sd:resultFormat?
> 
> 3.4.14 : range?
> 
> 3.4.15 : The text states that sd:namedGraph relates an sd:Dataset to a named
> graph, the domain however is sd:GraphCollection. A dataset can thus have either
> a graph plus one named graph, or a graph plus one graph collection? Still, the
> wording seems to be misleading.
> 
> 3.4.17 : I think there should be a paragraph about how to describe graphs. The
> example points to VoID. Shall that become the standard vocabulary, or would it
> be up to the service describer to use any model to describe data sets.
> Effectively, there are at least some overlaps between VoiD and the Service
> Description model, hence the relationship might have to be clarified; starting
> with void:Dataset vs. sd:Dataset or rather sd:Graph.
> 
> 3.4.1 - 3.4.17 : a bullet listing of the range and domain could improve the
> readability.
> 
Received on Thursday, 14 October 2010 21:16:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 October 2010 21:16:57 GMT