Barcode scannen mit Alma

Georg · 21. Januar 2019 um 13:22

Liebe Kolleginnen und Kollegen,

Hat wer mit Alma als Bibliothekssystem in Goobi Barcode Scannen zum Suchen im OPAC beim Anlegen von Vorgängen konfiguriert?

Mir kommt das nicht so trivial vor: Per SRU ist der Barcode ja nur in der Suche über alle Felder verfügbar (Parameter alma.all_for_ui), da besteht ein (wenn auch bei uns zumindest praktisch vernachlässigbares) Risiko, dass es zu Mehrdeutigkeiten kommt. Was allerding auch dazu kommt, ist, dass in der SRU-Antwort der Barcode selbst nicht enthalten ist und somit eine Zuordnung der gesuchten Item-Daten nicht möglich ist.

Wenn man den Barcode zuverlässig abfragen wollte, müsste man wohl zuerst per API den Barcode abfragen, in der Antwort bekommt man dann die Datensatz-ID für den Bib-Datensatz, den man dann per SRU abrufen kann.

Wie seht ihr das?

ristauut · 21. Januar 2019 um 15:43

Lieber Herr Mayr-Duffner,

wir haben uns aus den folgenden Gründen entschieden, die Alma-Daten nicht über den Barcode per SRU abzuholen.

a) An den Titelaufnahmen für Online-Ressourcen, die wir für die Digitalisate in Alma haben, hängen keine Exemplare mit Barcode sondern Portfolios.
b) Wir hatten auch überlegt, die Daten der Druck-Ausgaben aus Alma zu nutzen. Allerdings vor allem für Zeitschriftenexemplare. Da bräuchten wir Daten aus dem Alma-Exemplarsatz. Haben dann aber festgestellt, dass SRU nur die Daten aus den Holdings transportiert und nicht aus Exemplaren.
c) Also sind wir im monografischen Bereich dabei geblieben (wie früher aus Aleph), die Daten via BIB-ID der Online-Ausgabe zu holen. Alle für uns in Goobi relevanten Daten sind in der Titelaufnahme für die Online-Ausgabe vorhanden (so wie früher auch).
d) Bei den Zeitschriften müssen wir aber anders verfahren, als früher. Früher hatten wir in Aleph auch an Zeitschriften-Online-Ressourcen Exemplarsätze, die wir via Barcode abgeholt haben. Das ist nun nicht mehr möglich. Wir holen nun die Grunddaten auch über die BIB-ID der Online-Ausgabe und legen damit einen Vorgang in Goobi an, der als Vorlage dient. Die eigentlichen Vorgänge werden dann mittels dieser Vorlage angelegt und erhalten eine von Goobi verteilte ID. Als Anker dient weiterhin eine BIB-ID aus dem Katalog, damit sich Aleph- und Alma-Daten in Goobi zusammenfinden.

Viele Grüße

Ute Ristau (HU Berlin)

Georg · 30. Januar 2019 um 15:08

Liebe Frau Ristau,

danke für die Antwort. Das sind ein paar sehr interessante Informationen. Legt ihr also für Monographiedigitalisate einen e-Datensatz mit Portfolio an?

Für Zeitschriften-Exemplare müsste man wohl wirklich über die API gehen, was die Sache deutlich komplexer machen würde.

Zumindest für den aktuellen Fall werden wir der Einfachkeit halber die unscharfe Methode Barcode über SRU suchen anwenden. Unsere Barcodes sind prinzipiell so gestaltet, dass eine Verwechslung unwahrscheinlich ist. Die Exemplarinformationen, die dann noch fehlen, müssen händisch nachgetragen werden.

Schöne Grüße
Georg

ristauut · 30. Januar 2019 um 16:49

Lieber Herr Mayr-Duffner,

wir haben für E-Ressourcen immer eigene Titelaufnahmen, egal, ob frei verfügbar oder nicht und auch egal, ob Digitalisate oder nicht sowie, ob monografische oder ZDB-Materialien. Wir hatten das schon in Aleph so und jetzt auch in Alma. Alma trennt ja ohnehin das physische und das elektronische Inventar von Haus aus fein säuberlich.

Für monografische Materialien holen wir die Daten via BIB-ID des Titelsatzes für die Online-Ressource ab. Alle Angaben, die wir für das physische Exemplar in Goobi haben wollen, sind in dem MARC21-Beziehungsfeld 776. Hier ein Beispiel

Auf der Goobi-Seite ist sichergestellt, dass aus dem Unterfeld n nur die eigentliche Signatur in das passende Goobi-Feld übernommen wird.

Für ZDB-Materialien wird ebenfalls das MARC21-Beziehungsfeld 776 genutzt. Da steht dann allerdings nur so viel drin, wie die ZDB erlaubt, z.B. nicht die Signatur. Hier ein Beispiel

776 08 |i Elektronische Reproduktion von |t Sociologus |d Berlin |e Duncker & Humblot |f 1932- |x 0038-0377 |w BV002535726

Es fehlt die Angabe der Signatur. Diese schreiben wir in das Portfolio in die öffentliche Notiz. Diese wird im AVE-Feld über SRU mitgeliefert. Hier ein Beispiel:

<datafield tag="AVE" ind1=" " ind2=" ">
<subfield code="8">53627205920002882</subfield>
<subfield code="c">61639769230002882</subfield>
<subfield code="e">verfügbar</subfield>
<subfield code="l">OR010</subfield>
<subfield code="m">HU Digitalisate</subfield>
<subfield code="n"> 2006 - Im Digitalisierungsprozess - Nach einem Exemplar der Humboldt-Universität zu Berlin, Universitätsbibliothek mit der Signatur: LA 6467
</subfield>
<subfield code="s">Verfügbar von 2006.</subfield>
</datafield>

Auf der Goobi-Seite ist sichergestellt, dass aus dem Unterfeld n nur die eigentliche Signatur in das passende Goobi-Feld übernommen wird.

Die bibliografischen Daten sind somit abgedeckt. Für den Goobi-Vorgang fehlen uns für die folgenden Goobi-Felder die Daten (Aus Aleph hatten wir sie, da wir dort auch unter Online-Ressourcen Exemplare angelegt haben. Diese konnten dann via Strichcode abgeholt werden):

Titel (Band) = Sociologus, 2006/07 [das, was hinter dem Komma steht]
Titel (Band) (Sortierung) = Sociologus, 2006/07 [das, was hinter dem Komma steht]
Bandnummer = 2006/07
Nummer (Sortierung) = 2006200701
Erscheinungsjahr (Anzeige) = 2007

Mit den bibliografischen Daten und den fehlenden Band-/Exemplardaten legen wir in Goobi eine Vorlage an, die dann für alle Vorgänge nachgenutzt wird.

Allerdings funktioniert das Ganze nur für RDA-Aufnahmen. Das ist für Monografien kein Problem. Da können wir die Aufnahmen im B3Kat umarbeiten. Mit der ZDB gibt es da Probleme. Da darf nicht umgearbeitet werden. Hier haben wir mit Intranda eine Lösung vorbereitet, die eine entsprechende Codierung im Titelsatz auswertet.

Wenn ich Sie richtig verstehe, haben Sie gar keine separaten Aufnahmen für die Online-Ressourcen. Ist das korrekt?

Warum suchen Sie eigentlich nach dem Barcode und nicht nach der BIB-ID? Der Barcode wird über SRU doch ohnehin nicht ausgegeben.

Wir suchen nach der B3Kat-BIB-ID im MARC21-Feld 035. Das sieht dann z.B. so aus

https://hu-berlin.alma.exlibrisgroup.com/view/sru/49KOBV_HUB?version=1.2&operation=searchRetrieve&recordschema=marcxml&query=alma.other_system_number=BV043551281

Viele Grüße

Ute Ristau

Georg · 11. Februar 2019 um 08:29

Liebe Frau Ristau,

vielen Dank für die ausführliche Antwort.

Meine Frage nach den E-Datensätzen mit Portfolios zielte eigentlich in eine andere Richtung: Alma kennt ja auch D-Datensätze für Digitalisate (ich weiß allerdings nicht, wie die funktionieren). Es hätte also auch sein können, dass Sie solche verwenden. Bei uns stellte sich die Thematik noch nicht, da die bisherigen Bestände nur zum Teil in Alma nachgewiesen sind, aber gar nicht gepublisht werden. Daher hat sich bei der Digitalisierung auch niemand überlegt, die Digitalisate in Alma nachzuweisen, da der vollständige Bestand ohnehin nur in Goobi abgebildet wird.

Vielen Dank für die Details zur Datenübernahme, das ist wertvolle Information.

Zur Suche nach dem Barcode: an und für sich suchen auch wir nach der AC-Nummer (unser Äquivalent zur B3Kat-BIB-ID; sie steht bei uns in 009, einem lokalen (nicht wiederholbaren) Kontrollfeld für eine System-Nummer, das von Alma dementsprechend unterstützt wird; in 035 wird sie dann mit ISIL-Präfix wiederholt). Jetzt haben wir aber ein Projekt, wo der Workflow durch Einscannen des Barcodes erleichtert wird. Den Barcode selbst werden wir in den Metadaten nicht benötigen sondern die Signatur und die kommt beim AVA-Feld ja mit. Nachdem es sich um original digitale Beilagen zu gedruckten Werken handelt, wird es dafür auch keine gesonderte E-Aufnahmen geben.

Schöne Grüße
Georg Mayr-Duffner

ristauut · 11. Februar 2019 um 15:57

Lieber Herr Mayr-Duffner,

wir haben uns bis jetzt nicht mit den D-Datensätzen auseinandergesetzt. Solange man nicht via Alma digitalisieren und dort Bilddateien verwalten will, braucht man keine D-Datensätze. Deshalb sind für uns Titelaufnahmen für Digitalisate ganz normale E-Datensätze.

Wir hatten vor der Alma-Einführung einen längeren Disput mit Ex Libris, da wir gesagt haben, die Verbund-ID muss in einem eigenen separaten Feld stehen. Es führte kein Weg rein und so haben wir jetzt die ID in 035 zweimal, einmal mit und einmal ohne ISIL. In der Zwischenzeit habe ich sie, aus anderen Gründen, noch zusätzlich in ein lokales MARC-Titelfeld gesetzt. Das könnte man jetzt natürlich auch für Goobi verwenden. Das überlege ich noch.

Falls Sie zu einer Lösung kommen würden, die es erlaubt, auch Exemplardaten via API oder sonstwie zu übernehmen, wäre ich an der Lösung sehr interessiert.

Viele Grüße

Ute Ristau

Georg · 12. Februar 2019 um 20:11

Liebe Frau Ristau,

Ich hab es nicht in Aktion gesehen, aber angeblich soll genau das möglich sein. Die Prozesse würden über Workorders abgewickelt und es gibt die Möglichkeit, Metadaten für Digitalisate auch in DC abzuspeichern. Für den Datenspeicher hat ExLibris einen Vertrag mit Amazon 3S, dessen Nutzung lässt sich ExL extra kosten. Das hat bei uns in Österreich aber auch noch niemand und für uns an der WU Wien kam das gar nicht erst in Frage, da für die persönlichen Dokumente aus den Nachlässen das Vertrauenslevel genüber Amazon nicht hoch genug erscheint.

Diese Diskussion gab es bei uns auch, bei uns war aber eine Lösung mit 035 unmöglich, weil ja auch das Verbundsystem in Alma ist und daher ein Zähler in dem Feld realisiert werden musste. Deshalb hat ExL dann die Lösung mit 009, die im Verbund soweit funktioniert.

Lassen Sie mich raten – damit Sie die ID auch aus Analytics herausbekommen?

Gerne.

Schöne Grüße
Georg Mayr-Duffner

ristauut · 13. Februar 2019 um 11:51

Lieber Herr Mayr-Duffner,

wir haben die selben Gründe wie Sie, weshalb wir die Alma-Digitalisierungskomponente nicht nutzen.

Ja, wir haben die ID für Analytics in ein separates Feld geschrieben (und auch noch andere Dinge).

Viele Grüße

Ute Ristau