Re: today's SPARQL agenda

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