[ckan-discuss] Package Relationships - remove?

David Read david.read at okfn.org
Fri Sep 2 11:49:00 BST 2011


On 29 August 2011 15:32, Pablo Mendes <pablomendes at gmail.com> wrote:
>
> 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.

Yes, this is exactly the sort of package-to-package relationship we'd
like to express.

> * 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.

These could be relationships (although agreeing names for these
particular relationships might be difficult), although it may be
easier to simply use tags.

> * 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.

Again, another good use of relationships. I'll mention these use cases
in the ticket: http://trac.ckan.org/ticket/253

Because of these and Rufus' comments, Package Relationships do have a
future, to be extended to Resources, so I suggest we don't take them
out of the code after all.

David

> 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
>> >
>>
>



More information about the ckan-discuss mailing list