Re: today's SPARQL agenda

On 20/03/12 14:11, Birte Glimm wrote:
> Well, one could also say that DISTINCT can only be put around the
> complete path, e.g.,
> { ?X :a/DISTINCT(:c*)/:b*  ?Y } is invalid, but
> { ?X DISTINCT(:a/:c*/:b*)  ?Y } is ok

Yes but :-)

X/Y can be expanded out and executed as a plain BGP.

DISTINCT(path) requires implementation of "/" specially - for 
entailment, that's may need more illegal queries.

And can spot DISTINCT(:p*) which is particularly easy to do well on if 
it's written with DISTINCT close to * as possible.

 Andy


>
> Birte
>
> On 20 March 2012 15:09, Andy Seaborne<andy.seaborne@epimorphics.com>  wrote:
>>
>>
>> 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 15:08:14 UTC