Über das Projekt

Projektvorhaben

Im Rahmen meines studentischen Editionsprojektes will der Postkartenbestand – angefangen bei den beschrifteten – nach und nach erschlossen und in einer digitalen Edition erfasst werden. Das Projekt ist in vielerlei Hinsicht von experimenteller Natur, da erprobt werden wollte, inwiefern es auch ohne grosse Vorkenntnisse und ohne Budget möglich ist, eine vielseitig nutzbare digitale Edition zu erstellen. Um die Edition gerade angesichts des verhältnismässig kleinen Bestandes möglichst breit nutzbar zu machen, wurde beschlossen, nicht nur für die Postkarten, sondern auch für Korrespondent*innen und Produzenten1  Objekteinträge vorzunehmen. Für die Katalogisierung und digitale Präsentation der Postkarten wollte versucht werden, ein Grundmodell zu entwickeln. Von Beginn an war klar, dass die Transkription der Korrespondenzen und Adressangaben (bei beschrifteten Karten) sicherlich Teil dieses Grundmodells sein sollte. Dies im Gegensatz zu vielen Digitalisierungsprojekten, bei welchen die Adressseite beschrifteter Postkarten - ev.  aufgrund fehlender Kapazitäten oder auch aus Datenschutzgründen - nicht transkribiert oder gar nicht erst digitalisiert wurde. Während ziemlich bald klar war, dass sowohl für Postkarten, als auch für Korrespondent*innen und Produzenten (Firmen wie Personen) entsprechende Datensätze resp. "Objekte" angelegt werden wollten, erwies sich die Auswahl der Eigenschaften dieser "Objekte" bzw. die Entwicklung des Metadatenschemas/Grundmodells und insbesondere die Frage, auf Basis welcher Standards und Ontologien dieses realisiert werden wollte, als enorm zeitaufwändig und herausfordernd. Damit verbunden war auch die Frage, mit welcher Anwendung die Präsentation schlussendlich umgesetzt werden wollte und inwiefern dieser die Daten in einem gewissen Format übergeben werden müssten. Anfangs wurden die Metadaten der Postkarten, Personen und Organisationen deshalb noch eher unstrukturiert und provisorisch in einer Access-Datenbank erfasst, um überhaupt ein Bild, einen Überblick davon zu bekommen, welche Eigenschaften alle potenziell aus den - und über die - verschiedenen Karten gewonnen werden konnten. Dies half dann - in Kombination mit Recherchen zur Umsetzung/Präsentation bestehender Projekte - auch bei der Entscheidung, welche Eigenschaften und Standards Teil meines Grundmodells sein sollten. Nachdem die Grundmodelle endlich mehrheitlich festgelegt waren und klar war, dass das Projekt mithilfe des CMS (Content Management Systems) Omeka umgesetzt werden wollte, wurde die Access-Datenbank nicht mehr weiter aktualisiert. Stattdessen wurden die Postkarten, Personen und Organisationen direkt in Omeka als "Objekte" erfasst. Ein zentrales Anliegen war dabei auch der Ansatz von Linked Open Data, da die aus den Quellen gewonnen Daten mit Normdateien oder digitalen Sammlungen verknüpft und ergänzt werden wollten. Auf die festgelegten Standards zur Beschreibung der Entitäten, sowie auf im Arbeitsprozess daran vorgenommene Änderungen und Problemstellungen wird auf den Seiten zur Katalogisierung näher eingegangen. Aus Kapazitätsgründen wurde das Grundmodell für die Katalogisierung erst auf einen Bruchteil der Postkarten, Personen und Körperschaften angewendet. Die Bestandserschliessung möchte jedoch laufend fortgeführt werden, wobei erneute Änderungen bei der Katalogisierung und Darstellung nicht ausgeschlossen werden können. 

Fotografische Aufnahme 

Nach einer ersten Organisation des Bestandes wurde vom ersten zu bearbeitenden Teil der Postkarten je eine Fotografie der Vorder- und Rückseite gemacht. Jede Datei wurde mit der Signatur sowie einer Seitenangabe (recto/verso) abgespeichert (Signatur ohne Q., z.B. 01.001recto). Da die Fotografien nur mit einem Smartphone (Google Pixel 4a) gemacht wurden, ist die Qualität und Auflösung der Fotos teilweise leider etwas mangelhaft, doch es stand leider keine bessere Kamera zur Verfügung. Die ersten Fotografien wurden zudem mit der App «PhotoScan» gemacht, da dieses die Fotografie automatisch auf die Ränder der Postkarte zuschneidet und die automatische Anpassung später noch manuell korrigiert werden kann. Für eine bessere automatische Erkennung der Postkartenränder wurde bei manchen Postkarten eine blaue Unterlage verwendet, die gerade bei fehlenden Ecken oder gelochten Postkarten etwas störend sichtbar ist (vgl. z.B. bei Q.01.003). In Zukunft würde jedoch eher das App «DocScan» verwendet werden, mit dem die Fotografie automatisch im Transkribus-Account gespeichert werden könnte. «DocScan» bietet zudem eine ähnliche automatische «Zuschneidefunktion» wie «PhotoScan» an, auch wenn die automatische Anpassung bei ersten Versuchen nicht gleich akkurat ausfiel. 
Die Fotodateien wurden dann später bei jedem Postkartenobjekteintrag als Medien im jpg/jpeg-Dateiformat hinzugefügt. Die meisten Bilder besitzen zwar eine Bildgrösse von über 2 Megapixel und mind. 3000 Pixel in der Höhe/Weite, erfüllen mit einer Auflösung/Punktedichte von 72 dpi (Dots per Inch/Bildpunkte pro Zoll) und einer Bittiefe von 24 (bzw. als sRGB-Bilder mit 8 Bit pro Kanal) die üblichen Bedingungen für digitalisierte Ressourcen nicht.2  Die Qualität der Bilder möchte in Zukunft durch Optimierungen resp. vergrössertem Know-How beim Fotografieren sowie allfälliger Nachbearbeitungen mit Bearbeitungsprogrammen noch etwas verbessert werden bzw. zumindest versucht werden. Beim ersten Aufbau der Edition hatte dies jedoch schlicht nicht oberste Priorität, zu grossen Teilen schlicht aus praktischen Gründen, weshalb die Bilder vorerst unbearbeitet hochgeladen wurden.     

Transkription, erste Bearbeitung der Quellen 

Im Zentrum der Quellenbearbeitung stand zunächst die Transkription der beschriebenen Postkarten. Vor Beginn der Transkriptionsarbeit wurde bereits eine erste Version der Transkriptionsrichtlinien formuliert, welche jedoch beim späteren Transkriptionsprozess der verschiedenen Postkarten leider noch mehrmals angepasst werden musste, da nicht alle Aspekte bzw. mögliche Probleme mitgedacht wurden und es deshalb in einigen Fällen noch zur Änderung von Teilen der Transkriptionsregeln kam. Für die Transkription wurde mit Transkribus gearbeitet, jedoch aus mehreren Gründen nicht so konsequent wie anfangs geplant. So sind die Postkarten vom Layout her keine «idealen» Ressourcen für Transkribus, da die automatische Erkennung von Textregionen und Zeilen aufgrund der unregelmässigen, nicht liniengetreuen, nicht horizontalen Verteilung der Textelemente sowie übereinanderliegenden Textelementen (z.B. Mitteilungstext über Vorgedrucktem, Poststempel über Mitteilungstexten) nur mässig erfolgreich funktioniert. Natürlich können Textfelder und Zeilen immer abgeändert oder manuell eingetragen werden. Dies ist jedoch oft mit einem Mehraufwand verbunden, der gerade bei relativ kurzen oder leicht zu transkribierenden Textstellen nicht verhältnismässig ist – zumindest solange es «nur» um die Transkription geht und die akkurate Wiedergabe der Struktur resp. die Verortung einer transkribierten Zeile/eines Wortes innerhalb des digitalen Bildes nicht im Vordergrund steht. Ebenso konnte die von Transkribus angebotene Texterkennung mithilfe Künstlicher Intelligenz zwar auch für die Postkarten genutzt werden, jedoch konnte – anders als bei nur von einer Person geschriebenen Textquellen – nicht ein einziges, passendes HTR-Modell gewählt (oder gar selbst trainiert) werden, auf welches man sich bei der Transkription der restlichen Seiten verlassen konnte, da die Postkarten von unterschiedlichen Händen beschrieben wurden und die Menge der zu transkribierenden Texte verhältnismässig klein ist. Ein weiterer Punkt war das Kennzeichnen der textinhärenten Daten (Personen, Orte, Datierung, Abkürzungen, etc.) mithilfe von Tags. Dies wird mit Transkribus zwar ermöglicht und wurde anfangs auch entsprechend benutzt, ebenso wie der XML- und TEI-Export dieser Tags, wobei sowohl Tagging wie Export nicht ganz meinen Vorstellungen und Bedürfnissen entsprachen. Für spezifisch auf Korrespondenzen ausgerichtetes TEI-Tagging (wie dies zunächst in meinem Sinne war) müssten zuerst die entsprechenden Tags hinzugefügt werden sowie ein eigenes Stylesheet (für den TEI-Export) erstellt werden – und an das Transkribus-Team gesendet werden, damit dieses auch als Exportmöglichkeit verwendet werden könnte. Sobald klar war, dass die Umsetzung der Edition definitiv mit Omeka S durchgeführt werden würde und dass die zentralsten Informationen des handschriftlichen Textes (Absender*in, Verfasser*in, Datum, usw.) auch in separaten Metadatenfeldern eines Postkartenobjektes aufgenommen werden sollten, wurde Transkribus und insbesondere dessen Tagging nicht mehr konsequent genutzt. Stattdessen wurden die Transkriptionen vorerst schlicht ohne jegliches Tagging im Word Microsoft Office vorgenommen. Das vernachlässigte Tagging gründet u.a. darin, dass zunächst davon ausgegangen wurde, dass die Transkription als Teil eines Omeka-Objektes nur als "reiner Text" und nicht als HTML oder XML hochgeladen werden könnte. Da dies aber mithilfe des Moduls Data Type RDF dennoch möglich ist, war die Abwendung von Transkribus möglicherweise doch etwas vorschnell, da schlicht die angebotenen, "simplen Tags" genutzt und als XML hätten exportiert werden können. 

Technische Umsetzung

Web-Publishing mit Omeka S

Für die technische Umsetzung resp. die Präsentation der Datenbank wurde zunächst auch TEI Publisher in Betracht gezogen, schlussendlich fiel die Entscheidung unter anderem aufgrund der intuitiven Anwendung und der ausführlichen Dokumentation aber doch auf die open source Web-Publishing-Plattform Omeka. Das Content Management System Omeka ist ein Projekt von Digital Scholar, einer non-profit Organisation, die sich auf die Entwicklung von Anwendungen für die Präsentation und Recherche geisteswissenschaftlicher Inhalte konzentriert. Dabei bietet Omeka mehrere Versionen an, von welchen schlussendlich Omeka S (S für «Semantic») ausgewählt wurde.3 Omeka S ist zwar in erster Linie auf die Bedürfnisse von Institutionen ausgerichtet, kann aber auch für Einzelprojekte genutzt werden. Als relationales Datenbanksystem auf Basis von PHP mit MySQL/MariaDB ermöglicht Omeka S das Erzeugen von Linked Data/relationalen Daten, indem bereits erstellte Ressourcen (Objekte ("Items") und Sammlungen ("Item Sets")) für die Beschreibung anderer Ressourcen verwendet werden können. Dies ist gerade für die Erfassung der Beziehungen von Postkarten, Korrespondent*innen und Produzenten nützlich, da der Datensatz/Objekteintrag zu einer Person (z.B. einer Korrespondentin) beim Datensatz/Objekteintrag zu einer Postkarte direkt als Wert eines Attributs (z.B.  dem Feld Absender*in oder Empfänger*in) ausgewählt (und damit verlinkt) werden kann. Dies funktioniert, da jede Omeka S Ressource (Item, Item Set, Medium) über einen URI (Unique Resource Identifier) verfügt, der entsprechend verlinkt werden kann. Indem bei Omeka S der Wert eines Attributs (property) als URI übergeben werden kann, kann zudem das Potenzial von Linked Open Data (Modellen) genutzt werden. Gleichzeitig verwendet Omeka S «JavaScript Object Notation-Linked Data (JSON-LD) als natives Datenformat, weshalb die Datensätze/Omeka S Umgebung selbst wiederum als Linked Open Data geteilt werden können. Dafür sind die Feldkataloge von Omeka S auf «Felder aus publizierten, semantisch ausgewiesenen Vokabularen»  – dh. Linked Open Data Vokabularen – limitiert . Dabei behinhaltet die Basissoftware von Omeka S bereits die häufig genutzten Resource Description Framework (RDF) Vokabulare Dublin Core Metadata Initiative (DCMI) Terms, sowie DCMI Type, The Bibliographic Ontology (BIBO) und das Friend of a Friend Vokabular (FOAF).  Zusätzlich wird Benutzer*innen jedoch auch die Möglichkeit geboten, weitere Linked Open Data Vokabulare zu installieren und verwenden, falls gewisse Eigenschaften für die Beschreibung einer Ressource vermisst werden.4 

Installation 
Eine der grösseren Hürden bei der technischen Umsetzung war dabei das Aufsetzen und Installieren eines eigenen Servers sowie die Installation und Konfiguration von Omeka S. Die Herausforderungen ergaben sich jedoch vor allem deshalb, weil eine möglichst kostenlose Umsetzung angestrebt wurde. Dank Dokumentationen, Internetforen, Youtube-Tutorials sowie dem Austausch mit technikaffinen Freunden funktioniert die Website zwar, jedoch müsste gerade für eine längerfristige Erhaltung der Website noch einiges mehr investiert werden und gerade sicherheitstechnisch könnte sicherlich noch einiges optimiert werden.5  Zumindest für die kurz- bis mittelfristige Erhaltung wurde nun der kostenlose Service «DuckDNS» in Anspruch genommen (da meine Internetverbindung über eine dynamische, externe IP-Adresse hergestellt wird, die häufig wechselt). Konkret wurde bei dem von ihnen angebotenen öffentlichen DNS Server eine Subdomain («e-collection») registriert – deshalb ist auch das etwas deplatziert wirkende «.duckdns» im URL. Dank dem Dynamic Domain Name System (DDNS) «DuckDNS» werden die häufig wechselnden IP-Adressen meines Heimnetzwerkes an den statischen Domain-Namen weitergeleitet resp. diesem zugeordnet, wodurch die Website auch ausserhalb des Heimnetzwerkes erreichbar wird – und vor allem trotz ständig ändernder IP-Adressen erreichbar bleibt. 

Designvorlage und verwendete Module

Ein grosser Vorteil von Omeka sind die von Omeka selbst oder von anderen Nutzer*innen zur Verfügung gestellten Module6  und Designvorlagen7, welche gratis installiert und für die eigene Website genutzt werden können. Als Designvorlage wurde "Foundation" genutzt. Ausführungen zur Auswahl und Konfiguration von Designvorlagen findet man im Omeka S User Manual (Theme Selection). Des Weiteren wurden für das Editionsprojekt die folgenden Module genutzt:

 

1. Da zum momentanen Zeitpunkt nur männliche Personen als Produzenten der Quellen im Postkartenbestand nachgewiesen sind, wird hier bis auf Weiteres die männliche Form verwendet. 
2. Bedingungen/Qualität digitaler Ressourcen: Zumindest nicht die Bedingungen, die gemäss der Website der «State Archives of Florida» als national wie international übliche Mindeststandards gelten, vgl. https://www.floridamemory.com/learn/about/guidelines.php (Zugriff am 05.01.2022). 
3. Hilfreiche Blogbeiträge als Entscheidungshilfe betreffend der verschiedenen Angebote von Omeka, vgl. u.a.  https://forum.omeka.org/t/omeka-frequently-asked-questions/6777 (Zugriff am 05.01.2022). 
4. Zur Installation und Verwendung von weiteren Vokabularen vgl. die nächsten Seiten zur Katalogisierung oder im Omeka S User Manual (Zugriff am 05.01.2022). 
5. Zur Installation vgl. nebst dem offiziellen Omeka S User Manual unter anderem Reeve, Jonathan: Installing Omeka: https://programminghistorian.org/en/lessons/installing-omeka (Version vom 23.11.2020) sowie Kellogg, Jeremiah: Installing Omeka S on a Debian Based Server: https://www.youtube.com/watch?v=UG8S8qFR1po (Version vom 13.01.2021). 
6. Weitere Omeka S Module siehe auch: https://daniel-km.github.io/UpgradeToOmekaS/omeka_s_modules.html (Zugriff am 05.01.2022). 
7. Weitere Designvorlagen siehe auch: https://daniel-km.github.io/UpgradeToOmekaS/omeka_s_themes.html (Zugriff am 05.01.2022). 

Ariane Engler, Version vom 22.02.2022. 

Vorherige Seite Nächstes