Does the CrossRef Export tool overwrite data previously deposited at CrossRef? eg If DOIs were previously uploaded to CrossRef some time ago, then we try to write new DOI metadata that points back to an OJS based article, does that data actually get updated?
Thank you.
Hi @radjr
The Crossref export/registration plugin used the current article/DOI metadata. I.e. yes, if you use the export/registration it will update the DOI metadata previously registered. â If Crossref sees that a DOI is being deposited that is already in their system (i.e. previously registered/deposited) it will update the metadata of that DOI with the metadata from that new deposit/registration.
Best,
Bozana
Thanks Bozana, It seems that data for previously submitted DOIs is not being updated, or there is some propagation time for them to be live.
It seems that the re-registrations are failing because of an error where the system time does is less than or equal to the existing time. Here is a sample of the supplied data. The other interesting thing is the email address that is being used to submit the data. Where did that email come from? Thanks!
<doi_batch xmlns=âhttp://www.crossref.org/schema/4.3.6â xmlns:ai=âhttp://www.crossref.org/AccessIndicators.xsdâ xmlns:jats=âhttp://www.ncbi.nlm.nih.gov/JATS1â xmlns:xsi=âhttp://www.w3.org/2001/XMLSchema-instanceâ version=â4.3.6â xsi:schemaLocation=âhttp://www.crossref.org/schema/4.3.6 http://www.crossref.org/schema/deposit/crossref4.3.6.xsdâ>
ea437a67-bf44-43f9-8eae-3b2e364c99d8 1517847854 Richard A. DeVito, Jr. crlabs@fastmail.fm Weston Medical Publishing, LLC Journal of Opioid Management J of Opioid Management 1551-7489 1551-7489 09 01 2012 8 5Error Code: Record not processed because submitted version: xxxxxxx is less or equal to previously submitted version (DOI match)
Hi @radjr
Ah, yes, it happens that different systems use different time format for the XML element timestamp when depositing DOIs. OJS uses the PHP function time() for that, s. http://php.net/manual/de/function.time.php. Others maybe use something like YYYYMMDDHHmmss. Thus when Crossref compares them (maybe just as numbers?) it could happen that the OJS timestamp is less than the other, old one, that was previously deposited/used. In such a case the metadata are not updated, because Crossref thinks that that deposit is older than the previous one.
I do not know what possibility are there for Crossref to adapt the old timestamps for a specific DOI prefix to the new time format used. Else, maybe you can adopt the OJS function, but if the journal is planing to use OJS in the future, it would have to always consider that change.
The depositor e-mail that is used for DOI deposit can be defined in the Crossref plugin settings. If there is no such e-mail there and per default the technical support contact e-mail from the journal settings page is used.
Best,
Bozana
Thanks. I find it humorous that a standardized time format cannot be âstandardized.â I have asked Crossref if they can invalidate all our records and we will reload from OJS.
With regards to the depositor email, we are unable to find any settings in any of the crossref plugins and cannot find the âtechnical contactâ in the journal settings page of 2.4.x
Thank you.
Richard A. DeVito Jr.
Publisher
Weston Medical Publishing, LLC, 470 Boston Post Road, Suite 301, Weston, MA 02493 USA
radjr@pnpco.com - 781-899-2702 ext. 107 - 781-899-4900 fax
Join us at the 2018 International Conference on Opioids, June 10-13, 2018
www.opioidconference.org http://www.opioidconference.org/
So, here is the problem. I had to find the Crossref time stamp. It is as follows in bold:
10.5055/jom.2012.0128 10.5055 201301081344 2013-01-08 8
10.5055/jom.2012.0129 10.5055 201301081344 2013-01-08 4
10.5055/jom.2012.0130 10.5055 201301081344 2013-01-08 3
Crossref returns YYYYDDMMTTTT where as OJS returns number of seconds from the unix epoch.
OJS uses the Time() stamp which returns 1517847854 in the XML
How do I force OJS to create the appropriate time stamp to match the crossref format? Crossref has said the only want is to hand edit the xml and upload.
Thoughts? Thank you!
From CrossRef:
Feb 5, 17:41 EST
Hi Richard,
The web deposit form creates an XML deposit for you, based on the metadata that you entered manually. A copy of that deposit is emailed to the email address you submitted on the form (in this case, deborah_rines@pnpco.com) immediately after its submitted, and then once the file is processed a submission log email is sent out to that same email address.
While youâre entering metadata into the form, it does display as XML in the top of the form, and I think thatâs what youâve attached. However, thatâs not the full metadata deposit. It doesnât include the XML declaration, batch ID, or section with the depositor and registrant elements. Those are added when you complete your deposit and submit the form. A copy of that full XML that youâve deposited is whatâs emailed back to you.
So, youâre right in the sense that when you use the web form, you canât select your own timestamp for each deposit. The form adds in it automatically using a 12 digit time date format (YYYYMMDDHHMM). Typically web deposit users only update their DOIsâ metadata by resubmitting new deposits through the form, so the timestamp is incremented appropriately. And, if theyâre just doing URL updates, they send us files of DOIs and new URLs, so we can update them.
However, since youâre switching from the web deposit to depositing through OJS, youâll need to either adjust the timestamps on your OJS deposits to being numerically larger than the previous timestamps set by your web form deposits, or have us reset the timestamps. If you donât want to switch to a date-time format, you could just add three zeros on the end of your existing timestamps. I.e. if 1517587201 becomes 1517587201000, it will still be numerically larger than 201107261210, and so wonât be rejected.
( I would prefer to enter the correct TIMESTAMP data versus a UNIX TIMESTAMP. How can we do that?
Cheers!
@radjr, what ojs version exactly are you using?
OJS 2.4.8.1
Richard A. DeVito Jr.
Publisher
Weston Medical Publishing, LLC, 470 Boston Post Road, Suite 301, Weston, MA 02493 USA
radjr@pnpco.com - 781-899-2702 ext. 107 - 781-899-4900 fax
Join us at the 2018 International Conference on Opioids, June 10-13, 2018
www.opioidconference.org http://www.opioidconference.org/
Hi @radjr
If you go as Journal Manager to the Journal Management > Import/Export Data > CrossRef Export/Registration Plugin, you should see there the part âSettingsâ and the link âconfigure the CrossRef export/registration plug-in here.â. There you can add the depositor name and e-mail.
If you go as Journal Manager to the Journal Management > Setup > Details > 1.3 Technical Support Contact, you can add there the technical support contact name and e-mail.
Here is the place in the code (for your version 2.4.8.1) where the element âtimestampâ is created: ojs/CrossRefExportDom.inc.php at ojs-2_4_8-1 · pkp/ojs · GitHub. There you can adopt it as neededâŠ
Best,
Bozana
Thanks. Both locations are set up with our correct email. Note the (.fm) email address shown below. Very odd.
Re: Timestamp, we just select all issues in the crossref plugin, export the data and manually change timestamp to the crossref format and then upload it to crossref! Maybe this is fixed in the next release? Cheers!
On the Crossref side, the deposit-API that supports the OJS plugin inserts an email address to which a log file gets sent. This log is output by our batch deposit processes. The deposit-API scans for these emails, which verifies the deposit was completed. This supports CheckStatus feature in the CrossRef XML Export Plugin.
This workflow has been broken for the past 2+ months. It is now functioning again. However, it will only work for DOIs submitted going forward.
Note: the ânewâ CrossrefXMLDeposit OJS plugin will not operate this way.
Hi
I had the same problem with the 3.1.1.1 version and I changed row 102 and 103 in https://github.com/pkp/ojs/blob/ojs-stable-3_1_1/plugins/importexport/crossref/filter/IssueCrossrefXmlFilter.inc.php
to
$headNode->appendChild($node = $doc->createElementNS($deployment->getNamespace(), 'doi_batch_id',htmlspecialchars($context->getSetting('initials', $context->getPrimaryLocale()) . '_' . date("YmdHi"), ENT_COMPAT, 'UTF-8'))); $headNode->appendChild($node = $doc->createElementNS($deployment->getNamespace(), 'timestamp', date("YmdHi")));
where time() was replaced by date(âYmdHiâ)
Maybe this can be an option for future releases to choose format of timestamp?
Great! Nice to hear! Looking forward to it!
Hi @bozana,
We need an urgent help. The problem is this: we are testing the OJS 3.1.2. So we have two instances installed and working: 3.1.1-4 (production) and 3.1.2 (test).
Today weâve noticed that the CrossRef plugin in 3.1.2 seems to have updated metadata automatically. So all the DOIs at the production site now resolve to our test site 
The question is whether it is some new logic in the CrossRef API/module, which causes such behavior? What may trigger it? (such problem is observed only for one journal). How could we revert this back?
Please, help!
Thank you so much for this tip!
Thanks to it I could update data in CrossRef. (OJS 3.1.2.4)
Regards
Wojtek
Getting back to this thread. We have a 3.3.0.13 installation and the OJS plugin does NOT seem to update the data on the crossref side. For DOIs that were created manually on the crossref site, those DOI data are not being overwritten. We see OJS posting a changeâŠbut the xml file contains no updated information.
So, a little more data on this problem. It seems that when DOI data is âupdatedâ at crossref, the data does not populate immediately but takes some time to be reindexed by crossref.
If you go into the crossref portal, you can look at the data submitted and the data in the actual posting. I our case, the date field was right, but the data was not being updated (immediately). The update status was successful. So, we reached out to crossref and they explained the indexing issue and delay. Hope this helps.