Re: today's SPARQL agenda

That was how I guessed it worked, as I'd not seen any examples with DISTINCT() embedded in a path.

- Steve

On 2012-03-20, at 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
> 
> 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
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
> Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
> University of Ulm                         Fax:   +49 731 50 24188
> D-89069 Ulm                               birte.glimm@uni-ulm.de
> Germany
> 

-- 
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 14:43:40 UTC