[ckan-discuss] Package Relationships - remove?

[Pablo Mendes]

In the context of the LOD effort, I can think of the following uses for such
relationships:
* Links to other datasets. We would like to know when a dataset uses data
from another, so if somebody uses both in combination they may get answers
that they would not get by querying each one individually. In general those
links are useful to measure how connected the "data cloud" is.
* Umbrella projects (BioRDF, open.data.uk, Europeana) have many datasets
that make sense on their own but should also benefit from the "brand" of the
parent project. Such relationships could enable having them always separate
and linking them somehow into an umbrella project.
* Dependencies (RDF may come separate from the schema, but better use can be
made if the schema is also downloaded). Having "dependency" relationships
would allow automatic downloads of required packages.

For the first point we improvised "links:" in the extra fields. For the
second, sometimes we added them both as separate and subpackages. Sometimes
we added them only once. We've never done anything about the third, but I
was considering something along those lines to share the data I use for the
DBpedia Spotlight Debian Package.

This is not a +1 or a -1. Just trying to make sure the honorable mention to
"the LOD people" didn't echo in emptiness. :)

Cheers,
Pablo

On Thu, Aug 25, 2011 at 12:13 PM, David Read <david.read at okfn.org> wrote:

> On 25 August 2011 11:06, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> > On 25 August 2011 09:34, David Read <david.read at okfn.org> wrote:
> >> On 24 August 2011 21:47, Rufus Pollock <rufus.pollock at okfn.org> wrote:
> >>> I'm +1 to remove.
> >>>
> >>> Right now this isn't buying anything and we probably want something
> >>> different point. I do think that:
> >>>
> >>> a) At some point I'm pretty sure we will need things like "depends on"
> >>> or "requires"
> >>
> >> This was your original reasoning for the feature, and it's not
> >> happened. What do you see changing in the future?
> >
> > Actual integration with packaging tools / data management tools. But
> > right now that isn't there. Hence I said: "at some point" (and should
> > have added "in the future").
> >
> >>> b) there is a good use case right now for a more general form of
> >>> "connection" which isn't just between datasets but is e.g. from
> >>> dataset to external visualization or policy paper. E.g. it would be
> >>> really nice to say "this government report at url X uses data from
> >>> this dataset" or this visualization at url X uses this dataset (thanks
> >>> to Sam Smith for emphasizing the importance of this to me a few months
> >>> ago)
> >>
> >> Great to have a fourth suggestion of a relationship type. But
> >> visualisations are still simply Resources. I made the point that we
> >> could generalise Relationships to include Resources, but that is a
> >> subtle shift, not one that will suddenly create demand for this
> >> feature.
> >
> > It would create demand from me right now. I'm also not sure that make
> > visualizations into resources is what you want though you can do that
> > ...
> >
> >>> c) For derivation and transformation relationships (definitely going
> >>> to be important) we need to include resources not just
> >>> datasets/packages (maybe *just* resources).
> >>
> >> You started by saying get rid of Relationships and spend the rest of
> >> this email arguing *for* something very similar! ;-)
> >
> > I've argued for deprecating and removing the current relationship
> > system. Item (a) was for the future. Item (b) was about the fact that
> > we do want a simple way to link to other material and I'm not clear
> > this is resources (if it is then item (b) goes away which is great :-)
> > ). Item (c) was that we would need to include resources in any future
> > "relationship" style set up (but is not needed now).
>
> Ok so you do want a similar feature in the future but the best plan is
> to remove what we have now? From your analysis I would conclude:
> a) work on the complications of how it fits in the API and the logic
> layer now and broaden it to Resources
> or b) leave it not worked on
> rather than c) get rid of it and let the surrounding code grow in a
> different direction that makes it harder for this sort of thing in the
> future?
>
> David
>
> >
> > Rufus
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20110829/f0b81790/attachment.htm>