- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 20 Mar 2012 10:48:58 +0000
- To: public-rdf-dawg@w3.org
Lee - Excellent summary. A small point: The implementation issues of (3) are as (2) because DISTINCT(path*) is non-counting path*. It's currently mentioned in the editors working draft. We could even define it that way but I have currently singled out so we can help implementer by giving an algorithm which does significantly better than distinct-of-counting-path. Andy On 20/03/12 05:01, Lee Feigenbaum wrote: > 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 10:49:35 UTC