Re: my comments on the "Property Paths" document

Thanks Andy. I have added some notes inline below. -- Souri.

Andy Seaborne wrote:
> On 11/01/2010 2:42 AM, Souripriya Das wrote:
>> My comments for the Property Paths document:
>>
>>     * Section 2: Outstanding Issues
>>           o [typo] "includeds" => "includes"
>
> Done (and this section will disappear)
>
>>           o [my opinion regarding the "^" operator] exclude its binary
>>             version and keep only the unary version
>
> Noted in the issues section.
>
>>     * Section 3: Path Language
>>           o [typo] "an path element" => "a path element"
>
> Done
>
>>     * overall
>>           o [why not allow variables? is it because it introduces
>>             complexity?] If we do not allow variables, we lose in
>>             functionality because then we cannot *find* the (distinct)
>>             properties connecting two nodes (e.g., via an unknown or
>>             non-fixed length path). [Note: Specifically, we are just
>>             asking for the distinct properties that constitute a path.
>>             We are *not* trying to retrieve the path itself.]
>>                 + Example: {?x (?p)+ ?y}would allow us to find the
>>                   properties (if any) each of which make up a distinct
>>                   path from the source node to the target node. (Note:
>>                   0-length path may not be very useful in this case.)
>
> Wouldn't that be a path with the same property (?p) at each path step? 
> e.g. foaf:knows - so it's not any path from ?x to ?y which is my 
> reading of the text explaining it.  Or (?p)+ means something different 
> from the "sequence of one or more ?p".
>
Yes, ?p+ refers to single-property paths. Specifically, I am talking 
about the case where we do not know the property name at query writing time.

For example, in our data, <John> may be connected to <Raj> via a 
sequence of foaf:knows edges.

If we already knew the property to be foaf:knows, we can find <Raj> and 
probably a few others starting from <John> using
  SELECT ?y {<John> foaf:knows+ ?y}.

But, if we do not know the property and specifically trying to find some 
target object(s) reachable from <John> via single-property paths, we 
could write it as:
  SELECT ?p {<John> ?p+ <Raj>}
We could extend it by substituting <Raj> with ?y and then adding some 
filter conditions to limit ?y.

>>                 + Example: {?x (?p)+/(?q)* ?y . FILTER (?p != ?q)}will
>>                   give us property ?p that make up a single-property
>>                   path between the two nodes, or a property pair (?p,
>>                   ?q) such that a ?p-based path concatenated with a
>>                   ?q-based path connects the two nodes.
>
> Souri - there was a strawpoll of possible starting points for the 
> property path work. This included variables in the property position.
>
> Options:
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0439.html
>
> Strawpoll results:
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0055.html
>
> and discussion in email around that time.
>
> The strawpoll showed most support for not considering variables in 
> path sat this time.  The syntax does not prclude it in the future.
>
I see that option of allowing variables did not have the best support. :'(
>>     * Section 5.2: Complex Paths
>>           o [suggestion] Can we replace the resource, <http://example/>,
>>             used in the second example, { <http://example/>
>>             rdf:type/rdfs:subClassOf* ?type }, with foaf:alice or
>>             something like that.
>
> foaf: is the namespace of FOAF vocabulary.  It would be strange for 
> individuals (e.g. alice) to be in that namespace.
>
> I have changed it to <http://example/thing> in case the concern is the 
> use of http://example/.
That was the concern.
>
>     Andy
>
>>
>> Thanks,
>> - Souri.
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________

Received on Monday, 11 January 2010 20:38:27 UTC