[ckan-dev] Authors / maintainers

Thu May 31 08:27:58 UTC 2012

Done:

http://trac.ckan.org/ticket/2479
http://trac.ckan.org/ticket/2480

Mark


On 31 May 2012 09:08, Mark Wainwright <mark.wainwright at okfn.org> wrote:
> I guess Jan's example shows the importance of being able to tweak the
> metadata schema, since surely not everyone needs four separate fields
> here. But we're talking about a default.
>
> I see the value of distinguishing the actual data owner (or publisher
> or whatever) from the person maintaining the CKAN record (maintainer /
> CKAN owner), as Jan and Rufus suggest. So I'll make a ticket proposing
> the following:
>
> * Changing the '(none)' message as I suggested.
>
> * Keeping the current fields but renaming 'author' to 'owner', and
> having more helpful explanatory text. At present, the author is 'the
> main contact' and maintainer is 'another important contact' - I'll
> suggest wording that differentiates the roles.
>
> * Inserting the user's details as Maintainer by default, controlled by
> a check-box when creating the dataset.
>
> As Jan says this may not always be true, but then it's easy to uncheck the box.
>
> Mark
>
>
> On 30 May 2012 15:42, Jan Kučera <elquenor at gmail.com> wrote:
>> Hello,
>>
>>
>>
>> I have some comments to this. Adding a Publisher field to the CKAN is a good
>> idea but I would keep the Author/Owner of the data and the Maintainer of the
>> data as well. Actually we can have up to four roles and up to four different
>> persons or organizations acting in these roles – Owner of the data,
>> Maintainer of the data, Publisher of the data and Maintainer of the CKAN
>> data catalogue record. For example a ministry can own a dataset but it can
>> have it maintained by one of its agencies or one of the employees. The
>> ministry can have the dataset published by a central publishing agency and
>> some different ministry can maintain a data catalogue for the whole
>> government so they will create and maintain records in this catalogue.
>>
>>
>>
>> I do not think that the creator of the CKAN dataset should default to the
>> owner. I agree that it can be handy in some use cases but not in the example
>> above because it will not be true in every case and the workers creating
>> CKAN records would have to change it on many occasions.
>>
>>
>>
>> Better solution might be the CKAN package templates. It can be a simple
>> blank CKAN package with some prefilled values. You would be able to create a
>> template where owner defaults to the CKAN package creator but it will not
>> affect users not using this template. Package templates might be a valuable
>> tool for the managers of the authorisation groups because they would be able
>> to create templates which can help them to standardize package description
>> within the authorization group.
>>
>>
>>
>> Best regards
>>
>>
>>
>> Jan
>>
>>
>>
>> 2012/5/30 Rufus Pollock <rufus.pollock at okfn.org>
>>>
>>> On 30 May 2012 12:46, Mark Wainwright <mark.wainwright at okfn.org> wrote:
>>> > Some thoughts about dataset author/maintainer.
>>> >
>>> > (1) While it might be useful for some cases, it seems just confusing
>>> > having these two fields by default. I would suggest instead that the
>>> > default be to have one field ('Maintainer'), with an option to add
>>> > extra maintainers (in the same way as one adds extra fields).
>>>
>>> From conversations and experience over the year we should probably
>>> just have Publisher (and perhaps Maintainer)
>>>
>>> > (2) At present there is no maintainer (/author) until you go to the
>>> > 'further information' tab and type it in. I'd like to see a checkbox
>>> > when the data is created called 'I am the maintainer of this dataset',
>>> > which autofills my details in as the main contact (assuming I'm logged
>>> > in).
>>>
>>> I think we should at least see CKAN owner shown as "CKAN owner" in some
>>> way.
>>>
>>> > (3) If a dataset has no resources the resources list currently says
>>> > '(none)'. Here is a suggested improvement: 'There are no data
>>> > resources here yet. For information about this data, contact the
>>> > dataset maintainer.'
>>>
>>> Agreed. These are the kind of UX tweaks that really should go into
>>> tickes. We already have quite a lot of them ;-)
>>>
>>> > The idea of (2) and (3) is to make it as easy as possible for someone
>>> > holding some data to make a minimal useful dataset for it. For
>>> > whatever reason, they don't want to put it online at the moment, but
>>> > they can still register the fact that they have it in about a minute
>>> > by creating an empty dataset for it.
>>>
>>> Understood. This is more the catalog approach. I'm a little dubious of
>>> its value unless I can do something else like "Request access to this
>>> dataset". Having a bunch of datasets without any data reduces the
>>> value of a given instance I think.
>>>
>>> Rufus
>>>
>>> > Any thoughts? I can make this a ticket if there aren't howls of protest.
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Mark Wainwright, CKAN Community Co-ordinator
> Open Knowledge Foundation http://okfn.org/
> CKAN on Twitter: @CKANproject


-- 
Mark Wainwright, CKAN Community Co-ordinator
Open Knowledge Foundation http://okfn.org/
CKAN on Twitter: @CKANproject