Re: [TF-PP] Property Path FPWD

Hi Andy,

On 2010-1-4 13:11 , Andy Seaborne wrote:
>> - 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.

It works for me now. We should not make a big deal out of it...

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

You mean move the table to section 4? Works for me

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

Yeah. How widely is used is another matter. It has not been adopted to
Turtle, which is already a sign...

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

I would actually put the very existence of '^' as an issue. I am not
fully convinced it is necessary or all that useful.


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

Hm. Alternatively, ?x :p* ?y would not match anything with length zero?

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

:-) Got it.




Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:
FOAF   :
vCard  :

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