[okfn-help] Fwd: CKAN user requirements half-day?
jonathan.gray at okfn.org
Mon Jan 18 19:49:02 GMT 2010
---------- Forwarded message ----------
From: Jussi Arpalahti <jussi.arpalahti at gmail.com>
Date: Mon, Jan 18, 2010 at 7:31 PM
Subject: Re: CKAN user requirements half-day?
To: opengov_data <opengov_data at googlegroups.com>
On Jan 14, 8:43 pm, Antti Poikola <antti.poik... at gmail.com> wrote:
> 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.
> So I suggest that (in this order):
> 1. Jussi shares his questions and thoughts for this group.
The following is a rough overview I did on CKAN based on its web site,
development wiki and a cursory look at the source code.
CKAN is lacking technical documentation for the application structure
and I have yet to dive deep in
it. It's based on a Python web framework called Pylons that is by my
guestimate not nearly as popular as Django. It is said to be more
and customizable, which can be good or bad, depending on your usage
scenario. I prefer Django for its easy approachability.
Opengov_catalog and CKAN have some overlapping concerns, but they also
provide for different features. Catalog is more like a website, I
CKAN looks like a directory. It is possible to bring CKAN features to
catalog or vice versa, but combination of the two can be problematic.
Django's side it depends how much CKAN relies on Pylons web
CKAN's dataset component would supercede catalog's. Pylons very
has functionality for catalog's blog app, but how that would be
CKAN I don't know.
In CKAN the dataset record can be written in any language, but I see
support for direct translations. Perhaps different languages' records
CKAN's L19N seems to use gettext, like Django. There is only a partial
french translation. I don't know how good is Pylons support for
Opengov_catalog is (at the moment) much simpler than CKAN in the API
department. On the dataset part I think catalog is actually better off
its discussion option and suggestion form.
If we decide we need the versioning and flexible schema properties
CKAN, then there is not much point to re-implement them in catalog.
probably use CKAN's code from Django directly, but if code has Pylons
dependencies, there might be conflicts with Django's expectations.
for versioning records from database does exist as a Django app
CKAN's schema modifications look like old fashioned key-value pattern,
tags with values.
I'd like to know how popular CKAN is with its users and outside
It feels perhaps too large a program for the intended use case.
catalog would work as a platform for gathering information about
datasets that could be then transferred to CKAN for more complex usage
needed. If CKAN is already a healthy open source project with
backing it could be more sensible choice futurewise.
In summary I don't immediately see CKAN as a full replacement for
I fear that coexistence in the same software stack would be
wouldn't like to replicate CKAN's functionality in catalog, but that
depends mainly on usage scenarios we choose to support. Catalog could
support CKAN API for data import and export. For better analysis a
detailed look to CKAN code structure is needed.
The Open Knowledge Foundation
More information about the okfn-help