We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Nachhaltige Daten, Standards und Modelle für eine offene Datenkultur - Teil 4/7

00:00

Formale Metadaten

Titel
Nachhaltige Daten, Standards und Modelle für eine offene Datenkultur - Teil 4/7
Serientitel
Teil
4
Anzahl der Teile
7
Autor
Mitwirkende
Lizenz
CC-Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Dies ist Teil 4 von 7. Zunächst wird eine Definition offener Daten gegeben und die "FAIR" und "CARE" Prinzipien vorgestellt. Es wird ein Überblick über die Formen offener Daten gegeben. Es wird kurz auf das Urheberrecht und anschließend auf verschiedene Lizenzen eingegangen. Strukturierte, maschinenlesbare Daten sowie Probleme, die bei der Strukturierung für die Maschinenlesbarkeit auftreten können, werden dargelegt. CSV, XML und JSON werden vorgestellt. Es wird auf Verschlagwortung, Probleme, die hierbei auftreten können, und URI und RDF zur Umgehung dieser Probleme eingegangen. Das Konzept der Normdaten und der Linked Open Data durch URIs werden erläutert. Abschließend wird das Datenmanagement gezeigt.
Schlagwörter
Computeranimation
Transkript: Deutsch(automatisch erzeugt)
der dritte Stern offene Datenformate. So, wir kommen zum dritten Stern und damit zu den offenen Formaten. Auf der vorigen Stufe gab es vor allem zwei Probleme, also der Stufe mit den zwei Sternen. Das waren zwar strukturierte Formate, aber proprietäre Formate, wie zum Beispiel das alte Excel-Format.
Zum zweiten, komplexere Daten, also komplexere Strukturen, wie zum Beispiel Hierarchien, können damit nicht erfasst werden. Die Lösung besteht darin, dass wir einerseits offene Formate verwenden,
also keine proprietären, und andererseits auch Formate für komplexere Daten. Für die einfachen Daten, also einfache Tabellenstrukturen, gibt es das Format CSV und für komplexere Daten vor allem XML und auch JSON. Und wir werden beide oder alle drei Formate im Folgenden genauer anschauen.
Der Vorteil solcher offener Formate ist, dass die NutzerInnen die Daten beliebig nutzen und verändern können und dazu keine proprietäre Software benötigen. Schauen wir uns also zunächst das CSV-Format an. Das steht für Komma-separierte Werte. Das heißt, dass die einzelnen Felder bzw. Zellen durch Kommata getrennt sind.
Wobei man gleich dazu sagen kann, dass das nicht immer gilt, sind genauso gut auch Semikolon oder Tabulator denkbar. Manchmal sieht man auch die Dateiendung TSV für Tab-separierte Werte.
Typischer ist aber, dass die Dateiendung immer CSV ist und diese Dateien bestehen aus Plain Text. Das heißt, die Datei besteht nur aus den Zeichen selbst, also zum Beispiel Buchstaben, und enthalten keine zusätzliche Information zur Formatierung.
Die Felder bzw. Zellen sind wie erwähnt durch ein Trennzeichen, auch der Limiter genannt, getrennt. Und jeder Record, also jede Zeile enthält dieselbe Abfolge von Feldern. Und oft findet man in der ersten Zeile Spaltenbezeichner, also einen sogenannten Header.
Da es sich um Plain Text handelt, sind also in einer CSV-Datei keine farbigen Zellen oder auch keine fett gedruckten Einträge oder ähnliches möglich. Das CSV-Format wird oft als Austauschformat genutzt.
Das heißt, ich kann zum Beispiel aus einer Datenbank Daten extrahieren, also exportieren. Und das mache ich im CSV-Format. Und in der nächsten Datenbank, die ein ganz anderes Format nutzt als meine ursprüngliche Datenbank, kann ich wiederum CSV einlesen in das eigene Format dieser zweiten Datenbank.
Schauen wir uns ein Beispiel an. Hier links sieht man den Inhalt einer CSV-Datei, also die einzelnen Werte durch Kommata getrennt. Hier oben haben wir eine Header-Angabe, also das sind die Jahreszahlen. Also hier rechts sieht man es schöner formatiert. Und die einzelnen Einträge in der zweiten und dritten Zeile.
Hier rechts wird genau diese CSV-Datei visualisiert. Also zum Beispiel mit einem Programm wie Excel oder LibreOffice kann man sowas machen. Diese Information, dass das hier schön dunkelgrün gedruckt werden soll etc. die steht tatsächlich in diesen Daten selber nicht drin.
Das muss quasi das Programm, was die Daten visualisiert, selber erraten. Nun ein kleiner Exkurs zum Thema Kodierung. Ich habe gesagt, so eine CSV-Datei besteht nur aus Plain Text, also aus den Zeichen selbst. Aber man muss wissen, die Zeichen an sich können unterschiedlich kodiert sein.
Ein Computer kennt intern nur Nullen und Einsen oder An und Aus, könnte man sich vorstellen. Das heißt, wenn ich einen Buchstaben wie A repräsentieren möchte auf dem Computer, geht das nur durch eine Sequenz aus Nullen und Einsen. Also zum Beispiel diese Folge hier, das ist eine Binär-Kodierung der Zahl 65.
Also man könnte auch sagen, A wird durch die Zahl 65 hier jetzt in Binär-Kodierung repräsentiert auf dem Computer. Nun gibt es verschiedene Systeme zu dieser internen Kodierung. Zum Beispiel ASCII, das ganz alte System, dann Neuer ISO Latin 1, Windows 1252, UTF-8.
Das ist eine Unicode-Kodierung etc. Typischerweise sind die englischen Buchstaben, also das englische Alphabet, jeweils gleich kodiert hier, weil das eben das historisch älteste System ist.
Und die Unterschiede zeigen sich dann bei den Sonderzeichen. Also wenn Sie mal einen Text haben, wo die Sonderzeichen, wie zum Beispiel deutsche Umlaute, falsch dargestellt sind, dann hat das Programm offensichtlich die interne Kodierung nicht richtig erkannt oder die Kodierung war in irgendeiner Form fehlerhaft. Heutzutage ist UTF-8 sehr weit verbreitet und das ist auch eine sehr gute Kodierung
und sehr zu empfehlen, die eigenen Daten in dieser Kodierung tatsächlich auch abzuspeichern. Nun gleich ein zweiter Exkurs zum Thema Markup-Sprache. Das zweite offene Format ist nämlich XML. Das steht für Extensible Markup Language.
Deshalb schauen wir zuerst auf Markup-Sprachen im Allgemeinen. Dabei handelt es sich um Sprachen, die auch maschinenlesbar sind, aber auch von Menschen. Und in diesen Sprachen annotiert man mit Hilfe bestimmter Sonderzeichen extra Information. Und diese Sonderzeichen werden Markup genannt.
Hier ein simples Beispiel für solches Markup. Man kann zum Beispiel ein Stück Text mit Sternen umgeben und das bedeutet dann bitte dieses Stück Text hier kursiv drucken oder zwei Sterne bedeutet Fettdruck. Das heißt mit Hilfe von diesem Markup, also diesen Sternchen hier,
kodiere ich Informationen über das Layout, über die Formatierung von diesem Stück Text, der hier zwischen, also der anstelle von diesem Punkt, Punkt, Punkt stehen soll. Dieses Markup ist so simpel und knapp und minimalistisch, dass es auch anders genannt wird, nämlich Markdown.
Ein etwas deutlicheres Markup besteht in Form von diesen drei Zeichen hier, also dieses Spitzeklammer auf, i, Spitzeklammer zu. Das markiert den Beginn des Markups und entsprechend dieses Zeichen hier mit dem Slash,
der hinzukommt, das bezeichnet das Ende dieser Markup-Region. Und hier steht eben i für Italics, im Englischen für kursiv. Also das ist gleichbedeutend mit diesem Stern hier oben, nur offensichtlich ist das sprechender als Markierung. Also hier kann ich quasi erraten, dass i für Italics stehen soll
und b für Bold für Fettdruck. So die wichtige Idee von Markupsprachen ist, dass man den Inhalt und seine Formatierung voneinander trennen möchte. Und das berühmteste Beispiel könnte man sagen, für solch eine Trennung ist die Sprache HTML,
was für Hypertext Markup-Language steht und in dem die ganzen Webseiten geschrieben sind, die wir im Internet anschauen können. Dieses Markup hier, was wir hier gesehen haben, i und b, sind tatsächlich auch HTML-Tags, die eben genau kursiv und fette Teile auf Webseiten generieren.
Konkret heißt das, in dem HTML-Dokument steht tatsächlich wirklich nur dieses Zeichen hier und ein Webbrowser muss dann wissen, was er tut, wenn er auf solch einen Markup stößt, dann muss er die entsprechende Region eben kursiv darstellen.
So das Gegenstück von solch einer Markup-Sprache ist eine Wysiwix-Sprache. Das steht für What you see is what you get. Das heißt, ich schreibe einen Text, zum Beispiel in Word, und dort markiere ich gleich kursiv und bekomme das auch entsprechend gleich kursiv dargestellt.
Also in Word gibt es diese Trennung zwischen Inhalt und Formatierung eben nicht. Kommen wir jetzt zu XML. Das steht für Extensible Markup-Language und Extensible heißt, ich kann das Markup selbst definieren. Das ist die Besonderheit von XML. Zum Beispiel war vorhin das I für Italics in HTML eben standardisiert
und jeder Browser weiß genau, was er mit I tun soll, nämlich kursiv darstellen. Jetzt in XML habe ich die Möglichkeit, eigene Tagnamen, eigene Tags zu erfinden, zum Beispiel sowas wie kursiv oder auch sowas wie Keyword. Natürlich muss ich mich dann auch selber darum kümmern,
wie das jeweils dargestellt wird oder wie diese Tags interpretiert werden sollen. Der Vorteil der Flexibilität von XML kommt also mit einem Nachteil, dass ich eben mich auch selber kümmern muss, wie die Daten verstanden werden sollen. Zum Beispiel könnte ich damit meinen, dass dieser Teil hier irgendwie besonders dargestellt werden soll
oder mit diesen Ausdrücken hier, dass ich gerne möchte, dass der Teil zwischen der Markierung durch Keyword zum Beispiel in einen Index aufgenommen werden soll. XML eignet sich besonders gut für den Datenaustausch,
weil die Tags wie zum Beispiel Keyword oder ähnliches den Inhalt des Dokuments schon beschreiben. Das ist quasi eine Dokumentation, die mit den Daten mitkommt. Das ist zum Beispiel bei CSV nicht so der Fall. Da muss ich nicht unbedingt eine Headerzeile haben, die mir die Spaltenbezeichnung mit angibt.
Bei XML bekomme ich jeweils die einzelnen Felder direkt mit dokumentiert. Ein weiterer Vorteil, die Kodierung wird automatisch mitgeprüft. Also wenn ich UTF-8 angebe, dann wird auch überprüft, ob das wirklich tatsächlich in UTF-8 kodiert ist. Der Default ist tatsächlich auch UTF-8 für XML-Dateien.
XML kann ich im Prinzip auf zwei verschiedene Arten einsetzen. Ich kann zum einen damit hierarchisch strukturierte Daten kodieren, oder ich kann Text mit Annotationen versehen. Ich bringe jetzt jeweils Beispiele für beides. Hier zunächst ein Beispiel für hierarchisch strukturierte Daten.
Damit meine ich das in diesem Beispiel von der Religionszugehörigkeit. Zum Beispiel diese Überschrift evangelisch. Eine Spaltenüberschrift ist, die drei einzelnen Unterspalten entspricht. Also man könnte sagen, der Eintrag evangelisch bettet gewissermaßen diese drei Einzelspalten ein.
Und entspricht natürlich für römisch-katholisch. So, ich könnte das hier zum Beispiel so in XML wiedergeben. Hier habe ich diese Spalte etwas sprechender genannt Anzahl evangelisch. Die geht hier, geht dieses Tag auf und endet hier unten. Und bettet die drei anderen drei Spalten ein, nämlich die Total-Männer- und Frauenspalte.
Und dann kommt die größere Überspalte-Anzahl römisch-katholisch, die entsprechend auch wieder drei Unterspalten hätte. Diese Dreieckchen hier, die ergeben sich nur durch die Darstellung im Browser, aus dem ich das hier kopiert habe. Und diese Dreieckchen kann man auf und zu klappen.
Also das hier ist ausgeklappt und hier Anzahl römisch-katholisch habe ich quasi zugeklappt. Deswegen hier diese abkürzende Punkt-Punkt-Punkt-Schreibweise. Was auch der Browser gleichzeitig mitgemacht hat, ist diese Einrückung hier, damit es für uns als menschliche Leser klarer ist, dass hier was eingebettet ist.
Diese drei eingerückten Spalten sind eben auch eingebettet in einen Obertag. Was auch vom Browser übernommen wurde, ist eine unterschiedliche farbliche Darstellung. Also der sogenannte Inhalt der Tags wird schwarz dargestellt und die Tags sind lila.
Was Ihnen wahrscheinlich auffällt, ist, ich habe hier die Spalten und Zeilen-Header ein bisschen umgeschrieben. Ich habe hier keinen Umlaut benutzen. Ich habe alles kleingeschrieben. Also die Umlaute würde ich tatsächlich vermeiden in solchen Tags.
Eben aus dem oben genannten Grund, weil viele Tools davon ausgehen, dass hier nur rein englische, rein ASCII-Zeichen vorkommen. Das sollte man einfach konservativ sein und im Zeitsfall auf den Umlaut verzichten. Groß-Kleinschreibung hingegen ist kein Problem. Das gibt es ja auch im Englischen. Das hätte man hier auch machen können.
So, noch mal kurz zur Erinnerung. Diese Oberspalte, die drei Einzelspalten überdeckt, das wäre quasi etwas, was ich nicht in CSV-Dateien darstellen könnte. So, die Art und Weise, wie ich das hier in XML codiert habe, war jetzt nicht so richtig XML-mäßig, wie man das eigentlich tun würde.
Ich habe hier noch ein Beispiel, wo es ein bisschen mehr nach XML aussieht, wie man das typischerweise machen würde. Man würde wahrscheinlich diese Einzelanzahlen nämlich in Form von Attributen, das sind Merkmalswertpaare, darstellen. Also ich habe die Information, dass die Gesamtanzahl der Evangelischen 196 ist und die der Männer 70 etc.
Und das stelle ich da als Merkmal mit einem bestimmten Wert. Diese Merkmale sind jetzt hier in Beige und in Blau dargestellt. Und das Besondere ist jetzt, dieses Elementanzahl oder auch Taganzahl evangelisch ist tatsächlich ein leeres Element. Das hat jetzt gar kein Inhalt mehr.
Und deswegen kann man hier diese Schreibweise slash Spitzeklammer zu nutzen. Das bedeutet, das Tag geht auf und gleich wieder zu. Diese Darstellung ist ein bisschen mehr wie typisches XML. Allerdings glaube ich nicht, dass man Baden-Württemberg zum Beispiel als eigenes Tag annehmen würde. Das würde man wahrscheinlich auch eher als Wert von einem Attribut Bundesland ist gleich sich vorstellen.
Jetzt noch ein anderes Beispiel vom Einsatz von XML, nämlich einen Text mit Annotationen versehen. Da gibt es berühmte Guidelines, nämlich die TEI oder TEI Guidelines. Das ist ein XML-Standard für die Beschreibung von Texten mit Markup.
Und das wird besonders für Editionen genutzt. TEI steht für Text-Encoding-Initiative. Und ich bringe hier mal ein Beispiel für eine Edition. Wir haben einen lateinischen Text.
Und wir haben hier einen Tippfehler. Das hieß Angues in der, nicht Tippfehler, ein Schreibfehler im Manuskript. Und der Herausgeber der Edition korrigiert das nach Augens. Das heißt, ich brauche jetzt als nächstes noch ein Programm,
was dieses Markup mit Choice und SIG und COR versteht und weiß, wie es dann Angues und Augens korrekt darstellt. In der einen Edition könnte ich zum Beispiel die korrigierte Version im Haupttext haben und Angues in einem kritischen Kommentar zum Beispiel als originale Form angeben.
Neben solchen Text-Internen-Annotationen, wie wir sie hier sehen, definiert TEI außerdem sehr ausführliche Metadaten, wie sie zum Beispiel für Editionen relevant sind. XML ist eine sehr schöne Mark-Absprache, weil sie so explizit ist.
Also das kann man quasi als Mensch direkt unmittelbar verstehen, was das hier alles heißen soll. Aber der Nachteil ist natürlich, dass die Daten damit sehr stark aufgebläht werden. Und JSON ist eine Alternative, die quasi ein knapperer Formalismus ist und dieses Aufblähen vermeidet.
Es gibt in JSON verschiedene Elementtypen. Also ich kann unterscheiden zwischen Zahl, Zeichenkette, Liste. Ich habe auch Merkmalswertpaare, wie wir das von XML auch kennen. Und das Format für Merkmalswertpaare ist mit so einem Doppelpunkt getrennt.
Und wir schauen uns das direkt im Beispiel an. Das ist wieder unser Religionszugehörigkeitsbeispiel. Und ich kann hier schon sehen, dass ich wieder eingebettet in Anzahl evangelisch so ein sogenanntes Objekt habe, das mit geschweifter Klammer markiert wird. Und in diesem Objekt habe ich insgesamt drei Elemente enthalten.
Und das sind genau unsere drei originalen Spalten, die wir vorhin in XML auch schon gesehen hatten. Wir sparen uns hier also einiges an öffnenden und schließenden Klammern. Und das Ganze wird etwas kompakter.