RE: SPARQL WG Survey plan - input desired



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-
> request@w3.org] On Behalf Of Lee Feigenbaum
> Sent: 16 April 2009 17:54
> To: Steve Harris
> Cc: SPARQL Working Group
> Subject: Re: SPARQL WG Survey plan - input desired
> 
> Steve Harris wrote:
> > On 16 Apr 2009, at 16:53, Lee Feigenbaum wrote:
> >> [1] I'm tempted to use the chairs discretion to not list features
> that
> >> clearly did not receive a critical mass of support in our current
> >> discussions. If we do that, we'll still include features that weren't
> >> discussed at all.
> >
> > That seems reasonable to me.

Agreed.

> >
> >> [2] What's a good number here, if the goal is to end up with a small
> >> set of required deliverables and an approximately equal sized list of
> >> time-permitting deliverables?
> >
> > I would guess that 3 or 4 significant, but not very novel ones is
> about
> > the upper limit, based on experience from DAWG. The situation here is
> a
> > bit different, it feels more like uncharted territory as many of the
> > suggested features don't have a sufficient number of implementations.
> On
> > the other hand we have to fit in with existing SPARQL syntax and
> > semantics, which should make things quicker.
> 
> I agree with all this, and with the number. My question was more -- how
> many should we each rank to try to end up with enough "support data
> points" to pick out roughly 4 features as required deliverables? That's
> where my 8-10 number came from.

Good - when I read 8-10 I thought "too many", then I thought "some are much bigger than others".  SPARQL/Update looks large to me. So how the feature set fits together matters.

So pick a candidate set which is refined to a set we actually work on looks like a good process.  The final set has 2 halves for "do now", then "do if time remains" and I'm assuming that there will be time for at least some of the second-stage items.  That is, the "do now" set is planned to be easily achieved in the timescale permitted and consists of things we really ought to do (and there is good implementation experience).  Anything without the experience is more likely best put in the "do if time remains" subset.

> 
> > To complicate it further, some features work as natural and simple
> > extensions to other ones, eg. if we choose to tackle subqueries for
> > example, then negation (UNSAID etc.) is an obvious and straightforward
> > addition, but taken in isolation, it's probably a pretty big task to
> > specify either.
> 
> Right, and these sorts of pairs that go well together is one of the main
> reasons that I don't want the survey to drive the final decision on its
> own; I prefer people to look at the results and say "oh, there seems to
> be a bunch of agreement around this, and if we do these two things then
> there's a good synergy".

Agreed.  The survey does not mechanically produce the final decision.

> 
> >> [3] Would it be better to solicit one ranked list from each
> respondent
> >> with the goal being that those features receiving the "2nd tier" of
> >> support will be time-permitting features, or would it be better to
> >> have two separate questions (1. required features, 2. time-permitting
> >> features) on the survey? I lean towards the former.
> >
> > I would prefer to rank them, but I anticipate it being difficult to
> > interpret the results meaningfully, unless there's more consensus that
> > we saw in the straw polls.
> 
> We'll see. I remain naively optimistic :-)
> 
> Lee

 Andy

Received on Friday, 17 April 2009 13:10:12 UTC