Re: today's SPARQL agenda

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. 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
>> 
> 

-- 
Steve Harris, CTO
Garlik, a part of Experian
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 0535 7233 VAT # 849 0517 11
Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ

Received on Tuesday, 20 March 2012 13:49:24 UTC