Re: Feedback to some SPARQL 1.1 Working Drafts

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 UTC