Re: my comments on the "Property Paths" document

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

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

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

 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 10:28:01 UTC