Deal with NISO Accessing and License Indicators (ALI)

[Klortho]

JATS 1.1d3 was just released, see the version notes.

The only significant change was the incorporation of NISO's ALI elements: ali:free_to_read and ali:license_ref.

I would suggest that we add recommendations:

• If ali:license_ref is used, then the element should not have a URI.
• The validator could check the format of any @start_date or @end_date attributes, to make sure they are YYYY-MM-DD

Anything else?

[hubgit]

If ali:license_ref is used, then the element should not have a URI.

Better to say that only one of <license> or <ali:license_ref> can be present, to avoid confusion? (and recommend using the <license> element as normal unless the start_date attribute is needed).

The validator could check the format of any @start_date or @end_date attributes, to make sure they are YYYY-MM-DD

If there's no timezone information, how is a parser meant to know when the access information change should be applied?

[Melissa37]

As <ali:license_ref> is intended to phase out the url in <license>, I wonder whether we should use stronger wording and suggest people use this rather than adding the url to license.

Re ali:free_to_read, we should recommend that if the content is CC, then this tag should also be used along with the existing ones in permissions?

[hubgit]

As <ali:license_ref> is intended to phase out the url in <license>

Is that documented somewhere?

Re ali:free_to_read, we should recommend that if the content is CC, then this tag should also be used along with the existing ones in permissions?

If the content is already under an open license, then <free_to_read> is redundant and unnecessary, surely - it's only relevant if there isn't already a free license?

[Melissa37]

From http://jats.nlm.nih.gov/1.1d3/

ali:license_reference (namespace http://www.niso.org/schemas/ali/1.0/) This is an element intended as a pointer to a public license or waiver, this element may take content or be empty. The start date may be present as an attribute.
...
This arrangement has the result that JATS will recommend moving the URL for the license from the @xLink:href attribute of to a child of . However, we will leave @xLink:href as an attribute on for users who choose not to use the new ALI recommendation and for backwards compatibility.

My understanding of the free_to_read tag is so it is blindingly obvious and less work for Bots to harvest content - they don't have to parse the ali:license_reference or @xLink:href in or ali:license_reference.

But I might be missing something :-)

[hubgit]

I must admit, I'm having trouble seeing why JATS would adopt a new <license_ref> element that duplicates the information in the <license> element, rather than just adding a start-date (or even applicable-from, to be more meaningful) attribute to <license>.

That's a good point about "free_to_read" - it saves a harvester needing to know the meaning of each license URL. There is already a "license-type" attribute on the license element, though, which includes "open-access" as a possible value and could easily be extended to include "free-to-read".

[Melissa37]

Well I guess as it's the outcome of the bigger piece of work (http://www.niso.org/apps/group_public/download.php/14226/rp-22-2015_ALI.pdf) and the recommendations are for XML (not just JATS), JATS is falling in line with the recommendation?

[Melissa37]

Linked to closed #33

[jeffbeckncbi]

Well I guess as it's the outcome of the bigger piece of work

This is correct. The two elements were defined by a NISO group trying to solve the problems of how users can know that an article is free to read and what the license is. The JATS group decided that the cleanest way to adopt this recommendation would be to use the elements that the ALI group defined.

This puts us in a bind, but more of a philosophical one than a technical one. Unless we want to declare that only articles that use the latest (draft) version of the schema are valid (big mistake), we will need to support two ways of referencing a license. This is not ideal, but 2 is better than chaos.

I would encourage everyone to read the Access and License Indicators PDF. I think what they came up with, while again not ideal, is clean and workable.

[hubgit]

I've written up some technical comments on the NISO group's recommendations - not sure how to feed them back to the working group…

[Klortho]

Alf, I sat in on the recent NISO telecon, and they suggested to send comments to [email protected]. But, I think, for highly technical concerns, you'd probably do better to open an issue in the repo CrossRef/niso-ali.

There is a currently closed issue about the JSON-LD representation, but the comment thread is quite long, and I haven't had a chance to read it.

I agree with a lot of your comments, but I don't know what the likelihood is of them issuing a new version of this ALI recommendation with any substantive changes.

[Melissa37]

Jeff wrote to me: I think we need to modify our permissions rules to adopt the new ALI stuff. It can be something simple like:

Use what we already have if you are in JATS version 1.1d2 or earlier

Use ali:license_ref if you are in JATS version 1.1d3 or later. All of the rules for license/@xLink:href should apply to ali:license_ref, I think.

Maybe we don’t have to be so strict about which to use when. Any bots are going to have to look in 2 place now. We should say that if ali:license_ref and <license @xLink:href> exist, we prefer ali:license_ref .

[steve-byford]

I'd very much appreciate thoughts on how to deal with the following use case. (Daniel Mietchen kindly suggested this might be an appropriate place to raise this issue.)

I’m working on an initiative in the UK called Jisc Publications Router, a new version of which is currently under development (see http://scholarlycommunications.jiscinvolve.org/wp/2015/07/01/jisc-publications-router-enters-a-new-phase/). As part of this, I’m talking to publishers about how they might supply notifications/ content to us to enable us to redirect it to the open repositories of participating institutions. To get them on board, we’ll need to capture from them details of any embargo period they may wish to apply, and it seems that the NISO/ALI fields included within JATS might well be one mechanism to do that.

For example, if they were to tells us which licence (link) refers to the post-embargo period, we could interpret its start date in the metadata as the day after the end of the embargo, and pass that on for participating respositories to action as the date from which the content may be made open. Does this sound viable? If so, is there guidance that I could give to interested publishers on how to do this?

Is there any mechanism for dealing with mutiple versions of an article (e.g. accepted manuscript, AM, or version of record, VoR), as the CrossRef schema does?

Any thoughts, advice or guidance would be greatly appreciated.

[Melissa37]

Is there any mechanism for dealing with mutiple versions of an article (e.g. accepted manuscript, AM, or version of record, VoR), as the CrossRef schema does?

Within pub-date you can use the date-type attribute, but the listed variants on JATS (http://jats.nlm.nih.gov/archiving/tag-library/1.1d2/attribute/date-type.html) do not account for different "published" versions really.

It's something I'd like addressed here too as we publish a AM version (+) as well as VoR, and may start allowing a new VoR if there is an update that does not warrant a correction. We do not store these dates in the XML except the first publication date and rely on an internal database to provided the dates of the update on our HTML view. I'd like to add these dates to the XML, but there does not appear to be a clear way to do this which would be standardised.

[steve-byford]

Melissa – thanks: what I meant here was capturing different licence details for each different version, so that you could say e.g.

For the AM, licence1 applies, starting on date1, followed by licence2 starting on date2 etc
But for the VoR, licenceA applies, starting on dateA, followed by licenceB starting on dateB etc

This seems to be possible in the CrossRef schema – is there a way of doing it in JATS? Should there be?

It would be useful for my use case (see prev comment). For example, a publisher might send us updated metadata in which we would want them to be able to tell us (somehow) when an AM previously sent to us could be made open on a repository, and whether or not it is ever possible (allowed) to do the same with the VoR.

Steve

[Klortho]

Each JATS XML document is a self-contained entity, and in the use-case you're describing each one would correspond to a particular version of the article. I don't think there is any way for one JATS document to provide metadata about other JATS documents. If the license terms for the AM were to change, for instance, then the publisher should send a revised AM -- that wouldn't correspond to a new version, but just a transparent correction.
With NISO ALI, it definitely is possible to encode different licenses for different periods, but again, in the context of JATS, if different periods were specified in one document, they would correspond to that version.

[steve-byford]

In the UK, we have a requirement that research outputs (e.g. as AM) be deposited onto repositories at or near acceptance, even if held under embargo for a while. At acceptance, the end of the embargo period will not in general be known, as it typically depends upon the date of publication. I'm therefore imagining a workflow where publishers could supply AM + (incomplete) metadata at acceptance, followed by updated JATS metadata (rather than necessarily full text) upon publication describing the AM previously supplied. Can JATS accommodate this, or is it the wrong DTD to pick?

[Klortho]

That's really a metadata management / workflow issue, and out of scope for JATS, from my understanding. JATS is designed to capture journal articles, along with the metadata that goes with them, such as this licensing information. There's no standard mechanism provided by JATS for separating them. Maybe there is with other digital formats, but I don't know.

That's the philosophical side of things, but others here might have more practical suggestions for you. Since not everybody in the group follows these github issues, I'll forward a pointer here to the jats4r mailing list.

[steve-byford]

Chris, Melissa - thanks very much for your comments and suggestions on my query: greatly appreciated. I see Chris has already posted my original query to the mailing list, so I'll look there for any further comments. Thanks again.

[Melissa37]

It would be nice to be able to link versions of articles together more effectively. As an industry we are trailing behind on explicit details of versioning content. As an open access publisher, I don't have the issue of licenses changing over time, but I am considering changes to an article over time and how to indicate the previous versions of itself in the XML. The general consensus is there is 'potentially' an AM version and a VOR. FULL STOP. In your use case that's fine, as long as you can indicate the license of one in the other XML.
It's an interesting idea, but Chris makes a good point that this would be using the xml metadata of an article to provide information about another version of itself. However, I feel we need to be tackling this somehow.

[Klortho]

Okay, getting back to this. I re-read the comments above, and I see that the recommendations document currently reflects what Melissa suggested above, more or less:

<ali:license_ref> For 1.1d3 or higher, use this element to indicate both the human- and machine-readable license that applies. Place the human-readable form within the element. The @start_date attribute is only required if it differs from publication date.
<ali:free_to_read> Content that is not behind access barriers, irrespective of any license specifications, should also contain this tag. It is used to indicate the content can be accessed by any user without payment or authentication. If the content is only available for a certain period, then @start_date and @end_date attributes can be used to indicated that.

Melissa said "Maybe we don’t have to be so strict" -- so should we make these warnings?