[ckan-discuss] Multiple authors etc

[Ross Jones]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/pipermail/ckan-discuss/attachments/20131217/92605603/attachment-0001.html>