Re: [TF-PP] Property Path FPWD

Ivan,

Thank you for the comments.  Changes in response to them noted inline.

 Andy


On 16/12/2009 10:33 AM, 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:-)

:-)

A few words added - additional material welcome.

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

Done.

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

Removed first table.- but can we leave the examples to section 4 because 
one extra column isn't much space?

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

N3 also has this unary/binary operator.

Personally, I don't mind having to write "/^" but there is experience 
for such a form.  The application does not have to use it, of course.

> 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?

See again the N3 experience.  Indicating it's the inverse before reading 
on, is, IMO, better than afterwards (given that superscripts are right out!)

We ought to pull this out as an explicit issue.

Editor's issue section added.

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

?x :p* ?y needs a meaning.  :p* can appear in more complex paths 
(rdf:first*/rdf:rest).

Working backwards from e.g. ?list rdf:first*/rdf:rest ?elt, ?list 
rdf:first* ?x would match with ?x equal to whatever ?list is.

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

The case of variables for subject and object.

Typo:
"one end *or* the other"

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

Text added.

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

Done.

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

Done.

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