Re: property paths review

On 06/01/2010 9:03 AM, Lee Feigenbaum wrote:
> This is my review of
> http://www.w3.org/2009/sparql/docs/property-paths/Overview.xml in
> discharge of action-169.
>
> Overall, I support publication of th document as-is as First Public
> Working Draft.
>
> ~~
>
> * "The N3 path syntax" is a fragment, and it's unclear whether this is a
> suggestion as a possible alternative, or something else.

Fixed - it's just a reference to note that N3 has the same as property 
pthas for "^"

> * The second issue, about the order of RDF lists, is conflated with the
> issue of access to path lengths. It might be helpful if this were made a
> bit clearer:
>
> """
> * While property paths as currently specified can be used to access RDF
> lists (e.g. rdf:rest*/rdf:first), the Working Group notes that this
> would be more useful if results were returned in the order they occur in
> the RDF list. This presents significant complexity in the context of the
> existing SPARQL algebra.
>
> * The WG has discussed providing access to the length of matched paths,
> which would provide greater functionality but would complicate path
> evaluation. At this time, the WG's primary aim is to specify a core set
> of functionality while not blocking future enhancements.
> ***

Thank you for the text which I have included.

>
> (FWIW, I do not think we should tackle either the order question or the
> path length question at this time, though I realize this leaves the RDF
> list situation somewhat unsatisfactory.)

I agree.

Encoding as triples, then coping  with the consequences, seems to me to 
be the wrong way of approaching it when adding directly list handling is 
also an option.

>
> * In Section 3, what is "elt"? I'd expect that to be "path" instead, but
> maybe I'm misunderstanding?

Added :

  and <i><tt>elt</tt></i> is a path element, which may itself
     be composed of path syntax constructs.

>
> * I support ^ as purely a unary operator, but do not feel strongly about
> it.
>
> * The Path Terminology section introduces two terms (simple and complex
> paths), and the rest of the section reads like design notes. I'm not
> sure how much it adds to the document. I suspect it might be better to
> remove it and just let the introduction, the examples, and the formal
> algebra speak for itself.

Now the document is a time-permitting feature, it's probbaly right to 
remove explicitly pulling out the simple/complex distinction.

I'll leave it in for this publication and remove later.

>
> * "strict SPARQL query" -> "SPARQL 1.0 query" ?

and 1.1 :-)

>
> * I don't think the "Filtering duplicates" example adds much to the
> elucidation of property paths.

I agree. If/when this is incorporated into the main query doc, that can 
certainly go.  I've left it there for this publication and will remove 
afterwards.

> * 5.2 should be split into individual examples.


>
> * I don't recall the most recent discussions around cardinality.
> Currently, the draft says that we only ever get one path between 2 nodes
> in the graph. This seems to conflict with the basic behavior we have in
> SPARQL for "?s ?p ?o", but maybe that's OK and necessary to make
> property path evaluation tractable?

This certainly needs further discussion.  Added to issues.

If you look at { ?s :p ?o } then in SPARQL you get one path for two 
reasons - set of triples and for any BGP, there is are no duplicates. 
This is why I am suggesting looking for one path to give uniqueness of 
the bound variables.  But a BGP with implicit projection (e.g. bnode 
variables) does give duplicates of the named variables.

There may be very many paths so being any to restrict to one is helpful. 
  Path lengths help partially (can still have two paths of the same length).

> Lee

Thanks for the comments,

 Andy

Received on Wednesday, 6 January 2010 11:08:10 UTC