ارجوا ايجاد طريقة للحل

Content Registration
, , ,
1

ما هو الحل
ارجوا منكم المساعدة

<?xml version="1.0" encoding="UTF-8"?>

<submission_id>1607884831</submission_id>
<batch_id>_1705860465</batch_id>
<record_diagnostic Status=“Success”>
10.37376/glj.vi36
تم التحديث بنجاح في المقبض
</record_diagnostic>
<record_diagnostic Status=“Failure” msg_id=“4”>
10.37376/1570-000-036-001
لم تتم معالجة السجل لأن الإصدار المقدم: 1705860465 أقل أو يساوي الإصدار المقدم مسبقًا 20200203091724000
</record_diagnostic>
<batch_data>
<record_count>2</record_count>
<success_count>1</success_count>
<warning_count>0</warning_count>
<failure_count>1</failure_count>
</batch_data>
</doi_batch_diagnostic>

2

Hello, and welcome to the community forum.

The metadata update for the DOI 10.37376/1570-000-036-001 failed due to a timestamp error.

Each time a given DOI is updated, our system requires that the value in the xml is numerically larger than the previous submission’s . The purpose of this is to prevent someone from accidentally overwriting newer metadata with older metadata, if they happen to submit an outdated xml file.

Ensuring that each timestamp is numerically higher than the last is typically accomplished by using a standard date-time format to construct the timestamp when the xml files are created.

However, different systems use different date-time formats, so when a DOI needs to be updated by a different organization than the one that first registered or last updated it, or if you’re using a different system to produce the xml, there can be instances where a smaller timestamp value is used after a larger one. This will cause the deposit to fail.

We can reset the timestamp when necessary, after a title transfer or system change, etc. If you can send me a list of DOIs that need to be reset, I’ll change their timestamps to something smaller. Then, you can proceed with your update submissions.

If you ever need to check the most recent timestamp for a given DOI, you can find it in the previous metadata deposits, the xml api record, or the depositor report for the relevant journal.

Also, please note, if your xml is constructed in a way that you’re repeating the same DOI multiple times in a single deposit, this will always result in a timestamp error for all but the first instance. This is okay, and you can ignore the error in that case as long as the metadata is accurate and up to date.

Best,
Evans

3

السلام عليكم
ارسل لكم قائمة doi التي تحتاج الي تغير الطوابع الزمنية

في اثنين، 22 يناير، 2024 في 2:49 م، كتب Evans Atoni via Crossref Community Forum <notifications@crossref.discoursemail.com>:

extract.csv (37.2 KB)

4

Thank you @rwaida . I’ve gone ahead and reset the timestamps of all of the DOIs in your csv file. After doing so, I also reprocessed submission 1607884831. The metadata for DOI 10.37376/1570-000-036-001 has been successfully updated and a Similarity Check URL is now registered in that DOI’s metadata.

<record_diagnostic status="Success">
      <doi>10.37376/1570-000-036-001</doi>
      <msg>Successfully updated</msg>

We’re now working to index that update. You should see that metadata record updated in our APIs and the Similarity Check report in about 24 hours.

If you have other DOIs from that list in the csv file that you need to submit Similarity Check URLs for, you may do so now. You should no longer receive timestamp errors for the journal article DOIs in those submissions.

My best,
Isaac