W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2009

Re: SPARQL WG Survey plan - input desired

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Thu, 16 Apr 2009 12:53:50 -0400
Message-ID: <49E7629E.7010702@thefigtrees.net>
To: Steve Harris <steve.harris@garlik.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
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.
> 
>> [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.

> 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".

>> [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
Received on Thursday, 16 April 2009 16:54:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:38 GMT