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

Re: SPARQL WG Survey plan - input desired

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 16 Apr 2009 22:08:03 +0100
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <08DE2F28-B86F-49B9-AD81-006482A6A03E@garlik.com>
To: Lee Feigenbaum <lee@thefigtrees.net>
On 16 Apr 2009, at 17:53, Lee Feigenbaum wrote:
> 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.

Ah, sorry, I misunderstood. Well, it depends whether the ranking  
method, doesn't it? If we use something like Condorcet then there's no  
problem with people voting for as many as they care to, if I remember  

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

Alternatively it may be possible to pick out these groupings upfront,  
but maybe that's assuming too much common ground, for example I know  
that Eric P. is not convinced that aggregates and subqueries  
necessarily go together.

>>> [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 :-)

It's not that I don't think there is/can be consensus, just that it  
may be hard to determine at this stage, but good luck with that :)

- Steve

Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
Received on Thursday, 16 April 2009 21:08:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:56 UTC