Der Weg ins Portal
Erfahrungen der Fachstelle Archiv
im Handling von Datenlieferungen
Workshop mit Herstellern archivischer Software
10. März 2016, Sächsisches Staatsarchiv
Dresden
Agenda
1. Ausgangssituation
2. Anforderungen an Software-Exporte
3. Herausforderungen und Problemstellung
4. Wunschszenario: Optimaler Datenworkflow
5. Fazit
6. Ausblick
7. Diskussion
1. Ausgangssituation
Grundbedingungen und Motivation
1. Ausgangssituation
•
Vielzahl an Ausgangsformaten
•
EAD-Export enthält nicht zwingend alle benötigten
Informationen
•
bisheriges Vorgehen: Rückgriff auf proprietäre
Exporte, Entwurf eigener Transformationsszenarien
für einzelne Archivsoftware-Exporte
•
Ergänzt durch providerspezifische Skripte, um z.B.
individuelle definierte Masken verarbeiten zu
können
•
Praktisch jede Lieferung wird noch einmal
nachbearbeitet
1. Ausgangssituation
Strukturierung des Pre-Processings
Eingabe der Quell- und Ausgabe der Zieldaten
Softwarespezifische
Module
Providerspezifische
Anpassungen
Vom proprietären Datensatz zum
Austauschformat EAD(DDB)
Vielzahl an Ausgangsformaten
Optionale Zwischenformate
Eingangsformat
EAD(DDB)
Access-DB
Nicht standardisiertes XML
Exportformat
Verarbeitung
Proprietäre
Binärformate
--
Proprietäre
XML-Formate
-
Generische
EAD-Formate
+
EAD(DDB)
*1)
++
*1) EAD mit DDB-Anwendungsprofil
Vom proprietären Datensatz zum
Austauschformat EAD(DDB)
•
Spezialfall: Access-Export
als Zwischenformat
•
keine sprechenden
Feldnamen
•
Strukturierung abhängig
von Formular-
konfiguration
•
Access ermöglicht XML-
Export
•
nicht standardisiert,
aber automatisiert
weiterverarbeitbar
•
z.T. reichhaltiger als
EAD-Export
Vom proprietären Datensatz zum
Austauschformat EAD(DDB) (3)
Transformation
mit Hilfe von
XSLT
-Skripten
Archivdaten
(Ausgangsformat)
Excel-Sheet
(Definition des
Mappings
)
Providerspezifische
XML
-Dateien
(Metadaten und
Konversionsoptionen)
Transformierte XML-
Daten
EAD(DDB)
Voransichten,
technische
Validierung, Statistik
2. Anforderungen an Software-
Exporte
2. Anforderungen an Software-Exporte
•
Stabile Identifier
•
Konsistente Metadatendichte der Exportformate
•
Ausgabe von wohlgeformtem XML
•
Anbindung von Binärdaten
•
Umgang mit Updates
•
Möglichkeit des Abgleichs/Versionierung
•
Normdaten
•
Kontextualisierung von Freitextdaten
•
„Out-of-the-box“-Funktionalität: Vorkonfigurierter
EAD(DDB) Basis-Export
3. Herausforderungen und
Problemstellung
3. Herausforderungen und
Problemstellung
-
Fehlende/geänderte stabile Identifier
-
Insbesondere bei Updates: Führt zu Dubletten im
Portal
-
Generischer EAD-Export oft weniger reichhaltig als
proprietäre Formate bzw. XML-Anwendungsprofile
-
z.T. keine Möglichkeit, Tektonik zu exportieren
-
Umgang mit gesperrten Datensätzen
-
Hohe Flexibilität führt zu Vielzahl an Variablen
3. Herausforderungen und Problemstellung
Beispiele
•
Auch wohlgeformte
XML-Dateien
enthalten
syntaktische Fehler
3. Herausforderungen und
Problemstellung
Beispiele
Absätze werden im Portal nur angezeigt, wenn in
</lb>
umgewandelt
3. Herausforderungen und
Problemstellung
Beispiele
Fehlende Kontextualisierung
3. Herausforderungen und
Problemstellung
Beispiele
Header: fehlende / falsch zugeordnete
Informationen
3. Herausforderungen und
Problemstellung
Beispiele
3. Herausforderungen und
Problemstellung
Beispiele
fehlende Verknüpfung zwischen Findbuch
und Tektonik
3. Herausforderungen und
Problemstellung
Beispiele
Gleiche Identifier:
Daten werden überschrieben
Geänderte Identifier:
Daten werden doppelt geladen
Stabile Identifier
4. Skizze: Optimaler Datenworkflow
4. Skizze: Optimaler Datenworkflow
Datengeber
Archivsoftware
Fachstelle
Software
•
Schemavalidierung,
Wohlgeformtheit
•
Rollen bei Indexbegriffen
•
EAD(DDB)-Export
vorkonfiguriert
•
Verknüpfung und korrekte
Benennung sichergestellt
•
Stabile Identifier als zentraler
Bestandteil
Fachstelle
•
Datenübertragung
•
Auf Grundlage des Basis-EAD(DDB)-
Exports weitere Anpassungen (bilateral)
•
Weniger Datenverluste durch stabile
Identifier
•
Verarbeitung der Feld
inhalte
weiterhin
durch Fachstelle (providerspezifische
Skripte)
•
Weniger Iterationen beim Laden ins Portal
5. Fazit
5. Fazit
•
Stabile Identifier
als zentrales Qualitätskriterium
•
Tiefere Integration auf Softwareebene wünschenswert
•
Umgang mit
Updates
bei vorangegangenen
Lieferungen
•
Proprietäre Exportformate z.T. reichhaltiger als Belegung
des (generischen) EAD-Exports
•
Aufwendige und teils fragile Konversionsworkflows
der Fachstelle als Überganglösung
•
Langfristig:
valide EAD(DDB)-Exporte
benötigt
•
Scheinbar geringe Anpassungen führen zu hohem
Qualitätszuwachs
6. Ausblick
6. Ausblick
•
Data Preparation Tool (DPT) als Lückenfüller bei
„offiziellen“ EAD(DDB)-Export-Workflows
•
Behält seine Relevanz als Validierungs- und
Auswertungssystem
•
DDB plant Einführung von
Selbstbedienungskomponenten, Validierung
(Schematron) mit feinerer Granularität
•
Erfordert gewissen Mindeststandard an
Datenqualität
•
Exportschnittstellen der Softwareanbieter kommt hohe
Bedeutung zu
Vielen Dank für Ihre Aufmerksamkeit!
… Fragen?
Oliver Götze, MSc.
Landesarchiv Baden-Württemberg
In welchem Maße ist eine Anpassung Ihrer Software an
die Anforderungen von EAD(DDB) möglich?
Diskussion
