[okfn-help] CKAN user requirements half-day?

Fri Jan 15 11:12:01 GMT 2010

2010/1/14 Antti Poikola <antti.poikola at gmail.com>:
> Hi Jonathan and others,
>
> I will forward this email to the opengov_data developer list:
> opengov_data at googlegroups.com
>
> Jussi Arpalahti made recently a quick review on the CKAN codebase and
> hopefully shares his thoughts with you guys.

That would be great. opengov is very nice and it would be to have
feedback. I've just attached a full domain model listing for CKAN that
may assist in understanding it :) (this is just ckan/model/ stuff but
brought together in one file).

> Basically it seems that opengov is so far much lighter and simpler
> implementation that CKAN. CKAN is more datawarehouse oriented where the

I would imagine that opengov is more lightweight but most of the extra
"complexity" in CKAN comes from extra features:

  * Arbitrary metadata about packages (this is something everyone
seems to want beyond the basic stage and is the only way to accomodate
different sets of users with different sets of metadata)
  * Versioning of all metadata so that you can allow users to edit the metadata
  * Ratings and groups
  * Fine-grained authorization for packages and groups
  * Full text search

I've attached a full domain model dump in the form of DB table
listings for CKAN (in python). The opengov-catalog domain model I take
to be here:

http://code.google.com/p/opengov-catalog/source/browse/trunk/project/catalog/models.py

That has: Dataset (Package), Topic (Tag), License and 3 other tables
(Organization, Format etc) which would go in our package extras.

Correspondingly we have: Package (+ PackageExtra, PackageResource),
Tag and License -- which is practically identical except for the
Package Extras and Package Resource which are both additional features
that have been added due to user needs.

All the other tables provide additional features. I would imagine that
as opengov.se gets more fully featured it will grow in complexity in a
similar way :)

> opnegov is more usercommunity and UI oriented, though, not yet fully
> implemented. In my opinion replicating things in two projects (developing
> community approach, discussion and UI in CKAN or developing advanced data
> directory related features in opengov) should be avoided if possible. On the
> other hand putting two systems in one stack is not allways so straight
> forward.

CKAN has a lot of UI and user community stuff already -- in fact that
is where much of the complexity is coming from. For example:

  * Versioning is essential in allowing average users to participate
and edit information
  * Groups and ratings

> Of course this question goes beyond technology and the vision for good data
> catalogues should be developed further. In Finland we have some financial
> backing for developing the opengov further and I might be able to get some
> more for something useful, but before that I would like to push more the
> development of "international data catalogue builder community".

Completely agree. One of the things we're currently thinking about,
given the versioned domain model in CKAN, is whether we can push and
pull changes between different CKAN instances in the way distributed
version control systems do. However, I should emphasize that a
concrete implementation is likely some way off :)

> So I suggest that (in this order):
>
> 1. Jussi shares his questions and thoughts for this group.
>
> 2. One of the CKAN developers takes a quick look at the opengov code base:
> http://code.google.com/p/opengov-catalog/

See comments above -- though I've only looked through model in detail
(the rest looks to be standard django)

> 3. Before going to wiki, let's have an 1,5 hour data catalogue visioning
> session at Skype+Etherpad. After points 1 and 2, if there is interest for
> this point 3, I can coordinate the scheduling.

That sounds good.

Rufus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: domain_model.py
Type: text/x-python
Size: 10562 bytes
Desc: not available
URL: <http://lists.okfn.org/pipermail/okfn-help/attachments/20100115/8ba30e81/attachment.py>