Re: Feedback to some SPARQL 1.1 Working Drafts

forwarding Reto's reply which went to the wrong address for the records...
> -------- Original Message --------
> Subject: Returned mail: see transcript for details
> Date: Wed, 20 Oct 2010 07:59:43 +0200
> From: Mail Delivery Subsystem <MAILER-DAEMON@smtp.uibk.ac.at>
> To: <reto.krummenacher@sti2.at>
> 
> The original message was received at Wed, 20 Oct 2010 07:59:12 +0200
> from c703-deri12.uibk.ac.at [138.232.65.152]
> 
>    ----- The following addresses had permanent fatal errors -----
> <public-sparql-comments@w3.org>
>     (reason: 550 Unrouteable address)
> 
>    ----- Transcript of session follows -----
> ... while talking to aji.keio.w3.org.:
> >>> DATA
> <<< 550 Unrouteable address
> 550 5.1.1 <public-sparql-comments@w3.org>... User unknown
> <<< 503-All RCPT commands were rejected with this error:
> <<< 503-Unrouteable address
> <<< 503 Valid RCPT command must precede DATA
> 
> 
> 
> From: "Reto Krummenacher" <reto.krummenacher@sti2.at>
> Date: 20 October 2010 06:59:12 GMT+01:00
> To: <public-sparql-comments@w3.org>
> Subject: Re: Feedback to some SPARQL 1.1 Working Drafts
> 
> 
> Axel, SPARQL WG.
> 
> Thanks for this notice and the group answer, as well as public comment responses
> to my feedback on service descriptions.
> 
> Looking forward to contributing to future rounds,
> Reto Krummenacher
> 
> On 10/14/2010 11:16 PM, Axel Polleres wrote:
> > 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.
> >>
> >
> >
> 
> 
> 
>