Jakoblog — Das Weblog von Jakob Voß

Die Citation Style Language (CSL) als Metadatenformat

Auf der Code4Lib Mailingliste hat Tim Spalding vor einigen Tagen die Idee aufgeworfen, die angekündigten Twitter Annotations zur Übertragung von bibliographischen Daten zu verwenden. Die Beteiligten waren alle der Meinung, das bibliotheksspezifische Formate wie MARC und MODS unpassend sind; BibTeX scheidet ebenfalls aus.

Nach der Überlegung, dass Identifikation und Beschreibung zwei klar abzugrenzende Aufgaben von bibliographischen Daten sind, habe ich mir mal genauer die Citation Style Language (CSL) angeschaut. CSL wird unter Anderem in den Literaturverwaltungsprogrammen Zotero und Mendeley benutzt, um Literaturangaben in unzähligen Zitationsstilen ausgeben zu können. Die Grundidee von CSL ist, Zitationsstile als CSL-Styles zu definieren, mit denen dann ein CSL-Prozessor aus bibliographischen Datensätzen schön formatierte Literaturangaben und Bibliographien erstellt. Der am weitesten fortgeschrittene CSL-Prozessor ist citeproc-js. Er ist in JavaScript geschrieben und wurde als Modul aus dem Programmcode von Zotero herausgelöst, so dass er auch unabhängig verwendet werden kann (allerdings bislang noch nicht mit allen JavaScript-Interpretern).

Die Idee ist nun, das CSL-Eingabeformat als Metadatenformat für bibliographische Daten in Twitter-Annotationen zu verwenden. Im Code4lib-Wiki habe ich mal zusammengefasst, was ich zur Spezifikation des CSL-Eingangsformat gefunden habe. Das Metadatenformat ist ziemlich einfach aufgebaut und soll sich dem Entwickler Frank Bennett nach in einer kommenden Zotero-Version auch einfacher aus dem Programm exportieren lassen.

Zur Vermeidung des Umwegs über Zotero fehlen nur Exportmöglichkeiten von CSL-Eingangsdaten aus Bibliothekskatalogen. Deren Titel könnten dann automatisch mit CSL in hunderten von Zitierstilen exportiert werden. In Beluga wird dazu übrigens bislang refbase verwendet, das ebenso wie der CSL-Prozessor citeproc-js als Open Source verfügbar ist. Für die Wikimedia-Projekte bietet sich das Format ebenso an – so könnten die Leser auswählen, welchen Zitationsstil sie bevorzugen und Literaturangaben aus Wikipedia-Artikeln direkt in ihre Literaturverwaltung übernehmen.

William Kent: Ein weiterer Seelenverwandter?

Bei meinen Recherchen zu Datenmodellierung etc. bin ich über Lambda the Ultimate auf den 2005 verstorbenen Computerwissenschaftler William (Bill) Kent gestoßen. Er hat 1978 ein Buch über „Data & Reality“ geschrieben hat und ebenso wie der von mir sehr geschätze Ted Nelson scheint Kent vom „Informatik-Establishment“ nicht genügend rezipiert zu werden. Die meisten von Kent’s Texten sind auf seiner ehemaligen Homepage verfügbar.

In The Many Forms of a Single Fact zeigt Kent beispielsweise, wie sich eine Aussage im relationalen Datenmodell in dutzenden Varianten ausdrücken lässt. Ich bin sicher im RDF-Datenmodell ist das alles gaaanz anders und das Problem gleiche Information – unterschiedliche Daten löst sich in Luft auf 😉 Die Ignoranz (oder der Fatalismus) der Mainstream-Informatik-Forschung gegenüber der dahinter liegenden fundamentalen Begrenzung technischer Systeme ist einer der Gründe, warum ich lieber in der Informationswissenschaft promoviere. Kent schreibt:

“The questions aren’t so much about how we process data as about how we perceive reality, about the constructs and tactics we use to cope with complexity, ambiguity, incomplete information, mis­matched viewpoints, and conflicting objectives”.

Dazu fällt mir Lotfi A. Zadeh, der Erfinder der Fuzzy Logik ein. Die erste Anwendung der Fuzzy Logik auf Datenbanken stammt übrigens von Maria Zemankova, die auch im Bereich Digitaler Bibliotheken forscht. Aber zurück zu Kent: Diese Notiz von ihm über Bücher verdeutlicht, warum ich über die Modellierung von bibliographischen Daten schreibe 🙂

“It takes a good system and a lot of work to keep track of books.
[…] Books hold our universe, past, present, and future, and other universes, too.”.

Mit Ted Nelson hat William Kent meinem Eindruck nach gemeinsam, dass beide jahrzentelang aus verschiedenen Blickrichtungen gegen die Begrenztheit von vorhandenen Computersysteme angeschrieben haben. Man vergleiche beispielsweise Nelsons „The Tyranny of the File“ (1986, siehe dazu hier) und Kents „Limitations of Record Based Information Models“ (1979).

Wer sich weniger mit konkreten Strukturen der Datenverwaltung beschäftigen möchte aber das trotzdem alles irgendwie interessant findet: Passende Bücher sind Sorting Things out von Geoffrey Bowker und Susan Leigh Star sowie Everything is Miscellaneous von David Weinberger.

Was sind eigentlich Daten?

P.S: Inzwischen habe ich einen Aufsatz zur Frage dieses Blogartikels veröffentlicht: Jakob Voß (2013): „Was sind eigentlich Daten?“. In: LIBREAS. Library Ideas, 23 (2013). http://libreas.eu/ausgabe23/02voss/

Adrian Pohl ist in seinem Blog auf meinen in Zwickau gehaltenen Vortrag Semantic Web und Linked Data eingegangen (der Videomitschnitt des Vortrags ist noch nicht online, aber die Vortragsfolien) – vielen Dank für das Feedback!

Definitionen von Daten

In der ersten Hälfte des Vortrags ging es mir darum zu erklären, was überhaupt Daten sind. Meine Kurzdefinition, die Adrian in seinem Beitrag auseinander nimmt ist:

Daten: Strukturen aus unterscheidbaren Zeichen, die aufgrund von Vereinbarungen Informationen darstellen

Dem setzt er folgende Definition entgegen (Hyperlinks wie im Original):

Daten sind für mich in erster Linie eine Menge unterschiedener und unterscheidbarer, syntaktisch strukturierter Token, die gespeichert sind und transportiert und kopiert werden können. Syntax in diesem Sinne setzt Digitalität (d.h. eine endliche Menge klar abgegrenzter Typen) voraus und damit ist Digitalität auch Voraussetzung für Daten.

Zum Vergleich hier noch die aktuelle Definition (19 April 2010 16:22 UTC) aus Wikipedia:

The term data means groups of information that represent the qualitative or quantitative attributes of a variable or set of variables. [en.wikipedia]

Daten sind logisch gruppierte Informationseinheiten […], die zwischen Systemen übertragen werden oder auf Systemen gespeichert sind. [de.wikipedia, 19 April 2010 16:22 UTC]

Kurze Analyse der Definitionen

Die Definitionen aus beiden Wikipedias halte ich für haltlos (Was heisst „logisch gruppiert“? Warum basieren Daten auf einer „variable“?) – sie zeigen allerdings, wie eng der Datenbegriff oft an den Informationsbegriff gekoppelt wird. Im Falle der Wikipedia-Definitionen, die Daten praktisch als eine Aggregat von Information(seinheiten) auffassen, ist diese Kopplung aber viel zu eng. Ich denke hier würde mir Adrian rechtgeben, da er schreibt „Nach meinem Dafürhalten […] stellen Daten keine Information dar, wenn sie auch gespeicherte Information sein mögen.“ Nach einer Trennung des Begriffs in einen rein syntaktischen Teil (siehe seine Definition oben), auf welchen aufbauend ein „aufnehmen“, „erfassen“ oder „verstehen“ zu Informationen möglich ist, schlägt er in Abwandlung meiner Definition vor:

Daten: Syntaktisch geordnete Mengen von Token, in denen Information gespeichert ist

Ich halte diese Definition für ebenso problematisch, da unklar ist was eine „syntaktisch geordnete Menge“ sein soll und da Informationen nicht objektiv in Daten „gespeichert“ sind sondern erst aufgrund von Vereinbarungen als Informationen interpretiert werden. Von der Aussage her – so denken ich – liegen Adrian und ich jedoch nicht weit auseinander. Man könnte zugespitzt sagen, dass wir uns nicht über die Daten einig sind (wie soll die Definition lauten) aber über die Information (was soll die Definition bedeuten).

Daten als Strukturen

Der Begriff „Token“ zur Definition der Bestandteile von Daten ist vielleicht besser als „Zeichen“ und ich möchte Adrian ausdrücklich für den Hinweis auf den Unterschied zwischen Token und Type danken. Voraussetzung für Daten ist die Möglichkeit einer Unterscheidung. Erstens ist notwendig zu unterscheiden, wo ein Token anfängt und endet, um überhaupt „Mengen“ identifizieren zu können. Zweitens setzen Daten die Möglichkeit voraus, dass zwei Token identisch – also eine Type – sind. Zusätzlich ist es notwendig, dass die Token in einer Struktur angeordnet sind, zum Beispiel eine Reihenfolge. Ich würde sogar fast soweit gehen, die Definition auf „Daten sind Strukturen“ zu verkürzen, weil Strukturen aus unterscheidbaren Elementen bestehen. Diese Definition blendet jedoch – auch in ausführlicherer Form wie zum Beispiel als „Daten sind strukturierte Mengen unterscheidbarer Elemente“ – den Begriff der Information völlig aus.

Informationen

Ohne Daten kann es keine Informationen geben. Der Philosoph Luciano Floridi – vermutlich der renommierteste Experte auf dem Gebiet der Informationsphilosophie – bezeichnet diese Annahme als Ontological Neutrality. Obgleich umgekehrt Daten möglicherweise ohne Informationen existieren können (darüber wäre zu diskutieren) finde ich es angemessen bei der Definition von Daten direkt auf Informationen zu verweisen. Bei der Definition von Information beziehe ich mich auf die von Floridi dargestellte General Definition of Information (GDI). In Is Information Meaningful Data? fasst er diese Definition zusammen und argumentiert, dass (semantische) Information zusätzlich wahr sein muss. Diese Annahme ist umstritten, während die GDI eine stabilere Grundlage bietet. Demnach ist etwas Information genau dann wenn:

1. es aus einem oder mehreren Daten besteht
2. die Daten wohlgeformt (syntaktisch korrekt) sind
3. die wohlgeformten Daten eine Bedeutung (Semantik) besitzen

Im Rahmen meiner Dissertation beschäftige ich mich damit, wie die Beziehung zwischen Daten, Wohlgeformtkeit und Bedeutung in der Praxis hergestellt wird. Wie ich in Libreas skizziert habe, sind dabei die Begriffe Format und Modell hilfreich. Auf das Modell, welches meiner Meinung nach notwendig ist, um aus Daten bedeutungsvolle Informationen zu lesen (aufnehmen, erfassen, verstehen…) verweise ich in meiner Definition mit der „Vereinbarung“. Die Vereinbarung muss implizit oder explizit als Hintergrundwissen, Kontextinformation, given information, Exformation o.Ä. vorliegen, um Daten interpretieren zu können – denn prinzipiell kann ein gegebenes Datum sehr viele verschiedene Informationen enthalten.

Digitalität und Wissen

Auf den Begriff der Digitalität möchte ich hier erstmal nicht weiter eingehen – finite Strukturen sind immer digital kodierbar also ist Digitalität nicht Voraussetzung sondern Folge von Daten. Und was Wissen ist weiß ich auch nicht: es hängt jedenfalls sehr davon ab, was man vom Wissensbegriff wissen möchte 😉 Hinweisen möchte ich aber auf die Zitatesammlung mit weiteren Definitionen von Daten von Beat Döbeli Honegger und auf den schon oben verlinkten Artikel Semantic Conceptions of Information von Luciano Floridi. Und natürlich freue ich mich sehr über weitere Kommentare!

Qualitätssicherung von Freien Daten

Vor etwas über einem Monat hat Nat Torkington einen Blogbeitrag mit dem Titel Truly Open Data veröffentlicht, auf den ich hier kurz hinweisen möchte. Nat versucht seit geraumer Zeit verschiedene Einrichtungen dazu zu überzeugen, ihre Daten als (Linked) Open Data freizugeben. In Truly Open Data beschreibt er, warum das Freigeben alleine leider nicht ausreicht, sondern ein offenes Qualitätsmanagement notwendig ist.

Freie Daten lassen sich prinzipiell mit Freier Software vergleichen: dank expliziter Lizensierung (zum Beispiel CC0) kann jeder die Daten kopieren, ändern (mit anderen Daten kombinieren, bereinigen, Ausschnitte bilden etc.) und weitergeben. Wenn man sich allerdings erfolgreiche Open Source Projekte anschaut, passiert in der Praxis noch mehr: Vor allem gibt es eine Community, die das Projekt pflegt und vorantreibt.

Ned weist darauf hin, dass Open Data vergleichbare Praktiken und Werzeuge benötigt, wie Open Source: Die Daten müssen gemeinsam bearbeitet werden können und es muss Personen geben, die sich für ein Datenset verantwortlich fühlen und im Zweifelsfall Entscheidungen treffen können. Zur Kommunikation und Kollaboration sind zahlreiche Tools wie Mailinglisten, Chat, Bug-Tracking-Systeme etc. hilfreich. Es muss einfach sein, sich Änderungen anzeigen zu lassen (Diff) und Vorschläge für Änderungen weitergeben zu können (Patch) – das was in Softwareprojekten durch Versionsverwaltung unterstützt wird. Außerdem mangelt es häufig – wie bei Software – an guter Dokumentation.

Insgesamt dürfen Daten nicht nur als Endprodukt gesehen werden. Es reicht nicht, Daten zu öffnen (auch wenn das der erste Schritt ist), sondern es muss sich auch die Erstellung, Pflege und Weiterverarbeitung der Daten öffnen.

Ich kann Net nur Recht geben und darauf hinweisen, dass die von ihm angesprochenen Punkte eigentlich eine Frage des Qualitätsmanagement sind. Sowohl bei Software als auch bei Daten sieht es jedoch oft sehr schlecht aus, wenn man mal schaut, wie sie entstehen und gewartet werden – wenn sie überhaupt gewartet werden anstatt vor sich hinzurotten. Open Source ist unter Anderem deshalb oft kommerziellen Produkten überlegen, weil offene Systeme nicht so einfach ihren Dreck unter den Teppich kehren können. Kein Wunder, dass viele Produzenten von Daten davor zurückschrecken, ihre Daten freizugeben: Dann wäre ja sichtbar, wie schlecht die Daten tatsächlich gepflegt sind!

Aber es gibt auch gute Beispiel und Vorbilder für offene, lebendig Datenbestände: OpenStreetmap, MusicBrainz, Wikipedia und DBPedia etc. Das Comprehensive Knowledge Archive Network (CKAN) und datapkg sind gute Ansätze. In einem Kommentare beschreibt Gerry Creager wie die Datenqualität in Forschungsprojekten durch einige Regeln verbessert werden konnte. Und Bibliotheksverbünde bieten bereits seit Jahrzehnten Werkzeuge zur gemeinsamen Datenpflege (wenn auch inzwischen etwas veraltet). Wesentlich ist aus meiner Sicht erst einmal die eindeutige Referenzierbarkeit von publizierten Daten (siehe z.B. datacite.org)

Grundsätzlich steht die kollaborative Pflege von Datenbeständen noch in den Anfängen und es gibt noch kein allgemeines Diff/Path für RDF. Ich sehe diese Herausforderungen trotzdem nicht als Grund, den ersten Schritt hinauszuzögern, bis irgendwann ein Data Publishing Framework etabliert ist. Die Freigabe von Daten als Linked Open Data kann und sollte jetzt geschehen und darauf aufgebaut werden.