[ckan-discuss] Package Relationships - remove?

[David Read]

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
>