[okfn-help] CKAN suggestions (was Re: Another Internal Server Error in CKAN)

Fri Dec 4 09:21:22 UTC 2009

2009/12/4 Sören Auer <auer at informatik.uni-leipzig.de>:
> Hi all,
>
> I looked at CKAN a little last night and have the following
> questions/comments:
>
> * right now the general concept is still a little unclear to me: is CKAN
> really distributed? how do the different nodes communicate with each other -
> via the API? Where can I see a list of nodes? What information is replicated
> between them?

No CKAN isn't really distributed at the present. That said it wouldn't
be hard to implement basic distributed search across multiple CKAN
nodes. If one wanted more than that, e.g. ability to push and pull
between different CKAN nodes, that could be implemented piggy-backing
on the versioned domain model stuff we have.

> * Does the API already make metadata available as RDF? Then CKAN would
> basically be a Linked Data node.

Not at present. We push the data to Talis CC. However we really should
integrate this data into CKAN itself. Our one reluctance about this
has been that it creates yet another quite major dependency in CKAN
(on e.g. RDFLib). At the moment we can run the RDF conversions
"offline", pulling data from the API or via a dump.

> * What is really missing from the package details view is some kind of a
> preview.

Not sure what you mean here? You mean there isn't a preview on edit?

> * For each package it would be also good to have direct data download URLs
> available tagged with the format (e.g. RDF, CSV, JSON etc.).

That's a ticket that we're implementing right now :)

<http://knowledgeforge.net/ckan/trac/ticket/90>

> * It would be nice to indicate for each package with which other datasets it
> is interlinked with or related to.

See:

<http://knowledgeforge.net/ckan/trac/ticket/169>
<http://knowledgeforge.net/ckan/trac/ticket/176>

> * Quantity (amount of data, triples, entries etc.) and quality information
> (timeliness, flaws etc.) should be available for as much packages a
> possible.

Agreed. At the moment we tend to use tags for this as we only have
crude information.

> * Idally CKAN would have some kind of mechanism to discover and
> automatically update information on LOD datasets.

That would be nice. How would that work?

> Unfortunately me and my group are working in other technology landscapes
> (PHP, Java), which would make it quite difficult for us to directly get
> involved in the programming parts. However, I will try to register the topic
> as a bachelor or masters thesis, maybe I can find some interested student to
> help working on it in his thesis project.

That would be great. And there might also be ways to leverage your
programming expertise PHP, Java indirectly e.g. via the API ...

For example one thing that would be really cool would be to
auto-generate one of those LOD cloud diagrams using the CKAN LOD
group. We also are in need of maintainers for the LOD group on CKAN
...

Rufus