Re: [TF-PP] Property Path FPWD

Hi Axel,

Thanks for the comments,

On 22/12/2009 9:59 AM, Axel Polleres wrote:
> (late reply, sorry) In general: +1 to publish "as is" rather than not publish.
>
> 1) I agree that some works about where propoerty paths fit in should be added in the abstract,
> even if only copying the one sentence from the intro for the moment.

Done.

>
> 2) As for the notation for inverse, how about just (pre- or postfix) "-" instead of "^"?
> However then the shortcut  "elt1 - elt2" instead of "elt1 ^ elt2" would admittedly look
> a bit awkward.

Gets confusing because "-" is the start of -1 as well.  The design 
follows N3 for "^" so there is some experience here.

"\" is also a possibility (but ugly embedding in programming language 
strings).

>
> 3) I think that the shortcut elt1 ^ elt2 is anyways a bit strange... whouldn't we just
> have generally:
> "elt1  elt2 ... Shorthand for elt1 / elt2"

That (no "/") can make for very confusing patterns because it introduces 
variable length tuples for parsing. Given turtle abbreviations anyway 
";" and ",", having juxaposition seems to introduce easy mistakes.

> We may need to decide on a default precedence here, brackets should be used to indicate other precedence?

Section 2 has the precedence and has ().

	Andy

>
>
>
> All for now, more details to follow,
> Axel
>
>
> On 16 Dec 2009, at 10:33, 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
>>
>> --
>>
>> 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
>>
>
>
> ______________________________________________________________________
> 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:13 UTC