Re: [jats-list] Open Access Indicators in JATS

Subject: Re: [jats-list] Open Access Indicators in JATS
From: "Maloney, Christopher (NIH/NLM/NCBI) [C] maloneyc@xxxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 17 Oct 2014 05:32:21 -0000
Hi Shaun,

This is certainly a reasonable solution to a tricky tagging issue.  My only
reservation is that I think <license-p> should typically be used for human
readable text b itbs basically the equivalent of a <p> tag; the only
reason it has a different name is because within the context of <license> it
has a slightly different content model.  So, a typical renderer of your
markup, that wasnbt bawareb of the specific use values youbve defined,
would just display two dates in the human-readable version, with no context.

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 4AN36D-12

"Halloran, Shaun shalloran@xxxxxxxx<mailto:shalloran@xxxxxxxx>" wrote:

Hi Chris,

Yes, that's the CHORUS document to which I was referring.

I was thinking of something a little more simplistic, that would follow what
CHORUS proposes for JATS, but would still allow for specifying both start and
end dates. My plan was to use <license-p> for the dates, as follows:

<license license-type="ccc" specific-use="vor"
<license-p>Normal publisher stuff<license-p></license>
<license license-type="public-access" specific-use="am"
<license-p specific-use="start-date">2015-01-01</license-p>
<license-p specific-use="end-date">2015-12-31</license-p></license>

It's a little verbose, and it doesn't fit the typical description of
<license-p>, but it's true to the CHORUS recommendation, and it gives me
everything I need. So in the above example, I'm able to specify my normal
license for the VoR, but an alternate license for the AM, which is being
exposed for one year under OSTP Public Access mandates (this is just a
convenient example, though we have made the decision to use the AM for Public
Access purposes). This also fits with the JATS-recommended tagging for Open
Access, which we are currently using:

<license license-type="open-access"
<license-p>This is an open-access article distributed under the terms of the
Creative Commons Attribution License, which permits unrestricted use,
distribution, and reproduction in any medium, provided the original work is
properly cited.</license-p>

(Again, I realize not everyone is making a distinction between Public Access
and Open Access, but since the tag model works either way, that shouldn't be a
problem.) And assuming NISO comes out with an alternate plan later, this model
should be specific enough to allow for a relatively easy translation to the
"updated" tagging policy later. Your suggestion does that as well Chris, but I
like the idea of keeping @specific-use on <license> a little more focused.

As for the end date, I understand why CHORUS isn't worried about it, but I
feel like this is an opportunity to address the problem of dealing with
multiple licenses in a single document effectively, so we might as well come
up with a solution that can handle it.


Shaun Halloran
Senior Manager, Production
American Society of Civil Engineers
1801 Alexander Bell Drive
Reston, VA 20191

-----Original Message-----
From: Maloney, Christopher (NIH/NLM/NCBI) [C]
Sent: Tuesday, October 14, 2014 3:21 PM
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [jats-list] Open Access Indicators in JATS

I seem to remember some discussion of this at the last JATSCon, and the gist
of the conversation was that it might be quite some time before NISO comes out
with official recommendations, and then even more time before those get
incorporated into an official JATS release. So I think it would be best to
come up with a consensus on some conventions, if possible, before then, for
including this metadata in the existing JATS.

I just looked over how CHORUS recommends tagging license information (I assume
youbre referring to this document:

I agree that, when multiple licenses apply to the same document, that multiple
<license> elements should be used. The big confounder here is that there are
multiple reasons that multiple licenses might be applied to the same document,
but, correct me if Ibm wrong, the main problem that you are immediately
concerned with is how to specify the end of the embargo period (or the
start-date of the CC license), is that right? In the OAMI draft
recommendations, they invented the @start-date attribute for this purpose, but
therebs no good place to put this in JATS.

The only attribute suitable for disambiguating multiple <licenses> tags (that
appear at the same level in the hierarchy of the document) is @specific-use.
In the CHORUS recommendations, they give examples of values of bvor"
(version-of-record) vs. bamb (author manuscript), which would conflict
with using this for bstart-dateb.

The best suggestion that I can think of, that Ibd like to throw out for
consideration, is that the @specific-use be used to encode more than one type
of metadata. With a simple JSON-like key-value syntax; so, something like the

For an article that becomes available under a CC license on a particular date:

<license xlink:href=""/>
<license specific-use=bstart-date: 2014-12-31b

This is similar to the way the NISO recommendations work b they donbt
specify an end-date. So, any and/or all licenses that have start-dates prior
to todaybs date apply.

In a more complicated example, trying to harmonize this recommendation with
CHORUSb might look something like this (using bexpressionsb as the key
to indicate version-of-record vs author-manuscript):

<license specific-use=bexpression: vorb
<license specific-use=bexpression: vor; start-date: 2014-12-31b
<license specific-use="expression: am"

Chris Maloney
NIH/NLM/NCBI (Contractor)
Building 45, 4AN36D-12

"Halloran, Shaun

Thank you Nikos and Evan. I'm curious to see what the official recommendation
from OAMI looks like, but a namespace solution sounds perfectly reasonable.
For my implementation, I'm still waiting on a number of components that won't
be in place until early 2015, so I'm going to move slowly to try and let these
recommendations come to light. It should be interesting to see how this

Thanks again.

Shaun Halloran
Senior Manager, Production
American Society of Civil Engineers
1801 Alexander Bell Drive
Reston, VA 20191

-----Original Message-----
From: Evan Owens [mailto:evanpowens@xxxxxxxxx]
Sent: Monday, October 13, 2014 3:04 PM
Subject: RE: [jats-list] Open Access Indicators in JATS

Some additional information on this topic.

The JATS steering committee is still waiting to hear from the Open Access
Metadata and Indicators Working Group (OAMI) as to what their recommendation
is going to be so that it can be implemented appropriately in JATS. At the
recent NISO Board Meeting it was reported that OAMI had received 100+
comments, the most for any NISO document in several year but that they
expected to publish their final document early this fall.

Last June, Ed Pentz (co-chair of OAMI) asked me to prepare XML examples for
their document that included a schema and an OAMI namespace as proposed in the
comments to the draft by Jeff Beck and others. I prepared that, sent it to
Todd Carpenter for comments on the namespace syntax, and sent a revision to
Ed. I have not heard anything from them since then so I don't know what the
final direction is going to be but we can expect that it will include an OAMI
XML namespace and OAMI elements. We can then use that to plug it into JATS
similar to the way that MathML is included. Implementation details TBD when we
see the recommendation.

Evan Owens
NISO JATS Steering Committee
NISO Board Member

-----Original Message-----
From: Nikos Markantonatos
Sent: Monday, October 13, 2014 11:31 AM
Subject: Re: [jats-list] Open Access Indicators in JATS

Hi Shaun,

Two requests on this subject were placed for review by the JATS v1.1
maintenance committee a little less than a year ago and were reviewed this
past January. Here's what the committee recommended on them:

"A subcommittee of Jeff Beck, Debbie Lapeyre, Mary McRae, and Evan Owens will
investigate this, post comments on the draft NISO recommended practice
guidelines for open access metadata and indicators (NISO RP-22-201x), and
report our conclusions back to the JATS Standing Committee by email. No action
will be taken at this time."

Nikos Markantonatos

On 10/10/2014 08:58 PM, Halloran, Shaun
> Hi,
> Itbs been a while since Ibve seen any mention of Open Access
> indicators on the list. Webre in the early stages of implementing
> FundRef for our journals, and Ibm attempting to come up with a tagging
> solution for the Public Access items (such as what was mandated by the
> OSTP memo). Webre currently using JATS 1.0 Green.
> Ibm already using the JATS recommendation of <license
> license-type=bopen-accessb> for my open access content, and Ibm
> planning to use bpublic-accessb for federally funded content that must
> be made live following an embargo period (and to be clear, Ibm not
> attempting to spark a debate on public vs. open access b everyone is
> free to call it whatever they want). My problem is that, in the
> current tag set, I have no way of specifying the embargo period
> directly b this is something the NISO recommendation sought to fix.
> I thought about using a <date> element in the history for this, but I
> donbt like how it would be disassociated from the license information.
> So instead, I plan to use multiple <license> elements, as suggested by
> CHORUS, to identify public access articles and the licenses that apply
> to each published object (accepted manuscript and VOR), and <license-p
> content-type> (or perhaps <named-content content-type> within
> <license-p> to allow for start and end dates) to identify the embargo
> dates associated with each license. This essentially fits with the
> CHORUS recommendation, but is somewhat out of line with the bparagraph
> of textb description of what <license-p> is supposed to be.
> Before I finalize my decision, I wanted to see if any other publishers
> had already gone down this road, and what approach they have taken for
> specifying embargo dates. I will say that Ibm attempting to not
> superset the DTD with additional NISO-based elements because I doubt
> that our online platform would be willing to support those tags (they
> were hoping for an official JATS solution in 1.1, but it looks like
> webll have to wait a little longer for that).
> I appreciate any feedback on this approach.
> Cheers,
> Shaun
> Shaun Halloran
> Senior Manager, Production
> American Society of Civil Engineers
> 1801 Alexander Bell Drive
> Reston, VA 20191
> 703-295-6215
> shalloran@xxxxxxxx<mailto:shalloran@xxxxxxxx><mailto:shalloran@xxxxxxxx>
> ----------------------------------------------------------------------
> -- This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit
> ----------------------------------------------------------------------
> -- JATS-List info and archive
> <<>>
> EasyUnsubscribe <-list/244090>
> (by email <>)

Confidentiality Notice: This email and any attachments are for the sole use of
the intended recipient(s) and contain information that may be confidential
and/or legally privileged. If you have received this email in error, please
notify the sender by reply email and delete the message. Any disclosure,
copying, distribution or use of this communication by someone other than the
intended recipient is prohibited.

This email has been scanned for email related threats and delivered safely by
For more information please visit
________________________________ JATS-List info and
EasyUnsubscribe<-list/281881> (by email<>)

This email has been scanned for email related threats and delivered safely by
For more information please visit
JATS-List info and archive<>
EasyUnsubscribe<> (by

Current Thread