[okfn-help] CKAN fields

Fri Aug 28 17:58:17 BST 2009

2009/8/28 Jonathan Gray <jonathan.gray at okfn.org>:
> Wondered whether it might make sense to have a question mark next to
> CKAN fields (when entering package info) which brings up further info
> on hover over or upon clicking?

Do you want this in the read view or in the edit view. I assume the edit view.

> Especially with respect to new author/maintainer fields - not entirely
> clear what should be put in here. Could we give an example?

Author: author of the package (i.e. the organization which is the
author). So OECD. UN. Joe Bloggs.

Maintainer: who is the maintainer of the package. (If different from
the author). I felt it might make sense to default this to the person
registering it on CKAN in the first instance!

Both of these fields are less important for the general listing aspect
of CKAN and more important for its role as a "Package Index" (for more
on the difference between those see the CKAN "about" page but for
coders it is the difference between freshmeat/softpedia and
PyPI/CPAN/Debian Package Indexes/Repos ...).

The idea is the author allows us to add information about who created
this package in a free-form manner (unlike the url field) -- which
means you have someone to contact and credit regarding the pakage. The
maintainer field is crucial the 'package' aspect of CKAN is this gives
info about who is actually maintaining this package (my preference is
for this to be the CKAN maintainer ...).

One thing I do think, now I am reflecting a bit more, is that we
probably shouldn't have the additional email fields (after all these
can just go in the main field enclosed in <....>).

Should we remove these? Now would be the time ...

> Also wondered whether it could be worth having a "license_url" field -
> for terms of use, copyright or other legal info?

At the moment we cover this information in the notes. What do you feel
is the benefit of the license_url field as a specific field?

(Saying I realize the same could be said of the author/maintainer
stuff -- especially given that we have fields for emails as well!)

Rufus