[ckan-discuss] Multiple authors etc

Tue Dec 17 20:16:10 UTC 2013

> 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