[okfn-help] Introduction to the list

Mon Jan 11 00:01:22 GMT 2010

Hi Antti!

A few answers to some of your questions to get things started. I hope
other CKAN people will pitch in with more detail...

On Sat, Jan 9, 2010 at 1:31 PM, Antti Poikola <antti.poikola at gmail.com> wrote:
> 1. What is CKAN
> (some sort of standard / software backbone to build datacatalogs that are
> interoperable. In my understanding with CKAN you get also the very basic UI
> for browsing the entries etc, but you can use CKAN also behind the scenes
> and have your custom interface)

Rufus Pollock has just put together a list of CKAN's main features at:

  http://knowledgeforge.net/ckan/trac/wiki/WikiStart

> 2: Why CKAN and what are the other choises/options that should be
> benchmarked
> (CKAN is one approach promoted for wider use by the open knowledge
> foundation. The other choise is to build your own standalone system "out of
> your head" in which case it is not directly interoperable with any other
> data catalog. On the other hand CKAN is not yet any technology or de facto
> standard and there are not so many other catalogs that operate with CKAN.
> What is still unclear for me is that is it possible to make your own catalog
> and only a CKAN-compatible interface which enables the data transfer between
> the catalogs?)

Even though this is relatively new, I think there are several distinct
advantages to using CKAN, including (but not limited to!):

  (i) Structure and versioning. On the one hand you can use something
like a wiki, which are often editable by anyone and versioned. But
this may not give you a great deal of structure. On the other hand you
may use an existing CMS or build something bespoke which allows for
structured querying. But then you may not be able to see the history
of each page. I think one thing that may make CKAN attractive is that
it has the best of both worlds. It is fully versioned which means that
for any page you can view the history of changes. This is ideal for
something that is driven by the the public (and partly what makes
Wikipedia work!). Anyone can edit any page, and changes on any page
can be tracked - and if necessary undone. It also has structure - and
supports arbitrary metadata fields - so you can add in additional
'fields' if you want to. This allows you to, e.g. query for all 'open'
packages tagged 'geodata' or all packages with a download URL, that
are open that are tagged 'uk' and 'science'.
  (ii) It has a documented API and allows all material to be downloaded in bulk.
  (iii) It is both open source and actively supported. It has a home
at the OKF, and we will continue to support it indefinitely into the
future. We warmly welcome suggestions for changes or requests for
features.
  (iv) There is a command line client! (This may be very useful for
developers...)
  (v) We are already working on internationalising (i18n) CKAN.
  (vi) It can be rethemed and integrated with other resources.

> 3: What it actually means if one decides to use CKAN in her own catalog
> project?
> (It is propably quite straight forward to deploy a new instance of CKAN from
> the open source codebase, but in the case of using CKAN as the backbone in
> other system, or just building CKAN compatible interfaces, I have no
> idea...)

We are happy to help support people who wish to set up their own
instance of CKAN.

> I have one request for you, the CKAN developers, could you please examine
> the codebase of opengov.x and evaluate the possibilities to unite opengov
> with CKAN. I have tried this otherway round to get the developers here
> exited about CKAN and evaluate that code, but unfortunately I am not in the
> position of forcing them to do that. In order to get the things moving I
> decided to try this approach. In my mind opengov could be the Django based
> user Interface while CKAN would work as the python based core of the system.
> The ideology behing opengov.x is that the developer community of any country
> or city could easily establish their light weight datacatalog in case if the
> official catalog is missing. Other main objective is to build a "home" for
> the developer community where the ideas of possible applications, data needs
> etc. could be discussed.

I'm not sure about this one!

Best wishes,

Jonathan

> Jonathan Gray wrote:
>>
>> A few thoughts on language metadata in CKAN...
>>
>>  * I think a standard field for language of resource in CKAN might be
>> useful. Perhaps based on ISO 639 or similar? Most obviously useful for
>> corpora - such as collections of texts, dictionaries and so on, but
>> I'm sure there are many more potential uses of this field. We are
>> already starting to use 'language-' tags.
>>  * What about information on the language of the package description
>> (and so on) in CKAN? E.g. we might have a whole new bunch of packages
>> from de.ckan.net that we wish to  add to ckan.net. We may wish to have
>> basic metadata the same (short name, URL, license, etc.) but different
>> translations of the description. While I'm sure this could be
>> approached on a case by case basis in the first instance (soon we will
>> have material in English and German - later possibly in French,
>> Finnish, Swedish, ...) in the longer term it may make sense to think
>> about how we can deal more systematically with package descriptions in
>> different languages. My guess is English will continue to be the main
>> language of CKAN, but worth thinking about how CKAN can be a truly
>> multilingual resource in future.
>>  * This more a hypothetical question than an immediate concern - but
>> any thoughts about translating tags? I would imagine for a number of
>> reasons this would be totally non-trivial.
>>
>>
>
>

-- 
Jonathan Gray

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