Full Issue DOIs don't show up on export list

Software Support
1

We have been adding in full issue galleys to our past issues and the issue galleys were not showing up in the DOI export list. Under the DOI settings, I checked the galley option. The issue and article options where checked.

Questions:

  1. Do we need to unpublish an issue and republish the issue for the full issue galley DOI to show up in the list of DOIs?

  2. What is the difference between the “Issue” and “Galley” settings in the DOI settings page?

  3. In the issue galley DOI page, the prefix is already filled. Does the suffix need the leading “/” or does this get inserted automatically? eg should we put /jom.633 or jom.633 in the suffix field?

  4. What is industry standard for full issue DOIs?

Thanks!

OJS 3.3.0.20

2

I suspect not? But it might be worth trying if the issue your are seeing persists. I think that if you enable the DOI assignment for issue galleys in the DOI plugin settings after the issues are already published, DOIs may not be automatically generated for existing galleys. However, you may need to manually assign DOIs or use the “Assign DOIs” bulk feature in the DOI settings/Crossref plugin after enabling galley DOIs. If this doesn’t work, it may be worth unpublishing/republishing.

Issue settings: Assigns a DOI to the entire issue (the issue as a whole object).
Galley settings: Assigns DOIs to individual galley files, for example, if you have multiple galley types (e.g., PDF, HTML)

“Article” DOIs typically point to the article landing page, whereas “Galley” DOIs point to specific files. The article DOI is fairly standard for discoverability. Galley DOIs tend to be less common and are often not registered with Crossref unless specifically configured, as Crossref typically indexes article-level DOIs, and not file-level ones.

I think it should be that you do not include the leading slash in the suffix field. The DOI is structured as: prefix/suffix (e.g., 10.1234/jom.633 ). OJS combines the prefix and suffix with a slash automatically. So you should enter "jom.633" as the suffix, without a leading slash.

The most common standard is assigning DOIs to articles, not usually to full issue galleys.
When used, however, full issue DOIs follow the same DOI structure and are registered with Crossref using a logical, unique suffix (often including the journal acronym, volume, and issue), for example: 10.xxxx/jrnl.v1i2.issue

Many journals don’t register a DOI for the full issue galley. It is done, but just not as common.Instead, they provide DOIs for articles only. If you do register issue or galley DOIs, it’s best to test if they resolve to the article landing page.

I hope this helps to answer some of your questions.

Best regards,

Roger
PKP Team

3

Thanks Roger.

Couple of additional notes:

  1. We manually assign ALL DOIs to all articles and issues.

  2. Up until recently we were NOT using the ISSUE galley functionality.

  3. We never used the ISSUE DOIs but thought we had to now because we added issue galleys. (We used to add the full issue as an article before we understood to use the issue galley!) We want issue DOIs as we create them for each issue..so why not register them?

  4. The DOI setup has Issues, Articles and Galleys. You wrote “Galley settings: Assigns DOIs to individual galley files, for example, if you have multiple galley types (e.g., PDF, HTML)” We manually assign DOIs to everything but only have one galley type of PDF. Should I turn “Galleys” back off in DOI settings?

  5. Suggest that the page with the split DOI include the / at the end of the DOI example. That tells me that we just put the end of the DOI.

Finally, I have tried several ways and the full issue DOIs do NOT show up in the list of DOIs in the plugin. They show up on the issue page as expected but not on the DOI list. I checked the DOI submission email and there was NOT an email for the full issue DOI. Thoughts? Again, I have tried unpublish/republish and no change. Thanks!

4

Hi @radjr,

Thank you for the additional details. I’m afraid I’m at a loss for answering a number of your questions. I’m paging my colleague @AhemNason here, to see if he might be able to shed some light on these issues.

-Roger
PKP Team

7

This bug has been indentified in another post. Bottom line is that the

8

Further details.

The Email confirmation from Crossref on the submission does NOT list any details on the ISSUE doi, but somehow, the ISSUE DOI is registered with cross ref when the article is submitted.

I looked in the crossref admin page and the ISSUE doi job is there.

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

<doi_batch_diagnostic status=“completed” sp=“ip-10-4-2-147.ec2.internal”>
<submission_id>1709123612</submission_id>
<batch_id>_1755872640</batch_id>
<record_diagnostic status=“Success”>
10.5055/jom.0956
Successfully updated in handle
</record_diagnostic>
<record_diagnostic status=“Success”>
10.5055/jom.0915
Successfully updated
<citations_diagnostic deferred=“1709123613” />
</record_diagnostic>
<batch_data>
<record_count>2</record_count>
<success_count>2</success_count>
<warning_count>0</warning_count>
<failure_count>0</failure_count>
</batch_data>
</doi_batch_diagnostic>

So I looked at the JOB submission which is copied below. The article submission picks up the Issue data and submits it in line. This MAY be by design, but it has taken a couple hours to figure it out. Unpublishing and republishing an issue would not affect this. Again, you have to update the issue DOI, and then resubmit an ARTICLE from that issue.

I can't publish the entire XML because the system won't let me but here this was in the article XML file.

<doi_data>
<doi>10.5055/jom.0956</doi>
<resource>https://wmpllc.org/ojs/index.php/jom/issue/view/420</resource>
</doi_data>