[ckan-dev] Publishers vs. Publisher-centric package management

Wed Jul 6 09:49:41 UTC 2011

On 5 July 2011 21:58, David Read <david.read at okfn.org> wrote:
> On 5 July 2011 19:07, Friedrich Lindenberg
> <friedrich.lindenberg at okfn.org> wrote:
>> Hi David,
>>
>> thanks for your reply!
>>
>> On Tue, Jul 5, 2011 at 12:38 PM, David Read <david.read at okfn.org> wrote:
>>> We need more than one publisher per package for DGU. I think this
>>> needs to be flexible, through a pluggable authz system that David and
>>> James are discussing. I'd like to see a proposal / CREP for this.
>>
>> Is there really, really no way to model this other than multiple
>> publishers? I really think we need to simplify things and package
>> ownership is one amazing way to do this. Many to many is not
>> ownership, its ACLs again. Many to many does not give us nice URLs or
>> nice interaction patterns (forking, merging, ...). Many to many does
>> not reduce complexity, it adds to it. Please, please reconsider!
>
> I'm beginning to understand where you're coming from. You want the
> Github feature where a person or group 'owns' a Package. I'd have
> thought it's be useful for a User to fork a Resource and play with it,
> but I'm not seeing the advantage of multiple copies of a Package.
> Haven't we scrapped this Distributed VCS idea for Packages (see JB's
> code from last year) in favour of a single trunk of changes in, edited
> if necessary through Moderated Edits on the source CKAN and harvested
> as Read-Only copies into other CKANs if sharing is desired?
>
> Whatever your reasoning, I think we could make the DGU model fit with
> your ideas. We could have a package owned by only one publisher, yet
> we'd want to associate other publishers. The values for all these

I have to say that's a really weird definition of 'publisher'. In my
mind a dataset could have one and only one publisher at a give time.
If I wanted to associate a package/dataset with multiple entities I'd
use Package Groups -- and this discussion suggest Package Groups !=
Publisher/Agent Owner idea -- something we already knew (e.g.
bibliographic data group or science group on thedatahub.org is *not* a
publisher group). I know we have used Package Groups to do Publishers
in the past but I think it is becoming clear they are different
things.

> publishers would still need to be controller by the authz, as well as
> well as the authorization to edit them would be based on the values of
> all these fields - but this would only be in a plugged-in authz
> system, rather than the default CKAN one. What do you think?

I'm not sure what this changes. The key thing here is that we want
something like an 'owner' concept where owner can be an organization
or a normal user. We also want Package Groups it seems (arbitrary
groupings of datasets/packages but where there is control over who
adds what). We also want authorization groups. So we want 3 separate
things I think.

Aside: I note similarities with github here. While they don't have the
concept of Groups like us they do have Organization (= our
Agent/Publisher) and they separate this from Authorization Group
(called Teams by them).

>>> Yes, that's now the plan - I can't see why not reuse Groups. David has
>>> added a Member class which makes Users join many-many with Group - see
>>> the branch feature-1198-publisher-hierarcy if you are interested.
>>
>> I think they are different: one is for creating collections of things,
>> which arguably overlaps with packages themselves; the other is for
>> managing things and controlling them. Of course its nice to have a
>> general I-can-attach-both-packages-and-users-to-it entity, but I would
>> argue that it is not actually a design: what usage does it *imply*
>> rather than just enable?
>
> The particular packages that a user is allowed to edit is commonly the
> same packages that are 'owned' by the publisher he/she works for. So
> being able to link users to publishers and making this data available
> to the module which grants or denies access is I think a reasonable
> design. This might not always be the authz logic of course. The authz
> module you plug in for a different project may prefer to use the
> current Role-Base ACL, or new another set of user groupings like the
> one you suggest. I don't see the pluggable authz idea as a blocker for
> your github-style ownership idea, or is it?

I really think you will want authz groups to be separate (though with
some relationship) from Publisher/Organization/Agent stuff. But I
agree this is orthogonal to pluggable authz .

[...]

Rufus