Re: [jats-list] Request to identify each <sec> in an article by a unique DOI

Subject: Re: [jats-list] Request to identify each <sec> in an article by a unique DOI
From: "Evan Owens eowens@xxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 17 Jul 2014 18:50:58 -0000
CrossRef does support DOIs for components of a journal article; the CrossRef
documentation mentions figures, tables, or images but the description is broad
enough that it looks like sections would be allowed as well.  You do not need
a response page for the component as you do for the article proper; all it has
to do is to link to the componentb&so I would imagine that it would point
directly to the section in the HTML full text.  If that is the functionality
that is desired, it is not unreasonable to consider using DOIs for sections.

Assigning DOIs and not registering them is definitely a bad practice. In my
Portico days when processing content from 70 publishers, we saw at least one
major publisher (who will remain anonymous) who had tons of unregistered DOIs
buried in their journal articles, including a DOI for the abstract and the
other components.

From: Alexander Schwarzman aschwarzman@xxxxxxxxx
[mailto:jats-list-service@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Thursday, July 17, 2014 1:36 PM
To: jats-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [jats-list] Request to identify each <sec> in an article by a
unique DOI

Linda:
This may not be a very politically correct thing to say, but has anyone asked
WHY the customer wants to have a DOI on each section of an article? Are they
really going to deposit metadata for each section of the article through a
registration agency, like CrossRef? Are they willing to pay for that? Are they
really going to create a response page for each section of the article? What
would be the rationale for doing so? If so, why? If not, and they just need a
section ID, why should that ID assume the form of the DOI?
We know that in the current publishing paradigm hidden metadata has a tendency
to get exposed, unexpectedly. If there is a DOI in the article, and it is not
deposited through a registration agency, it is a violation of best practices.
DOI, if assigned, should be deposited; and the response page, created.

In my humble opinion, before rushing to change the Tag Set to accommodate this
request, shouldn't someone question the assumptions underlying the customer's
request? What problem are they trying to solve, really?
-- Sasha
Alexander ('Sasha') Schwarzman
Content Technology Architect
OSA -- The Optical Society

On Wed, Jul 16, 2014 at 2:01 PM, Good, Linda
linda.good@xxxxxxxxxx<mailto:linda.good@xxxxxxxxxx>
<jats-list-service@xxxxxxxxxxxxxxxxxxxxxx<mailto:jats-list-service@xxxxxxxxxx
errytech.com>> wrote:
Hello,
Webve had a customer request to add unique DOI numbers for each <sec> of an
article, e.g. if primary DOI is:   10.????/_______, then each sub-item would
have 10.????/_____.a,  10.????/_____.b, etc.

Is there a preferred method of including this type of functionality in the
JATS dtd structure?
Thank you in advance for any advice.

Lin



[cid:image001.jpg@xxxxxxxxxxxxxxxxx]<http://www.cenveopublisherservices.com/>



Linda J. Good

XML Dev. Team Leader / Sr. Content Architect

Cenveo Publisher Services
3575 Hempland Rd., Lancaster PA 17601

t. 1.717.285.6815<tel:1.717.285.6815> | e.
Linda.Good@xxxxxxxxxx<mailto:Linda.Good@xxxxxxxxxx>
c. 1.717.471.6406<tel:1.717.471.6406>

w. www.cenveopublisherservices.com<http://www.cenveopublisherservices.com>

Innovate.  Automate.  Collaborate.


[cid:image002.png@xxxxxxxxxxxxxxxxx]<http://www.linkedin.com/company/12745?tr
k=tyah&trkInfo=tas:cenveo%20publisher>[cid:image003.png@xxxxxxxxxxxxxxxxx]<ht
tps://twitter.com/CenveoPublisher>





****
JATS-List info and archive<http://www.mulberrytech.com/JATS/JATS-List/>
EasyUnsubscribe<-list/183043> (by email)

JATS-List info and archive<http://www.mulberrytech.com/JATS/JATS-List/>
EasyUnsubscribe<-list/168508> (by email<>)

[demime 1.01d removed an attachment of type image/jpeg which had a name of image001.jpg]

[demime 1.01d removed an attachment of type image/png which had a name of image002.png]

[demime 1.01d removed an attachment of type image/png which had a name of image003.png]

Current Thread