How to generate a DOI suffix in accordance with CrossRef recommendations?

Software Support
,
1

Dear Community,

We need to determine the DOI suffix to our new journal. One thing that is clear from the CrossRef documentation is that it must be opaque.

Suffixes are ‘dumb numbers.’ They are essentially meaningless on their own and meant to be that way–opaque. source

However I did not find (yet) a good solution with the PKP DOI plugin.

Use %j for journal initials, %v for the volume number, %i for the issue number, %Y for the year, %a for the OJS article ID, %g for the OJS galley ID, %f for the OJS file ID, %p for the page number and %x for “Custom Identifier”.

What are your tips for generating a suffix with OJS in compliance with CrossRef?

Some ideas

  • /my-journal.id
    id can be generated via the DOI plugin with the %a.
    but even an increment is not recommended (because of scrapping). And nor the journal name is recommended.

  • /id
    problem : the id of the publication is unique for the journal, not for the “plateform” : what about tomorrow when I will have 4 journals and 2 monoraphies ?

  • /custom-identifier
    with the %x feature. But it should be managed manually.

I feel like I cannot respect all CrossRef recommandations with current OJS, because of a lack of an identifier (not an increment).

  • /my-journal.42010
    will satisfy us, but how to generate an identifier with 5 digits that correspond to the id of OJS, any tips ?

best,
Maxence

3

Hi @mlarrieu,

Thanks for your question. There is some information about configuring the DOI plugin in our documentation: DOI Plugin

The “Use default patterns” option does comply with the CrossRef requirements for DOIs.

I will ask a PKP colleague to weigh-in with some more specific information to address your questions.

Best,

Kate

1 Like
4

Thank you for your feedback @kshuttle.
the “use default patterns” option correspond to %j.v%vi%i.%a.
It will certainly work, but unfortunately it will not be in accordance with CrossRef guidelines: none of these elements are opaque.

DOIs should not include information that can be understood, interpreted or predicted, especially information that may change. Page numbers and dates are examples of information that shouldn’t be included in suffixes source

5

My best practice is: %Y.%i.%p I think this is absolutely clear. The first tag in the suffix is generated from the journal name or abbreviation. So I use the custom generation in OJS.

6

Thank you for your feedback @molnart.

for information, a suffix generator made by CrossRef, available as an .xlsm file

example of generated DOIs :

10.456/PSWT5792
10.456/WXPE2165
10.456/PFDU6201
10.456/BQSB1203
7

I can provide a little bit of context here. The “use default patterns” is definitely a little outdated in the plugin and it does go against Crossre’s recommendations. But it does not go against any guidelines or policies. Crossref will not stop you from registering any suffix unless it has characters it cannot parse.

We’ve been discussing the implementation of opaque, generated DOIs for the plugin for some time and it’s on our list of features to add to the plugin down the road. It is a complicated issue. A lot of publishers really do want to fill their suffix with human-readable content and it can cause a lot of issues down the road if, say, the journal name changes and they want to update their suffixes.

Crossref understands this as well, which is why they don’t force opaque dois to be generated.

My recommendation is to limit metadata-based suffixes as much as you’re comfortable with. Usually, when I set clients up in our hosting service I chose the journal abbreviation, year, and article id. It’s kind of a concession. This definitely does not meet the best-case scenario outlined by Crossref, but these DOIs work fine, and Crossref won’t prevent you from doing this.

Best,
Mike

1 Like
8

Thank you for your feedback.
We have chosen the following syntax /journal-abbr.hashId
with hashId being the result of the Hash function crc32 on the submission id within OJS.

So our DOIs will looks like /journal-abbr.4sdf

Currently it is an option, hard coded in the OJS plugin. When we have more time we would like to better integrate it (%h as a new element in the “Use the pattern entered below” option").

best,
Maxence

9

Here is the current version of my plugin :

It uses the hash crc32c function of php to generate an opaque code from article identifiant using %h in the pattern. It generates a 4-character hexadecimal code without collision for the first 8000 articles, then 6 characters until the 200000th article and then 8 characters until the 2000000th.

This seems to work well but only when used in the publication DOIs because galleys DOIs are generated through the js/build.js script for some reason unknown to me…

2 Likes