Beim Zusammenführen der auf verschiedenen Dokumentenservern generierten und archivierten Metadaten – beim Prozess der Aggregation – ergibt sich die Frage, wie die eingesammelten Daten für die Schaffung eines gemeinsamen Datenraumes vergleichbar gemacht werden können. Open-Access-Netzwerk hat für dieses Themenfeld häufig den Begriff „Harmonisierung“ verwendet. In diesem Artikel soll dies näher betrachtet werden.
Metadaten und Metadatenformat
Zur Begriffsklärung vorweg: Die Metadaten eines Dokumentes sind ein semantisches Konstrukt. Es sind Eigenschaften, die das Dokument, sowie den Kontext seiner Entstehung und Verbreitung, beschreiben. Bibliothekarisch gesehen ein ganz alter Hut, unabhängig von der elektronischen bzw. digitalen Welt gewachsen und gereift. Um interoperabel zu werden, um Vergleichbarkeit zu schaffen, wurden und werden Standards geschaffen. Formal abgebildet ergibt sich daraus ein Datenmodell und aus dem Datenmodell eine Syntax. Ein Informatiker würde sagen, man einigt sich auf eine Grammatik, d. h. auf ein Format für die Metadaten, um sie durch einen strukturierten Symbolstrom abbilden zu können.
So, und da fangen die Probleme an. Wie umfangreich will bzw. kann man die Dokumente beschreiben? Welches Datenmodell bzw. Metadatenformat wende ich an? Ist es mächtig genug, um die zu erfassenden, semantischen Beziehungen abzubilden? Wie werden die formatierten Daten möglichst verlustarm zwischen verschiedenen, technischen Umgebungen übertragen? Und ist das, was der Aggregierende am Ende aus Symbolstrom und Datenmodell semantisch als Aussage ableitet, wirklich das, was der Erfasser ursprünglich intendiert hat?
Schwierig. Halten wir uns zuerst an die konkreten Fakten: Der gemeinsame Nenner, mit denen die Datenerfasser (die Dokumentenserver) und die Datenzusammenführer (z. B. Open-Access-Netzwerk) ihre Metadaten austauschen, ist (zumindestens hier in Deutschland) noch immer das Metadatenformat „Dublin Core Simple„. Einige Server bieten auch alternative Formate an, aber nicht alle. Welches Format auch immer konkret eingesammelt und verarbeitet wird, es muss irgendwie „ins System“. Also muss es ein Datenmodell geben, was die von außen kommenden Datensätze aufnimmt.
Internes Metadatenformat und Objekterfassung
Die Technik von Open-Access-Netzwerk ist so beschaffen, dass alle ankommenden Daten in ein Internes Metadatenformat gespeichert werden. Das bedeutet wiederum, dass die Harmonisierung in diesem Speicherschritt stattfindet. Da das Filterungen und Interpretationen bedingt, die möglicherweise Information verwerfen, weil sie nicht auswertbar ist, haben wir Harvesting und Aggregation auf separate Komponenten verteilt. Der Datensatz wird zuerst im Originalformat bezogen und einem Objekt innerhalb unseres Systems zugeordnet (bzw. ein neues Objekt erstellt). Dabei wird genau der Datensatz unverändert als BASE64-Blob gespeichert und sein Bitstrom gegen Zeichensatzverluste konserviert. Die Aggregation, die Umsetzung ins Interne Metadatenformat, findet erst in einem Folgeschritt statt.
Im Vorübergehen haben wir jetzt einen wichtigen Punkt gestreift: Wie ist die Datenhaltung strukturiert bzw. was ist ein Objekt? Ein Objekt in Open-Access-Netzwerk ist immer genau das, was ein Datensatz abbildet. Im günstigsten Fall ist das genau ein Dokument. Wie genau der Dokumentbegriff zu fassen ist und welche Ausnahmen dabei in der Praxis auftreten, führt in eine tiefere Diskussion. Halten wir an der Stelle einfach fest, dass ein Objekt einem Datensatz entspricht und dieser Datensatz in der Mehrheit aller Fälle genau ein Dokument (eine Publikation) beschreibt.
Um nun aus dem registrierten Metadatensatz im Originalformat einen Datensatz des Internen Metadatenformats zu aggregieren, setzt Open-Access-Netzwerk eine eigene Software-Komponente als Aggregator ein. Diese ist so implementiert, dass später neben Originaldaten in Dublin Core Simple auch andere Formate geparst werden können. Aktiv ist jedoch im Moment nur ein Interpreter für den besagten, gemeinsamen Nenner Dublin Core Simple. Alternative Formate in den Prozess einzubeziehen, machte momentan nur Sinn, wenn man dadurch mehr Datensätze aufnehmen könnte. Das ist nicht der Fall. Einfach alternative Formate für bereits durch Dublin Core Simple beschriebene Objekte auszuwerten, stellt die Frage, wie beide (gewissermaßen konkurrierende) Formate in eine gemeinsame Beschreibung (das Interne Metadatenformat) abgebildet werden. Dafür gibt es noch kein zufriedenstellendes Lösungskonzept.
Harmonisierung = Informationsverlust? Smart Up!
Wie bereits angedeutet, ist der große TradeOff bei der Aggregation, die Balance zwischen „Was verwerfe ich, weil es für mich Rauschen bzw. Abweichungen zum erwarteten Standard darstellt?“ und „Was bewahre ich zusätzlich, auch wenn noch unklar ist, wozu ich es später parallel zu den benutzten Standards als Information habe?“
Man muss sich klarmachen, dass wenn wir sagen, wir beziehen einen Metadatensatz in Dublin Core Simple, dann haben wir zum Zeitpunkt der Aggregation ein XML-Dokument, welches in seinen Elementen die Metadatenfelder benennt und ihre Werte mit Zeichenketten ausdrückt. Was in diesen Zeichenketten steht, ist jetzt die große Frage. Weder bildet das XML-Schema ab, welche Kodierung für die Zeichenkette gilt, um von diesem primitiven Datentyp z.B. auf eine Datumsangabe zu kommen, noch welches Datum hier semantisch erfasst wurde. Erstellungsdatum des Dokuments? Publikationsdatum? Datum der letzten Änderung? Komplexere Formate wie Dublin Core Qualifed machen sich genau über diese beiden Punkte mehr Gedanken. Deren Datenmodell ist komplexer, ausdrucksmächtiger. Aber auch daran hängen im Grundsatz die selben Fehlermöglichkeiten, ganz zu Schweigen von der Problematik der Altbestände, die „unschärfer“ beschrieben sind.
Im Umfeld des besagten Dublin Core Qualifed wird bisweilen der Begriff des „Dumb-Down“ verwendet. Er adressiert das Problem unterschiedlich detaillierter Metadaten und wie man damit umgeht. Bei Open-Access-Netzwerk stellen wir den Gedanken auf den Kopf. Wir machen gewissermaßen ein „Smart-Up„. Fakt ist, wir wollen bei der Harmonisierung Daten nicht einfach umschreiben, und damit vielleicht Informationen verlieren oder falsche Interpretationen einbauen, sondern Daten mit Mehrwerten anreichern. Die Metadatenfelder im Internen Metadatenformat sind daher – auch wenn das Konzept in der vorliegenden Implementierung noch nicht perfekt überall eingehalten wurde – kleine „Smart-Up„-Container aus Originalwert und harmonisiertem Wert.
Der harmonisierte Wert darf dabei leer sein, wenn er nicht sinnvoll ermittelbar ist. Der Originalwert wird nicht mit einer Interpretation überschrieben und bleibt für alternative Deutungen mundgerecht zugreifbar. Vor allen Dingen kann man ihn einem menschlichen Nutzer wieder zur Anzeige bringen, der kann damit vielleicht intellektuell noch eine Mehrinformation herauslesen.
Mal ein Beispiel: Sprachkennung
In Dublin-Core-Simple-Metadatensätzen gibt es ein Feld „language„. Da soll in der Regel semantisch vermerkt sein, in welcher Sprache der Volltext vorliegt. Faktisch ist es jedoch eine Zeichenkette beliebiger Kodierung. Beim Aggregator kommen also wild gemischt natürlich sprachliche Begriffe, Kürzel konkurrierender Kodierungsstandards oder einfach falsch eingetragene oder falsch übertragene Kodierungen an. (Ja, auch die OAI-PMH-Schnittstelle kann die in der Datenbank eines Dokumentenservers abgelegten Werte falsch in den „Container“ des auszuliefernden Metadatenformats einfügen. Solche serienmäßigen Fehler kann man jedoch im Gegensatz zu Ungenauigkeiten der initialen Metadaten-Erfassung leicht identifizieren und abstellen.)
Open-Access-Netzwerk möchte das Metadatum der Sprachkennung gerne mit einer ISO-standardisierten Kodierung notieren. Das ist in dem Fall ISO-639-2, ein eindeutiger, dreibuchstabiger Code, dessen Interpretation in der Zuordnung zu einer Sprache weltweit nachlesbar ist. Für die Sprache „Deutsch“ gibt es das ISO-639-2 Kürzel „deu“. Ist in einem Wert also die Zeichenkette „Deutsch“ enthalten, soll auf „deu“ abgebildet werden. Leider gibt es im Standard auch den alternativ gültigen Wert „ger“. (Einige wenige Sprachkennungen haben nämlich nach terminologisch (ISO 639-2/T) und bibliografisch (ISO 639-2/B) synonyme Werte. Aber das kann man ja abbilden.)
So, ignorieren wir Case-Sensitivität, bilden zweibuchstabige Codes (ISO 639-1) auf die höhere Kodierung ab, ordnen natürlich sprachliche Begriffe den korrespondierenden Kürzeln zu, dann sind wir schon einen Schritt weiter. Dank Smart-Up-Container haben wir ja später immer den Original-Wert. Bei „Deutschland“ wäre „deu“ als Wert relativ unstrittig. (Obwohl in Deutschland nicht nur deutsch gesprochen und publiziert wird und der Wert eigentlich uneindeutig ist.) Bei „Schweiz“ wäre es noch komplizierter, da man auch auf die Werte von „Italienisch“ oder „Französisch“ abbilden könnte. Allein, dass „Schweiz“ selbst ein deutsches Wort ist, könnte man als Hinweis werten. Doch da endet die implementierte Heuristik unserer Harmonisierung. Am besten würde hier eine nachgeschaltete Sprachprüfung des Volltextes helfen, die die Werte zusätzlich am Volltext nachprüft, anstatt sie nur zu harmonisiseren.
Der Vollständigkeit halber sei noch erwähnt, dass auch die Spezialwerte des Standards verwendet werden: Mit mul (von englisch multiple languages für „mehrere Sprachen“), der für die Auszeichnung mehrerer Sprachen gedacht ist, wenn eine Kennzeichnung durch alle einzelnen Kennungen nicht angebracht ist, sowie und (von englisch undetermined für „unbekannt“) für eine nicht identifizierbare Sprache gibt es zwei besondere Kennungen. Mit mis kann man angeben, dass die Kennung generell fehlt, und sie nicht einfach weglassen. Das grenzt Leerkennungen von bloßen Fehlern ab.
Andere Beispiele sind Datumswerte, die nach ISO8601 normiert werden müssen, oder die Dewey-Dezimalklassifikation (DDC), die mit den Set-Strukturen der OAI-PMH-Records übertragen werden. Nicht alle Set-Strukturen sind sofort als Wert von DDC, DNB oder DINI-Standard interpretierbar und werden ggf. als „OtherClassification“ aufbewahrt. Die Volltextlinks, die aus den Identifiern gezogen und dahingehend überprüft werden, ob sie zu einem vermutlich zugehörigen Volltext führen, schlagen in die gleiche Kerbe. Wie gesagt, Open-Access-Netzwerk wirft nach Möglichkeit nichts weg. Anreicherung ist die Prämisse.
Das Problem an der Wurzel packen – DINI-Zertifizierung
Die handfesten Erfahrungen mit den ankommenden Daten zeigen, dass man an vielen Stellen Hand anlegen kann, um die Qualität der Metadaten zu erhöhen und dass Forschung und Entwicklung (s. Testbett-Aspekt) in Fragen der Harmonisierung noch Fortschritte erzielen kann. Verglichen mit Projekten, die sich auf ganz andere Datenquellen bzw. ein viel größeren Datenraum stützen, hat Open-Access-Netzwerk eine ganz entscheidende Erleichterung: Die DINI-Zertifizierung.
Die OAI-PMH-Schnittstelle wird kontrolliert, Dublin Core Simple ist als gemeinsamer Nenner Pflicht, es gibt Empfehlungen, welche Werte wie auszufüllen sind, Klassifikationen werden per Set-Struktur übertragen. Das alles macht das Leben als Aggregator so viel leichter. Wenn man jemals zu komplexeren Formaten als Dublin Core Simple kommen will, muss man schon an dieser Stelle beginnen, Richtlinien zu schaffen und vor allen Dingen eine organisatorische Infrastruktur schaffen, um diese Richtlinien einzuhalten und in Hinblick auf zukünftige Entwicklungen auszubauen. Auch da setzt Open-Access-Netzwerk immer wieder an. Das Netzwerk ist eben nicht nur – auch wenn es durch die technische Orientierung des Autors oft den Anschein haben mag – eine technologische Infrastruktur.
Eines der großen Ziele für kommende Projektphasen soll daher auch sein, den Bezug der neuen DRIVER Guidelines für Content Provider zum DINI-Zertifikat besser zu klären. Ein großer Abschnitt darin (Kapitel S.52) befasst sich mit der immer wiederkehrenden Thematik, wie Dublin Core Simple denn zu benutzen und günstigerweise strikter zu handhaben ist. Auch wenn hier bisweilen noch einige DRIVER-spezifische Zusatzannahmen getroffen werden, die gerade auch im Kontext des DINI-Zertifikates diskutiert werden müssen: Dieses Kapitel sollte jeder Data Provider einmal gelesen haben! Es beantwortet wichtige Fragen. Bei der Implementierung der Harmonisierung lag eine gedruckte Version immer neben den Begleitempfehlungen zum DINI-Zertifikat griffbereit.
Weiterführende Gedanken
Zuletzt noch ein paarAnmerkungen, die in die Thematik der Harmonisierung hineinspielen. Einerseits möchte ich den, meiner persönlichen Meinung nach sehr mächtigen (wenn auch sehr aufwändigen) Ansatz erwähnen, die Methoden der Harmonisierung repositorienabhängig zu gestalten. Meines Wissens nach zielt DRIVER darauf ab bzw. ist bereits an der Umsetzung einer solchen Aggregation. Anstatt einer gemeinsamen Heuristik für alle Datenquellen, kann man in DRIVER angeblich jede Datenquelle einzeln durch Mapping-Dateien „finetunen“. Fündig wird man wohl unter dem Begriff „transformation rules“. Ein guter Ansatz, und auf paneuropäischer Ebene (ohne die Erleichterungen der DINI-Zertifizierung) wahrscheinlich unumgänglich. Open-Access-Netzwerk stützt sich eher auf das Prinzip der Anreicherung, so dass im Datenknoten möglichst viele Daten erhalten bleiben.
Als Zweites stellte sich im Zuge der Implementierung die Frage, ob jemals konkret durch ein Projekt untersucht wurde, wie man bereits durch die Gestaltung der Technologien der Dokumentenserver während der Erfassung Fehler minimieren und Standard-Einhaltung anregen, wenn nicht gar forcieren kann. Warum – ganz ketzerisch gefragt – ist es überhaupt möglich, in ein Feld, das eine Sprachkennung aufnehmen soll, Freitext einzufügen? Warum gibt es da nicht serienmäßig eine Auswahlbox für ISO-Werte? Wenn unbedingt Freitext gewünscht ist, dann nur als optional auszufüllender Zusatz zum Striktwert. Das gleiche gilt für viele andere Werte. Ein optionaler (in der Repository-Software zuschaltbarer) strikt-Modus für die Eingabe-Oberflächen würde bereits dort die Datenqualität erhöhen.
Unterm Strich wäre es wirklich spannend zu erfahren, wo und wie die Fehler eigentlich entstehen und wie man Guidelines und Empfehlung dem Erfassenden zum Zeitpunkt der Ersteingabe wirklich präsent und praktisch umsetzbar macht. Mensch-Maschine-Interaktion ist doch kein neues Themenfeld. Da gibt es etablierte Methoden und Leute, die sich damit auskennen.
(-rm)
Open-Access-Netzwerk 