[okfn-help] International development data on CKAN

Thu Dec 3 10:13:30 GMT 2009

Ben,

Pleased to meet you! It sounds excellent to get the IDD onto CKAN.
Here are some pointers (see below), but feel free to ask more. All the
best,

David

> It would be great if this could be done either via CKAN (and then
> published on an external website with basic querying functionality),
> or at least published in a form that meant copies of the profiles
> could go onto CKAN.

Yes, do link up with our API data to get data into and out of CKAN. If
you've not already, see: http://ckan.net/api/

>  * Currently we have several fields that it would be good to import
> into CKAN preserving some structure (rather than just adding to free
> text field). I understand CKAN can now support arbitrary metadata. Is
> this the same as the key/value pairs?

Yes, see the 'extras' field in a package. The key and value is free
text. Structure the value field as you see fit.

> If so can we have more than the
> three that come up on web interface?

You can use as many as you like. In the web interface, when you run
out of fields, hit 'preview' to get some more.

> It would be great to use this
> functionality for our data profiles. For example, we have fields with
> dates and associated country names - which are probably fairly generic
> fields. Some have many country names associated with them. Perhaps we
> could use appropriate ISO values?

We're currently evaluating using Ordnance Survey ontologies but
geography in the UK (with the current focus on UK government datasets)
but not clear yet on what to use abroad.

Rufus mentioned you might be interested in temporal fields and it
certainly looks like we'll have some for the government data.

>  * In some areas changes to our model would be quite simple. E.g. we
> currently have a 'contact information' field. We could create a
> separate email address field which could correspond to the 'owner
> email ' field or 'maintainer email' field in CKAN. What is distinction
> between owner/maintainer here?

Our intention is that 'Author' is the original creator of the data. If
the Maintainer is different to the Author then supply Maintainer too.

>  * Regarding license field, we currently have 'OKD compliant' as
> Yes/No field. Would probably better to use something to correspond
> with drop down menu in CKAN menu. Would a number be best here? If so,
> is there a list that we can use to link numbers to items in the menus?

There is an ID for every license (license_id is there but undocumented
in the API), but I fear it's best not to make a dependency on that. So
I suggest just using the text name of the license.

>  * Generally, I wonder whether it would be worth looking to existing
> standards and guidance for this. Especially where fields may be
> generic. It would be great to ensure the fields in our profiles comply
> with standards, where standards exist. I wonder whether this has been
> thought about in relation to government data? Should we be looking to
> Dublin Core? Are there other metadata standards we should examine?

A few weeks ago we copied ckan.net packages to an RDF store and you
can look at the ontologies used here:
http://api.talis.com/stores/ckan/meta?about=http%3A%2F%2Fckan.net%2Fpackage%2Frdf%2F32000-naples-florida-businesses-kml
This is still experimental, so things could well change soon.