- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 20 Mar 2012 14:09:31 +0000
- To: Steve Harris <steve.harris@garlik.com>
- CC: public-rdf-dawg@w3.org
On 20/03/12 13:48, Steve Harris wrote: > Though I haven't implemented it, so there's a lot of guesswork going on, I don't think I agree. > > (2) adds extra syntax, and allows for a mixture of approaches in one path. So does just DISTINCT(path) if I understand it: e.g. { ?X :a/DISTINCT(:c*)/:b* ?Y } Andy > My preferred implementation, if both were supported, would be to > have one counting, and one non-counting implementation and handoff the the appropriate one - this generally makes optimisations easier. c.f. DISTINCT/REDUCED v's not queries. > > - Steve > > On 2012-03-20, at 10:48, Andy Seaborne wrote: > >> 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 14:10:06 UTC