This past year has been a captivating journey of immersion within the Crossref community, a mix of online interactions and meaningful in-person experiences. From the engaging Sustainability Research and Innovation Conference in Port Elizabeth, South Africa, to the impactful webinars conducted globally, this has been more than just a professional endeavour; it has been a personal exploration of collaboration, insights, and a shared commitment to pushing the boundaries of scholarly communication.
One of the challenges that we face in Labs and Research at Crossref is that, as we prototype various tools, we need the community to be able to test them. Often, this involves asking for deposit to a different endpoint or changing the way that a platform works to incorporate a prototype.
The problem is that our community is hugely varied in its technical capacity and level of ability when it comes to modifying their platform.
When each line of code is written it is surrounded by a sea of context: who in the community this is for, what problem we’re trying to solve, what technical assumptions we’re making, what we already tried but didn’t work, how much coffee we’ve had today. All of these have an effect on the software we write.
By the time the next person looks at that code, some of that context will have evaporated.
It turns out that one of the things that is really difficult at Crossref is checking whether a set of Crossref credentials has permission to act on a specific DOI prefix. This is the result of many legacy systems storing various mappings in various different software components, from our Content System through to our CRM. To this end, I wrote a basic application, credcheck, that will allow you to test a Crossref credential against an API.
The Metadata Manager tool is in beta and contains many bugs. It’s being deprecated at the end of 2021. We recommend using the web deposit tool as an alternative, or the OJS plugin if your content is hosted on the OJS platform from PKP.
Once you click Deposit, we immediately process the deposit and display the results for accepted and rejected deposits. All deposit records accepted by the system have a live DOI.
All deposit results are archived and available for reference on the Deposit history tab on the top menu bar.
You can also see your deposit history in the admin tool - go to the Administration tab, then the Submissions tab. Metadata Manager deposit filenames begin with MDT. You can even review the XML that Metadata Manager has created your behalf.
Updating existing records and failed deposits
Metadata Manager also makes it easy to update existing records, even if you didn’t use Metadata Manager to make the deposit in the first place. You must add the journal to your workspace before you can update the records associated with it - learn more about setting up a new journal in your workspace.
Accepted and Failed submissions can be updated using the respective tabs in the workspace. Click into the journal, and then click into the article. Add or make changes to the information, and then deposit.
What does the status “warning” in my submission result mean?
When similar metadata is registered for more than one DOI, it’s possible that the additional DOIs are duplicates. Because DOIs are intended to be unique, the potentially duplicated DOI is called a conflict. Learn more about the conflict report.
In Metadata Manager, if you register bibliographic metadata that is very similar to that for an existing DOI, you will see a status “warning” with your submission result. This is accurate.
When you return to your journal workspace in Metadata Manager to review your list of DOIs, the DOI that returned the “warning” will display as “failed”. This is inaccurate, as you can see if you try to resolve the DOI in question. We are working on improving the wording in this part of the process to make it less confusing.
Page owner: Sara Bowman | Last updated 2022-July-22