Kontext
Der OERSI bietet einen einheitlichen Suchindex für OER für den Hochschul-Bereich. Die Quelldaten werden in JSON auf Grundlage des AMB übertragen und sind über die ElasticSearch abfragbar und nachnutzbar. Die Metadaten sind CC0 und damit frei verfügbar und nachnutzbar.
Wunsch von Verbundbibliotheken zur OERSI-Einbindung in deren Discoverysysteme
- ein erstes Treffen dazu gab es bereits im März 2022
- es folgten drei weitere Treffen 2023-03-23 statt (Treffen, 2023-10-26, Treffen, 2023-03-23, Treffen, 2022-10-13)
- Nächstes Treffen: 2024-06-26 11-Uhr
- die Treffen sind in diesem Pad dokumentiert: https://pad.gwdg.de/s/orca-und-bibliotheken
Anfrage aus dem MKW
Von Seiten des Ministeriums schickte Drees eine Anfrage am 29.06.2023:
im letzten jourFix mit ORCA.nrw kam die Frage auf, ob OERSI zukünftig auch in Alma und/oder den Discovery-Systemen der Hochschulbibliotheken eingebunden wird. Können Sie uns zu entsprechenden Planungen und einer möglichen Zeitschiene bitte eine kurze Rückmeldung geben?
Ich ahne ja, dass es sich bei den Discovery-Systemen wahrscheinlich nur um DigiBib IntrOX als Produkt des hbz handeln kann, was aber nicht alle Hochschulbibliotheken in NRW einsetzen.
Implementierungswege und -fragen
Für die Einbindung gibt es eine Reihe von Möglichkeiten, die in den folgenden Abschnitten erläutert werden.
Individuelle Einbindung in das eigene Discovery-System/den eigenen Discovery-Index
Ist möglich durch die offene API bzw. den OERSI-MARC-Dump.
- Versuch geplant durch Dortmund und auch Paderborn hat Interesse angekündigt. Eventuell mal checken, ob andere das schon machen.
- Stand Juni '24:
- Die Umsetzung wird aktuell mithilfe des neuen Marc-Dumps von Dormund erprobt
Nachnutzung der Daten in der ALMA-Netzwerk-Zone oder in der ALMA-Community-Zone
TO DOs
- Transformation der OERSI-Daten nach MARC => https://gitlab.com/oersi/oersi-marc
- Veröffentlichung der OERSI Datenals MARC und JSON Dump => https://oersi.org/resources/dumps/oer_data.mrc.xml
- Begutachtung der MARC-Daten durch Community
- Begutachtung der MARC-Daten durch Verbundgruppe/E-Book-Gruppe
- ggf. Nachbesserung der Transformation
- Feld 001 zu einer persistenten id machen und link auf OERSI ergänzen, in fix mit dem neuen `to_base64`
- Einspielroutine auf Basis des wöchentlich aktualisierten OERSI-MARC-Dumps unter https://oersi.org/resources/dumps/oer_data.mrc.xml
- Klären und Umsetzung desAufsetzen und der zukünftige Verwaltung der OERSI-Kollektion
- Mail von B.B.:
- "wir befinden uns jetzt zwar in NZ Phase 2, allerdings sind wir bezüglich neuer Themen im Allgemeinen und neuer Kollektionen für die NZ derzeit nicht handlungsfähig, da wir zunächst für alle bestehenden Lieferanten die Umstellung auf den Import nach Alma vollziehen müssen.
Leider können wir hier auch noch keine Zeitschiene nennen.
Theoretisch wäre es denkbar, dass ihr die Daten in die CZ einbringt, was - jeweils nach Rücksprache mit Ex Libris - generell möglich ist.
Wie das konkret geht und ob das der beste Weg ist, können wir derzeit nicht einschätzen und haben leider derzeit keine Kapazitäten, uns damit zu beschäftigen oder euch irgendwie zu unterstützen. Hier ein Link für eine erste Info: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/Electronic_Resource_Management/030_Working_with_Local_Electronic_Resources/030Contributing_to_the_Community_Zone_%E2%80%93_Local_Electronic_Collections" - Stand Juli '24:
- Anpassung der OERSI-Marc Transformation für 001 zu einem base64 hash:
- Die Daten im Test bei Silke Tölle
- Email-Austausch zur Qualität mit Verbundgruppe/E-Book-Team:
- Rückmeldung von Silke Tölle nach Analyse (Email 17.07.24 // Betreff: Re: Antw: OERSI als NZ-Kollektion? - ID / Kennzeichen / MARC-Feld für Provider / Umfang ):
- 001: Unsicher ob ID wirklich persistent ist, wenn base 64 id: "Da sind wir nicht sicher, ob sie wirklich permanent ist. Wir vermuten nein, denn wir sehen, dass sie das Ergebnis von base64# ist und vermuten weiter, dass da Datensätze bei jeder Lieferung/Änderung das Verfahren durchlaufen und dann wieder ein neues Ergebnis erzeugt wird. Aber vielleicht ist das ja anders, dann gäbe es da technisch kein Problem, auch wenn sie wirklich unhandlich ist und es gibt eine Verwaltung der IDs und die ID wird nicht noch einmal oder gleich vergeben. "
- Antwort Petra Maier : Häßliche, aber stabile Id. Basiert nur auf base64 hash der Resourcen URL. Die nicht zweimal vergeben wird. Neue URL führt zu neuer Ressource und die alte wird gelöscht.
- 100: Intertierte Reihenfolge der Namen (Kein Deal-Breaker)
- Antwort Petra Maier :Wildwuchs von Datengebern, leider trade-off bei der Vereinheitlichung.
- 264: Reihenfolge der Unterfelder c und b vertauscht?
- 520: wird bisher nicht standardmäßig übernommen, vielleicht aber notwendig.
- Antwort Petra Maier : Feld sollte übernommen werden.
- "Mal abgesehen von der ID-Frage sieht das also gut aus. "
- 001: Unsicher ob ID wirklich persistent ist, wenn base 64 id: "Da sind wir nicht sicher, ob sie wirklich permanent ist. Wir vermuten nein, denn wir sehen, dass sie das Ergebnis von base64# ist und vermuten weiter, dass da Datensätze bei jeder Lieferung/Änderung das Verfahren durchlaufen und dann wieder ein neues Ergebnis erzeugt wird. Aber vielleicht ist das ja anders, dann gäbe es da technisch kein Problem, auch wenn sie wirklich unhandlich ist und es gibt eine Verwaltung der IDs und die ID wird nicht noch einmal oder gleich vergeben. "
- Weitere Rückmeldung Silke Tölle (25.7.24):
- 100/ID: Hash über URL - > wir befürchten, dass sich die URL durchaus ändern kann. Dann hätten wir tatsächlich wieder das Problem der nicht konstanten ID. Wenn das so ist und eine stabile ID wg. des Verfahrens nicht möglich ist, könntet Ihr dann eine Konkordanz alte ID -> neue ID liefern?
- Antwort Tobias Bülte (2.9.24): Die URL/ID sind stabil. Seltene Ausnahme: Bei URL Änderungen durch Datengeben bekommt eine Ressource eine neue ID und für den OERSI wird diese dann wie eine neue Ressource behandelt. Würden daher Löschlisten bereitstellen
- Silke Tölle ( 5.9.24): "Persistente IDs gehören absolut zu unseren Minimalanforderungen, z.B. auch, da nicht 100% persistente IDs problematisch wg. der Löschungen in Alma sind."
- Frage von Tobias Bülte Was heißt persistent, reicht eine Löschliste und die Sicherheit, dass eine ID nur einmal vergeben wird?
- 520: Für noch Aleph-Bibs ist das Feld 520 teilweise zu lang: max 2000 Zeichen. Können wir schreddern.
- Antwort Tobias Bülte (2.9.24): Würden vorschlagen, keinen Sonderweg für Aleph-Bibs zu machen
- Silke Tölle ( 5.9.24): Gegenvorschlag: 520 bis zur migration erstmal ausklammern. Wechselwirkungen ALEPH ↔ ALMA noch unklar, daher erst nach der Abschaltung von ALEPH 520 einspielen.
- 100/ID: Hash über URL - > wir befürchten, dass sich die URL durchaus ändern kann. Dann hätten wir tatsächlich wieder das Problem der nicht konstanten ID. Wenn das so ist und eine stabile ID wg. des Verfahrens nicht möglich ist, könntet Ihr dann eine Konkordanz alte ID -> neue ID liefern?
- Rückmeldung von Silke Tölle nach Analyse (Email 17.07.24 // Betreff: Re: Antw: OERSI als NZ-Kollektion? - ID / Kennzeichen / MARC-Feld für Provider / Umfang ):
- Stand Sept '24:
- Aktuell gibt es noch Klärungsbedarf bei der ID, siehe Austausch mit Silke Tölle im Punkt Email-Austausch zur Qualität mit Verbundgruppe/E-Book-Team
- Termin zum gemeinsamen Austausch von Verbund und Metadateninfrastruktur ist für Anfang Oktober geplant, wenn Elona Weiper wieder da ist.
Treffen
hbz-internes Treffen am 2024-10-10
Anwesend: Adrian, Petra, Tobias, Benedikt, Ramona, Silke, Elona
Punkte des MI-Teams zur Vorbereitung:
- Bibliotheken warten auf Anbindung, UB Paderborn und Hochschule Bonn-Rhein-Sieg hatten im September bereits nachgehakt.
- MARC-Daten sind von verschiedenen Bibliotheken qualitätsgeprüft: TU Dortmund, UBPaderborn. finc & BASE haben die Daten auch geprüft, bei finc sind sind sie bereits eingespielt.
- Umsetzung der Alma-NZ-Integration sollte bis spätestens Ende des Jahres erledigt sein.
- Updates: Wie setzen wir die Update-Routinen um? Welche Frequenz ist sinnvoll? Was muss MI vorbereiten?
Problem Löschungen
- Hängen sich Bibliotheken an die Titel eines Pakets dran oder an das Paket? – Eher an das Paket.
- Problematik: Web-Ressourcen in OERSI verhalten sich anders als Titel in E-Book-Paketen
- Sobald Bibliotheken anfangen, sich an OERSI-Untermengen zu hängen, könnten Probleme entstehen.
- Es lässt sich nicht technisch verhindern, dass Bibliotheken sich an einzelne Titel ansigeln.
- Optionen:
- Bibliotheken spielen selbst in die IZ ein
- Verabredung, dass Bibs sich nicht mit Einzelbeständen anhängen. Monitoring, ob sich doch Bibs einzeln anhängen (evtl. via lobid) und schnelle Meldung an Bib bei Bruch der Verabredung.
To Do
- Nächstes Treffen mit Bibliotheken terminieren, um sich gemeinsam für beste Option zu entscheiden.
hbz-internes Treffen am 2023-10-20
Anwesend: Adrian, Elma, Jens, Tobias, Uwe
- Elmar: idealerweise OERSI als Kollektion in NZ, so dass Bibliotheken es für sich als Portfolio ergänzen können
- Adrian: manche Nutzer:innen wollen nur Untermenge der OERSI-Daten
- Frage: Müssen wir mehrere KOllektionen anbieten oder läst sich eine Alma-Kollektion leicht filtern auf die gewünschten Ressourcen?
- Elmar: Es gibt auch Interesse, Daten in finc, EBSCO und Introx zu bekommen. Alma-Kollektion würde alle drei Anwendungsfälle erleichtern.
- Thomasi publiziert bereits eigene Daten nach finc. Sobald sie OERSI-Kollektion drin haben, wäre das also abgedeckt.
- Uwe: Direkt in der CZ wäre es noch besser, dann können es auch direkt Bibs außerhalb NRWs benutzen.
- Tobias: einfacherer Weg, um erstmal NRW-Bibliotheken zufriedenzustellen wäre ein NZ-Kollektion. Evtl. ließe die sich auch dann in die CZ übertragen.
- Tobias: CZ sei auch attraktiv, weil dann Primo-Kunden, die kein Alma haben, die Daten einbinden könnten
- MI/TIB möchen größtmögliche Sichtbarkeit (=CZ-Integration), Drees' Anforderung lässt sich aber warhscheinlich am schnellsten über NZ umsetzen
- Uwe formuliert für Donnerstag: "Wir haben das große Interesse an den OERSI-Daten verstanden und haben mit der Prüfung begonnen, wie wir die Bereitstellung am besten umsetzen können." (oder etwas in der Art, solange man da - vorläufig - keine verbindliche Zusage herauslesen kann ...)
- Tobias: Paderborn wollte Ansage haben, ob wir das zumindest in 2024 umsetzen werden.
Nachgespräch Adrian & Tobias:
- Ein Fortschritt lässt sich am Donnerstag mitteilen: Wir werden bald mit der Transformation der OERSI-Daten nach MARC21 beginnen. Der kann als Dump zum Import in Kataloge/Discovery genutzt werden und perspektivisch in Alma ergänzt werden.
Nachnutzung der Daten im Finc-Discovery-Index 
- Kontakt mit Finc:
- "O., inzwischen habt ihr glaube ich wieder Zugriff auf das finc-Projektmanagementsystem. Magst Du evtl. erstmal einfach ein Ticket zum Quellenwunsch anlegen, dann würde sich das R. gerne ansehen. Danke!
Mir scheint die Möglichkeit des Bulk Downloads am ehesten für den Abruf für finc passend: https://oersi.org/resources/pages/en/docs/api/data/
Sehr gern holen wir aber auch regelmäßig bereitgestellte Dumps ab, egal in welchem Format … " - Stand Juni '24:
- Es gab die Info, dass die SLUB Dresden bereits OERSI-Daten verarbeitet, habe den Kollegen angeschrieben, aber nichts zurückgehört
- Nochmal nachgefragt bei den Kollegen aus Leipzig. → Sie werden den wöchentlichen Dump in Finc übernehmen. Die Testung erfolgt aktuell.
- Einbindung in den Finc ist erfolgt. Hier einsehbar bei der TU Freiberg an https://katalog.ub.tu-freiberg.de/Search/Results?lookfor=source_id%3A227
- Mail. O.W. 27.06.23:
- "
OERSI ist als Quelle im finc-Index drin und kann von den Institutionen ausgewählt werden. Da wir Haupttreiber waren, wurden wir per default mit der Quelle ausgestattet. Wenn du jetzt sagst, in NRW kennst du Hinz und Kunz, die die Quelle in ihrem finc wollen, dann schreib sie an, dass sie sich die Quelle aktivieren. (Die sollten aber auch die News aus dem finc Team erhalten haben)."
- "
Nachnutzung der Daten in anderen großen Discovery Indexen
- Hier wäre die Frage, wie wir z.B. in Ebsco reinkommen. Und andere.
Nachnutzung in Introx
Generell wollen wir es in IntrOX ermöglichen, die Oersi-Daten mit durchsuchbar zu machen. Ob die einzelnen Bibliotheken das Angebot annehmen ist ein anderes Thema
Da das Datenmodel von OERSI sich vom "normalen" bibliothekarischen Datenmodel unterscheidet, muss auf Seiten von lobid und auf Seiten der Gruppe Portale noch ein bisschen Arbeit investiert werden (Thema Mapping)
Eine Anbindung von OERSI ist natürlich nicht nur IntrOX-Bibliotheken vorbehalten, sondern auch anderen Bibliotheken mit anderen Discovery-Systemen. Die OERSI-Daten sind - das ist jedenfalls mein Kenntnisstand - ja open data.
Denkbar ist ja auch, dass die OERSI-Daten z.B. in den Verbund geladen werden, auch wenn ich vermute, dass da nicht alle Beteiligten glücklich darüber wären oder "mitspielen" würden
Da Adrian und Tobias nicht da sind, kann ich im Moment leider nicht sagen, ob die OERSI-Daten schon soweit wären, dass wir zeitnah (für die Gruppe Portale heisst zeitnah: nach Abschluss des GOAL-Projektes) mit den Arbeiten beginnen könnten.
Einbindung in BASE
- Stand Juni '24: Testet die Einbindung auf Grundlage der wöchentlichen Dumps
- Die Transformation erfolgt auf Basis des JSON Dumps. Die Daten werden nach Dublin Core transformiert.
Weitere Überlegungen
- Wollen wir paketweise nach Fächern oder nur Komplette Bereitstellung?
- Aus Paderborn kam die Anfrage, dass die verschiedenen Quellen als Kollektionen in den MARC-Daten erfasst werden, wie kann das am besten geschehen: Feld 830, 962, oder anderes?
- Bedarf es einer Aufbereitung der Metadaten?
- Andere Ideen noch, die Kollegen von BASE frage, wie Sie in Indexe reingekommen sind.
- Termin erfolgte am 23.04.24 mit V.P.
- Einbindung von BASE erfolgt aufgrund von Größe als Player und durch Kontakt von außen.
- Base beabsichtigt die Indexierung vom OERSI, s.o.
- Desweiteren stellt sich die Frage, ob die Erreichbarkeit durch Bereitstellung einer OAI-PMH-Schnittstelle verbessert. Dafür wären aber Dinge, wie ein Mapping von AMB auf DublinCore notwending und anderes.