Re: Some comments on F&R (2)

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