Options on Property paths

Dear all,
 
thanks Andy and Greg for further clarifying the discussion.
 
Let me try, along the lines of http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0262.html to summarize the options on the table (I left out option 4, since it was canceled out before being voted upon in the Telco 2 weeks ago and added options 6 and 7 as discussed in the mail, as well as option 8 (which was "in the air" in the last telco if I understood it correctly). As to Lee's earlier summary, I added the votes two weeks ago, as well as an item estimating the danger of "lock-in".

(will send a proposed way forward in a separate mail, since I have to send regrets for the upcoming telco)
 
 
1) Leave as is, no change
   + Does not require a new last call
   + Does not open up any potential _new_ issues from aspects of new 
design(s)
   - Almost surely results in a formal objection from the various 
commenters about the counting property path execution complexity issue
   - Potentially hamstrings some use cases of property paths, depending 
on whether all non-counting pp instances can be rewritten as SELECT 
DISTINCT subqueries
  - lock-in to counting semantics as default
  - Strwapoll on http://www.w3.org/2009/sparql/meeting/2012-03-20 : 
       2 x +1
       6 x 0
       1 x -1 (Paul)
 
 
2) Add DISTINCT(path) and {+}/{*} operators
   + Addresses the commenters' concerns JP-4(as per informal discussions 
with some of them offlist)
   + Gives query authors significant expressivity in choosing the path 
counting semantics vs. performance tradeoff they want
   - Requires a new last call
   - Raises the burden to implement property paths
   - New design may have unknown interactions between counting and 
non-counting operators in the same path
  - Strwapoll on http://www.w3.org/2009/sparql/meeting/2012-03-20 : 
      2 x +1
       6 x 0
       1 x -1 (Steve)
  
3) Add DISTINCT(path) only
  + Addresses the commenters' concerns (as per informal discussions 
with some of them offlist)
  + Gives query authors some expressivity in choosing the path counting 
semantics vs. performance tradeoff they want
  - Requires a new last call
  - Raises the burden to implement property paths (but not as much as #2)
  - lock-in to counting semantics as default (new: raised by greg)
  - Strawpoll on http://www.w3.org/2009/sparql/meeting/2012-03-20 : 
      8 x +1
      2 x 0


5) Mark property paths as non-normative
   +/- Not sure if this requires a new last call
   + Lowers implementation burden
   + no lock-in to counting- or non-counting semantics for future specs
   - Removes a significant feature from SPARQL 1.1 Query
   - May lead to formal objections within the working group
   - Strawpoll on http://www.w3.org/2009/sparql/meeting/2012-03-20 : 
      6 x 0
      3 x -1 (Andy, Matt, Paul)
 
6) change the semantics of * and + only, leave everything else as in LC, cf.
    http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0285.html          
    http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0286.html
    - Requires a new last call
    - May lead to formal objections within the working group?
    +/- unsure whether it addresses commenters (mixing counting and non-counting)
    + more intuitive for common reachability use cases than option 3

7) Add ALL(path) only, and change default to DISTINCT(path)
    - Requires a new last call
    - May lead to formal objections within the working group?
    - lock-in to non-counting semantics as default
    + addresses commenters (for sure JP-4, who suggested this, not sure about JB-10, WM-1)
    + more intuitive for common reachability use cases than option 3

8) Add ALL(path) and DISTINCT(path), and one alternative being obligatory
    - Requires a new last call
    +/- May lead to formal objections within the working group? (not sure)
    + no lock-in to counting or non-counting semantics as default
    + probably addresses commenters (for sure JP-4, who suggested this, not sure about JB-10, WM-1)

----------------------


-- 
Dr. Axel Polleres 
Siemens AG Österreich 
Corporate Technology Central Eastern Europe Research & Technologies 
CT T CEE 
 
Tel.: +43 (0) 51707-36983 
Mobile: +43 (0) 664 88550859
Fax: +43 (0) 51707-56682 mailto:axel.polleres@siemens.com

Received on Sunday, 1 April 2012 20:32:53 UTC