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

[Jonathan Gray]

---------- 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.
<snip>
> So I suggest that (in this order):
>
> 1. Jussi shares his questions and thoughts for this group.
>
<snip>

Hi.

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
powerful
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
think.
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.
On
Django's side it depends how much CKAN relies on Pylons web
environment.
CKAN's dataset component would supercede catalog's. Pylons very
probably
has functionality for catalog's blog app, but how that would be
crafted on
CKAN I don't know.

In CKAN the dataset record can be written in any language, but I see
no
support for direct translations. Perhaps different languages' records
can be
linked somehow.

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

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
with
its discussion option and suggestion form.

If we decide we need the versioning and flexible schema properties
like
CKAN, then there is not much point to re-implement them in catalog.
One can
probably use CKAN's code from Django directly, but if code has Pylons
dependencies, there might be conflicts with Django's expectations.
Support
for versioning records from database does exist as a Django app
already.
CKAN's schema modifications look like old fashioned key-value pattern,
like
tags with values.

I'd like to know how popular CKAN is with its users and outside
developers.
It feels perhaps too large a program for the intended use case.
Perhaps
catalog would work as a platform for gathering information about
country's
datasets that could be then transferred to CKAN for more complex usage
as
needed. If CKAN is already a healthy open source project with
financial
backing it could be more sensible choice futurewise.

In summary I don't immediately see CKAN as a full replacement for
catalog.
I fear that coexistence in the same software stack would be
complicated. I
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
more
detailed look to CKAN code structure is needed.


Jussi



-- 
Jonathan Gray

Community Coordinator
The Open Knowledge Foundation
http://www.okfn.org

Twitter/Identica: jwyg