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 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:01 UTC