[Kobv-opus-tester] OAI-Set: Volltexte
Jens Schwidder
schwidder at zib.de
Mo Jan 13 15:51:15 CET 2025
Liebe Frau Baade-Kelishani,
On 1/13/25 14:28, Baade-Kelishani, Annegret wrote:
> Lieber Herr Schwidder,
>
> herzlichen Dank für Ihre schnelle und ausführliche Antwort.
>
> XMetaDissPlus war mir schon bekannt, es wird von uns ja für die
> Ablieferung von Dokumenten an die DNB genutzt.
>
> Im konkreten Fall geht es mir darum, dass ich ein Set im Marc21-Format
> erstellen möchte, weil wir unsere OPUS-Aufnahmen, an denen Volltexte
> hängen, gerne auf diesem Weg automatisiert nach Alma exportieren
> möchten. Nach derzeitigem Stand müsste ich mehrere Importprofile
> erstellen, diese dann jeweils mit einem Set verknüpfen und versuchen,
> das Ganze so zu gestalten, dass möglichst genau die Titel getroffen
> werden, die wir übernehmen möchten. Mir würde es hier natürlich sehr
> helfen, wenn ich die Möglichkeit hätte, alle Titel, an denen Volltexte
> hängen, mit einer Abfrage zu erwischen, aber auf längere Sicht und für
> alle Anwenderbibliotheken gedacht, wäre eine flexible Lösung, bei der
> man Sets mit Regeln zusammenbauen könnte (so wie "hat Volltext und
> gehört zur Bibliographie", "hat Volltext und gehört zum Open-Access-
> Set", "ist bestimmter Dokumenttyp und ..."), sicherlich zielführender.
>
> Dabei fällt mir noch eine Verständnisfrage ein: im Moment beziehen sich
> die Sets, die man über OAI ansprechen kann, immer nur auf der untersten
> Ebene, also da, wo die Dokumente anhängen?
>
> Wir haben ein Set "Geförderte OA-Publikationen"
Ist das eine CollectionRole oder eine Collection/Sammlung? Man kann
einen ganzen Sammlungsbaum (CollectionRole) aus OAI ausblenden.
Sammlungen sind nur sichtbar, wenn Dokumente verknüpft sind und ein
Subset-Name gesetzt wurde.
>
> Darunter hängen Subsets, die Dokumente hängen an den Subsets:
>
> Das Set "Geförderte OA-Publikationen", was für den Zweck des
> automatisierten Exports nach Alma ebenfalls hilfreich wäre, kann ich
> unter OAI nicht finden, sondern nur die Subsets DEAL Elsevier ... .
Der Set wird durch die CollectionRole (also den "Sammlungstyp")
bestimmt. Der Subset durch die Sammlung. Das ist unabhängig davon wie
die Baumstruktur Ihrer Sammlungen aussieht. Es nur diese zwei Ebenen bei
den OAI-Sets.
In der aktuelle Version (4.8) kann man das ganz gut beim "open_access"
Set sehen. Die Open-Access CollectionRole definiert den Set
"open_access". Die "open_access" Collection definiert den Subset
"open_access". Wenn Dokumente mit der "open_access" Collection verknüpft
sind, tauchen zwei OAI Sets auf:
open_access
open_access:open_access
[set]:[subset]
[role]:[collection]
Mit der "open_access" Collection verknüpfte Dokumente sollten in beiden
Sets auftauchen. Manche Institute haben eine weitere Sammlung
"closed_access" angelegt.
HINWEIS: Das ist nicht ideal und hat einiges an Entwicklungsaufwand für
die nächste Version verursacht. Es entspricht nicht der ursprünglichen
Idee für die "open_access" Sammlung.
Dort ergeben sich dann aber die folgenden Sets.
open_access
open_access:open_access
open_access:closed_access
Der "open_access" Set sollte in diesem Fall alle Dokumente beinhalten,
die entweder mit der "open_access" Sammlung oder der "closed_access"
Sammlung verknüpft sind.
Das gesagt, entspricht der Set "open_access:open_access" nicht ganz den
Anforderungen. Deshalb wurde für die nächste Version ein Mechanismus
entwickelt, um eine komplette Sammlungsbäume (CollectionRole) als ein
Set abzubilden. Damit werden in Zukunft alle Dokumente, die mit
Sammlungen in der "open_access" CollectionRole verknüpft sind in dem Set
"open_access" ausgeben, egal wie die Sammlungsstruktur aussieht und ob
dort weitere Untersammlungen für das Open-Access-Model (green, usw.)
angelegt wurden. Die Sichtbarkeit einzelner Sammlungen bestimmt, ob
Dokumente in dieser Sammlung dabei berücksichtigt werden. Es gibt dann
also nur noch den Set.
open_access
Das lässt sich auch für andere Sammlungsbäume (CollectionRoles) verwenden.
Ich befürchte die Erklärung oben ist vielleicht etwas undurchsichtig,
aber hoffe, dass sie Ihnen trotzdem weiter hilft.
Das OPUS 4 Handbuch wird für die neuen Konfigurationsmöglichkeiten noch
angepasst werden müssen.
https://www.opus-repository.org/userdoc/admin/collections.html
https://www.opus-repository.org/userdoc/export/oaiexport.html
>
> Soll ich unseren Wunsch noch zusätzlich in GIT erfassen? Dann müsste ich
> mich da registrieren.
Das wäre gut. Sonst muss es jemand anderes machen, vermutlich ich.
Generell wäre es besser, wenn auch Fragen/Anworten auf GitHub stehen
würden, weil sie dann besser nachgenutzt werden können. Die Mailing
Liste existiert noch, weil nicht jeder sich bei GitHub anmelden möchte.
Das kann ich verstehen, aber sie erzeugt zusätzlichen Aufwand und
Antworten erreichen nur einen kleinen Nutzerkreis.
Das Hauptproblem ist, dass OPUS 4 nur einen Vollzeitentwickler hat.
GitHub stellt eine Vielzahl von Tools zur Verfügung, die es halbwegs
möglich machen den Überblick zu behalten und den Overhead zu reduzieren,
damit auch noch Zeit für die eigentliche Programmierarbeit übrig bleibt.
Schöne Grüße
Jens Schwidder
>
> Viele Grüße in die Runde
>
> Annegret Baade-Kelishani
>
> Am 13.01.2025 um 11:09 schrieb Jens Schwidder:
>> Liebe Frau Baade-Kelishani,
>>
>> XMetaDissPlus setzt mit den Dokumenten verknüpfte Dateien voraus und
>> könnte vielleicht für Ihre Zwecke genutzt werden.
>>
>> Einen OAI-Set "fulltext" gibt es nicht. Um ihn in der aktuellen
>> Version umzusetzen, müsste in den Code des OAI-Modules eingegriffen
>> werden. Ohne jetzt im Detail in den Code zu schauen, wären vermutlich
>> Änderungen an mehreren Stellen notwendig.
>>
>> Für die kommenden Version (4.8.1, wird als 4.9 veröffentlicht werden)
>> wurde das OAI-Modul überarbeitet. Dort lässt sich eine neue Klasse für
>> den gewünschten OAI-Set implementieren und über die Konfiguration
>> hinzufügen. Es ist also auch Entwicklung notwendig, aber nur noch für
>> eine isolierte neue Klasse, ohne in den restlichen Code eingreifen zu
>> müssen und damit die existierende Funktionalität zu gefährden.
>>
>> Wenn für Sie ein Set "fulltext" wichtig ist, könnten sie den Wunsch
>> auf GitHub festhalten, am besten hier:
>>
>> https://github.com/orgs/OPUS4/discussions
>>
>> Gibt es noch weitere Anforderungen an den neuen Set? Dinge, die
>> berücksichtigt werden müssen? Es wäre auch gut eine Idee vom
>> Anwendungsfall zu haben, der abgedeckt werden soll.
>>
>> Schöne Grüße und ein frohes, neues Jahr
>>
>> Jens Schwidder
>>
>> PS. Die Umsetzung als neue Set-Klasse (mit 4.9) wäre momentan die
>> einfachste Lösung und würde sich auf das OAI-Modul beschränken.
>>
>> Als Konzept wären aber für die Zukunft auch "Smarte"-Collections
>> denkbar, für die Regeln definiert werden könnten, z.B. "alle Dokumente
>> mit Volltext". Collections werden bereits jetzt als OAI-Sets
>> abgebildet. Das wäre also eine allgemeinere Lösung, außerhalb des OAI-
>> Modules. Der Weg dahin ist aber noch lang und setzt eine Reihe von
>> Zwischenschritten voraus. Trotzdem ist vielleicht eine interessante
>> Idee, die weitere Anwendungsfälle ermöglichen würde.
>>
>> On 1/8/25 19:35, Baade-Kelishani, Annegret wrote:
>>> Liebe Kolleginnen und Kollegen,
>>>
>>> ich hätte gern gewusst, ob es möglich ist, ein OAI-Set zu erhalten,
>>> dass alle OPUS-Aufnahmen enthält, die mit einem Volltext verknüpft sind.
>>>
>>> Vielen Dank und noch nachträglich ein frohes neues Jahr in die Runde
>>>
>>> Annegret Baade-Kelishani
>>>
>>>
>>> --
>>> Kobv-opus-tester mailing list
>>> Kobv-opus-tester at zib.de
>>> https://listserv.zib.de/mailman/listinfo/kobv-opus-tester
>>
>>
>> --
>> Kobv-opus-tester mailing list
>> Kobv-opus-tester at zib.de
>> https://listserv.zib.de/mailman/listinfo/kobv-opus-tester
--
==============================================================
Jens Schwidder
Kooperativer Bibliotheksverbund Berlin-Brandenburg (KOBV)
Zuse Institute Berlin (ZIB)
Takustr. 7, 14195 Berlin
Telefon: +49 (030) 841 85 - 308
E-Mail: schwidder at zib.de
WWW: http://www.kobv.de
==============================================================
Mehr Informationen über die Mailingliste Kobv-opus-tester