Hi,
I’m struggeling with DOI-Assignment in OJS 3.3.0.6.
The CrossRef Export Plugin seems to be correctly configured, it assigns correctly DOIs to articles and volumes following the default pattern (%j.v%vi%i.%a for articles).
It breaks down when I want a DOI to be assigned to an article of Volume “0” Issue “0”. I started working with this dummy issue for publishing online first articles, that are assigned later to a “real” issue.
This has been working fine with OJS 2.x now the issue arises.
I suppose it is related to the definition of the fields “volume” and “number”, that require a positive integer.
Unfortunately, no error is thrown when setting “0” for volume and number. It is saved without errors, but fields remain empty when editing the issue data again:
Any idea on how to solve this or get a workaround?
Many Thanks
Marco
There are a few things happening here, I suspect. One is that I think you’re clearly encountering a bug related to this interpretation of issue-level metadata. There’s been a few changes to the Crossref plugin as of late and some non-trivial work going into the plugin in general over the next few months. I can keep an eye on this bug and see if I can recreate it as we go.
Secondly, the other is that I get a sense that you’re manipulating issue-level metadata as a work-around for “online first” articles. As you probably know, OJS does not currently have any online-first or other “not-quite-published” features. As a result, the best I can do for you in terms of a work-around-for-a-work-around would be one of the following:
You could configure the Crossref plugin to not automatically deposit DOIs, and choose to assign DOIs for published material by hand (this is the third choice for suffix generation in the DOI plugin settings). This would be more work, but whatever DOI you want would be in place.
You could simply use a custom pattern that skips issues and volumes entirely. I recommend this broadly anyway, because users who are trying to “fix a DOI that came out wrong” is probably the leading cause of Crossref/DOI related headaches we see in support.
DOIs aren’t intended to be human-readable, so limiting your DOI suffix to abbreviation, year, and article ID should be sufficient for suffix needs and would avoid this issue altogether.
There kind of aren’t good answers here. If the workflow includes moving this article to the final published location, then editing that DOI from 0.0, and then registering that DOI, that’s a lot of effort. I’d probably just hand-mint at that point and not assign a DOI to anything in the “online first” “issue”.
If you’re registering these online first DOIs and then you’re minting a second set when the content is published, that’s similarly problematic. And it’s also costing you twice the amount of money.
OJS supports minting and registration of DOIs of published works. So for the best results in using and registering your DOIs, I can’t really recommend a workflow that involves DOI registration or assignment before they are actually published. Crossref does support DOI registration for pending publication but our current plugin does not.
If I’ve misunderstood any of your workflow here please let me know or hit me up with any follow-ups. Like I say, I’ll keep an eye on the metadata issue. in 3.3.x as we move forward with additional plugin development this summer.
Dear Mike,
Many Thanks for your thourogh analysis and exhaustive answer.
Things are pretty much as you describe them, I’m using a workaround for keeping (few) single online-first articles distinct from their issue-published version.
Most probably I will go with your suggested option 2. and switch to a custom pattern that doesn’t use issue and volume number!
Thanks also for keeping an eye on the Crossref plugin “0”-“0” behavior.
Kind regards,
Marco
