today's SPARQL agenda

Please note that the call today is still one hour earlier for folks not 
in the US.

Sorry for the late agenda.

Let's attack the property paths issue today and see if we have any 
consensus on how to proceed.

Our options that we need to choose from are (I've tried to summarize 
pros (+) and cons (-) below, but apologize if I've mis-represented or 
mis-characterized anything):

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


2) Add DISTINCT(path) and {+}/{*} operators
   + Addresses the commenters' concerns (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


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)


4) Add {+}/{*} counting/not-counting operators only
   + 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 (but not as much as #2)
   - Likely results in a formal objection from the various commenters 
about the counting property path execution complexity issue (based on 
offlist discussion of this option)
   - New design may have unknown interactions between counting and 
non-counting operators in the same path

5) Mark property paths as non-normative
   +/- Not sure if this requires a new last call
   + Lowers implementation burden
   - Removes a significant feature from SPARQL 1.1 Query
   - May lead to formal objections within the working group

Lee

Received on Tuesday, 20 March 2012 05:01:45 UTC