graph LR
A[Omeka API] --> B[Data Extraction]
B --> C[Data Transformation]
C --> D[DSP Upload]
D --> E[DSP API]
F[Configuration] --> B
F --> C
F --> D
style A fill:#86bbd8,color:#000
style E fill:#dbfe87,color:#000
style B fill:#ffe880,color:#000
style C fill:#ffe880,color:#000
style D fill:#ffe880,color:#000
style F color:#000
omeka2dsp
Omeka–DaSCH-Transfer-Pipeline
Langzeitarchivierung für Stadt.Geschichte.Basel
Die Forschungsdaten aus dem Projekt Stadt.Geschichte.Basel werden auf der Forschungsdatenplattform annotiert zur Verfügung gestellt. Die Metadaten dafür wurden mit einer von der Universität Bern bereitgestellten Omeka-S-Instanz kuratiert und verwaltet. Die Daten werden für die Forschungsdatenplattform zur Anzeige mit CollectionBuilder vom Omeka-Server extrahiert. Diese Konfiguration birgt jedoch erhebliche Risiken für die langfristige Verfügbarkeit:
- Omeka unterliegt nicht unserer institutionellen Kontrolle und wird möglicherweise nicht dauerhaft finanziert.
- GitHub Pages ist nicht für die Bereitstellung großer Dateien oder die Gewährleistung der Persistenz geeignet.
- CollectionBuilder bietet keine integrierte Unterstützung für Versionierung und persistente Identifikatoren auf dem Niveau, das von Forschungsdateninfrastrukturen gefordert wird.
Um diesen Herausforderungen zu begegnen, implementieren wir eine Übergangspipeline zur Archivierung aller Metadaten und zugehörigen Dateien mit DaSCH, wobei wir dessen Infrastruktur für die versionierte, dauerhafte und FAIR-konforme Veröffentlichung von Forschungsdaten nutzen.
Die neue Pipeline umfasst:
- Erfassung und Umwandlung von Metadaten aus Omeka in das DaSCH-Datenmodell.
- Automatisierte Ablage- und Aktualisierungsroutinen unter Verwendung der DaSCH-REST-API, einschließlich Unterstützung für die Versionierung bestehender Datensätze.
- Zurückschreiben stabiler DaSCH-Identifikatoren und Zugriffs-URLs auf unsere öffentlich zugängliche Plattform, um Transparenz und Zitierfähigkeit zu gewährleisten.
- Erhaltung hierarchischer Beziehungen und Medienmetadaten in Übereinstimmung mit unserem benutzerdefinierten Metadatenmodell, das die Grundsätze antidiskriminierender Beschreibungspraktiken berücksichtigt.
System Architecture
Wichtigste Komponenten
graph LR
A[Omeka API] --> B[data_2_dasch.py]
B --> C[DSP API]
B --> D[File Storage]
E[process_data_from_omeka.py] --> B
F[Configuration] --> B
style A fill:#86bbd8,color:#000
style C fill:#dbfe87,color:#000
style B fill:#ffe880,color:#000
style D color:#000
style E color:#000
style F color:#000