W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Some comments on F&R (2)

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Wed, 10 Jun 2009 09:46:09 +0000
To: "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3646C65D2E9@GVW1118EXC.americas.hpqcorp.net>
(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.

------------------


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
        ...       

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.
------------------

== 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.

Push the "structure of document" text into a subsection.

------------------
== 2.1, 2.4.3 and other
Variable names without ? are confusing (and there are parser issues about clashes with keywords).

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";    

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 }
}
----
------------------
"""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.
It just drop the sentenance - does not add anything IMO.

------------------
== 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".  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!).
------------------
== 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
      } 
  }   	
Received on Wednesday, 10 June 2009 09:47:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT