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

Re: [TF-PP] Property Path FPWD

From: Ivan Herman <ivan@w3.org>
Date: Wed, 16 Dec 2009 11:33:32 +0100
Message-ID: <4B28B77C.6080804@w3.org>
To: Andy Seaborne <andy.seaborne@talis.com>
CC: Souripriya Das <SOURIPRIYA.DAS@oracle.com>, Lee Feigenbaum <lee@thefigtrees.net>, Axel Polleres <axel.polleres@deri.org>, W3C SPARQL Working Group <public-rdf-dawg@w3.org>
Hi Andy,

Here is my review of the Property Path Document. My comments are all
light-weight, meaning that there is no doubt in my mind that the
document can (and should) be published as a FPWD.



- It is probably worth writing a few words more about what property
paths are in the Abstract. The current abstract is, hm, not too

- First paragraph in section 2, "although is the path"->"although if the

- I am not sure what the role of the first table is. Well, it is,
obviously, a table with examples, but it comes a bit out of the blue there.

I would propose to remove it. However, it might be good to add a third
column in the definition table and add simple examples for each feature.

- This is my personal, technical comment and is _not_ a reason not to
publish. With this caveat: I am not fully convinced of the ^elt
notation. Of course it is useful but it also makes the syntax a bit more
opaque, see the confusion we had in the mailing list on the meaning of
elt1^elt2. It is also the only feature that is 'new' v.a.v. the usual
regular expressions that people use with texts...

It may be only a matter of syntax. I would find it more natural to have
something like elt<sup>-1</sup> but that, of course, would not work.
Maybe by putting ^ _after_ 'elt': like elt^ meaning the inverse?

This of course would make the elt1^elt2 syntax not possible but I am not
sure I would care. As an author, I would have not problem writing
elt1/elt2^ instead...

- I am not sure what "A path of length zero connects a graph node to
itself." means in terms of a triple pattern...

- I am not sure I understand "Paths do not need to be anchored at one
end of the other, although this can lead to large numbers of result
because the whole graph is searched." Please clarify...

- As far as I understand Section 5 is the syntax that should be used to
extend the SPARQL language syntax. I thing this is worth emphasizing.

Actually, it may be worth stating (status section?) that the WG may
decide to merge this document with the SPARQL Query Language document

- Section 7: " Cycle detechion" -> " Cycle detection"

On 2009-12-14 11:36, Andy Seaborne wrote:
> Dear reviewer of the Property Paths time-permitting feature,
> There were some comments when I put the xmlspec version into CVS [1]
> which I haven't processed yet, including the lack of clarity as to
> whether it enables new things to be asked that could not be asked before
> (it does - via * and +)
> The question is whether the document in its current state, particularly
> missing the formalism of the feature, is sufficient for a First
> Published Working Draft.
> What I would value from you, as a reviewer, is an early indication of
> whether the WG should publish the property paths doc in this round or
> wait until it is more complete.  In prioritising my WG time, then if
> we're not going to publish this round, then knowing very soon would be a
> great help.
> This document was not published in the last round of documents so I,
> personally, think that the WG should publish something to let the
> community know that the feature is under consideration (time permitting).
>     Andy
> [1] http://www.w3.org/2009/sparql/docs/property-paths/Overview.xml


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Wednesday, 16 December 2009 10:34:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:58 UTC