W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

my comments on the "Property Paths" document

From: Souripriya Das <SOURIPRIYA.DAS@oracle.com>
Date: Sun, 10 Jan 2010 18:42:20 -0800 (PST)
Message-ID: <61a8b01d-cbf0-4832-8f17-dee634b9d5a9@default>
To: <public-rdf-dawg@w3.org>







My comments for the Property Paths document: 


    • Section 2: Outstanding Issues 


        • [typo] "includeds" => "includes" 
        • [my opinion regarding the "^" operator] exclude its binary version and keep only the unary version 
    • 
Section 3: Path Language 

        • [typo] "an path element" => "a path element" 
    • overall 


        • [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.) 
            • 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. 
    • 
Section 5.2: Complex Paths 

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

Thanks, 
- Souri. 
Received on Monday, 11 January 2010 02:42:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT