- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 16 Apr 2009 22:08:03 +0100
- To: Lee Feigenbaum <lee@thefigtrees.net>
- Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
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 correctly. >> 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 9AD
Received on Thursday, 16 April 2009 21:08:40 UTC