Working Draft feedback items

 From the publication of the latest SPARQL/Query working draft, I have seen 
the following points on the comments list, or elsewhere, which are not
editorial or clarifications.  The list is a a bit rushed but it seems better 
to list them than wait.  If there is anything I've missed, please let me 
know.  (Eric?)


== 1 == Request for streaming CONSTRUCT

Each solution generates on RDF graph from the template.

This feels more like a new result form despite being a simple syntax change.
Given bNodes, merging the graphs e.g. if streamed across the network
serialized in RDF/XML) isn't the same as the single graph.

So far, a SPARQL query can't generate more a single RDF graph.


== 2 == LIMIT applies to CONSTRUCT (and DESCRIBE) as a pragmatic error control.

This is reasonable and has been added.


== 3 == request for boolean literals

The words true and false (no quotes, no type, like numbers) for 
"true"^^xsd:boolean and "false"^^xsd:boolean


== 4 == Syntactic support for reification

Some people use reification and use it a lot - some people use named
graph-like approaches and avoid reification - most people just don't use either.

This is a resonable if there is a syntax suggestion; something like

REIFICATION ?id ?subject ?predicate ?object

being

   ?id rdf:subject    ?subject ;
       rdf:predicate  ?predicate ;
       rdf:object     ?object .

(that is, not including  an "?id rdf:type rdf:Statement")

except that really is bit long.  Various suggestions like

     # Straight quad (the other kind of quad)
     ?id ?subject ?predicate ?object .

     # A marker:
     ?id <- ?subject ?predicate ?object .

     # A bit quoting-like (my current favourite)
     ?id << ?subject ?predicate ?object >> .

     # Using a word
     ?id FOR ?subject ?predicate ?object .

I haven't checked these in a grammar.

There has been confusion between statings and statements.


== 5 == Sorting/Grouping

A request for SQL-like facilities to control the presentation of result
sets.  It makes testing interesting - sometimes unordered is acceptable and
sometimes it's (partially) not.

There are issues around defining the ordering between unrelated things like 
strings and URIs, bNodes and integers, dates and doubles - would need some 
arbitrary decisions.  Not clear to me that it could be pushed into SQL 
sorting for the semi-structued cases - in SQL, the engine knows the column type.

The decision would seem to be as much WG time as anything else.  I suppose 
that we could reserve syntax without defining semantics in tests at this 
stage but that isn't very helpful to interoperability/


== 6 == Optionals and order dependencies.

The alternatives I think if or know about are (briefly):

   A/ An order rule that states variables must be used in fixed
      patterns before optionals if possible.  We can either make
      a query that does not do this illegal, execute in this
      canonical order or leave to implementations.

   B/ "true OR P" - this generates spurious solutions.  While theoretically
      nice it is quite hard to work with.  Multiple interacting optionals
      make it hard to filter the spurious solutions.

   C/ Live with it.

   D/ Use-once variables in optionals
      This is a kind of simpification of A but has not been thought through.
      A variable can appear once in an optional and must be after
      any fixed use.  Possibly very restrictive.

   E/ Default values - assign a NULL (regular value - can't be rebound)
     to variable if not matched in an optional.  Still order dependent.
      Non-monotonic in the data.

My preference is A then C

 Andy

Received on Sunday, 6 March 2005 17:03:55 UTC