[ckan-discuss] Editing package relationships (was: Re: [ckan-dev] Package Resources Proposal)
kindly at gmail.com
Wed Feb 2 23:17:41 GMT 2011
On Wed, Feb 2, 2011 at 5:40 PM, Rufus Pollock <rufus.pollock at okfn.org>wrote:
> On 2 February 2011 17:10, Stefano Costa <stefano.costa at okfn.org> wrote:
> > Il giorno mer, 02/02/2011 alle 16.54 +0000, Rufus Pollock ha scritto:
> >> To give a concrete example: original data is excel and I want to
> >> convert to google docs / csv / json / rdf. Definitely agree this very
> >> important. In discussions in the past  have discucssed the 2
> >> alternatives (both of which have happened on CKAN): a) new related
> >> package b) new resource in existing package.
> > I hope not entirely off-topic,
> > but how do you create "related" packages in CKAN? Or, more specifically,
> > how can you create forks of existing packages for derivatives (and
> > possibly mark those as being derivatives)?
> Package relationships are completely functional (and have been used
> for some time) but we haven't yet implemented editing in the web
> interface :) (part of the reason being that most usage of them came
> via the API).
For interests sake, in working out what to do with package resources I made
the following. (I apologise that it is a bit of a mess)
This is a graph of *all* active relationships in ckan.net.
Currently the only active relationships are of the linked-to type. I think
they are meant as general expressions that the data within the rdfs they
contain are linked. I can not prove this though..
Are there any linked data spiders to do these links automatically?
> An example of them being used: <http://ckan.net/package/rkb-explorer-irit>
> For the tickets for the web interface editing:
> http://ckan.org/ticket/253 - relationships meta-ticket
> http://ckan.org/ticket/256 - edit in the the web interface
> One extreme idea: given the CKAN API it is probably possible to knock
> about an hour. Might be worth trying ;)
> My feeling on this is that just arbitrarily linking packages with no
structure/ontology will not help people get more out of the data in the long
However, I always err on the structured side, when it comes to data.
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ckan-discuss