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

[David Read]

On 6 July 2011 08:35, <p.romain at cg33.fr> wrote:

>
> Hi,
>
> I dive in this conversation even if I am not sure to understand all the pro
> and cons of it.


Pascal, welcome!

Having looked into what has been achieved by the DGU team, I thought about
> reproducing their architecture for publishing open data material : CKAN for
> storing and organizing data and Drupal for all the animation features.


Many projects successfully use CKAN as a back-end and Wordpress / Drupal /
etc. as front-ends - both by us and people using CKAN independently.

The first difficulties I had was to understand the authorization process
> linking some cck filed in drupal and groups and authorizationgroups in CKAN
>

As David says, In DGU we have the main auth in the Drupal side and the CKAN
site is read-only apart from sys admins and edits authorized by Drupal.


> I also had difficulties implementing the DGU ckan_package drupal module as
> well as making the ckan app to work. Therefore I end up in the worst
> situation : publishing my content only relying on Drupal features.


The DGU Drupal team made a release of their module last year, and they are
intent on another release shortly. Did you look at the existing one? The
CKAN API is RESTful - pretty simple, so it would be interesting to hear what
problems you had.

Doing a basic data catalogue in Drupal (or any decent CMS) can of course be
done in a couple of weeks, but we're aiming CKAN to provide a lot more than
the basics. Already we have wiki-style edit history, change feeds, RDF,
standard API, federated search, moderated edits, etc. and since it's open
source people like yourself can contribute for the benefit of all.


> If that's acceptable for a first step I am still looking into a more stable
> solution.
>
> The publisher issue you arose is a central one to me. I need to be able to
> provide user acces to ckan as well as drupal. I noticed the XML-RPC code
> provided in the ckan-dgu extension but I was not sure how to work with it.
> Is it the authorization model in CKAN that governs the way users role are
> defined in the Drupal architecture or the other way round ?
>

The XML-RPC interface isn't used for authorization, but it can supply user
and publishers details as well as authenticating users.

All the recent improvement made on the CKAN tool (congratulations by the
> way) also makes my thing about what should be implemented on the CMS side
> and what should be left to CKAN.
> The DGU team told me tha they were reconsidering their implementation of
> the interaction between the two but I have no visibility on the direction
> they choose.


Yes, we're talking about some improvements to the API to help CMSs.


> Before going further I would need the following elements:
>
> - a clear documentation on how to set up a production environnement of CKAN
> on a linux server (and not only ubuntu distro). I would be happy to
> contribute to the writing of it.


We mention Ubuntu because that is what we are testing on, but we also have
CKAN running on other distros, and are delighted to include tweaks for other
distros in the instructions. It's always a balance of what we spend our
resource on, but we suggest Ubuntu as the easiest path for those in the
community who want to install CKAN themselves.


> - a explanation of the way the ckan team sees the interaction of this tool
> with other tools like CMS : is it planned to port all the CMS-like features
> into CKAN or is it reasonable to use CMS like wordpress or drupal to
> intercat with it ?


We're not keen to duplicate CMS features, so we are moving towards improved
integration with CMS's like Drupal.

David


>
> Best,*
> Pascal Romain**
> *
>
>
> *David Read <david.read at okfn.org>*
> Envoyé par : ckan-dev-bounces at lists.okfn.org
>
> 05/07/2011 22:58
> Veuillez répondre à
> CKAN Development Discussions <ckan-dev at lists.okfn.org>
>
> A
> CKAN Development Discussions <ckan-dev at lists.okfn.org>
> cc
> Objet
> Re: [ckan-dev] Publishers vs. Publisher-centric package management
>
>
>
>
> 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
> 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?
>
> >> 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?
>
> >>> 3) Are there going to be other types of groups as well? If so, how do
> >>> we avoid ambiguity in user-land?
> >>
> >> I'm not understanding you - do explain what confusion could arise.
> >
> > Well, I think we're going to end up with a system in which people will
> > recognize that groups and publishers are related - in the worst case
> > it will be some dropdownish thing - and then get confused over the
> > distinction and end up using neither.
>
> I'm still lost... Are you talking about the admin who installs a CKAN
> and sets up the publishers and users? Or the person creating a package
> choosing a group for it?
>
> I guess the key thing is that the model is understandable. I'll agree
> that Groups are a little tricky to understand, and the new 'Member'
> class might be as difficult as AuthorizationGroups are now. I don't
> think Agent is ideal though. We can work on the terminology, but yes
> do suggest improvements to the modelling too.
>
> David
>
> >>> 4) What speaks against the Agent (User, Group) model where they are
> >>> active authorization objects next to normal users rather than just
> >>> groupings?
> >>
> >> As I said before, this seems a reasonable improvement, but since we're
> >> moving the authz into plugins then this needs to be considered.
> >>
> >>> From my PoV the Agent model would be very simple to implement, very
> >>> clear also in the conceptual model and it would allow for the new URL
> >>> scheme which I'm really a big fan of.
> >>
> >> +1 to the URL scheme
> >
> > Again: doesn't make *any* sense for many to many where you then end up
> > with several URLs for the same package. Of course you can hide this
> > somehow but thats just terrible design.
> >
> > - Friedrich
> >
> > _______________________________________________
> > ckan-dev mailing list
> > ckan-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/ckan-dev
> >
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
> __________________________________________________________________
>
> Ce message et toutes les pièces jointes sont confidentiels et établis à
> l'intention exclusive de ses destinataires. Ce message ne constitue pas un
> document officiel. Seuls les documents revêtus de la signature du Président
> du Conseil Général ou d'un de ses délégataires sont de nature à engager le
> Département.
> Toute utilisation ou diffusion non autorisée est interdite. Tout message
> électronique est susceptible d'altération et le Département de la Gironde
> décline toute responsabilité au titre de ce message s'il a été altéré,
> déformé, falsifié.
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110706/dd2d3465/attachment-0001.html>