Goobi und Karteikarten

Liebe Gemeinde,

wir planen eine Kartei mit ca. 250.000 Karten (Vorder- und Rückseite) mit goobi.workflow zu verarbeiten und im goobi.viewer zu präsentieren. Die Kartei enthält Daten zu Personen in alphabetischer Reihenfolge.

Ich möchte Euch, liebe Gemeinde, fragen, welche Lösung dafür gut wäre. Beim Schreiben dieser Zeilen scheint mir folgendes ein erster Ansatz zu sein:

  • Jede Kartei-Karte ist ein eigener Vorgang und gilt als eigenständiges Dokument. Welcher Dokumenttyp ist dazu geeignet?
  • Jede Karte kennt den Vorgänger und Nachfolger.
  • Jeder Karte gehört zu einer Collection, z.B. mit einer Gliederung nach Buchstaben-Räumen, meinekartei#A, meinekartei#Bi-Bu …
  • Einen übergeifenden Zusammenhang als Kartei z.B. in einer METS-Datei gibt es nicht.

Klingt das plausibel? Habt Ihr andere Erfahrungswerte?

Herzlichen Dank und frohe Ostern

Im Grunde entspricht eine Karteikarte doch dann ehesten einer Postkarte (was das handling angeht)?

Mir fallen folgende Rückfrage ein:

  • solle es eine OCR geben?
  • soll der Inhalt der Karte überhaupt tiefer erschlossen werden?
  • haben die einzelnen Karten jeweils eine Signatur?
  • anstatt jeder Karteikartei einen eigenen Vorgang zu geben, könnte auch jede Karte innerhalb einer bestimmten Collection ein Strukturelement sein, und die Collection als solche bildet den Vorgang?
  • übernimmt Goobi die Aufgabe des primären Kataloges, oder sind die Karten auch im OPAC etc. erfasst?

Beste Grüße und erholsame freie Tage

Die einzelnen Karten werden irgendeine Form von Identifier/Signatur haben und sind auch deshalb einzigartig, weil sie ja ein spezifisches Objekt beschreiben (in diesem Fall Personen).

Eine OCR oder Tiefenerschließung gibt es in unserem Fall nicht, weil die Datensätze bereits in einer Fachanwendung erschossen sind und der goobi.viewer in erster Linie dazu dient die Imagedigitalisate auszuliefern. Dennoch soll eine grob Orientierung im viewer möglich sein.

Eine Karteikarte kennzeichnet vielleicht folgendes:

  • eine Art Titel, z.B. eine bibliographische Angabe, in unserem Fall der Name und Geburtsdatum, für menschen lesbar
  • ein Identifier aus dem Aufbau der Kartei, z.B. die Signatur, die Personen-Registrierungsnummer, o.ä.
  • eine laufende Nummer, kann fingiert sein oder einer vorhandenen Paginierung entsprechen,
  • die Karte davor
  • die Karte danach
  • eine Collection oder ein Anchor-Dokument, dass einer realen (oder fingierten) Gliederung entspricht: die Nummer des Karteikastens, ein alphabetischer und nummerischer Abschnitt.

Das ist eine meiner Fragen an das intranda-Team: bis zu welcher Größe ist denn ein Vorgang, bzw. die handhabung einer METS-Datei möglich oder sinnvoll.

Um diese Grenze erst gar nicht austesten zu wollen, würde ich gleich die Lösung “1 Karte - 1 Vorgang” wählen.

Das ist leider nicht so einfach zu beantworten. Ich kann Dir aber sagen, das zum Beispiel in der Zentral und Landesbibliothek Berlin vereinzelte Werke mit mehr als 7.000 Bildern in einem Vorgang existieren. Soweit ich weiß ist das vom Handling her kein Problem. Hier ein Beispiel:

Ich glaube, dass das Problem eher darin liegen wird wie viele Strukturelemente Ihr pro Vorgang habt. Da sind mir ebenfalls keine Performanceprobleme bekannt, aber irgendwann wird es einfach unübersichtlich. Hier ein Beispielwerk mit einem sehr langen Strukturbaum:

Ich möchte aber darum bitten zu vermeiden eine Struktur aufzubauen, bei der die Datensätze verschachtelt über lose Verbindungen / Metadaten verknüpft werden, die der Goobi viewer dann als Struktur anzeigen soll. Dafür gibt es zwar eine Logik, die scheint aber nicht gut zu skalieren. Wir hatten da in der Vergangenheit bereits öfter Probleme mit. Konkret meine ich diese Option:

<toc>
    <ancestorIdentifierFields listSiblingRecords="true">
        <field>PI_PARENT</field>
    </ancestorIdentifierFields>
</toc>

Sie ist im Kapitel 1.20.1 der Goobi viewer Core Dokumentation weiter beschrieben.

Ich persönlich finde die Kombination aus diesen beiden Vorschlägen von @bbfks gut: