Re: [jats-list] NISO ALI adoption

["Mark Donoghue m.donoghue@xxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Hi Armin,

My understanding of the documentation is to avoid this when using ALI:

  <license xlink:href="https://creativecommons.org/licenses/by/4.0/";>
    <ali:license_ref xmlns:ali="http://www.niso.org/schemas/ali/1.0/";>
https://creativecommons.org/licenses/by/4.0/</ali:license_ref>
  </license>

I don't know why exactly -- probably because it's redundant and therefore
inelegant :-)

Using ALI would be a good choice to indicate licenses that have a URI
because ALI is used in other systems i.e.: Crossref and CHORUS.

Regards,
Mark
- -- --- ----- -------- -------------
Mark Donoghue
IEEE
(732) 562-6045
m.donoghue@xxxxxxxx

IEEE - Advancing Technology for Humanity


On Tue, Jan 12, 2021 at 3:39 AM Armin GC<nther ague@xxxxxxxxxxxxxxxxxxxxxx <
jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Dear all,
>
> I am thinking about whether we should use NISO ALI with JATS, especially
> for referencing to the public license (CC BY) of articles. I found this
> recommendation in the JATS documentation:
>
> JATS best practice is to omit the @xlink:href attribute from <license> if
>> a NISO ALI ali:license_ref> is used.
>
> see:
>
https://jats.nlm.nih.gov/publishing/tag-library/1.2/element/ali-license_ref.h
tml
>
> However, I am not sure about the "if" part of this recommendation: Is
> it advisable (or when is it advisable) to use NISO ALI (
> https://www.niso.org/schemas/ali/1.0) ? My impression is that NISO ALI
> until now is not widely adopted/supported.
>
> Any thoughts on this? Thanks!
>
> Armin
>
>
>
> Armin GC<nther, Prof. Dr.
> PsychOpen, Managing Editor
>
> www.leibniz-psychology.org
> ZPID - Leibniz-Institut fC<r Psychologie
> ZPID - Leibniz Institute for Psychology
> UniversitC$tsring 15
> D-54296 Trier - Germany
> Tel.: +49b651b201-2055
> www.psychopen.eu
> JATS-List info and archive <http://www.mulberrytech.com/JATS/JATS-List/>
> EasyUnsubscribe <http://lists.mulberrytech.com/unsub/jats-list/253780> (by
> email <>)