Re: [TF-PP] Property Path FPWD

Hi Andy,

Here is my review of the Property Path Document. I think the document is 
ready for a FPWD.

Thanks,
Matt

+ In the first paragraph of Section 2: "although * is => if * the path 
is used in a situation where * it's => its * initial points is already 
repeated in a pattern, then this duplication is preserved"
I don't think I fully understand this statement. I assume this means an 
end point of the path appears at another place in the graph pattern. i.e.

{ ?a :p1+/:p2 ?b .
   ?b :p3+/:p4 ?c }

could return many more rows than

{ ?a :p1+/:p2/:p3+/:p4 ?c }

It may be useful to clarify this statement with an example.

+ I don't understand "Example: Reverse path sequence" at the end of 
Section 4.1:
 From the text of the example, it sounds like the following triples 
should be matched:

:Person1 foaf:knows :Person2 .
:Person2 foaf:knows :Person1 .

It seems like { ?x foaf:knows/foaf:knows ?x } should work for this 
query. I don't see why foaf:knows^foaf:knows is needed.

+ A more general comment: a significant subset of Property Path queries 
can be translated to SQL CONNECT BY queries. Would it be worthwhile to 
explicitly
identify this subset? It could be useful for those of us implementing 
triple stores on top of relational databases.

Ivan Herman wrote:
> 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
>>     
>
>