Kurze Einführung in die Semantic Web Standards

OA-Netzwerk startet eine Blogreihe zum Thema „Pragmatische Lösungsansätze für automatisierte Linked Open Data Dienste für Open Access Repositorien am Beispiel von OA-Netzwerk“. Die Blogreihe beginnt mit einer Einführung in die Standards und Semantic Web Technologien und konzentriert sich später auf die konkreten Lösungenansätze und deren Umsetzung im OA-Netzwerk-Kontext.

Standards für das Netz der Daten 

Der Aufbau eines funktionierenden globalen semantischen Netzes ist auf die Anwendung einheitlicher Standards angewiesen. Schon seit den frühen 90’ger haben zahlreiche Arbeitsguppen unter dem Dach des World Wide Web Consortium an die Lösungen zur Erarbeitung der notwendigen Standards getüftelt. Somit wurde im Jahre 1999 mit der offiziellen Veröffentlichung des ersten Semantic Web Standards – das Resource Description Framework – der Grundstein zur globalen semantischen Vernetzung gelegt. Es folgten weitere Bausteine wie das RDFS, OWL und OAI-ORE. Diese Standards schafften die Voraussetzungen für den Aufbau eines angereicherten semantischen Netztes im WWW. Heute existieren zahlreiche Softwarelösungen und Tools, die auf diese Standards aufegbaut sind.

1.   Resource Description Framework
Der Grundbaustein vom Linked Data ist das Resource Description Framework, kurz RDF. RDF ist das W3C Standardpackage für die Modellierung von Informationen über Objekte. Laut RDF werden alle Web-Ressourcen durch eindeutige (URIs) identifiziert. Das RDF-Modell ist ein auf formale Semantik graphenbasierendes einfaches Datenmodell. In RDF werden Aussagen über Ressourcen als einfache sprachliche Triple modelliert. Das Subjekt ist die Ressource über die eine Aussage getroffen wird, das Prädikat ist die Eigenschaft oder Erläuterung des Subjektes und das Objekt ist das Argument bzw. den Eigenschaftswert des Prädikates. Eine Menge solcher RDF-Tripel ist ein RDF-Graph. Die Beziehungskante ist im RDF eine gleichwertige Informationseinheit, die keinem der beiden Knoten hierarchisch untergeordnet ist, was den Unterschied zu einem XML-Dokument ausmacht. Tripeln können beliebig zusammengefügt werden und somit Teil eines globalen semantischen Graphen werden, die dadurch miteinander kombiniert und weiterverarbeitet werden können. Durch RDF sollen Anwendungen in die Lage versetzt werden, Daten im Web Auszutauschen, ohne dass ihre ursprüngliche Bedeutung dabei verloren geht. Durch die formale Repräsentation in RDF sind Informationen von Maschinen auswertbar. Dadurch sind sie maschinell durchsuchbar (z. B. mithilfe der Anfragesprache SPARQL) und implizit vorhandene Informationen können durch den Einsatz von genaueren Spezifikationen des modellierten Bereichs, z. B. mithilfe von RDF-Schema (RDFS) oder der Web Ontology Language (OWL) maschinell erschlossen werden, obwohl die Information nicht explizit vorliegt. Das RDF-Schema ist die Schemasprache für RDF und liefert neben der Informationen über Daten auch Informatioenen über deren Semantik. RDFS ermöglicht die Beschreibung von Ressoursen, die in Relation stehen und die Beziehungen zwischen dieser Ressoursen. RDF Schema ist RDF/XML serialisiert. Weitere RDF Notationen sind N3, N-TRIPLE und Turtle.

2.  Object Reuse and Exchange
Ein weiterer Standard, der die Zusammenführung und die eindeutige Identifizierung von verteilten Web-Ressourcen unterstützt ist die ORE-Spezifikation der Open Archives Inititive. Diese wurde von Herbert Van de Sompel und Carl Lagoze entwickelt und im Oktober 2008 vom W3C-Konsortium als Standard- Spezifikation in der Version 1.0 veröffentlicht. ORE ist eine Erweiterung vom OAI-PHM Standard, um die Binnenstruktur von digitalen Objekten in Repositorien und die Verknüpfungen zwischen ihnen abzubilden. Die Dokumentstruktur von digitalen Objekten in Repositorien kann aus verschiedenen Versionen und Formaten bestehen. Der Volltext kann in PDF und HTML vorliegen. Die Metadaten des Objektes können z.B. in RDF-Form existieren. Desweiteren kann ein digitales Objekt unterschiedliche Teile wie Kapitel, Bilder und Dateien bein- halten. Es können Verknüpfungen zu anderen Objekten in Form von Zitationen oder Versionierungen existieren. Die Gesamtheit dieser Ressourcen wird im ORE als Aggregation bezeichnet. Die Grundideel von OAI ORE ist es, mittels URIs die Binnenstruktur der Aggregation – d. h. die Beziehungen, die aus den einzelnen Objekten eine Aggregation machen – zu identifizieren und gleichzeitig die Komponenten und Grenzen der Aggregation zu beschreiben. Das Ziel von ORE ist diese Binnenstruktur eines Dokumentes maschinenlesbar zu machen und in einer Resource Map abzubilden. Somit wird der Austausch und die Nachnutzung von digitalen Objekten und deren Aggregationen ermöglicht. Digitale Objekte werden mittels URIs eindeutig identifiziert, um Interoperabilität auf Objektebene zu schaffen. Durch die Objektidentifikation wird das Wiederverwenden und veränderte Zusammensetzen von publizierten Inhalten vereinfacht. Um diese Standards anzuwenden bedarf es ein domänenespezifisches Vokabular mit der dazugehörigen Grammatik bzws. Ontologie, die es möglich macht eine standardisierte Lösung für die Vernetzung heterogener Datenprovider im kulturellen Bereich zu etablieren. Dies ist das Ziel vom Europeana Datenmodell.

3.  EDM
Das Europeana Datenmodell (EDM) ermöglicht den Erhalt der Originaldaten und erreicht dennoch Interoperabilität der Daten. Um eine Datenintegration und Kontextualisierung zwischen Europeana und OA-Netzwerk zu erreichen werden folgende Maximalziele als notwendige Bausteine einer Semantic Web Applikation im OA-Netzwerk verfolgt. Erstellung Semantischer Resource Map und Mapping der Metadatensätze nach RDF bzw. RDFS in RDF/XML-Syntax. Unter Berücksichtigung des Europeana Datenmodells (EDM) werden die RDF-Tripels idealerweise in einen RDF-Triplestore gespeichert. Der Zugriff auf den Triplestore wird durch eine SPARQL-Schnittstelle ermöglicht und bereit gestellt. Die RDF-Triples können so als Linked Open Data im Semantic Web freigegeben werden. Um diese Ziele zu erreichen und korrekte semantische Beziehungen der Metadatensätze zu identifizieren wären ideallerweise Zusatzangaben seitens der lokalen Repositorien notwendig. Eine dezentrale Lösung auf Repositirienseite für eine semantische Anreicherung der Daten wäre erstrebenswert ist aber in der Projektlaufzeit nicht realisierbar. Daher wird derzeit eine zentrale Lösung zur Kontextualisierung und semantischer Anreicherung der geharvesten und aufbereiteten Dublin-Core-Metadaten erarbeitet. Dabei wurde die Ontologie vom Europeana Datenmodell als eine übergreifende universelle Datenstruktur berücksichtigt.

Fortsetzung folgt…

Advertisements

Aggregation und Harmonisierung

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)