[ckan-dev] publisher model

Thu Apr 28 09:49:24 UTC 2011

On 27 April 2011 19:06, Richard Cyganiak <richard at cyganiak.de> wrote:
> On 27 Apr 2011, at 18:07, Seb Bacon wrote:
>>> A part of the story is still missing from the picture you're painting: ckan.net is a wiki-like site. Many people can make small contributions towards making a good package. This, I think, is a useful and important part of the story.
>>
>> I agree.  On the other hand, curating the data, wiki-style, is quite a
>> specialist role.  I feel we are too optimised for that case when it's
>> not very mainstream.
>
> Well, it's a main part of the appeal of CKAN to me.

Sure, but are you representative of the audience we are building CKAN
for?  My intuition is that CKAN could be much more useful if we
optimise for other audiences.  I guess this is quite a meaty question
and a hard one to answer.

Perhaps the wiki-editor-role could be called Curator.

Apparently ("apparently" because I'm making it up as I go along), my
argument is that we would do better to focus on the Data Wrangler,
because they will produce stories for the Visitor based on sources
originally compiled by Curators. 'm not advocating getting rid of the
wiki-like element, but I think CKAN-as-data-story-production-platform
will have greater impact than CKAN-as-metadata-curation-platform.  I'm
advocating a shift in perspective.

> It is hard to make a good “half wiki, half individually-owned content” system.

Yes.  Isn't that kind of what we have now?  That's also kind of what
Github is, which is why, I suppose, Friedrich mentioned it.

>> I agree, but also think we need to make it easy for users to put C's
>> resources in many different packages, and conversely to list all the
>> packages that C's resources are used in.  I suspect the
>> copy-and-edit-this-data-story workflow is a more common case than the
>> directly-edit-this-data-story, and therefore one that it would be
>> better to optimise for in the UI.  It allows very similar yet
>> importantly different packages to be grouped together -- a data
>> stories around "UK spending in the last 12 months", "Wales spending in
>> the last 12 months", "Wales spending over £10k in the last 12 months"
>> would all have their own pages yet have nearly identical sets of
>> resources.
>
> +1 to all this. But why do you think that sharing resources between packages (be it by cheap copying, or by reference) can't work with the current model/terminology?

I don't think it can't work :)  But the different ways of skinning the
same apple aren't all equivalent.  The choice of paradigm can
powerfully impact how people interact and use the system.  I think the
copy-and-edit-this-data-story paradigm feels like a more natural fit
-- *if* we want the system be generating real value from the data we
are cataloguing.

Seb