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

Wed Jul 6 12:04:30 UTC 2011

David Read <david.read at okfn.org> 
Envoyé par : ckan-dev-bounces at lists.okfn.org
06/07/2011 11:12
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 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.

> Do you have examples other than data.gov.uk ?

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.

> I used the module and was able to fill up the ckan_package content type 
with packages details using the drush command. You also provided me with 
the ckan.node.tpl.php and template.php examples but I was not able to 
display all the fields and was blocked form using this solution because I 
was not able to display the ressources attached to the ckan package.

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.

> Yes that's why I would like to use CKAN as well. I am specially 
interested in the semantic side of things and it looks to me better to 
link ckan to a rdf triple-store than to do it in my drupal CMS

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.
> So a "drupal user" is linked to a publisher and a publisher can have 
more than one user. And a provider has a list of packages that belongs to 
it ?

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.

> I have a ckan instance working but I was blocked form making it 
available through apache in a daemon mode. Rufus tried to gime me some 
help (thanks again) but my sys admin was not able to make it to work in 
the time available.

- 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.
> So all the features like comments, followers, wiki are for internal (i.e 
the authorized users of a given ckan instance) use and a public ounterpart 
is made available on the CMS side ?

Pascal 
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

_______________________________________________
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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110706/853869d3/attachment-0001.html>