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: Tue, 14 Oct 2014 19:44:33 -0000
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:
http://www.chorusaccess.org/wp-content/uploads/chorus-publisher-implementatio
n-guide-v1-21.pdf)?

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
following:

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

  <license xlink:href="http://publishername.org/licenses/1.0v1/"/>
  <license specific-use=bstart-date: 2014-12-31b
xlink:href="http://creativecommons.org/licenses/by/2.0/"/>

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
xlink:href="http://publishername.org/licenses/1.0v1/"/>
  <license specific-use=bexpression: vor; start-date: 2014-12-31b
xlink:href="http://creativecommons.org/licenses/by/2.0/"/>
  <license specific-use="expression: am"
xlink:href="http://creativecommons.org/licenses/by/2.0/"/>



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


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

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
develops.

Thanks again.
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>

-----Original Message-----
From: Evan Owens [mailto:evanpowens@xxxxxxxxx]
Sent: Monday, October 13, 2014 3:04 PM
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list@xxxxxxxxxxxxxxxxxxxxxx>
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 nikos@xxxxxxxxxx<mailto:nikos@xxxxxxxxxx>
[mailto:jats-list-service@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Monday, October 13, 2014 11:31 AM
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list@xxxxxxxxxxxxxxxxxxxxxx>
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."

Best,
Nikos Markantonatos
Atypon


On 10/10/2014 08:58 PM, Halloran, Shaun
shalloran@xxxxxxxx<mailto:shalloran@xxxxxxxx> wrote:
> 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>
>
>
>
> ----------------------------------------------------------------------
> -- This email has been scanned for email related threats and delivered
> safely by Mimecast.
> For more information please visit http://www.mimecast.com
> ----------------------------------------------------------------------
> -- JATS-List info and archive
> <<http://www.mulberrytech.com/JATS/JATS-List/>>
> 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
Mimecast.
For more information please visit http://www.mimecast.com
________________________________
JATS-List info and archive<http://www.mulberrytech.com/JATS/JATS-List/>
EasyUnsubscribe<http://lists.mulberrytech.com/unsub/jats-list/281881> (by
email<mailto:jats-list-unsub@xxxxxxxxxxxxxxxxxxxxxx?subject=remove>)

Current Thread