[okfn-help] Introduction to the list

[Antti Poikola]

Hello all CKAN developers,

I am new to this list, Antti Poikola from Finland.

Currently in Finland we have two datakatalog projects slowly but 
steadily moving on and personally I believe having opportunity to some 
extent influence both of them.

#1
One is the national more official datacatalog where all the entries are 
validated by people working for the government... this will appear 
somewhere in the national portal called suomi.fi (Suomi is finnish and 
means Finland)

#2
Second one is a more developer- and community oriented catalog 
opengov.fi where anyone may add entries and details, this will not be 
restricted to "Public Sector Information", but all usefull resources 
from the public, private and third sector are wellcome. Other difference 
to the official catalog is that here could be identified also data 
sources that are not yet open, but should be.

#3
Third one might come later as the regional catalog for the Helsinki 
region (14 independent municipalities), but this is so far only a vague 
idea.

The different catalog projects have their needs, but in the end of the 
day all catalogs should work technically togeather so that there is no 
need for manual copy-paste. Basically the entries in official catalog #1 
are a subset of entries in the developer community catalog #2. I have 
recommended CKAN for the developers of #1 and #2 but haven't got any 
stratight answers. As I am not a developer myself I feel that I would 
need stronger tools for communication. I think that I sort of understand 
what CKAN is, but it seems that I am not capable to communicate it further.

Basically the questions (and my current understanding) are:

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)

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?)

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

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.

Best regards,
Antti Poikola

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