Re: today's SPARQL agenda

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 10:49:35 UTC