"Forschungsprimärdaten bilden einen wertvollen Fundus an Informationen, die mit hohem finanziellem Aufwand erhoben werden. Je nach Fachgebiet und Methode sind sie replizierbar oder basieren auf nicht wiederholbaren Beobachtungen oder Messungen. In jedem Fall sollten die erhobenen Daten nach Abschluss der Forschungen öffentlich zugänglich und frei verfügbar sein."
Aus: Empfehlungen zur gesicherten Aufbewahrung und Bereitstellung digitaler Forschungsprimärdaten, DFG: Ausschuss für Wissenschaftliche Bibliotheken und Informationssysteme, Unterausschuss für Informationsmanagement, S. 2, Januar 2009.

Dokumenten-basierte Datenbanken

Details
Erstellt am Mittwoch, 26. Januar 2011 19:24
Geschrieben von Claus Zinn

Schemas, Schemas, Schemas und wie man mit ihnen umgeht

Eine wesentliche Aufgabe des NaLiDa-Projekts ist es, deutsch-sprachige linguistische Ressourcen elektronisch zu erfassen und einer breiten Fachöffentlichkeit zugänglich zu machen. Plakativ formuliert arbeitet das NaliDa-Projekt an einer elektronischen Version der "Gelben Seiten": Ersteller und Anbieter linguistischer Ressourcen melden dem NaLiDa-Team Metadaten, d.h. Daten, die ihre linguistischen Ressourcen beschreiben; das NaLiDa-Team pflegt diese Daten in ihren Katalog ein und macht ihn über eine Web- bzw. Browser-basierte Schnittstelle öffentlich. Das elektronische Medium birgt gegenüber einer althergebrachten Papierversion viele Vorteile, wie zum Beispiel eine regelmäßige Aktualisierung der Datenbestände oder ein multi-dimensionaler Zugang über verschiedene Suchkriterien und eine damit kombinierbare Volltextsuche auf beliebige Metadatenfelder oder gar den Gesamtbestand.

Die Umsetzung der Idee wirft eine Reihe von technischen Fragen auf: wie sollen die Ersteller bzw. Anbieter linguistischer Ressourcen ihre Bestände beschreiben; wie sollen sie ihr Angebot bzw. eine Aktualisierung ihres Bestandes übermitteln; und wie können selbst unerfahrene Nutzer diese "Gelben Seiten" effektiv und effizient nutzen? Zunächst eine kurze Antwort auf die zweite Frage: idealerweise sollte eine regelmäßige automatische Datenübermittlung über ein automatisches Harvesting mittels dem Protokoll OAI-PMH geschehen - wir werden dazu in Kürze einen erklärenden Blogbeitrag haben. Die Antwort auf Frage 3 erfahren Sie mit unserem Faceted Browser, der auch eine Volltextsuchfunktion enthält.

Aber beschäftigen wir uns mit der ersten Frage. Es ist davon auszugehen, dass die Ersteller und Anbieter von Sprachressourcen, üblicherweise akademische Forschungseinrichtungen und -verbünde, diese bereits mit Metadaten beschrieben haben; bisher gab es aber kein einheitliches Beschreibungsformat, und dies selbst nicht für einzelne Ressourcentypen wie Korpora oder Lexika. Daher haben verschiedene Institutionen eigene, idiosynkratische Beschreibungsverfahren entwickelt. Nicht alle davon beachten dazu die Unterschiede von Ressourcentypen, wodurch manchmal neue Schemas ad hoc entwickelt werden. Es ist also davon auszugehen, dass n Institutionen m>n Beschreibungsschemata für diesen Zweck einsetzen. Gehen wir aber vereinfachend davon aus, dass zur Datenübermittlung zumindest diesselbe Basistechnologie eingesetzt wird, nämlich ein XML Schema, das nach dem Komponentenmodell für Metadaten (CMDI) erstellt wurde, und XML-kodierte Datensätze zur Beschreibung linguistischer Ressourcen; diese sollten valide sein, d.h., die Datensätze sollten sich nachweislich an das Beschreibungsformat halten.

Auf Empfängerseite stellt sich nun die Frage, wie man mit einer solchen Datenvielfalt umgeht. Sollen Metadatenbeschreibungen, die m verschiedenen Schemata gehorchen, in ebenso vielen Datenbanken gespeichert werden, d.h. sollte man also für jedes der m Schemas ein korrespondierendes (relationales) Datenbankschema anlegen, um dann alle dem Schema zugehörigen Datensätzen dort abzulegen? Oder sollte man ein allumfassendes Schema definieren, mit dem beliebige Sprachressourcen beschrieben werden können, und alle m Schemata auf dieses "Super-Schema" abbilden -- und natürlich die entsprechenen Metadateninstanzen passend transformieren? Ein nicht-triviales Unterfangen! Ersterer Ansatz zwingt einen in m Datenbanken gleichzeitig zu suchen, und wie soll man einen einheitlichen Zugang zu Daten schaffen, die auf verschiedenen Datenbanken mit unterschiedlicher Struktur verstreut sind? Auch der zweite Ansatz birgt Probleme. Wie soll man sicherstellen, dass das "Super-Schema" wirklich allumfassend ist; werden in Zukunft vielleicht doch noch einige Metadatendeskriptoren nötig, an die man heute nicht gedacht hat?

Dokumenten-basierte Datenbanksysteme stellen in diesem Kontext eine interessante Lösung dar. Anstelle von Datensätzen nach einem relationalem Schema speichern solche Schema-freien Datenbanken Dokumente beliebiger Struktur. Bekannte Vertreter dieser NoSQL Datenbanken sind CouchDB und MongoDB. Im NaLiDa-Projekt haben wir CouchDB im Einsatz und skizzieren nun unsere Vorgehensweise.

Eine CouchDB-Datenbank kann beliebige Dokumente speichern. Dabei ist zu unterscheiden zwischen einem "Datensatz-Dokument", der im JSON-Format vorliegen muss, und beliebig formatierten "Anhängen", die einem Datensatz-Dokument zugeordnet werden können. Ginge es nur um die Speicherung von beliebig strukturierten Metadatensätzen in CouchDB, dann würde eine simple Transformation ihrer XML-Bäume nach strukturerhaltenden Attribut-Wert Paaren in JSON-Syntax ausreichen; dem entstehenden JSON-Dokument muss lediglich ein eindeutiger Identifikator zugeordnet werden. Der Zugriff auf ein Datensatz-Dokument erfolgt dann über ein REST-basiertes Interface, wobei sich die URL wie folgt zusammensetzt: URL des CouchDB-Servers (mit Portnummer 5984), Name der Datenbank, sowieso Identifikator. Liegt der Datenbank-Server lokal, so kann auf Dokumente der Datenbank "nalida" z.B. wie folgt zugegriffen werden: http://localhost:5984/nalida/weblicht-99 (hier ist "weblicht-99" der Identifikator eines Dokumentes, das eine Ressource aus dem Projekt Weblicht beschreibt). Will man Dokumente einspielen, modifizieren oder löschen (oder neue Datenbanken anlegen oder alte löschen) so kann man dies mit entsprechenden REST-basierten Kommandos durchführen. CouchDB führt eine Revisionshistorie, sodass jederzeit auf alte Revisionen eines Dokumentes zurückgegriffen werden kann; ein nicht unwichtiges Feature.

Die Implementierung einer Volltextsuche über alle in einer Datenbank gespeicherten Dokumente lässt sich mithilfe von CouchDB-Zusatzpaketen einfach realisieren. So bietet CouchDB-Lucene eine vollwertige Schnittstelle zur Java-basierten Suchmaschine Lucene an.

Für einen einheitlichen Zugang auf alle (verschiedenartig) strukturierten Metadatensätze bietet sich neben der Volltextsuche auch ein Faceted Browsing an. Hier ist allerdings weit mehr Implementierungsaufwand notwendig, da die verschiedenartigen Dokumentenstrukturen mit in Betracht gezogen werden müssen. Aber beginnen wir zunächst mit der Auswahl der Facetten und ihrer Wertebereiche oder Ausprägungen. Im NaLiDa-Projekt haben wir die Facetten "modality", "language", "resourceClass", "country", "organisation" und "origin" gewählt, da die große Mehrheit der uns vorliegenden Metadaten Informationen über diese Facetten beinhalten. Bedingte Facetten wie "genre" oder "tooltype" machen nur in bestimmten Kontexten Sinn, nämlich wenn man sich auf Ressourcen vom Typ "corpus" oder "tool" beschränkt. Die Wertebereiche bzw. Ausprägungen von Facetten ergeben sich im Regelfall aus den Daten; hier ist von einem gewissen Standardisierungsbedarf auszugehen -- mein Blog-Beitrag über Organisationsnamen hat mehr dazu.

Will man die gewählten Facetten auf die entsprechenden Deskriptoren der Metadatensätze abbilden, so empfiehlt sich die Hinzunahme der entsprechenden Dokumentenschemata. So findet sich die Facette "organisation" in Tübinger Datenbeständen in den Teilstrukturen "doc.CMD.Components.TextCorpusProfile.GeneralInfo.LegalOwner.$t" und "doc.CMD.Components.LexicalResourceProfile.GeneralInfo.LegalOwner.$t" (d.h. die Tübinger Daten beschreiben ihre Daten mithilfe der CMDI Profile "TextCorpusProfile" und "LexicalResourceProfile"), während man in Stuttgarter Beständen im "ToolProfile"-Schema unter "doc.CMD.Components.ToolProfile.Project.Institution.Organisation" fündig wird (dabei bezeichnet "doc" die Dokumentwurzel und "doc.X" einen Teilbaum von "doc" mit Wurzelelement "CMD").

Um einen Zugang auf alle Metadatenbestände einer Datenbank (z.B. "nalida") unter der Dimension bzw. Facette "organisation" zu erhalten, muss in CouchDB ein sogenanter "View" programmiert werden. Dieser in Javascript erstellte "View" codiert o.g. Pfadinformationen für die Facette "organisation". Im NaLiDa Faceted Browser werden Views für alle unbedingten und bedingten Facetten definiert. Um die Anpassung der Views zu vereinfachen, stehen Skripte bereit, die aus Facettenspezifikationen den entsprechenden Javascript Code für einen View automatisch generieren. Solche Spezifikationen stellen jede unbedingte und bedingte Facette mit CMDI-Profilen und Zugriffspfaden deklarativ in den oben skizzierten Zusammenhang.

Die generierten Javascript Views kann man als hard-codierte SQL Queries auffassen; sie partitionieren die verschieden-artig strukturierten Dokumente einer CouchDB Datenbank in Teilmengen; jede Teilmenge entspricht einer Facette, und jedes Element (Dokument) einer Teilmenge hat eine der möglichen Facettenausprägungen. Dabei wird ein Dokument im Regelfall mehreren Teilmengen, aber nicht notwendigerweise allen Teilmengen angehören.

Die Realisierung von Faceted Browsing kann nun als Schnittmengenbildung auf Basis der elementaren Views betrachtet werden. Wählt der Nutzer in Faceted Browser die Facette "organisation" mit Ausprägung "Universität Tübingen" aus, so beschreibt diese Auswahl eine nicht-leere Teilmenge M von n Dokumenten. Einige dieser Dokumente treten auch in anderen Facetten-Teilmengen auf, was durch Schnittmengenbildung von M mit allen anderen Teilmengen berechnet werden kann. Die Schnittmengenberechnung erfolgt in der Implementierung des NaliDa Faceted Browser ebenfalls durch Views, und auch diese Views können automatisch generiert werden. Hier verwenden wir aus Effizienzgründen aber nicht Javascript, sondern Erlang - das ist die Programmiersprache, in der auch CouchDB implementiert ist.

Fassen wir zusammen! Was haben wir durch unseren Ansatz gewonnen?

  • CouchDB erlaubt zunächst einmal die Speicherung beliebig-strukturierter Dokumente; dafür ist eine Betrachtung der jeweiligen Dokumentschemata nicht nötig.
  • CouchDB erlaubt ebenso Schema-unabhängig eine Volltextsuche über alle Dokumente einer Datenbank.
  • Zur Schaffung eines Facetten-basierten Zugangs müssen die jeweiligen Dokumentenschemata in Betracht gezogen werden. Für jedes Schema ist es aber nur nötig Facetten auf Schema-eigene Metadatenfelder abzubilden, und dies mitfilfe von Dokumentpfadinformationen. Die Schemata müssen also nicht vollständig verarbeitet werden, sondern nur soweit es für das Faceted Browsing notwendig ist.
  • Dokumente, die einem nicht-bekannten Schema angehören, können unmittelbar in CouchDB eingespielt werden und sind damit mittels Volltextsuche bereits erreichbar -- Lucene indiziert neu eintreffende Dokumente spätestens bei Vorliegen einer neuen Suchanfrage automatisch. Sobald die Facettenspezifikation für ein neues Profil erweitert worden ist, können aktualiserte Views neu generiert werden; und damit werden auch Dokument-Instanzen des neuen Schemas über Faceted Browsing zugänglich gemacht.
  • Will man die Inhalte von Dokumenten beliebigen Schemas benutzerfreundlich anzeigen, kommt man um eine vollständige Betrachung der jeweils zugrundeliegenden Dokumentstruktur nicht herum. Im NaLiDa Faceted Browser werden "Document Views" (also Darstellungen von Metadaten in angenehmen Layout, nicht zu verwechseln mit den weiter o.g. "Views") für jedes bekannte Profil definiert; Dokumente mit (noch) unbekanntem Profil werden strukturerhaltend als auffaltbarer Baum angezeigt.