Re: comments JP-4 how to proceed?

On 21 Feb 2012, at 11:17, Andy Seaborne wrote:

> 
> 
> On 21/02/12 08:54, Axel Polleres wrote:
> > Rethinking of the past Telco, and not having read any further discussion on the mailinglist,
> > I think that some things became clear in the context of comment JP-4:
> >
> > Option 1 is not viable, and Option 2 seems to turn out just too late in the game,
> > particularly since there is little/no resources to spec it out, even if there was two
> > possible implementors (Andy+Matt).
> 
> I willing to spec for 2.1 (DISTINCT modifier on path components) but not
> in the framework you outlined in the telecon which was to produce all
> the spec material, then decide which option the WG will pursue.  I don't
> think people will engage in a process to come up with the necessary
> design on the basis it might all be thrown out based on reasons we have
> before the spec work starts.

Ok, so how do the other s think here? Andy's is the only answer I got.
Given that he volunteers to spec it out, can we have a vote on whether we are 
willing to bring this into the spec (particularly, also as there was a slight majority 
on the call two weeks ago for the DISTINCT() option):
     http://www.w3.org/2009/sparql/meeting/2012-02-14#line0064

(Andy, one question in case: I agree we can't waste his resources at this stage 
specing out things that are eventually not used in the spec, but I could imagine 
that if we go down that route, we *could* end up with this part being 
informative/non-normative, i.e. to not make it binding for implementers, would that 
be ok as a fall-back solution?)

> 
> > So, unless someone jumps up to spec out the feature by the end of the month, the obvious
> > way to proceed seems Option3, i.e. leave things as they are, and put something like ALLPATHS
> > or DISTINCT() around paths as a proposal which could be considered on the future_items
> > list and send a reply along these lines to JP-4.
> 
> Default to unique solutions is a bad design as a holding pattern

I just mentioned the both "ALLPATHS" and "DISTINCT()" as those were the two proposals
in the air for future considerations (bot in the comment and in our discussions). 
But you are right that, in case we put it on the future work items list we should mention 
the perceived agreement that we stick with defaulting to counting semantics, which would only 
leave DISTINCT() as an option.

> - it
> breaks the transformations; it does not do what you might expect because
> the rest of the graph pattern does not produce distinct subsets of
> bindings.  It breaks aggregations.  It does not leave open the way to
> path length handling.
> 
> > Let me know if anyone thinks different.
> >
> > BTW: As for the related comment JP-5, it seems obvious that not all implementations
> > cover the current property-pths semantics uniformly, and that we need to fix this before going to PR.
> 
> ?? That's what the implementation report is about

As I read the process doc, in the entrance criteria for PR we should have two interoperable 
implementations: If what comment JP-5 says, then this is not given at the moment, right? Team?

Axel
 
> 
> > best,
> > Axel
> 
>         Andy
> 
> I have implemented DISTINCT() on paths or path components, now with an
> implementation specific to DISTINCTness.  Available in ARQ development
> build in the extended language.
> 
> http://s.apache.org/UgJ


best,
Axel

Received on Monday, 27 February 2012 12:36:30 UTC