Offenes Datenformat

Was ein Datenformat beschreibt

Ein Datenformat legt fest, wie Informationen dargestellt und strukturiert werden.

Ein sehr einfaches Format könnte beispielsweise festlegen:

name;email;customer_number

und anschließend Daten enthalten:

Anna Beispiel;anna@example.org;4711

Damit ein anderes Programm diese Daten zuverlässig verarbeiten kann, muss es jedoch mehr wissen als die Position einzelner Trennzeichen.

Beispielsweise:

Welche Zeichenkodierung wird verwendet?
Ist die erste Zeile immer eine Kopfzeile?
Dürfen Felder leer sein?
Wie werden Trennzeichen innerhalb eines Wertes dargestellt?
Welche Bedeutung besitzt customer_number?
Ist die Nummer eindeutig?
Welche Version des Formats gilt?

Ein Datenformat umfasst deshalb nicht nur die sichtbare Darstellung der Daten.
Auch Regeln und Bedeutung gehören dazu.

Offen bedeutet dokumentiert und unabhängig implementierbar

Bei einem offenen Datenformat sind die für eine Implementierung notwendigen Informationen ausreichend öffentlich dokumentiert.
Dadurch kann grundsätzlich mehr als eine Software das Format implementieren.

Vereinfacht:

öffentliche Spezifikation
        ↓
Implementierung A
Implementierung B
Implementierung C
        ↓
gemeinsames Datenformat

Die Anwendungen müssen dabei nicht vom selben Hersteller stammen.
Sie müssen auch nicht denselben Quellcode verwenden.
Entscheidend ist, dass sie sich auf eine ausreichend klar beschriebene Struktur und Bedeutung der Daten beziehen können.

Offen ist nicht gleich textbasiert

Ein häufiger Kurzschluss lautet:

Kann ich mit einem Texteditor lesen
        =
offenes Format

Das stimmt nicht.
Ein proprietäres Format kann vollständig aus lesbarem Text bestehen und trotzdem nur unzureichend dokumentiert sein.
Umgekehrt kann ein offenes Format binäre Bestandteile enthalten.
Die technische Kodierung entscheidet deshalb nicht allein darüber, ob ein Format offen ist.
Relevant ist, ob seine Struktur und Bedeutung unabhängig von einer bestimmten Anwendung nachvollzogen und implementiert werden können.

JSON ist nicht automatisch ein offenes Datenformat

JSON besitzt eine öffentlich dokumentierte Syntax.

Damit weiß ein Programm beispielsweise, wie dieses Dokument strukturell gelesen werden kann:

{
  "customer": 4711,
  "status": 3
}

Damit ist aber noch nicht bekannt:

Was bedeutet customer?
Ist 4711 eine interne ID oder Kundennummer?
Was bedeutet status = 3?
Welche anderen Werte sind erlaubt?
Welche Felder sind verpflichtend?
Wie verändert sich das Schema zwischen Versionen?

Die Verwendung eines offenen Serialisierungsformats macht ein konkretes Datenmodell deshalb noch nicht automatisch offen oder interoperabel.
JSON kann die äußere Syntax liefern.
Für das eigentliche Datenformat muss zusätzlich die Bedeutung der darin verwendeten Strukturen beschrieben sein.

Dasselbe gilt für XML

XML definiert Regeln zur Strukturierung von Dokumenten.

Aus:

<customer>
  <status>3</status>
</customer>

folgt noch nicht, was status fachlich bedeutet.
Die Offenheit einer Syntax und die Offenheit eines darauf aufgebauten Datenmodells sind deshalb zwei verschiedene Ebenen.
Ein dokumentiertes Schema kann dabei helfen.
Für echte Austauschbarkeit muss jedoch auch die Semantik ausreichend klar sein.

CSV ist ein gutes Warnsignal

CSV wirkt zunächst wie das denkbar einfachste offene Format:

4711;Anna;active

Aber bereits hier entstehen Fragen:

Komma oder Semikolon?
UTF-8 oder eine andere Kodierung?
Gibt es eine Kopfzeile?
Wie werden Zeilenumbrüche in Feldern behandelt?
Was bedeutet Spalte 3?
Welche Werte sind dort erlaubt?

Die Lesbarkeit der Datei löst diese Fragen nicht.
Ein einfaches Format kann hervorragend für einen Datenaustausch geeignet sein.
Dafür müssen seine konkreten Konventionen jedoch bekannt sein.

Offenes Format und offene Spezifikation

Eine Spezifikation beschreibt das Format.

Sie kann beispielsweise festlegen:

• Struktur
• Elemente
• Attribute
• Wertebereiche
• Datentypen
• Beziehungen
• Kodierung
• Pflichtfelder
• Erweiterungen
• Versionsverhalten
• Semantik

Je vollständiger und eindeutiger diese Beschreibung ist, desto besser können unabhängige Implementierungen dasselbe Format verarbeiten.
Eine veröffentlichte Spezifikation allein garantiert allerdings noch keine gute Spezifikation.
Wenn wichtige Eigenschaften unklar bleiben, können verschiedene Programme trotz derselben Dokumentation unterschiedliche Ergebnisse erzeugen.

OpenDocument als Beispiel

Das OpenDocument Format, kurz ODF, ist ein standardisiertes Dokumentformat für beispielsweise Texte, Tabellen, Präsentationen und grafische Dokumente.
Die Spezifikation beschreibt unter anderem Struktur, Paketformat und Schema der Dokumente.
Sie ist nicht an eine einzelne Office-Anwendung gebunden.
Dadurch können verschiedene Programme ODF-Dokumente implementieren.
Das bedeutet jedoch nicht, dass jedes Programm sämtliche Möglichkeiten des Standards identisch unterstützt.
Ein komplexes Dokument kann deshalb trotz offenem Standard in verschiedenen Anwendungen unterschiedlich dargestellt werden.

Ein offenes Format garantiert keine Interoperabilität

Angenommen, ein Standard erlaubt die Eigenschaften:

A
B
C
D
E

Programm 1 unterstützt:

A B C D E

Programm 2 unterstützt:

A B C

Beide können dasselbe offene Format implementieren.
Beim Austausch eines Dokuments mit Eigenschaft E kann trotzdem Information verloren gehen.

Deshalb gilt:

offenes Format
        ≠
garantierte vollständige Interoperabilität

Ein offenes Format schafft eine wichtige technische Voraussetzung für Interoperabilität.
Ob konkrete Implementierungen tatsächlich kompatibel sind, muss gesondert untersucht werden.

Profile und Teilmengen

Komplexe Standards besitzen häufig viele optionale Funktionen.
Für einen konkreten Anwendungsfall kann deshalb eine definierte Teilmenge sinnvoll sein.

Beispielsweise:

Unser Austauschformat verwendet:

Version 2
Felder A bis G
UTF-8
keine proprietären Erweiterungen
Datumsformat YYYY-MM-DD

Eine solche Einschränkung kann den praktischen Datenaustausch zuverlässiger machen als die allgemeine Aussage:

Wir unterstützen Standard X.

Die genaue Beschreibung des tatsächlich verwendeten Profils gehört damit ebenfalls zur Interoperabilität.

Erweiterungen können Offenheit praktisch einschränken

Ein offenes Format kann Erweiterungsmechanismen besitzen.

Eine Anwendung könnte darüber eigene Funktionen speichern:

Standarddaten
+
Herstellererweiterung X

Eine andere Anwendung versteht möglicherweise nur:

Standarddaten

Sofern das Format solche Erweiterungen zulässt, kann das Dokument weiterhin dem offenen Format entsprechen.
Ein Teil seiner Bedeutung kann dennoch von einer einzelnen Implementierung abhängen.
Dadurch kann ein offenes Format praktisch erneut eine Herstellerabhängigkeit enthalten.

Die entscheidende Frage lautet daher nicht nur:

„Welches Format verwenden wir?“

Sondern auch:

„Welche Teile dieses Formats verwenden wir tatsächlich?“

Datenexport und offenes Datenformat

Ein System kann einen Export anbieten:

Export erfolgreich.

Das sagt noch wenig darüber aus, wie nützlich die exportierten Daten außerhalb des ursprünglichen Systems sind.

Ein brauchbarer Export sollte beispielsweise untersuchbar machen:

• welche Daten enthalten sind
• welche Daten fehlen
• wie Beziehungen dargestellt werden
• welches Format verwendet wird
• welche Version gilt
• wie Felder interpretiert werden
• wie Anhänge behandelt werden
• welche Metadaten enthalten sind

Ein technisch vorhandener Export ist deshalb nicht automatisch eine realistische Exit-Strategie.

Offene Formate und digitale Souveränität

Offene Datenformate können digitale Souveränität unterstützen.
Wenn Daten unabhängig von einer einzelnen Anwendung verstanden und verarbeitet werden können, entstehen zusätzliche Handlungsmöglichkeiten.

Beispielsweise kann man:

eigene Werkzeuge schreiben
alternative Anwendungen verwenden
Daten prüfen
Daten migrieren
Daten langfristig archivieren
automatisierte Verarbeitung aufbauen

Das reduziert bestimmte Formen des Vendor Lock-in.
Es beseitigt jedoch nicht automatisch alle anderen Abhängigkeiten.

Ein offenes Format kann trotzdem schwer nutzbar sein

Offenheit und Einfachheit sind unterschiedliche Eigenschaften.
Ein Format kann vollständig dokumentiert und trotzdem extrem komplex sein.

Für eine unabhängige Implementierung können beispielsweise benötigt werden:

mehrere tausend Seiten Spezifikation
zahlreiche optionale Funktionen
komplexe Abhängigkeitsregeln
mehrere ergänzende Standards

Formal besteht dann eine Möglichkeit zur unabhängigen Implementierung.
Praktisch kann diese Möglichkeit für kleine Organisationen begrenzt sein.
Auch hier zählt deshalb nicht nur die theoretische Offenheit.
Relevant ist, welche reale Handlungsfähigkeit daraus entsteht.

Offen bedeutet nicht unveränderlich

Auch offene Formate entwickeln sich weiter.

Es kann beispielsweise geben:

Format 1.0
Format 1.1
Format 2.0

Damit entstehen neue Fragen:

Kann Version 2 Dateien aus Version 1 lesen?
Kann Version 1 Daten aus Version 2 verarbeiten?
Welche Funktionen wurden verändert?
Wie werden unbekannte Elemente behandelt?

Versionierung gehört deshalb zu einem langlebigen Datenformat.
Eine Spezifikation sollte ausreichend deutlich machen, wie sich verschiedene Versionen zueinander verhalten.

Langzeitarchivierung

Bei langfristig aufzubewahrenden Daten besitzt die Dokumentation eines Formats besondere Bedeutung.
Die ursprüngliche Anwendung kann nach Jahrzehnten nicht mehr existieren.
Hardware und Betriebssysteme können verschwunden sein.
Ist das Format ausreichend dokumentiert, besteht zumindest die Möglichkeit, neue Software zur Verarbeitung der Daten zu entwickeln.
Das macht offene Formate für Archivierungsstrategien interessant.
Es garantiert allerdings nicht automatisch, dass alle benötigten Informationen tatsächlich dauerhaft erhalten bleiben.

Open Source und offenes Datenformat

Open Source und offene Datenformate können sich ergänzen, beschreiben aber unterschiedliche Dinge.

Open Source
    ↓
Wie darf Software verwendet, untersucht,
verändert und weitergegeben werden?

Offenes Datenformat
    ↓
Wie sind Daten strukturiert und beschrieben,
sodass unterschiedliche Implementierungen
sie verarbeiten können?

Eine proprietäre Anwendung kann ein offenes Datenformat verwenden.
Eine Open-Source-Anwendung kann umgekehrt ein schlecht dokumentiertes eigenes Datenformat verwenden.
Das eine folgt nicht automatisch aus dem anderen.

Self-Hosting und offene Datenformate

Auch bei selbst gehosteten Systemen sind offene Formate relevant.
Der eigene Betrieb kann direkten Zugriff auf die gespeicherten Daten ermöglichen.
Das bedeutet jedoch nicht automatisch, dass sie einfach in ein anderes System übertragen werden können.
Eine Anwendung kann beispielsweise Daten in einer komplexen internen Datenbankstruktur speichern.
Solange nur die Anwendung selbst diese Struktur zuverlässig versteht, bleibt eine Migration schwierig.
Self-Hosting schafft Zugriff.
Ein offenes und dokumentiertes Datenformat kann zusätzlich Verständlichkeit und Austauschbarkeit schaffen.

Warum offene Datenformate praktische Auswirkungen haben

• Daten werden unabhängiger von einzelnen Anwendungen: Andere Implementierungen können sie grundsätzlich verarbeiten.
• Migrationen werden erleichtert: Struktur und Bedeutung müssen nicht vollständig durch Reverse Engineering rekonstruiert werden.
• Eigene Werkzeuge werden möglich: Daten können unabhängig analysiert und verarbeitet werden.
• Archivierung wird unterstützt: Spätere Software kann sich weiterhin auf eine dokumentierte Spezifikation beziehen.
• Vendor Lock-in kann reduziert werden: Daten werden weniger stark an eine einzelne Implementierung gebunden.
• Interoperabilität wird unterstützt: Unterschiedliche Systeme erhalten eine gemeinsame technische Grundlage.
• Prüfbarkeit steigt: Struktur und Inhalte können gegen dokumentierte Regeln untersucht werden.
• Offenheit bleibt überprüfbar: Erweiterungen, Profile und tatsächlich verwendete Teilmengen müssen weiterhin betrachtet werden.

Typisches Beispiel

Eine Organisation möchte ein bisher verwendetes System ersetzen.

System A bietet einen Export als:

backup.dat

Die Datei enthält alle Daten.
Das Format ist jedoch nicht dokumentiert.
Nur System A kann es lesen.
Technisch existiert ein vollständiger Export.
Praktisch besitzt die Organisation damit nur begrenzte Handlungsmöglichkeiten.
System B exportiert dieselben Informationen in einem dokumentierten Format.

Die Beschreibung enthält:

Felddefinitionen
Datentypen
Beziehungen
Zeichenkodierung
Versionsnummer
Schema

Mehrere Programme können die Daten verarbeiten.
Zusätzlich besitzt die Organisation ein kleines eigenes Werkzeug, das den Export auf Vollständigkeit prüft.
Damit ist nicht garantiert, dass jede zukünftige Migration problemlos funktioniert.
Aber die Daten sind erheblich weniger stark an eine einzelne Implementierung gebunden.

Abgrenzung

• Offenes Datenformat beschreibt ein ausreichend öffentlich dokumentiertes Datenformat, das unabhängige Implementierungen ermöglicht.
• Offener Standard bezeichnet einen technischen Standard, dessen Spezifikation öffentlich zugänglich ist und dessen Entwicklung und Nutzung nach festgelegten offenen Bedingungen erfolgt. Welche Anforderungen darüber hinaus an einen offenen Standard gestellt werden, hängt von der verwendeten Definition ab. Ein offenes Datenformat kann durch einen offenen Standard spezifiziert werden.
• Serialisierungsformat beschreibt die technische Darstellung von Daten, beispielsweise JSON oder XML. Eine offene Serialisierungssyntax macht das konkrete darauf aufgebaute Datenmodell noch nicht automatisch offen.
• Interoperabilität beschreibt die Fähigkeit unterschiedlicher Systeme, Informationen auszutauschen und sinnvoll zu verwenden. Offene Datenformate können dies unterstützen, garantieren es aber nicht. -Open Source betrifft Software und ihre Lizenzierung beziehungsweise die mit ihrem Quellcode verbundenen Nutzungsrechte. Es ist nicht mit einem offenen Datenformat identisch. -Digitale Souveränität beschreibt die Fähigkeit, bei digitalen Abhängigkeiten reale Entscheidungs- und Handlungsmöglichkeiten zu behalten. Offene Datenformate können diese Möglichkeiten erweitern.

Weiterführend

Verwandte Begriffe

→ Digitale Souveränität
→ Schnittstelle
→ Systemintegration
→ Legacy-System
→ Legacy-Modernisierung
→ Self-Hosting
→ Interoperabilität