Re: Working Draft feedback items

On Sun, 2005-03-06 at 16:58 +0000, Seaborne, Andy wrote:
>  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.

Yes there are two choices, we picked one for CONSTRUCT without
modifiers.  Flipping between the two choices as our default isn't likely
better so either we do nothing (postpone it) or add a modifier to allow
the one-graph output - CONSTRUCT DISTINCT?    I say postpone to
sparql.next().

> 
> == 2 == LIMIT applies to CONSTRUCT (and DESCRIBE) as a pragmatic error control.
> 
> This is reasonable and has been added.

yes.

> 
> == 3 == request for boolean literals
> 
> The words true and false (no quotes, no type, like numbers) for 
> "true"^^xsd:boolean and "false"^^xsd:boolean

yes.  Looking at my sparql grammar, seems I already had them.  Oops.

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

There is no need to support this triple bloat.  Reification has remained
a bad idea since 1998.

If anything deserves more syntax support in isn't this, it's collections
which helps modern RDF designs such as OWL.

My least negative answer to this is postpone.

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

Postpone.

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

I've implemented A as the only sensible choice I managed to work out
over a few months.  (It's also what Sesame's SeRQL does if I recall
correctly).

Dave

Received on Friday, 11 March 2005 11:33:08 UTC