Re: today's SPARQL agenda

I'll have to send my regrets as I'm at the AMIA TBI 2012 this week and
won't be able to attend the SPARQL WG teleconference tomorrow.

On Tue, Mar 20, 2012 at 1:01 AM, Lee Feigenbaum <lee@thefigtrees.net> 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 05:30:23 UTC