Property Path Update (doc issues)

These are the issues in the document:


* The use of "^" as a unary and binary operator may be confusing.

In the N3 community "^" is binary (and you can't say ":x ^foaf:knows 
:y").  In N3, things are more resource-centric and you can write paths 
in the subject and object locations of a "triple".  The property path 
design is arc-centric.

The WG tends towards "^" being unary and having to write "/^". I think 
we should not invalidate the N3 style completely when it is just a 
matter of syntax.

This is only about syntax.  It does not change the operators.


* While property paths as currently specified can be used to access RDF
  lists (e.g. rdf:rest*/rdf:first), the Working Group notes that this
  would be more useful if results were returned in the order they occur
  in the RDF list. This presents significant complexity in the context
  of the existing SPARQL algebra.

I don't think there is anything we can do about this.  It would be a 
much wider change to SPARQL, roughly, for every algebra operator, say 
what its effect on ordering is, but that is not a change to SPARQL 1.0 
because the order can't be set except by ORDER BY and that's at the top 
level of a SPARQL1.0 query.

See also ORDER BY in sub-SELECTs in SPARQL 1.1


* The WG has discussed providing access to the length of matched paths,
   which would provide greater functionality but would complicate path
  evaluation. At this time, the WG's primary aim is to specify a core
  set of functionality while not blocking future enhancements.

Currently, we aren't considering explicit lengths.  No time.


* How does this interact with inference when SPARQL is used with systems 
carrying out inference as part of query processing?

Proposal (RDFS, RIF?): it's equivalent to walking the virtual triples.

I don't know about OWL, DL or Direct.


* Paths expressions match once even if there are multiple possible paths 
between two points (c.f. SPARQL BGP)

((Discussed in other email.))

 Andy

Received on Tuesday, 16 March 2010 10:00:22 UTC