[ckan-discuss] Multiple authors etc

Wed Jan 8 16:44:22 UTC 2014

I guess that's right - it seems that people are using it, anyway. It
seems to me its intended meaning is not very well-defined, (partly
because its original intended meaning really was as a badly-named
extra author field,) but maybe that's not a good enough reason to get
rid of it at this point.

On thinking about Ross's suggested principle (that everything in the
default schema should be in the default UI) I think that's very
sensible - basically, when you take CKAN out of the box, it shows you
everything it's got. Of course that's orthogonal to the question of
whether to enable multiple authors (which would require a change to
the schema anway), which I think is a no-brainer.

Mark

On 22/12/2013, Aaron McGlinchy <McGlinchyA at landcareresearch.co.nz> wrote:
> 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
> _______________________________________________
> 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