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 301-594-2842 "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" xlink:href="http://publishername.org/licenses/1.0v1/"> <license-p>Normal publisher stuff<license-p></license> <license license-type="public-access" specific-use="am" xlink:href="http://creativecommons.org/licenses/by/2.0/"> <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" xlink:href="http://creativecommons.org/licenses/by/4.0/"> <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> </license> (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. 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> -----Original Message----- From: Maloney, Christopher (NIH/NLM/NCBI) [C] [mailto:maloneyc@xxxxxxxxxxxxxxxx] 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: 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><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><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><mai lto: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:nikos@xxxxxxxxxx> [mailto:jats-list-service@xxxxxxxxxxxxxxxxxxxxxx] Sent: Monday, October 13, 2014 11:31 AM To: jats-list@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list@xxxxxxxxxxxxxxxxxxxxxx><mai lto: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><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><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<-list/281881> (by email<>) ________________________________ 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [jats-list] Open Access Indicat, Halloran, Shaun shal | Thread | Re: [jats-list] Open Access Indicat, Halloran, Shaun shal |
[jats-list] Replication publication, Melissa Harrison m.h | Date | Re: [jats-list] Open Access Indicat, Halloran, Shaun shal |
Month |