[ckan-discuss] CKAN packages containing packages query

Fri Jul 15 13:36:55 BST 2011

On 15 July 2011 07:32, Jo Walsh <jo.walsh at ed.ac.uk> wrote:
> Wrote some ScraperWiki scrapers for our Datashare repository.
> No RDF yet, hoping to do that with OpenOrg Grinder quite soon.
> However this is enough to result in questions...
>
> http://ckanvm.inf.ed.ac.uk/package/edinburgh-datashare
>
> Are there recommendations for what to do with CKAN packages containing other
> packages? For example. There is a list here of the packages in Edinburgh's
> research data repository (yes, all 12 of them).

So packages containing packages are usually catalog / repositories /
listings. On thedatahub.org (ckan.net) we adopted the practice of
tagging these with: package-type.catalog:

<http://thedatahub.org/tag/package-type.catalog>

> http://scraperwiki.com/scrapers/dspace_package_metadata/
> This won't work with ERA as it has a different table-based layout.
> Thinking about turning the scraper into a command-line module and ensuring
> it works with more DSpaces.
>
> Would like to make a CKAN package per dataset in Datashare - adding extra
> metadata about downloadable files, links to papers, websites etc. We *could
> think about* a bridge between CKAN and DSpace (so one can post a package to
> DSpace storage by entering it in the CKAN - issues here with multi-hop
> login/authentication (EASE, email registration for Datashare) - may be
> unrealistic to hope to resolve this in the next two weeks.)

This would be very cool.

> So Datashare is a package (?) which in turn contains other packages.
> - thoughts on customising the UI to show 'higher-level' but not
> 'lower-level' packages? some ckanjs thing needed?

I think that as a first pass something in ckanjs plus use of package
relationships ...

> - thoughts on structuring containment relations in package metadata?

This would be a new type of relationship.

@David (Read): any thoughts on this?

> - thoughts about publications from a much larger DSpace repository - they
> don't need to be individual packages but we should index them.

You could do them as resources in a single package. We've had thoughts
with other use cases for situations where there are *lots* of
resources in a package (e.g. where you have a package for german
legislation with one resource per act ...)

Rufus