OMP: DOI missing in OAI-DC

Hallo,

we are setting up the OAI-Interface of our OMP 1.1.1.1 platform. Unfortunately the dc:identifier element for the DOI is missing within the OAI-DC records. Within the html representation of an object the DOI shows up as "meta name=“DC.Identifier.DOI” but it is not included in the OAI-DC output (as it is for OJS). Is that a common problem or do I have to configure somehow the OAI-DC fields?

Best
Martin

Hi @matre,

The DOIs are not considered via the OAI yet – we are currently working on some improvements and will consider it too. If you need it and would like, I could take a look and send you the code you will have to insert, in order to display them via OAI…

Best,
Bozana

Hi Bozana,

thanks a lot for your reply. If it would be possible (and would not cost to much of your time) to send me the necessary code changes this would be great because we are using the OAI-Interface to register automatically our DOIs at the ETH Doi-Desk (http://www.library.ethz.ch/en/Dienstleistungen/Publizieren-registrieren-verwalten/DOI-Desk-der-ETH-Zuerich), so this would facilitate our workflow a lot

Best
Martin

Hi Martin,

You could use this code:
$pubIdPlugins = PluginRegistry::loadCategory('pubIds', true); foreach ((array) $pubIdPlugins as $plugin) { if ($plugin->getEnabled()) { $pubId = $plugin->getPubId($publicationFormat); if ($pubId) { $dc11Description->addStatement('dc:identifier', $pubId); } } }

And add it in the class plugins/metadata/dc11/filter/Dc11SchemaPublicationFormatAdapter.inc.php, where the other identifiers are build too, e.g. on the line 149: omp/Dc11SchemaPublicationFormatAdapter.inc.php at omp-stable-1_1_1 · pkp/omp · GitHub

I hope that helps…
Best,
Bozana

1 Like

Hi Bozana,

thank you very much for your fast help. Unfortunately PluginRegistry::getAllPlugins() only returned five Plugins (pubIds/doi is not included though plugin/pubIds/doi/index.php exists). A lot more plugins show up under Administration → Website Settings → Plugins.

Finally I got it working with the following lines. It seems like the DOI-Plugin is not enabled. Do you think that might create problems because the enabled check is missing?

                $doi_plugin= PluginRegistry::loadPlugin('pubIds','doi');
                $pubId = $doi_plugin->getPubId($publicationFormat);
                    if ($pubId) {
                            $dc11Description->addStatement('dc:identifier', $pubId);
                            }

Best
Martin

Hmmm… Interestingly the other piece of code is working for the HTML code… and for me, on my local installation… :open_mouth: But, if it works for you now, it is OK to leave it like that – it is for your own installation where the DOI plugin is/will always be enabled, right? And when working on the improvement for the next version we will double check that and then once you upgrade to that version, you will not have to take care about that code any more…

Best,
Bozana

Thanks a lot again for your fast and efficient help! Not only OJS/OMP are great, but also the people working there :thumbsup: :slight_smile:

just a short footnote: the HTML Code has never been the problem. It already worked before

Thanks a lot @matre! I am very glad you like the software and us! :slight_smile: It’s good to here that :-)))

Hello! Sorry to resurrect an old thread, but I’m getting the same problem in our OMP, running 3.2.1-4. We only get the URL in oai_dc, even though we have the DOI plugin enabled and the DOI can be found in the html. See here:
https://books.lub.lu.se/oai?verb=ListRecords&metadataPrefix=oai_dc

Does anyone know what may be the problem?

/Magnus

Hi @mannemark,

Can you double-check your OMP version number? There is no release called 3.2.1-4 (yet).

Regards,
Alec Smecher
Public Knowledge Project Team

Oops, sorry! I meant 3.1.2.4

Hi @mannemark,

just wanted to let you know, I will look into the problem and I will come back to you in the coming days.

Best wishes,
Dulip

1 Like

Hi @mannemark

I have gone through your issued and most probably, you have not assigned the dois
although you have activated the plugin.

Could yor confirm me the following settings are set correctly ?

  1. That you have checked the settings in your plugin
    Screenshot from 2020-11-22 09-16-51

  2. You have really assigned DOIS to your wished components e.g. submission or publication format.
    Screenshot from 2020-11-22 09-17-21

If those are set correctly, please let me know.

And also there is another problem, that may be an issue. I would like to pinpoint it.

Could you provided me the following details.

  1. Please provide the log message when you click on the following link in your installation.
    https://books.lub.lu.se/oai?verb=ListRecords&metadataPrefix=oai_dc&set=testpress2753

Hello Dulip,

Thank you so much for the help! It seems that the issue was the DOI plugin settings. I had set it to only be able to assign DOI to monographs and chapters, not the publication formats and files. Once I checked publication formats and files, it works. But this is quite odd, shouldn’t it work when only selecting some of the object types?

I thought I’d let you know that it works now, but I’ve also asked for the log about the testpress2753 error from my IT department, so I will get back to you on that.

Best regards,
Magnus

Very sorry, I checked again, and it looks like it takes the wrong DOI. I’ve assigned DOI to monograph and chapter levels, but after I activated DOI for publication formats and files in the plugin, it uses the DOI for the publication format (which I have not even assigned) in the OAI stream.

/Magnus

Hello!

I still have this problem with the DOI missing in the OAI DC output. The DOI only shows up when activating DOI:s for the publication format. This doesn’t work for us because we have only assigned DOIs to monographs and chapters, not for the formats.

Is it meant to be this way, or could it be a bug? It doesn’t make much sense to us to assign DOIs to publication formats. The DOI will resolve to the same page anyway, and the publication format DOI turns up at the bottom of the publication-details and is incorrectly formatted according to Crossref standards.
bild

All the best,
Magnus

Sorry to bump an old thread, please let me know if I should start a new topic instead.

I’m still wondering about this, would love it if someone has a comment. @Dulip_Withanage do you know anything about the logic behind this? I think it would make sense if the monograph DOI showed up in the OAI-DC, I will probably ask our developers to try to make it work this way once we start making use of the metadata, but I could also make it into a feature request if you agree.

Hi @mannemark

Via OAI interface the publication formats are provided, a OAI record for a publication format. That is why in the OAI interface we only consider DOI of the publication format.

Best,
Bozana

Thank you @bozana! That helps to understand. Although, may I ask why this is the case? I’m having problems sorting this out.

For instance, the publication date is always the one from the “monograph” (as in the metadata for the book in OMP) level, which will be the date of publication for the digital version, but not necessarily for the print version. We alse get the books’ URL in the dc:identifier for the print version, but the URL does not lead us to the print version any more than the DOI would.

There’s also the point I made above, that the way to get the system to display the DOI according to the crossref guidelines (https://www.crossref.org/display-guidelines/) is to use the monograph DOI. So to me it seems that users will have to choose between proper display of DOI, or full metadata in the OAI-PMH.

Sorry to go on about this, I’m trying my best to figure things out :smile:

Hi @mannemark

Yes, I think you are right…
Let me double check it all within the team…
And, to double check: you only have DOIs on the monograph/submission level, correct?