Re: [TF-PP] Property Path FPWD

Hi Matt,

Thank you for the comments ...

On 21/12/2009 9:43 PM, Matt Perry wrote:
> 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.
>

This is probaly not the right place in the document to get into some 
detail anyway - it should be left until the formal section and I've 
removed it.

The issue is

{
    some pattern .. leading ?a=:a  more than once ...
    ?a :p1+/:p2 ?b
}

and say :a leads to :b via :p1+/:p2

will (it's a join) give ?a=:a ?b=:b more than once, as it would for any BGP.

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

Good point.  The example is just plain wrong.

Changed.

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

How about writing up the cases and positing them to the WG mailing list?

CONNECT BY is a feature of Oracle.   I believe the same can be achieved 
with WITH (common table expressions).

As to the general issue, it's also possible for anyone to blog or 
otherwise write up various implementation techniques.  The WG can't 
validate each approach in the time available and I'm wary about picking 
out one example without a through investigation.

 Andy

>
> 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
>>>
>>
>>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________

Received on Monday, 4 January 2010 12:12:10 UTC