image
image
image
image
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

image
image
image
image
Agenda
1. Ausgangssituation
2. Anforderungen an Software-Exporte
3. Herausforderungen und Problemstellung
4. Wunschszenario: Optimaler Datenworkflow
5. Fazit
6. Ausblick
7. Diskussion

image
image
image
image
1. Ausgangssituation
Grundbedingungen und Motivation

image
image
image
image
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

image
image
image
image
image
image
image
1. Ausgangssituation
Strukturierung des Pre-Processings
Eingabe der Quell- und Ausgabe der Zieldaten
Softwarespezifische
Module
Providerspezifische
Anpassungen

image
image
image
image
image
image
image
image
image
image
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

image
image
image
image
image
image
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

image
image
image
image
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

image
image
image
image
2. Anforderungen an Software-
Exporte

image
image
image
image
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

image
image
image
image
3. Herausforderungen und
Problemstellung

image
image
image
image
image
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

image
image
image
image
image
3. Herausforderungen und Problemstellung
Beispiele
Auch wohlgeformte
XML-Dateien
enthalten
syntaktische Fehler

image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele
Absätze werden im Portal nur angezeigt, wenn in
</lb>
umgewandelt

image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele
Fehlende Kontextualisierung

image
image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele
Header: fehlende / falsch zugeordnete
Informationen

image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele

image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele
fehlende Verknüpfung zwischen Findbuch
und Tektonik

image
image
image
image
image
image
image
3. Herausforderungen und
Problemstellung
Beispiele
Gleiche Identifier:
Daten werden überschrieben
Geänderte Identifier:
Daten werden doppelt geladen
Stabile Identifier

image
image
image
image
image
4. Skizze: Optimaler Datenworkflow

image
image
image
image
image
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

image
image
image
image
image
5. Fazit

image
image
image
image
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

image
image
image
image
6. Ausblick

image
image
image
image
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

image
image
image
image
Vielen Dank für Ihre Aufmerksamkeit!
… Fragen?
Oliver Götze, MSc.
Landesarchiv Baden-Württemberg
oliver
.goetze@la-bw.de

image
image
image
image
In welchem Maße ist eine Anpassung Ihrer Software an
die Anforderungen von EAD(DDB) möglich?
Diskussion