[ckan-discuss] Questions and comments about package/group maintenance

Mon Jul 12 12:25:07 BST 2010

On 10 July 2010 19:06, Richard Cyganiak <richard at cyganiak.de> wrote:
> Hi,
>
> A few comments and questions on ckan.net, from a package/group maintainer's
> point of view.
>
> Comment: Adding a package to a group should be possible from the package's
> page. Currently one has to go to the group page and click "edit", then
> copy-paste the package name into a field. That's inconvenient.

Noted and this has already been brought up before so it's clearly
something to fix. Why this hasn't been done yet (and wasn't done
initially) is the permissions to edit a package and the permissions to
add it to a group are very different (only group admins can add a
package to that group while most people can edit a given package).

> Comment: The search box should be accessible from every page, not just from
> the home page. The extra click becomes quite annoying when one has to search
> a lot. (Or please at least place a "search" link somewhere on every page.)

This has just been done :) <http://knowledgeforge.net/ckan/trac/ticket/356>

> Question: Are there guidelines for naming packages? Around capitalization,
> abbreviations, what to put in or leave out?

Not really. I think, in general, we more guidance on the package
new/edit form about what the conventions for things are.

> Question: How to treat packages where the data is originally created by one
> party, then re-packaged in a different format elsewhere on the web by
> another party? That's quite a common case in the RDF/LOD world. In several
> cases, the same data has even been re-packaged multiple times by different
> parties. Should I create a package for the original data and one for (each
> of) the re-packaged version(s)? How do I indicate the original source?

Either:

a) Create separate packages for original and derived datasets and use
package relationships (not yet in edit page in WUI but stably in REST
interface, WUI view and backend for several months)

b) Have one package (probably for LOD) dataset and just mention in
notes where it came from.

> Question: A lot of the tags used in ckan.net appear to have very specific
> meaning (todo.list-datasets, access-bulk, access-registration and so on).
> Are the meaning of these tags documented somewhere? I want to correctly
> categorize packages that I create, but I find it difficult because I don't
> know what tags to use.

Some documentation here:

<http://wiki.okfn.org/ckan/doc/faq#TagConventions>

Does not cover that much yet. Also I would imagine it needs to be
integrated into the web interface a bit (?).  We could also do a
better job of pushing more popular tags to the top.

> Question: Is there a convention for specifying the date when a package (or
> rather the data in the package) has been last modified?

Not at the moment. I think this is probably essential. I suggest we
start with an agreed "extra" field named, say, "Last Modified".

I note data.gov.uk uses a package form with Date Released and Date
Updated in it:

<http://ckan.net/package/new?package_form=gov>

> Question: For packages whose data is accessible via a SPARQL endpoint, I'd
> like to add the SPARQL endpoint URL to the ckan.net package information. Is
> there an existing convention for this? Should I add a custom URL with
> format="sparql", description="SPARQL endpoint"?

Yes I think we should do something like this. In fact, I think this is
one of the most interesting/innovative "standards" can can produce
here: "mime-types" (formats) for non file based resources such as
apis. In this case I would make the suggestion of:

api/sparql

I'm also interested in things like google docs. At the moment I use:

gdocs/ccc # spreadsheet
gdocs/doc # doc (rare)

> Comment: In general, it seems like package and group maintainers must follow
> quite a large number of conventions for ckan.net to be really useful. I
> would have expected some documentation on this in the user guide, but
> couldn't find much of help. I think this area of the documentation needs
> work.

Agree completely. I have started some work on this, incoporating some
of the above discussion, on this new user guide page:

<http://wiki.okfn.org/ckan/doc/package>

Rufus