[ckan-discuss] What open data projects could use storage/bandwidth? (Proposal for 'Open Data Labs')

[Rufus Pollock]

On 7 July 2010 22:53, Tim McNamara <paperless at timmcnamara.co.nz> wrote:
> On 7 July 2010 23:54, Jonathan Gray <jonathan.gray at okfn.org> wrote:
>>
>> Hi all,
>>
>> We (Open Data Network / Open Knowledge Foundation) currently have an
>> opportunity to receive support for storage and bandwidth for open data
>> / open government data related projects which need it.
>>
>> We have started brainstorming on a project tentatively dubbed 'Open
>> Data Labs', which would be an umbrella project for various bits and
>> pieces we need storage/bandwidth for. We are currently brainstorming
>> for things which we could use this for -- so if you have any ideas,
>> please add them to:
>>
>>  http://okfnpad.org/opendatalabs

[...]

> time:
>  - what time is it anywhere in the world (largely complete)
>  usecase: what time will it be in Chile in 47h, 34mins from now?
> cities:
>  - lists of radio stations, etc: GPS coordinates of things in openstreetmap
> economy:
>  - country & regional statistics
> health:
>  - mainly stats
>
> Yes- lots of these things are solved problems. However, I want to make it
> easier for people to create visualisations & wider applications - basically
> by removing the need to create a database. If they can get started with HTTP
> calls, they reduce the time to get a working prototype.
>
> Am I duplicating effort? Does this seem worthwhile?

I can't answer this entirely, but I certainly think maintaining small
individual datasets/services that do one thing, and one thing well is
very valuable. Furthermore, the glue to put together different
datasets/services can themselves be additional small
datasets/services.

I'd suggest, initially, focusing on one particular (ckan) data package
(or maybe packages) in a given area, and focus on making that a really
good data package and perhaps building a service on top of it (I'm
big, as you can tell, on data before services ...).

We've long thought about the concept of having CKAN package
maintainers like you have debian package maintainers. The crucial
point, in my mind, about a debian maintainer is that it is not their
job to maintain the underlying piece of software but rather to rather
to "package" that software up (make sure it up to data, that it
compiles with other stuff, that has a standard way to be installed
etc). That's what CKAN maintainers would be: people making sure the
data was fit for purpose, that it downloaded and "installed" etc (not
people, necessarily making the original data -- though just like
debian in some cases the two people would be the same).

Rufus