- From: Alexandre Passant <alexandre.passant@deri.org>
- Date: Wed, 10 Jun 2009 12:17:20 +0200
- To: "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Hi, Le 10 juin 09 à 11:46, Seaborne, Andy a écrit : > (I'm not waiting until I have done a complete review but sending > things in chunks, hope that is alright.) > > Comments relative to v1.70 > > Andy > > ------------------ > Will the time-permitting features at least be mentioned? Especially > SPARQL/OWL. > They don't need as much justification (IMO) - indeed for this > publication, just placeholder structure is enough but something > should go in. We've commented them from the TOC / Structure as we didn't have time to properly define it for the FPWD. Yet, I just added the list of complete features in the introduction, which lists all of them. > > > ------------------ > > > Structure: > Currently it is: > ---- > # 4 SPARQL/Update 1.0 > > * 4.1 Update > > # 5 Protocol Enhancements > > * 5.1 HTTP graph update > ---- > > I prefer putting protocol under update to be clear it is in support > of update. "Enhancement" suggests tweaks to the query protocol to > me but we wish to leave the design space open and avoid prejudging > naming issues. > > Also, the new protocol is there to support update so make that > explicit. > > Suggested structure: > > 4 SPARQL/Update 1.0 > > * 4.1 Update Language > ... > * 4.2 Protocol Enhancements > ... Are we sure that no other feature will imply some protocol enhancements ? (esp. wrt Service Description and using GET or some HTTP Options as raised during yesterday's call) > > > 5 Service Description > > ------------------ > TOC: > Don't include the Motivations/Description/... subsections in the > first TOC to be seen. This is to be more read-focused. > Seeing the complete list of features in the TOC is useful to convey > the overall direction which is the point of this doc. > > Could have two TOCs: one that is shorter then a full one. Not sure about two TOCs will be useful. The OWL F&R document uses a Javascript to show / hide some content, I'll check how we could use a similar approach to display the shorten / extended toc. > > ------------------ > > == 1. Introduction > Don't pick out one or two features by name ("why this, and not > that") but when there is a complete list in the intro it won't be > needed anyway. Done > > > Push the "structure of document" text into a subsection. Done (is that what you meant ?) > > > ------------------ > == 2.1, 2.4.3 and other > Variable names without ? are confusing (and there are parser issues > about clashes with keywords). Fixed > > > Please provide a mixture of syntaxes from different implementations > for naming select expressions. The doc uses only one syntax but we > haven't decided anything yet. Give examples from different systems. > > ARQ is "(expression AS ?var)" > For reasons of simple parsing - it is overly restrictive but safe. > > > ------------------ > == 2.2.2 > > The example is wrong: correction - need LIMIT. > > $query = "SELECT ?name WHERE { > ?person foaf:name ?name . > } LIMIT 1"; Fixed > > > In the example from ARQ, use a more pure form that is just about > subquery not select expressions (ARQ does not put scalar subqueries > in select expressions anyway). > > Suggestion (includes other fixes): > ---- > SELECT ?person ?name > { > :Alice foaf:knows ?person . > { SELECT ?name { ?person foaf:name ?name } LIMIT 1 } > } Fixed, I added WHERE keywords, is that compliant with the ARQ syntax ? > > ---- > ------------------ > """The type of subqueries has not yet been decided by the WG (see > issues below).""" > > 'type' is tricky word as it means so many things. > "Query form" is SPARQL terminology. Fixed > > It just drop the sentenance - does not add anything IMO. Won't that sentence be needed from a charter perspective ? > > > ------------------ > == 2.3: Negation > == 2.3.1 Motivations > > Rather than drive it from a technical perspective, why not just say > "common user request which the WG agrees with". Added that mention to "user-request" > Then examples and existing implementation are simple to the point of > not needed. The existing SPARQL form could go as an example (of how > not to do it!). I'd say the motivation of going to the technical perspective is to emphasize that the feature is there, but technically complex for users. To that extend, I think that examples are needed. But most complex examples are more than welcome. All these changes have been committed. Best, Alex. > > ------------------ > == 2.4.2 Project expressions / Descriptions > "ex:substring" > > Use and example from XQuery/XPath F&O (e.g. fn:substring and strings > are zero-based) to indicate we will reuse where possible. > ------------------ > == 2.4.3 Project expressions / Existing implementation > > """ > This is also useful in CONSTRUCT: > > CONSTRUCT { ?x foaf:name (concat(?fn, " ", ?sn)) . } > WHERE { ?x foaf:firstName ?fn ; foaf:family_name ?sn . } > """ > This is not a project expression! > > Just keep the section clean and don't discuss CONSTRUCT. Just need > a direct discussion of project expressions. > > > ---- Examples for SPARQL/Update 1.0 > > From the submission, simplified: > -------- > PREFIX dc: <http://purl.org/dc/elements/1.1/> > INSERT DATA > { <http://example/book3> dc:title "A new book" ; > dc:creator "A.N.Other" . > } > > > > DELETE { ?book ?p ?v } > WHERE > { ?book dc:date ?date . > FILTER ( ?date < "2000-01-01T00:00:00"^^xsd:dateTime ) > ?book ?p ?v > } > } -- Alexandre Passant Digital Enterprise Research Institute National University of Ireland, Galway :me owl:sameAs <http://apassant.net/alex> .
Received on Wednesday, 10 June 2009 10:18:02 UTC