Requirements for changes to OAI interface MARC21

Dear Community,

we are planning to have some automated interface for connecting our OJS to our library catalogue. Our catalogue is in Germany and called K10plus (behind that is OCLC PICA/WinIBW).

We already got in contact with their service center and they mentioned they could connect to our OAI interface, however they have some change requests. They would like to add some identifier for the journal, so the article can be connected to the journal automatically (in our case the so called ZDB-ID, from the German Journal database ZDB) and give volume, number, year and pages in own subfields.

This is our link to the OAI: https://journals.wlb-stuttgart.de/ojs/index.php/index/oai
And this would be some example article (using marc21 format):
https://journals.wlb-stuttgart.de/ojs/index.php/index/oai?verb=GetRecord&metadataPrefix=marcxml&identifier=oai:ojs.journals.wlb-stuttgart.de:article/32

What they need additionally:

Included in WLB-Forum (DE-600)2054088-7 volume:23 number:1 year:2021 pages:76–77

So my questions would be:

  • How and where could we add this other journal identifier? Could we save it somewhere centrally like the ISSN or would it be per article?
  • How can we change the OAI interface? If we would do it locally, it would be gone with the next update. Could it come with some central update? Or do we need to build our own plugin (similar to e.g. the DNB plugin GitHub - ojsde/dnb: OJS plugin that exports full texts and metadata to the Deutsche Nationalbibliothek (DNB))?
  • Could we somehow export marcxml files with the mentioned requirements? It would be also possible to put some files on their FTP-server.

This is the link to our journal WLBforum and we are using version 3.2.1.4.
They want to use this protocoll.

Metadata Format
metadataPrefix marcxml
metadataNamespace http://www.loc.gov/MARC21/slim
schema http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd

Thanks a lot for your support and have a nice weekend!
Best regards
Julia

Hi all,

Our question might look complicated. But our main question is: what is the correct process to do future-proof changes in the OAI interface?

Somehow the code was not shown correctly. Below an update of what is needed additionally for OAI harvester:

<datafield tag="773" ind1="0" ind2="8" >
<subfield code="i" >Included in</subfield>
<subfield code="t" >WLB-Forum</subfield>
<subfield code="w" >(DE-600)2054088-7</subfield>
</datafield>

<datafield tag="773" ind1="1" ind2="8" >
<subfield code="g" >volume:23</subfield>
<subfield code="g" >number:1</subfield>
<subfield code="g" >year:2021</subfield>
<subfield code="g" >pages:76–77</subfield>
</datafield> 

Best regards
Julia

Hi Julia,

this is interesting - we have now the same intention by our library service team. They want to index the journal articles in their Swisscovery discovery platform (based on Ex Libris Alma).

They had analyzed the MarcXML format provided by the OJS OAI-PMH and provided a long list of MARC fields that are either missing or are not compliant to their needs.

It looks like the OAI-PHP MarcXML by PKP is a minimal format - anyway, depending on the local implementation of the harvesting system, it should be possible to extend it (or create a copy of the plugin that can be extended).

Hi all,

The MarcXML support in OJS’s OAI-PMH interface is rarely used and thus doesn’t receive a lot of maintenance/improvement; pull requests, improvements, etc. are welcome!

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher

thank you. We will decide internally whether we go the MarcXML route. It’s also possible that the SLSP harvesting pipe will be configured to harvest the Dublin Core metadata format.

See also OAI-PMH issues (multi-journal installation, multi-language) for issues detected with DC.

Actually, adapting and extending a MarcXML plugin for our repository was quite tedious (one has to inspect and follow the extensive LOC documentation for each MARC element). At the end, it was worth it - having now National Libraries of two countries and a national catalog service that harvest the output of this plugin.