Does the Crossref Issue Export care about Issues, or Articles?

[ctgraham]

Branch from #808

In User Home > Journal Manager > Import/Export Data > Crossref Export/Registration Plugin > Select Issues, we check each issue for unregistered Articles. If the issue contains unregistered articles, we add it to the display.
https://github.com/pkp/ojs/blob/ojs-dev-2_4/plugins/importexport/crossref/CrossRefExportPlugin.inc.php#L123

The messaging when no issues are queued for display is "plugins.importexport.common.export.noIssues". This currently indicates that "No issues have DOIs assigned". If the plugin really does support Issue DOI registration, the issues display should not be dependent on (only) the article statuses. If the plugin is strictly concerned with article registration, the message should be different.
CrossRefExportPlugin::canBeExported() seems to be concerned with Articles, but the opinion of the Pitt ULS is that this plugin should be able to register the Issue DOI itself.

[asmecher]

Thanks for filing!

[ctgraham]

I should also mention that while we think the Crossref plugin should be concerned with Issue DOIs, we don't actually use Issue DOIs ourselves. That's why I'd prefer a wider conversation before "fixing" this myself.

[asmecher]

Agreed; I don't know, but perhaps @jmacgreg and @mnason have some ideas?

[bozana]

I think that theoretically it is possible to use the DOIs for any objects but we decided long time ago that this plug-in will base and support only i.e. mainly articles, i.e. articles have to be chosen in the plug-in settings. If additionally somebody assigns DOIs also to the issues, the issue DOI will be exported by/in the article XML export too. I think the same is for the supp files -- they can get DOIs, but will be exported just together with the article export, in the article XML export file -- Just an info, for you to know the background...

[jmacgreg]

Yep, what Bozana said. :-) CrossRef, as far as I know, only permits article
(and supp file) DOIs to be registered.

On Thu, Oct 15, 2015 at 6:57 PM, bozana notifications@github.com wrote:

I think that theoretically it is possible to use the DOIs for any objects
but we decided long time ago that this plug-in will base and support only
i.e. mainly articles, i.e. articles have to be chosen in the plug-in
settings. If additionally somebody assigns DOIs also to the issues, the
issue DOI will be exported by/in the article XML export too. I think the
same is for the supp files -- they can get DOIs, but will be exported just
together with the article export, in the article XML export file -- Just an
info, for you to know the background...

—
Reply to this email directly or view it on GitHub
#824 (comment).

James MacGregor
Publishing Services Coordinator
Public Knowledge Project (PKP)
Twitter: @jmacgreg
Skype: j.macgreg

[ctgraham]

From the Crossref docs:

DOIs may optionally be assigned to the journal itself, a specific volume or a specific issue. However, we strongly encourage the assignment of a DOI at the journal title level (journal title DOIs often use the ISSN as the suffix). DOIs should be assigned to all articles published within the journal and may be assigned to other content as well (e.g. book reviews, editorials etc.). Items that are part of an article which may benefit from having their own identifier can be registered as components and given a DOI unique from that of the article. These items include figures, tables or supporting data files.

http://help.crossref.org/deposits

[ctgraham]

See some current confusion on the existing setup here:
http://forum.pkp.sfu.ca/t/why-are-some-issues-missing-for-crossref-xml-export/4765

I think this use-case (batch updating metadata, issue-by-issue) would also point toward changing the plugin's workflow and not just the messaging of the "No Issues" message.

[asmecher]

@jmacgreg, you're the assignee for this; any plans for OJS 2.4.8 or should I defer it?

[jmacgreg]

Man, I have no idea why I assigned this to myself, but OJS 2.4.9 has a good ring to it.

[jmacgreg]

I will try and prioritize this, but I'm wondering if it would be better to send @bozana 's way. Bozana, would you mind?

[bozana]

Hi all,
Yes, I can do it, but I don't know what :-DDD I am not sure what is then the preferred/best way to go:
a) to support the only issue DOI deposit or
b) to improve the naming/usability of the current articles batch (issue-by-issue) DOI deposit?
If a): what would then be the best way to make the batch article DOI deposit (e.g. issue-by-issue) easier? Or would there then be none such?
If b): I will surely have some questions how to name it best (e.g. article batch (issue-by-issue) export) i.e. how to best improve it :-)

A note: I am not sure how many Crossref users will use (only) DOIs for issues. If they use issue and article DOIs, the issue DOIs are included in the article XML deposit file, so that they are however registered in Crossref, right? In that case caring for issue export would make sense only if the journal is using DOIs only for issues. This case (using DOIs only for issues) is not considered in the current plug-in solution.

What do you think?
Thanks!!!

[bozana]

Hi @jmacgreg and @ctgraham, the same question appeared in the forum: http://forum.pkp.sfu.ca/t/ojs-crossref-plugin-doi-to-issues-only/13291, so maybe to decide how shall we proceed with this issue for OJS 2.4.x?
I believe the minimum invasive thing to do would be to leave "Export issues" page mostly as it is and just behave accordingly:

• if only issue object (and no article object) is selected in the DOI plugin settings, then export/register only issues (the XML would look the same, but just without 'journal_article' part)
• if article object is selected in the DOI plugin settings, then as till now.

What do you think?

[jmacgreg]

Hi @bozana, that sounds good to me.We should probably run the XML output by Crossref though, just to make sure it looks appropriate to them.

[NamitaBi]

Hi @bozana @jmacgreg @asmecher Let me explain a situation here. If user wants to assign DOIs later to all old issues/volumes, then there is no way to do that.

A additional tab like this for issues will do no harm:

Kindly consider it and make it happen.

Thanks

[ctgraham]

Hi, @NamitaBi, please use the Feature Request section in the PKP Support Forum to propose this change. You may want to link to this closed GitHub Issue in the "Additional information" section of the template, but PKP colleagues are not monitoring comments on closed issues here in the same way that we are monitoring activity in the Support Forum.

[NateWr]

Just FYI that this request is already addressed in the DOI improvements coming in 3.4. That will add bulk actions to assign and deposit DOIs, and includes filters to see all submissions in an issue.

[ctgraham]

@NateWr , does that include assigning DOIs to the Issues themselves?

[NateWr]

Yes, the new DOI management screen has a tab for assigning and depositing issue DOIs as well (when they are enabled).

[NamitaBi]

Just FYI that this request is already addressed in the DOI improvements coming in 3.4. That will add bulk actions to assign and deposit DOIs, and includes filters to see all submissions in an issue.

Yes, the new DOI management screen has a tab for assigning and depositing issue DOIs as well (when they are enabled).

@NateWr That's wonderful news. When it's going to be live? Any approximate date or month?

[NateWr]

We hope that 3.4 will be released in the next 3-6 weeks.