[ckan-discuss] Multiple authors etc

Sun Dec 22 20:41:03 UTC 2013

Hi,
  If you add the ability to record multiple authors, it's not clear to me why you would want to remove Maintainer from the UI.  Hasn't the problem been that people were using maintainer as a secondary author only because currently they can only put 1 author, but if that is addressed then people should use maintainer for what it is meant (or should be meant) - the person maintaining the CKAN record and/or the best contact person for queries about the dataset.

I don't see Maintainer as a redundant field?

Aaron

----------------------------------------------------------------------

Message: 1
Date: Tue, 17 Dec 2013 20:16:10 +0000
From: Mark Wainwright <mark.wainwright at okfn.org>
To: Ross Jones <ross at servercode.co.uk>
Cc: CKAN discuss <ckan-discuss at lists.okfn.org>
Subject: Re: [ckan-discuss] Multiple authors etc
Message-ID:
        <CAJhtavYDmq1PuEBgf-rWQrFJhQ3JCYhZxdbaGji9=pXowQKcFA at mail.gmail.com>
Content-Type: text/plain; charset=windows-1252

> I think CKAN is best staeying
> as a generic solution with vaguly sensible defaults, with specifics
> implemented in extensions.

Absolutely; this is exactly why I would like to remove Maintainer from the UI. We agree on the principle but perhaps we have slightly different perspectives on what constitutes 'sensible'. Mine is from a UX point of view. I spend an awful lot of time giving demos of CKAN or showing people how to use it, and when it comes to dataset creation, if I try to say anything meaningful about this field, their eyes glaze over.

By the way, for essentially the same reason I very strongly feel that the 'Extras' fields should be hidden from the UI by default. I absolutely understand that adding your own key-value pairs is useful on datahub.io (so, as you say, implement it in an extension), but on pretty much any other install, it's extremely unlikely that you want users creating random extras. If there are extra fields you want to use systematically, you will set up your schema (and input forms) accordingly. And as for the poor users, again it is likely to do nothing but confuse them. But anyway, that's another story.

Conversely allowing multiple authors is extremely straightforward to understand and doesn't require any explaining at all.

Mark

On 17/12/2013, Ross Jones <ross at servercode.co.uk> wrote:
> Ah I see. It wasn?t clear to me that you just wanted a UI change.
>
> For my current work with Local Government the maintainer is the
> person/organisation responsible for keeping the data up-to-date, which
> is often _not_ the Local Authority itself and nearly always not a
> publisher on our site.  This is totally different from the 'second
> author? interpretation of the field.
>
> For the specific use-case where multiple authors are required, and no
> maintainer, perhaps it would be better to start an extension for
> academia with support for multiple authors, different types of
> citations and so forth. Personally, and you may well disagree, I think
> CKAN is best staying as a generic solution with vaguely sensible
> defaults, with specifics implemented in extensions.
>
> Ross
>
> On 17 Dec 2013, at 18:12, Mark Wainwright <mark.wainwright at okfn.org> wrote:
>
>> I don't really care about the default schema. They can stay there if
>> they like, I just want them out of the default UI form.
>>
>> Saying that, it will only create work providing a workaround if
>> anyone's really using it. So far that's not very clear. Liip were the
>> most plausible example, but it turns out they are just using it as a
>> workaround because there are no hierarchical organisations - which
>> there will be from CKAN 2.2.
>>
>> If anyone is using them in the 'recommended' way (as details for an
>> extra author), this really should be done with multiple authors
>> (#1365), and they ought to think of making that shift at some point
>> assuming #1365 is implemented. But I agree, we need not force that
>> work on them straight away.
>>
>> Mark
>>
>>
>> On 17/12/2013, Ross Jones <ross at servercode.co.uk> wrote:
>>> There?s no reason that the data, if it exists, couldn?t be migrated
>>> to an extra as part of the upgrade to the version without the
>>> maintainer field, however...
>>>
>>> Unless there?s a dramatic change to the schema in a future
>>> release(perhaps basing the default schema on DCAT), where there is
>>> an opportunity to make the change with plenty of notice and an easy
>>> migration I think removing fields from the default schema should be
>>> avoided.
>>>
>>> Those ?unused? fields might be considered cruft in some respect, but
>>> will likely end up generating even more in providing a workaround to
>>> each one removed.
>>>
>>> Ross.
>>>
>>>
>>> On 17 Dec 2013, at 15:31, St?phane Guidoin <stephane at opennorth.ca>
>>> wrote:
>>>
>>>> The obvious issue with this approach is that it will require some
>>>> work for implementation that are currently using the maintainer
>>>> fields and will see it disappear. They will have to create 2 extra
>>>> fields and then write a script to transfer the content. Not sure
>>>> they will appreciate the surprise.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Dec 17, 2013 at 6:17 AM, Mark Wainwright
>>>> <mark.wainwright at okfn.org> wrote:
>>>> After some discussion on #1366, I believe we should just delete the
>>>> "maintainer" fields:
>>>>
>>>> https://github.com/okfn/ckan/issues/1402
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>> On 07/12/2013, Mark Wainwright <mark.wainwright at okfn.org> wrote:
>>>>> Hi all,
>>>>>
>>>>> I think there's a problem with 'Author' and 'Maintainer'. A
>>>>> digital object in practice may have multiple authors; the meaning
>>>>> of "maintainer" is unclear.
>>>>>
>>>>> I'm sure  I've suggested these in the past, but anyway, I've just
>>>>> created Github issues for what I think should be done with these -
>>>>> comments welcome:
>>>>>
>>>>> https://github.com/okfn/ckan/issues/1365
>>>>> https://github.com/okfn/ckan/issues/1366
>>>>>
>>>>> Probably best to comment there rather than here.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>> --
>>>>> Business development and user engagement manager The Open
>>>>> Knowledge Foundation Empowering through Open Knowledge
>>>>> http://okfn.org/  |  @okfn  |  http://ckan.org  |  @CKANproject
>>>>>
>>>>
>>>>
>>>> --
>>>> Business development and user engagement manager The Open Knowledge
>>>> Foundation Empowering through Open Knowledge http://okfn.org/  |
>>>> @okfn  |  http://ckan.org  |  @CKANproject
>>>> _______________________________________________
>>>> ckan-discuss mailing list
>>>> ckan-discuss at lists.okfn.org
>>>> https://lists.okfn.org/mailman/listinfo/ckan-discuss
>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-discuss
>>>>
>>>>
>>>>
>>>> --
>>>> St?phane Guidoin
>>>> Director, Transportation
>>>> Open North
>>>> 514-862-0084
>>>> http://opennorth.ca
>>>> Twitter: @opennorth / @hoedic
>>>> _______________________________________________
>>>> ckan-discuss mailing list
>>>> ckan-discuss at lists.okfn.org
>>>> https://lists.okfn.org/mailman/listinfo/ckan-discuss
>>>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-discuss
>>>
>>>
>>
>>
>> --
>> Business development and user engagement manager The Open Knowledge
>> Foundation Empowering through Open Knowledge http://okfn.org/  |
>> @okfn  |  http://ckan.org  |  @CKANproject
>> _______________________________________________
>> ckan-discuss mailing list
>> ckan-discuss at lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/ckan-discuss
>> Unsubscribe: https://lists.okfn.org/mailman/options/ckan-discuss
>
>

--
Business development and user engagement manager The Open Knowledge Foundation Empowering through Open Knowledge http://okfn.org/  |  @okfn  |  http://ckan.org  |  @CKANproject

------------------------------

Subject: Digest Footer

_______________________________________________
ckan-discuss mailing list
ckan-discuss at lists.okfn.org
https://lists.okfn.org/mailman/listinfo/ckan-discuss
Unsubscribe: https://lists.okfn.org/mailman/optionss/ckan-discuss

------------------------------

End of ckan-discuss Digest, Vol 47, Issue 16
********************************************

________________________________

Please consider the environment before printing this email
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz