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?
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…
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); } } }
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?
Hmmm… Interestingly the other piece of code is working for the HTML code… and for me, on my local installation… 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…
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
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.
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.
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.
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.
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.
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
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?