We are currently in the process of applying as an independent member of Crossref and I, as a technician, have some questions about the generation of DOIs.
more specifically, I am trying to understand the proper way to use OJS-Crossref plugins for our scientific journals, so I was wondering if you could help me
So, here’s the setup
We have a printed-first type of journal. Only when the physical copy of an issue is out, we publish it online via OJS
We have already 13 (quarterly) issues of the journal (published both physically and in OJS), first 4 of them have DOIs with incorrect suffixes made by our previous sponsored DOI supplier (which ceased its operation unfortunately).
We want to have DOIs for every article to be represented in the printed copies of issues, so we have to know or guess them (according to some predetermined pattern) prior to sending the issue to the publisher
So, I was checking Crossref’s DOI guidelines, and as you all know it is recommended that the suffixes are “dumb” and opaque, which can be achieved automatically via Crossref’s XML OJS plugin
The problem is, these “proper” suffixes are randomly-generated after you publish the article online, so as far as I’m concerned, it’s impossible to assign them PRIOR to physical publishing phase
Anyway, the ideal workflow as I see it would be as such:
Create “preliminary” article entities in OJS in order to generate proper suffixes (or some other method in order to reserve the required number of suffixes)
Use those suffixes in publishing to have them represented in the printed physical version of the issue
After the final editing and layout phase, continue with the online publication via OJS
As this workflow is presumably impossible, I was wondering if the dumb-and-opaque requirement is more connected to the “online-only” journals, and in our case, when we have this dependency to a physical copy, we can use the custom and predictable DOI pattern which can be used in order to print them into the physical copies.
In our system, we assign a globally unique identifier to a submission, and that ID lives through the complete workflow. If the article is eventually published, then we simply construct an opaque ID from that (we use a trivial encryption technique that simply obfuscates what the original article ID was. We use a LaTeX-based workflow so the article can be compiled with the DOI baked into it as soon as the article is accepted. We do not use OJS, but their plugin has several patterns, and one of those allows the DOI to be known before it is published. Perhaps you should take it up with the OJS developers if you need a new pattern to generate the DOIs.
I understand that you need DOI suffixes generated prior to publishing your content in OJS so that you can prepare the printed version of the issue. Below are a few options that may streamline the process:
General Comments
If you are using OJS for submission, peer review, and copyediting:
Your submissions are already in the system.
In OJS 3.3: You can assign DOIs during the copyediting stage and keep the submissions unpublished until the print version is released. This way, you’ll have the DOIs in advance.
In OJS 3.4: Go to Distribution > DOIs and select “Upon reaching the copyediting stage” for Automatic DOI Assignment. This will allow you to generate DOIs before publication.
If you are only using OJS for publication:
You can upload your submissions into OJS using the QuickSubmit plugin, and mark them as Unpublished.
In OJS 3.3: You can assign DOIs before publication.
In OJS 3.4: Again, set Automatic DOI Assignment to “Upon reaching the copyediting stage” so DOIs can be generated in advance.
Once your print version is ready, you can publish the content in OJS at the appropriate time.
*If the content in the print and digital versions is identical, you should not generate or assign separate DOIs.
I hope this helps clarify the options. Please let us know if you have further questions.