- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 16 Dec 2009 11:33:32 +0100
- 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>
- Message-ID: <4B28B77C.6080804@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. Cheers Ivan - It is probably worth writing a few words more about what property paths are in the Abstract. The current abstract is, hm, not too informative:-) - First paragraph in section 2, "although is the path"->"although if the path" - 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 eventually. - 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 16 December 2009 10:34:09 UTC