Datenanreicherung auf LOD Basis

Datenanreicherung auf LOD-Basis

Kontext zur Kataloganreicherung

Lizenz:creative commons by

Titel: Datenanreicherung auf LOD-Basis

Artikel erschienen in:“(Open) Linked Data in Bibliotheken”

Herstellungsdatum: 2013-09-11

Autor: Pascal Christoph

Keywords: Linked Data Semantic Web Bibliothekswissenschaft Elektronische Bibliothek Katalogisierung Metadatenmodell


Motto: „ Access to information is not so much of an
issue anymore, but rather aggregation and contextualisation of data and
information and thus knowledge enabling . And with knowledge on their
agenda libraries are back in the role they once had, before the advent
of printing.“1

Inhaltsverzeichnis:

  1. Einleitung
  2. Definition von Kataloganreicherung
  3. Lizenzen
  4. Drei Formen der Kataloganreicherung
    1. Bloße Verlinkung
      1. Nachteil
      2. Vorteil
    2. Dynamische Kataloganreicherung
      1. Nachteil
      2. Vorteil
    3. Datenübernahme
      1. Nachteil
      2. Vorteil
    4. Resümee
  5. Provenienz
  6. Vokabular
  7. API
  8. Laborbericht: Kataloganreicherung in lobid-resources
    1. Software zur Verknüpfung: Silk
      1. Vorteil von Silk
      2. Nachteil von Silk
      3. Konfiguration für das Matching
      4. Verknüpfungsergebnisse von Silk
    2. Postprozessierung
    3. Speicherung
      1. Vokabular
      2. Arten der Anreicherung
      3. Provenienz
      4. Datenintegration via API
  9. Ausblick
  10. Quellen

Einleitung

Immer weniger Metadaten werden in Bibliotheken erstellt: Metadaten kommen nehmend von Verlagen, aus großen Systemen wie z. B. Ex Libris’ Alma oder OCLCs Worldshare, und potentiell aus Crowdsourcing-Projekten wie OpenLibrary2, oder zukünftig Wikidata3.
Bibliothekare werden daher in Zukunft eher „Information Broker“ denn „Information Provider“ sein, d. h. die Aufgabe wird eher darin bestehen,
Kontexte zu (Titel- und Norm-)Daten herzustellen als diese gänzlich neu zu erfassen. Die (aktive) Herstellung von Kontext bzw. der (passiven) Ermöglichung von Kontextherstellung durch andere kann als Kataloganreicherung einen Mehrwert bei der Recherche mit sich bringen:
Ein Buch, das häufig in den 1990er Jahren von Linguisten zitiert wurde, hat eben eine wichtige Bedeutung für die Linguistik der 90er Jahre.

Doch wozu ist Kataloganreicherung überhaupt wichtig?

Die originäre Aufgabe bibliothekarischer Daten besteht in der Unterstützung des Menschen, relevante bibliographische Ressourcen aufzufinden. Wenn bibliothekarische Daten mit zusätzlichen Daten angereichert werden, dann kann diese Aufgabe unter Umständen besser erfüllt werden. Zusätzliche Schlagwörter oder Tags machen ein Dokument besser recherchierbar – sei es durch Erweiterung des Suchindexes oder der Möglichkeit mittels Facetten durch die Ressourcen zu „browsen“. Deshalb ist ein Desiderat der Bibliothekswelt die Kataloganreicherung.

Die Anreicherung von Katalogdaten findet statt durch Datenverknüpfungen, z. B. zu Klassifikationen, Inhaltsverzeichnissen, Cover-Bildern und zu Kontexten (z.B. (domänenspezifische) Referenzierungen4, Ausleihhäufigkeit usw.) . Das schon im Begriff von Linked Open Data (LOD) steckende Wort „linked“ (also: „verknüpft“) legt nahe, dass die Vorhaltung bibliographischer Metadaten in Form von Linked Data prädestiniert ist, um Kataloganreicherung durchzuführen.

Durch Linked Open Data ist es aber nicht nur möglich Daten zu konsumieren (und damit den eigenen Katalog anzureichern), vielmehr ist die Basis von LOD das Publizieren der Daten. Ein Seiteneffekt dieser Art der Arbeit an den eigenen Daten ist die Steigerung ihres Wertes, da sie dadurch in größeren und in ganz anderen Zusammenhängen als der Bibliothekswelt gebraucht werden können. Als LOD exponierte Daten können wiederum von anderen konsumiert werden und sich mit deren Datentöpfen verbinden.5 Geschieht dies wiederum auf Basis von Linked (Open) Data, dann lassen sich diese von anderen erzeugten Verknüpfungen prinzipiell wieder rekonsumieren:
Es kann sich also (bis zu einem gewissen Sättigungsgrad) ein sich selbst verstärkender Kreislauf der wechselseitigen Datenanreicherung entwickeln.

Dieser Beitrag beleuchtet einführend theoretische Aspekte, die im Zusammenhang mit Kataloganreicherung auf Basis von Linked (Open) Data wichtig sind. Danach wird anhand des hbz LOD-Services lobid.org beispielhaft gezeigt, wie bibliographische Datenauf Basis anderer LOD-Quellen angereichert wurden. Neben diesen konkreten, praktischen Erfahrungen, die das hbz mit lobid.org gesammelt hat werden begleitend theoretische Aspekte beleuchtet und ein Blick in die Zukunft geworfen.

Definition von Kataloganreicherung

Die Wikipedia definiert: “Mit Kataloganreicherung (englisch catalog enrichment) werden Einträge eines Bibliothekskatalogs um weiterführende Informationen ergänzt, die über die reguläre Formal- und Sacherschließung hinausgehen.“6
Dazu gehören also beispielsweise Inhaltsverzeichnisse und -angaben, Rezensionen, Volltexte, Coverabbildungen und zusätzliche Schlagwörter. Dabei spielt es im Prinzip keine Rolle, ob die Daten maschinell oder intellektuell, von einer Bibliothekarin oder durch Crowdsourcing von einem Studenten
angefertigt wurden.7Die
sogenannte „Query Expansion“, bei der die Sucheingaben des Benutzers erweitert werden durch Hinzuziehen etwa eines Thesaurus’ oder Synonymwörterbuchs, zählt an dieser Stelle (im Gegensatz zu der Wikipediadefinition: „Die so genannte Query Expansion,[...] die Erweiterung der Benutzeranfragen durch zusätzliche semantische Ressourcen (Thesaurus, Ontologie,[...]) ist eine weitere Option.“8) nicht als ein Mittel zur dynamischen Kataloganreicherung: „Katalog“ wird hier katalogsdatenzentriert verstanden, d. h. ein Kopieren der Katalogsdaten (also Texte oder Links) muss genügen um die Daten präsentieren zu können . Da die vom Benutzer eingegebenen Suchbegriffe nicht Teil dieser Katalogsdaten sind reichern sie auch nicht den Katalog an – sie reichern lediglich die Suchanfrage an.

Lizenzen

Nicht immer ist die Entscheidung für oder wider eine der drei im folgenden Kapitel beschriebenen Anreicherungsarten freiwillig – die Auswahl einer Nachnutzungform kann etwa rechtlichen oder technischen Beschränkungen unterliegen. Ist – z. B. wie in LibraryThing – das Verwenden von Teilen der Daten nur in einem nicht-kommerziellen Rahmen erlaubt9, so ist die Datenübernahme in einen LOD-Dienst nicht möglich10,
lediglich der Link zu einer Ressource darf gespeichert werden. Sind die
Daten hingegen frei verwendbar wie z. B. die Public- Domain-Daten der
Open Library11,
dann dürfen die Daten in jedes Anwendungsszenario integriert werden.
Alleine aus lizenrechtlichen Gründen wird es wahrscheinlich in einem
komplexeren LOD-Portal eine Mischung aller drei im folgenden Kapitel
beschriebenen Szenarien geben.

Drei Formen der Kataloganreicherung

Werden Daten angereichert, kann dies entweder
lediglich durch Speichern von Referenzen geschehen (z. B. durch einen
Link zu einem Inhaltsverzeichnis) oder/und durch direkte Verspeicherung
der durch diese Referenzen erreichbaren Neudaten (z. B.
Inhaltsverzeichnisse in maschinenlesbarer Textform). Im Zusammenhang mit
der Lizenzbestimmung folgen drei technisch grundlegend verschiedene
Ansätze der Anreicherung, mit spezifischen Vor- und Nachteilen gegenüber
den anderen Ansätzen.

Bloße Verlinkung

Die primitiveste Form der Kataloganreicherung
funktioniert auch mit restriktiv lizensierten Daten, ist aber weit
entfernt von einer Integration der Daten in das eigene Portal und den
daran angeschlossenen Retrievalsystemen. In den bibliographischen Daten
werden lediglich URLs zu den neuen Daten hinterlegt. Diese Links lassen
sich im Portal darstellen, die Benutzerin kann diese Links anklicken und
somit durch die Daten browsen. Dadurch verlässt die Benutzerin das eigene Portal und gelangt in eine andere Anwendung.

Nachteil

Dieser Bruch der Anwendungsoberfläche wird oft als
verwirrend erfahren, u. a. weil die neue Oberfläche meist ein ganz
anderes (Navigations-)Design haben dürfte, was wiederum zu einem
Mehraufwand führt, um in der neuen Umgebung erfolgreich recherchieren zu
können. Wenn zudem in diesem neuen Portal ebenfalls Links zu anderen
Portalen führen steigt die Gefahr eines „Verirrens“ stetig, und es ist
nicht immer leicht zum eigentlichen Ausgangspunkt zurückzukehren.

Dazu ein Beispiel: folgt die Benutzerin den
Links in das fremde Portal und kann sie dort vielleicht tatsächlich eine
passende Ressource finden, so wird wahrscheinlich eine dortige
Verfügbarkeit nicht für die Bibliotheken ihrer Wahl durchführbar sein.
In diesem Fall muss durch das händische Kopieren von
Identifizierungsmerkmalen in das Ausgangsportal eine
Verfügbarkeitsprüfung angestoßen werden.

Der größte Nachteil besteht sicherlich darin,
dass über Daten, die lediglich verlinkt sind, keine integrierte Suche
stattfinden kann.12

Die genannten Nachteile zeigen, dass diese
Form der Anreicherung eine umständliche Nutzererfahrung bewirkt, weshalb
bloße Verlinkung oft suboptimal ist.

Vorteil

 

Die Einfachheit dieser Anreicherungsart ist ihr
Vorteil. Handelt sich z.B. um einen Link zum Volltext oder zum
Inhaltsverzeichnis oder ähnliches kann diese Art der Anreicherung
durchaus sinnvoll sein.

Verlinkung zwingt mich nicht, die Daten lokal zu speichern für ihre Synchronisierung zu sorgen etc.

Verlinkungen können auch zu restriktiv lizensierten
Daten erfolgen. Zudem ist diese Form der Anreicherung technisch am
leichtesten umzusetzen.

Der Link auf die Fremdressource sollte zudem auf
jeden Fall, auch bei Umsetzung der anderen Anreicherungsformen, immer
auch mit verspeichert werden, da er grundlegend für die Rekonstruktion
der Provenienz (also der Herkunft) der Daten ist.13

 

Dynamische Kataloganreicherung

Wie im Szenario „Verlinkung“ werden in den
bibliographischen Daten lediglich HTTP-URIs zu den neuen Daten
hinterlegt. Liegt hinter diesen URIs direkt ein konsumierbares Objekt (z.B. ein Textdokument, ein PDF oder ein Bild) oder eine strukturierte Quelle (wie etwa RDF)14),,
dann lassen sich diese externen Datenquellen dynamisch, also zur
Laufzeit generiert, konsumieren, indem sie etwa durch ein Javascript Mashup in das eigene Portal eingeblendet werden,.15

Nachteil

Da die Daten extern gespeichert sind, können sie nicht in eigene Suchindexe eingespielt werden. Viele
Dienste, die ein Kopieren und Verspeichern ihrer Daten verbieten,
erlauben aber dynamische (Such-)Abfragen durch Bereitstellung einer API.
Ist z.B. ein SPARQL16 Endpoint17
verfügbar, so lassen sich sog. Federated Queries über diese HTTP-URIs
absetzen – dabei werden mehrere Endpoints in einer einzigen Suchanfrage
gleichzeitig abgefragt. Die Ergebnisse lassen sich dann ebenfalls
dynamisch in die Benutzersicht einblenden.Auf diese Weise kann über Daten gesucht werden, obwohl sie nicht in einen lokalen Index eingespielt werden dürfen.18 Aus Performanzgründen sollte sich bei Anwendung dieser Technik allerdings auf das Suchen über URIs beschränkt werden19, eine Suche steht also nur eingeschränkt zur Verfügung.20

Aus dem gleichen Grund, nämlich dem Fehlen der
Daten in einem lokalen Suchindex, gibt es normalerweise keine
Facettierung ohne Portalgrenzenbruch. Diesem Umstand kann wiederum mit
einer API begegnet werden.21

Da die Daten immer aktuell bei Anfrage
abgeholt werden, entfällt der Aufwand von Updates. Es besteht jedoch die
Gefahr bei einer eventuellen Umstellung der Datenstruktur oder gar bei
einem Ausfall des Services des Fremdanbieters, dass zeitgleich die Daten
im eigenen Portal nicht mehr ordentlich dargestellt werden. Zudem kann
die dynamische Integration zu spürbaren Performanzeinbußen führen.

Der Datenintegrationsaufwand liegt nicht im Backend, sondern auf Seiten des Portals (siehe dazu das Kapitel „Datenintegration“).

 

 

Vorteil

Da die Daten immer aktuell bei Anfrage abgeholt werden, entfällt der Aufwand von Updates.

Die dynamische Kataloganreicherung
funktioniert auch mit restriktiver lizenzierten Daten, die z.B. in der
weiter unten beschriebenen Form „Datenübernahme“ nicht verwendet werden
dürften.

Datenübernahme

Der durch die Verknüpfung erreichte Anschluss der
Fremddaten an die eigenen Daten wird durch eine teilweise oder
vollständige Integration der Fremddaten in den eigenen lokalen Index
vollendet.

Nachteil

Die zur Datenintegration notwendigen Arbeiten sind
mindestens ebenso hoch wie bei der dynamischen Anreicherung. Höher wird
der Aufwand , wenn eine einheitliche Feldersuche oder Facettierung über
alle Daten aus diesen verschiedenen Quellen möglich sein soll: hierzu
bedarf es, je nach Art der Vokabulare, verschiedener Mappings, um zu
einer für Facettierung oder Feldersuche notwendigen Vereinheitlichung zu
gelangen.22

Da die Daten vom Datenanbieter abgeholt werden
müssen, fällt die Aktualität der Daten mit der Periodizität der
Datenabholung zusammen. Wenn der Datenanbieter keine inkrementellen
Updates bietet, sondern lediglich Vollabzüge, dann ist bei größeren
Datenmengen eine zeitnahe Aktualisierung unmöglich oder zumindest
erschwert.

Vorteil

Im Gegensatz zur dynamischen Anreicherung sind damit
endlic auc Freifeldsuchen,Einzelfeldsuchen ufd Facetten zum explorativen
Suchen über die Fremddaten möglich,je nach dem Grad des betriebenen
Datenintegrationsaufwandes. Ein weiterer Vorteil liegt in der
Unabhängigkeit von der technischen Infrastruktur des Fremdanbieters: die
Daten können performant aus dem eigenen Backend geholt werden und einer
eventuellen Datenstrukturumstellung des Datenanbieters kann
kontrolliert begegnet werden, da die Daten lediglich periodisch abgeholt
werden.

Resümee

Vor einer Datenintegration, egal ob dynamisch oder per Übernahme, muss zuerst immer ein Blick auf die Lizenzen geworfen werden.23 Dies ist bei einer reinen Verlinkung nicht notwendig. Auch aus
Entwicklersicht ist die Beschränkung auf reine Verlinkung am
einfachsten umzusetzen. Daraus folgt für den Benutzer der geringste
Mehrwert. Aus lizenzrechtlichen Gründen führt manchmal kein Weg am
lediglich Verknüpfen vorbei. Aus der Erfahrung lässt sich aber leider berichten, dass viele Volltextlinks, Links zu Abstracts oder Inhaltsverzeichnissen keine direkten Links
zur Ressource darstellen., Sie führen oft lediglich zu einer
Landingpage (oder „Splash-Seite, also eine Webseite), auf der wiederum
der Link zur tatsächlichen Ressource hinterlegt ist.
24 Ein
Inhaltsverzeichnis lässt sich dann nicht als Mashup in das Portal
einblenden. Daraus folgt, dass auch bei den beiden anderen
Verlinkungsformen immer ein Anteil an einfacher Verlinkung mitsamt
Portalanwendungsbruch vorhanden sein wird. Außerdem ist der Link zur
Fremddatenressource obligato
risch für die Nachhaltung von Provenienzangaben und sollte deshalb auch bei den beiden anderen Formen nachgehalten werden.

Aus Anwendersicht bietet die Datenübernahme
am meisten: selbst wenn die Daten nicht zu 100% zu den eigenen Daten
passen um z. B. nahtlose Facettenintegration zu ermöglichen, so ist doch
allein die Möglichkeit, über alle Daten suchen zu können, ein Gewinn.
Die komplette Datenübernahme ist außerdem die nachhaltigste Form: Werden
die Daten, die durch die Anreicherungen gewonnen wurden (z. B. Social
Tags und Rezensionen usw. ) als Open Data wieder zurückgegeben, dann
sind sie direkt auch außerhalb der eigenen Anwendung wiederverwendbar
und tragen mit dazu bei, dass der Pool an freien Daten mit dem ihm
inhärenten Potential weiter wächst. Ein Seiteneffekt ist die redundante
Datenhaltung nach dem LOCKSS-Prinzip („Lots Of Copies Keep Stuff Save“).
Diese Form ist dafür mit dem größten Entwicklungsaufwand verbunden.

Sowohl was die Lizenzen als auch was die Technik angeht ist die dynamische Anreicherung
ein Kompromiss aus einfacher Verlinkung und kompletter Datenübernahme:
das dynamische Einbinden der Daten ist oft eher erlaubt als die
Möglichkeit alle Daten zu laden und zu verändern; und wenn es schon
keine Suchmaschinenintegration gibt, so ist doch eine Integration der
Daten in ein Portal möglich und der Portalanwendungsbruch wie bei der
reinen Verlinkung entfällt.

Aus den oben detaillierter beschriebenen Vor- und Nachteilen ergibt sich folgende, grob verallgemeinerte Kurzübersicht:25

 

 

nur Verlinkung

dynamisch

Übernahme

Lizenzbeschränkung

 

 

 

Aktualisierungsaufwand

 

 

 

Datenaufbereitung

 

 

 

Präsentationsperformanz

 

 

 

Fremdanbieterunabhängigkeit

 

 

 

Portalintegration

 

 

 

Suchmaschinenintegration

 

 

 

Tabelle 1: Kurzübersicht Vor- und Nachteile der Anreicherungsarten

Provenienz

Das Nachhalten von Informationen zur Provenienz
(also: Herkunft) der Daten ist unter verschiedenen Aspekten wichtig.
Sowohl bei der Datenhaltung in den Backends als auch bei der
Datenpräsentation im Frontend sollten nachgenutzte Daten aus anderen
Quellen von selbst erstellten, „eigenen“26
Daten unterscheidbar sein: Im Backend lassen sich z. B. besondere
Suchfelder verwenden, die eine andere Rankinggewichtung haben als die
Originärdaten27;
im Frontend ließe sich z. B. selektieren, ob (und welche)
Fremddatenquellen zur Anzeige gebracht werden sollen. Über An- und
Abschalten von Datenquellen können z. B. verschiedene Ebenen von
Verlässlichkeit oder auch von Details oder domänenspezifische
Ausschnitte erzeugt werden. Dies kann wichtig sein, da die Daten aus
sehr verschiedenen Quellen stammen können, angefangen von anderen
deutschen Bibliotheken mit einer dementsprechend hohen Authentizität,
über teilweise supervisierte Crowdsourcing-Projekte wie DBpedia und Open
Library bis hin zu privaten Webseiten auf denen Aussagen über
Katalogsressourcen vorliegen.28

Vokabular

Sollen Datenquellen angebunden werden, so muss sich mit
dem verwendeten Vokabular auseinandergesetzt werden, um die Daten
richtig miteinander in Beziehung bringen zu können. Das Vokabular ist
für zweierlei Dinge grundlegend: Zum einen gilt es – um überhaupt Daten
miteinander verknüpfen zu können – Anknüpfungspunkte zu finden, im
Idealfall sind dies Identifier wie z. B. die ISBN.29
Zum anderen müssen auch andere Daten bei der Zusammenführung, ob im
Backend oder im Frontend, in Beziehung gebracht werden, z. B. für
Facettierung. Es ist also ein Mapping von Fremdvokabular zum eigenen
Vokabular notwendig.

Die Prädikate definieren die Beziehungen von Subjekt
und Objekt. Sie sind also mindestens das, was in MARC/MAB/PICA die
Felder und Unterfelder sind. Verwenden beide Datensets die gleichen für
die Verlinkung notwendigen Prädikate, z. B. bibo:isbn30 und dct:issued
, dann ist das Mapping eine einfache 1 zu 1 Abbildung. Werden
verschiedene Prädikate verwendet, so müssen diese Prädikate erst in
Verbindung gebracht werden. Fehlt ein sog. Vocabulary Alignment (also
die Beschreibung der Beziehung unterschiedlicher Vokabulare), so muss
die Beziehung durch eigene Arbeit hergestellt werden. Ist aber schon der
Gebrauch von z. B. dct:title teilweise
unterschiedlich (z. B. mal mit, mal ohne Zusätze zum Hauptsachtitel), so
verschärft sich potentiell die Differenz bei Verwendung
unterschiedlicher Vokabulare – zumindest wird der zu betreibende Aufwand
des Vokabularmappings größer sein.. Deshalb ist es vorteilhaft für das
Datenmapping die zu integrierenden Daten mit einem geläufigen Vokabular
zu beschreiben. So ist die Wahrscheinlichkeit größer, dass die beiden
Datensets die gleichen Vokabularien benutzen und damit überhaupt die Notwendigkeit eines Datenmappings entfällt.31 Zudem ist der Gebrauch von häufig vorkommenden Vokabularien wahrscheinlich besser dokumentiert .32
Für die Datenmodellierung sind spezielle, genauere Vokabularien
natürlich besser geeignet um die Informationen zu beschreiben: z. B. ist
isbd:P1004 und isbd:P1006 für die Beschreibung der Titel genauer als ein sehr allgemein definiertes Prädikat wie dct:title. Es spricht aber nichts gegen Redundanz: in lobid.org wird sowohl das Prädikat dct:title verwendet, da es auch in nicht-bibliothekarischen Kreisen bekannt ist, als auch die genaueren isbd-Prädikate.

 

API

Eine API (englisch application programming interface (API), deutschSchnittstelle zur Anwendungsprogrammierung“) ist eine Programmierschnittstelle.
APIs können abgefragt werden und liefern eine Antwort. Somit können sie
von anderen Programmen benutzt werden. Es gibt verschiedene Typen von
Programmierschnittstellen. Die Programmierschnittstelle zum
Betriebssystem eines Computers, z.B. um Dateifunktionen (Dateien lesen,
ändern, löschen usw.) durchführen zu können, ist die älteste Form von
API. Mit Aufkommen des WWW enstand die Möglichkeit, APIs über das
Internet anzubieten, und somit jedem zur Verfügung zu stellen, der an
das Internet angebunden ist. Solche APIs werden auch Web-Services
genannt. Web-Services können z. B. programmiersprachenspezifisch sein,
d. h. , dass für ihre Nutzung eine bestimmte Programmiersprache benutzt
werden muss.33 Web-Services können oft einfach über HTTP angesprochen werden. Genügen diese APIs dann vor allem auch noch der Prämisse „[...]dass eine URL
genau einen Seiteninhalt als Ergebnis einer serverseitigen Aktion (etwa
das Anzeigen einer Trefferliste nach einer Suche) darstellt, wie es der
Internetstandard HTTP für statische Inhalte (Permalink) bereits vorsieht[...]“34 , dann heißen sie RESTful Web-Services oder auch Web-API. Die URLs lassen sich z.B. einfach im Browser aufrufen.35
Das Ergebnis des URL-Aufrufs ist unabhängig vom Zustand des anfragenden
Programms (etwa eines Browsers). Der Aufruf ist also
„Session-unabhängig“. Solche URLs lassen sich z. B. „bookmarken“ oder
jemand anderem per Mail senden.

LOD ist bereits auch eine API, nämlich eine Web-API36
(was ein Synonym für RESTful Web-Service ist). Kommen neben den basalen
Prinzipien von LOD, nämlich Dereferenzierung von HTTP-URIs und
Bereitstellung von Daten in RDF, noch die SPARQL-Technik hinzu (die
heutzutage, abhängig vom Triple Store, meist ebenso über HTTP
anwendbar), dann lassen sich Daten z. B. nicht nur lesen sondern
optional auch schreiben. Die Daten lassen sich vor allem durch
elaborierte Weise abfragen und kombinieren, sogar über mehrere SPARQL
Endpoints hinweg.37 Beispiele hierzu liefert der Laborberichts-Abschnitt „Datenintegration“.

Es spricht nichts dagegen die basale API und
die SPARQL-API durch andere APIs zu kapseln. Die Reduktion an
Komplexität geht zwar Hand in Hand mit einem Verlust an Möglichkeiten,
aber oftmals werden nur ein paar einfache Funktionen von
Frontend-Entwicklerinnen benötigt und somit deren Arbeit erleichtert.

Laborbericht: Kataloganreicherung in lobid-resources

Der hbz LOD Service „lobid.org“ existiert seit Mitte 2010. Wie der Ausschnitt aus der LOD-Cloud von 201038
in Abbildung 1 zeigt, bestanden bereits zu Anfang Verlinkungen zu zwei
anderen Datenquellen: zur GND (Verlinkung zu Personennormdaten und
Schlagwörtern) und zum Linked-Data-Index kultureller Institutionen
„lobid-organisations“39,
um Titel mit besitzenden Organisation zu verbinden. Diese Links
basierenauf den orignär im hbz-Verbundkatalog vorhandenen Daten. Die
Links zu den Organisationen leiten sich aus den Bestandsangaben im
Verbundkatalog ab, wo zu einem Titel die International Standard
Identifier for Libraries and Related Organizations (ISIL) der
Institutionen verspeichert ist, die ein Exemplar besitzen.40.

 

Abbildung 1: Ausschnitt aus der Lod Cloud 2010
 

 

 

 

 

 

Die folgenden Kapitel
erläutern Techniken zur Herstellung von Verknüpfungen zu Fremddaten und,
anhand eines Beispiels, das in lobid.org tatsächlich zum Einsatz
kommende Verfahren mit der Software
Silk . Es wird auf Matchingprobleme
und mögliche Disambiguierungslösungen eingegangen. Im Anschluss werden
Wege für die Portalintegration der lobid-Daten aufgezeigt.
Anschließend wird der Gewinn durch – und das Potential von – verknüpften Daten angerissen.

Software zur Verknüpfung: Silk

Es existieren verschiedene Werkzeuge um Datenverknüpfungen herzustellen, z. B. die Software Google Refine42, Silk43 und culturegraph44.
In lobid.org kam bisher lediglich Silk zum Einsatz. Nachfolgend werden
einige Ergebnisse einer Anreicherung mit der deutschen DBpedia
dargestellt.45

Vorteil von Silk

Neben der Verarbeitung von RDF Dumps lassen sich
mit Silk auch SPARQL Endpoints abfragen, d.h. es ist nicht notwendig
einen Vollabzug der nachzunutzenden Daten herunterzuladen. Somit sind
auch nicht-offene Linked Data einfach verknüpfbar. Ein großer Vorteil
von Silk ist die sehr gute Dokumentation und die einfache Bedienung.
Matchingalgorithmen werden hauptsächlich durch SPARQL Queries definiert,
zudem gibt es diverse „Linkage Rules“46.

Silk gibt es in verschiedenen Varianten. Für
kleinere Anreicherungen kann auf einfache Installationen zurückgegriffen
werden. Für Anreicherungen über größere Datensets gibt es komplexere
Cluster-Versionen. Zum Einsatz für die lobid Anreicherungen kam die
hadoop Variante.47

Die Konfiguration von Silk kann entweder durch
Manipulation eines XML Files geschehen oder durch Verwendung einer
Weboberfläche, der Silk Workbench. Für lobid.org Anreicherungen wurde
nicht die Workbench verwendet, sondern direkt die XML Datei angepasst.
Eine Beispieldatei folgt weiter unten.

 

Nachteil von Silk

Ein Abfragen vom lobid-SPARQL Endpoint von 16
Millionen Ressourcen dauert 40 Stunden. Auch wenn ein einmal erzeugtes
Binärfile durch einfaches Kopieren mehrmals benutzt werden kann, um z.
B. einmal mit der deutschen DBpedia und danach mit der internationalen
DBpedia usw. zu verknüpfen, so ist dies insgesamt sehr langsam und der
offensichtliche Flaschenhals bei der Herstellung der Verknüpfungen. Zum
Vergleich: das Matching der Daten dauerte gerade einmal 4 Minuten.48

 

Konfiguration für das Matching

Die triviale Feststellung „Es kann nur gematcht
werden was auch vorhanden ist.“, mündet in einem eher primitiven
Matchingalgorithmus, dessen Ergebnisse49 nachträglich mit weiteren Heuristiken verbessert werden müssen.50
Die Silk XML Konfigurationsdatei, mit der die Verknüpfungen zur deutschen DBpedia erzeugt wurden, finden sich auf github.51

Diese Konfiguration beschreibt folgenden natürlichsprachlich ausgedrückten Matchingalgorithmus:

Nimm alle Titel der deutschen DBpedia Ressourcen der Kategorie „Literarisches Werk“, wandle alle Zeichen in Kleinbuchstaben, ersetze alle Unterstriche mit einem Leerzeichen und
vergleiche diese Zeichenkette mit dem ebenfalls nach Kleinbuchstaben
gewandelten Titel aller Bücher aus lobid. Wenn beide identisch sind,
speichere die Beziehung als Triple mit dem Prädikat
rdrel:workManifested.52

Verknüpfungsergebnisse von Silk

Mit dem oben beschriebenen Algorithmus wurden ca.
28.000 Verknüpfungen zwischen lobid-Ressourcen und der DBpedia
hergestellt. Da der Algorithmus zu primitiv ist, gibt es viele „false
positives“: So haben z. B. die folgenden Ressourcen den gleichen Titel (dc:title)
„Helden“, zeigen also laut dem oben beschriebenen Algorithmus alle auf
denselben DBpedia URI, haben aber unterschiedliche Autoren:

http://lobid.org/resource/HT009535982

http://lobid.org/resource/HT013915133

http://lobid.org/resource/HT002957164

http://lobid.org/resource/HT003564841

Diese verschiedenen Ressourcen Teilen sich nun einen
gemeinsamen Identifier (die DBpedia URI) und könnten könnten deshalb
unter einer einzigen URI gebündelt werden. Dieser gemeinsame Identifier
ist aber falsch, da die einzelnen Manifestationen nicht
dieselbe Ressource identifizieren. Eine Bündelung wäre also ebenso
falsch. Für eine Bereinigung ist eine Postprozessierung notwendig.

Postprozessierung

Eine Postprozessierung zur Disambiguation baut auf
einfachen bis komplexen Heuristiken auf. Sie kann bis zu einem gewissen
Grad automatisiert erfolgen doch sollte am Ende auch immer eine
intellektuelle Überprüfung anstehen.53 Eine
einfache Heuristik ist: Ein Bündel von Manifestationen, die ein
gleiches Werk identifizieren wollen, ist dann zu verwerfen, wenn die
Ressourcen auf unterschiedlichen Autoren verweisen.54Eine
komplexere Heuristik wäre: Wenn ein Bündel mit z. B. 10 Manifestationen
besteht, wobei 9 Manifestationen den Autor A haben und nur eine
Manifestation den Autor B, dann wird nicht das gesamte Bündel verworfen,
sondern lediglich die Manifestation mit Autor B, denn es wird
angenommen ,dass je bekannter ein Werk ist, umso mehr Manifestationen
davon im Katalog vorhanden sind. Und ebenso, dass zumindest das
bekannteste Werk in der DBpedia beschrieben ist (wenn zusätzlich auch
noch die anderen (unbekannteren) Werke beschrieben sind, ist das in der
Wikipedia durch die sogenannte Disambiguierungsseite kenntlich gemacht).55

In lobid.org wurde bisher nur der oben
beschriebene einfache Postprozessierungsalgorithmus angewendet. Dadurch
schrumpfte die Anzahl der Links zur Dbpedia von 28.000 auf nunmehr
6.000.

Um eine noch größere Sicherheit bei der
Verknüpfung von Datensets zu erreichen, sollten die automatisch
hergestellten Beziehungen (oder zumindest ein durch bestimmte Kriterien
maschinell bestimmbares, „unsicheres“ Subset dieser Beziehungen)
intellektuell überprüft werden. Wenn auf intellektuelle Aufarbeitung
nicht verzichtet werden sollte, wozu ist dann eine Automatisierung
überhaupt sinnvoll ? Ganz einfach: zumindest der Schritt, der die Liste
von möglichen Beziehungen herstellt, entfällt. Diese Liste manuell
herzustellen, auf Grundlage gleichen Titels und für 16 Millionen
Ressourcen, würde ein paar Dutzend Bibliothekare ein paar Jahre
bechäftigen.56

Für diesen letzten Schritt, der
intellektuellen Evaluierung, bietet sich supervisiertes Crowdsourcing
an, also die durch z. B. einen Bibliothekar überprüfte Zusammenführung
durch die Katalogsnutzer.

Speicherung

Im Folgenden wird gezeigt mit welchen Prädikaten
die Verknüpfung zur DBpedia und Wikipedia geschieht, welche Arten der
Anreicherung verwendet werden, wie die Provenienz vorgehalten wird und
wie die Daten abgefragt werden um sie z. B. in ein Portal integrieren zu
können. (Um die Beispiele nachvollziehen zu können, ist es wichtig zu
wissen, dass das Webfrontend unter lobid.org mittels Phresnel57
gerendert wird. Phresnel ist auf Basis der Daten im Triple Store
konfiguriert und gibt nicht notwendigerweise alle Aussagen über eine
Ressource wieder. Die Beispiele funktionieren also zumindest mit dem
Triple Store, aber nicht notwendigerweise über das lobid.org Portal).

Vokabular

Es gibt eine reiche Auswahl an Verknüpfungsprädikaten, z. B. owl:sameAs wenn es sich um identische Ressourcen handelt; foaf:isPrimaryTopicOf wenn die Zielressourcen lediglich das primäre Topic der Katalogsressource ist; rdf:seeAlso für eine eher unspezifische Verbindung uvm. Im vorliegenden Fall wird rdrel:workManifested verwendet,
da die DBpedia eher eine Art Werk-Ebene als eine konkrete Manifestation
beschreibt. Auf diese Art kommt der Katalog den FRBR
58-Ebenen näher.
Da
die DBpedia auf Grundlage der Wikipeda erzeugt wird, bedeutet eine
Verknüpfung zu DBpedia immer auch zugleich eine Verknüpfungsmöglichkeit
zur Wikipedia. Das passende Prädikat haben wir aus der Music Ontology
ausgesucht.
59 Auch
wenn die Wikipedia nicht maschinenlesbar ist, so kann eine Verknüpfung
durchaus Sinn machen, da hier mehr Informationen stehen als in der
DBpedia extrahiert wurde und die Benutzerin kann sogar die
Grundlage der Katalogsanreicherung, nämlich die DBpedia, durch Veränderung der Wikipediaartikel modifizieren.60

Es folgen zwei Tripel – als Beispiel zur Verknüpfung von lobid.org Ressourcen zur DBpedia und Wikipedia:

<http://lobid.org/resource/TT002313455> rdrel:workManifested <http://de.dbpedia.org/resource/Gödel,_Escher,_Bach> .

<http://lobid.org/resource/TT002313455> mo:wikipedia <http://de.wikipedia.org/wiki/Gödel,_Escher,_Bach> .

Arten der Anreicherung

Neben
der Verspeicherung des Links ist es darüber hinaus auch lizenrechtlich
gestattet alle Daten aller direkt in lobid-resources verlinkten Quellen
in das eigene Backend zu integrieren. So könnte es z. B. zu einem Merge
mit den Daten des b3kat kommen, denn trotz Datenaustauschs der Verbünde
untereinander („Ringtausch“) und der beide Katalogeinträge als identisch
definierende „EKI“, fehlt im hbz-Katalog teilweise die
Verschlagwortung, die der b3kat vorhält.
61

In
lobid.org wurden die Daten der DBpedia-Matches bisher lediglich in den
lobid.org Triple Store eingespielt. Die Anreicherung des
Suchmaschinenindex soll noch in 2012 geschehen.

Provenienz

Die Herkunft jedes Datums (aka Triple) lässt sich in lobid.org zurückverfolgen.62 Dazu
muss unterschieden werden zwischen 1. dem Datensatz, also den die
Ressource beschreibenden Tripeln, 2. dem Datenset, also z. B. ob es sich
um Titeldaten handelt oder um das im selben Triple Store liegende
Verzeichnis kultureller Institutionen „lobid-organisations“ für
Organisationen
63 und 3. um welchen (Herkunfts-)Graphen es sich handelt. Das nebenstehende Bild veranschaulicht diese Zusammenhänge.

 

 
 
 
 
 
 
 
 
 
 
 

Abbildung 2

Zusammenhang Datensatz, Datenset und Named Graph
 

Anhand eines Beispiels wird
im folgenden gezeigt wie sich die Provenienz ermitteln lässt. Da das
Ding an sich, für die der URI steht (hier also: ein Buch), nicht direkt
durch das Netz ge
schickt werden kann wird per Content Negotiation eine Beschreibungsseite dieses Objektes geliefert: die Metadaten.64 Diese Beschreibung enthält u.a. das folgende Triple:

<http://lobid.org/resource/TT002313455> powder:describedby <http://lobid.org/resource/TT002313455/about> .

Der Objekt-URI steht für die Metadaten (im Ggs. Zu dem „Ding-an-sich“). Damit können sich nun Aussagen über Metadaten generieren lassen, z.B. :

<http://lobid.org/resource/TT0023134559/about> dct:isPartOf <http://lobid.org/dataset/resource> .

Wiederum kann dem Objekt-URI nachgegangen werden, u.a. mit dem Ergebnis:

<http://lobid.org/dataset/resource> dct:hasPart <http://lobid.org/graph/dbpedia>  

Der Objekt-URI ist ein Named Graph65. Die Metadaten zu diesem URI enthalten
die Informationen über das „Wann – Wie – von Wem“ usw. , also die
Proveninezinformationen über die Erstellung der Anreicherung, z. B.:
<http://lobid.org/graph/dbpedia/about> opmv:wasGeneratedBy _:b108c6c05000000c2 . 66

_:b108c6c05000000c2 opmv:wasControlledBy <http://lobid.org/person/pc> .

Ein
Named Graph kann wie ein Container verwendet werden: in dem DBpedia
Graph sind alle Triple eingespielt worden, die die
Titelkatalogressourcen mit der DBpedia verbinden. So
kann auf diesen Daten via SPARQL unabhängig vom Rest der Daten im Triple Store67 gearbeitet werden, als handele es sich um eine separate Datenbank.68
Somit lassen sich auch Aussagen über die Provenienz machen. Folgende
Anfrage liefert alle Triple der Beispielressource, die explizit aus dem
deutschen DBpedia- Graphen kommen:

 

curl -H “Accept: application/rdf+xml” -d ‘query=

SELECT * FROM <http://lobid.org/graph/dbpedia> WHERE {

<http://lobid.org/resource/TT002313455> ?p ?o .

} ‘ http://lobid.org/sparql/

Der hier gezeigte Weg Provenienzinformationen
zugänglich zu machen, ist sicher nur einer von mehreren, zeigt aber die
prinzipielle Möglichkeit Provenienzangaben bis auf Tripleebene
abzubilden und deutet die Wichtigkeit sowie die Möglichkeiten an, die
sich damit eröffnen.69

Datenintegration via API

Prinzipiell ist das LOD-Netz schon die API, alle Daten lassen sich RESTful
abholen. Das Antwortformat wird per Content-Negotiation bestimmt und
kann z. B. RDF-XML, Turtle, RDFa in HTML oder auch JSON sein. Hier ein
Beispiel um die Daten so zu bekommen wie es das Phresnel Webfrontend
präsentiert:

curl -L http://lobid.org/resource/HT016508950 

Dasselbe als RDF-XML:

curl -H “Accept: application/rdf+xml” -L

http://lobid.org/resource/HT016508950

usw. Um elaboriertere Abfragen zu gestalten, z. B.
um alle deutschsprachigen Bücher zu erhalten, die mit dem Hugo-Award
ausgezeichnet wurden,70 lässt sich folgende RESTFulRESTful Anfrage an den SPARQL Endpoint stellen:

curl -H “Accept: application/json” –data-urlencode ‘query=

prefix bibo: <http://purl.org/ontology/bibo/>

SELECT ?slo WHERE {

?sdb <http://dbpedia.org/ontology/wikiPageWikiLink> <http://de.dbpedia.org/resource/Hugo_Award> .

?slo

<http://rdvocab.info/RDARelationshipsWEMI/workManifested>

?sdb .

}’ http://lobid.org/sparql/

 

Das Antwortformat ist JSON und sollte sich einfach
z. B. mittels Java-Script oder serverseitige Programme in eigene
Portalanwendungen einbinden lassen.

Die hier durch curl gezeigten Beispiele lassen sich auch als Links für den Browser beschreiben, doch ist die Antwort dann immer in XML71.
Für einen Anwendungsfall „Ich schreibe eine E-Mail und möchte dort
einen Link mitteilen der alle Ressourcen auflistet die von Philip K.
Dick geschrieben wurden“72 sieht der Link wie folgt aus (es lassen sich natürlich beliebig komplexe, durch SPARQL beschreibbare Abfragen formulieren):

http://lobid.org/sparql/?query=SELECT%20*%20WHERE%20%7B?s%20%3Chttp://purl.org/dc/elements/1.1/creator%3E%20%3Chttp://d-nb.info/gnd/174660774%3E%7D

Durch die Named Graphs lassen sich die abzufragenden Daten einschränken, z. B. kann über alle Graphen außer dem
DBpedia Graphen gesucht werden um z. B. die DBpedia Daten aus einer
Anwendung auszublenden. Ebenso kann über alle Daten des gesamten Triple
Stores gearbeitet werden, als ob es keine Container gäbe. Beispiel für
eine SPARQL Abfrage die Ressourcen sucht, de
ren frbr:Work Ebene durch einen bestimmten Wikipedia-Eintrag beschrieben werden:

curl -H “Accept: text/plain” –data-urlencode ‘query=

SELECT * FROM <http://lobid.org/graph/dbpedia> WHERE {

?s
<http://rdvocab.info/RDARelationshipsWEMI/workManifested>
<http://dbpedia.org/resource/Do_Androids_Dream_of_Electric_Sheep%3F>
.

} ‘ http://lobid.org/sparql/

Trotz der relativen Einfachheit neigen
Frontendprogrammierer zum Konsum von in der Mächtigkeit stark
reduzierten Schnittstellen der folgenden Art:

http://lobid.org/ISBN-lookup/$isbn

Diese Schnittstellen geben als Antwort eine
Aggregation in einem einfachen JSON-Format zurück. Solche Schnittstellen
herzustellen ist allerdings nicht schwer: sie sind nichts weiter als
kleine Proxies für die oben genannten RESTful SPARQL Abfragen mit einer zusätzlichen Wandlung in ein einfaches JSON.7374
Die Proxies könnten aber durchaus an Komplexität gewinnen, wenn über
diese Zwischenschicht z. B. eine sich verändernde Datenbasis, etwa durch
Umbenennung der Prädikate,75
durch ein Mapping von Feldern auf die vom Konsumenten erwarteten
Feldnamen begegnet werden würde. Dies würde zudem sicherlich Arbeit
ersparen, wenn mehr als nur ein Konsument diese API verwendet, da sich
der Mappingaufwand auf den zentralen Proxy beschränkt, statt in
zahlreichen Anwendungen nachimplementiert werden zu müssen.

Da wir Linked Open Data vorliegen haben, kann prinzipiell jede Programmiererin diese einfachen Schnittstellen implementieren.

Dank Open Data lässt sich die Datenbasis
ebensogut auf die eigenen Server spiegeln und beliebig aufbereiten, z.
B. für Suchmaschinen, und somit in idealerweise in das eigene
Datenökosystem integrieren, ganz ohne die Notwendigkeit der Schaffung
einfacher Schnittstellen. Nur weil die Daten durch LOD erzeugt wurden
und als LOD zur Verfügung gestellt wurden, heißt das nicht, dass sie
nicht in eine nicht-LOD konforme Form zu bringen und zu verwenden wären.
LOD schließt das keinesfalls aus und eröffnet im Gegenteil eine große
Palette an Nachnutzungsszenarien.

Egal, ob LOD nun über LOD-Schnittstellen
konsumiert wird, ob die Daten über einfachere Schnittstellen angeboten
und konsumiert werden76
oder ob Daten direkt in eigene Datensysteme übertragen werden sollen:
weil das Ermöglichen des Konsums der Daten der eigentliche Zweck von LOD
ist, ist LOD ideal für Menschen, die Daten integrieren wollen.

Ausblick

If Content is King, then Context is Queen

Der Katalog ist für Bibliotheken wichtiger denn je. Das, was Jakob Voss über eRessourcen schreibt, gilt auch für Metadaten:

The
eResource fallacy Libraries that license eResources to be accessed from
publisher sites, limit their role to temporary, intermediary retailers.
Advice: Data that cannot be copied and modifed is lost. Libraries must
actually collect and process digital documents (or won’t be in the
document business anymore)
77
Ohne die Möglichkeit, fremde Metadaten
frei zu kopieren und den eigenen Bedürfnissen nach anzupassen, bleiben
diese Metadaten temporäre Artefakte. Zwar können Kataloganreicherungen
wie sie beispielsweise von LibraryThing und Amazon angeboten werden,
einen momentanen Nutzwert bieten; die Form der Nutzung ist jedoch in der
Regel von den Anbietern vorgegeben und damit beschränkt. Zudem steigt
so die Abhängigkeit der Bibliotheken zu Fremdanbietern
. Bleibt
der eigene Katalog ein „Rumpfkatalog“, der lediglich mit geschlossenen
Datentöpfen verbunden ist, führt das langfristig dazu, dass es
letztendlich gar keines eigenen Katalogs mehr bedarf.
78 Dies
kann durchaus gewünscht sein, um, zumindest kurz- oder mittelfristig,
Kosten zu sparen. Eine Konsequenz ist die Aufgabe von eigenen, selbst
anpassbaren Suchmaschinen und letztendlich von eigenen, speziellen
Portalfunktionalitäten. Bibliotheken wären dann nur noch
Wieder“verkäufer“ der Daten anderer: aggregierte Daten werden von
lizenzierbaren Indexe eingekauft und durch ein Portal den Kunden
zugänglich gemacht. Die Chance, selber als „Information Broker“
auftzutreten oder
jedem anderen die Möglichkeit dazu zu geben, wäre vertan. Ein unwahrscheinliches, aber nicht ganz unmögliches Szenario, ist: Alle Daten gelangen in geschlossene Datentöpfe, es entwickeln sich zentrale Gewaltstrukturen
(also:Monopole), mit den daraus folgenden Kontrollmöglichkeiten (z. B.
Präferierung im Suchmaschinenranking aufgrund von Verlagszugehörigkeit
oder politischer Ausrichtung).
79 Dieser
pessimistischen Möglichkeit der Entwicklung der Zukunft kann mit
(Linked) Open Data, dem Teilen und der Anreicherung der Daten, begegnet
werden.
Neben den direkten Verbesserungen von Katalogen durch Datenanreicherung, gibt es ein gewaltiges indirektes Potential. Dazu gehören z. B. die Schaffung einer frbr:Work-Ebene über eine Bündelung von Ressourcen, egal ob dies z. B. über die Verknüpfung mit der in Open Library vorhandenen frbr:Work-Ebene geschieht, 80 oder durch die interne Zusammenführung im eigenen Katalog (sog. Deduplizierung)81.
Durch diese maschinelle Bündelung können prinzipiell die Titeldaten der
verschiedenen Manifestationen voneinander partizipieren, um z. B.
Schlagworte zu (ver)erben.
Werden,
wie in der Einleitung angeklungen, die eigenen Katalogsressourcen von
anderen Benutzern konsumiert, z. B. in Literaturlisten oder Handapparate
(per RDFa in HTML
82 oder sogar in PDF via XMP83), dann lassen sich diese Daten rekonsumieren und an die eigenen Ressourcen anhängen, mit dem Effekt z. B. einen Impact Factor84, Ähnlichkeitsbeziehungen, Empfehlungen und einen Social Graph85 von Autoren berechnen zu können.
Durch
die LOD-Technik können Benutzer dem Datengraphen Informationen zufügen,
ohne die Datenbank, auf die sie sich beziehen, direkt ver
ändern zu müssen.86 Zukünftig werden deshalb Bücher aus der dem Internetbenutzer
nächsten Bibliothek in Online-Fernsehzeitungen als Programmbegleitung
angezeigt und die Bücher im Gegenzug mit dem Hinweis auf den sie
erwähnenden Film versehen werden.
Der
Beispiele ließen sich noch weitere aufführen. Ihnen gemeinsam ist die
dem LOD inhärenten „Win-Win-Situation“, das aus dem „Web of Documents“
ein „Web of Data“ macht und damit zum Semantic Web führt, ganz so wie es
Tim Berners Lee antizipierte.
87
Der Begriff Wissensallmende88 bringt das Ziel von LOD auf den Punkt: es wird davon ausgegangen, dass das Wissen, anders als natürliche Ressourcen, durch Gebrauch aufgewertet wird. Der Gebrauch von Daten wird sich erhöhen, wenn sich deren Nutzbarkeit und Nützlichkeit erhöht, wenn also die Daten maschinenlesbar, offen und mit anderen Daten verknüpft sind. Aus diesem Grund ist LOD ideal um die Idee der Wissensallmende für
Daten umzusetzen. Und da vor allem die Bibliotheken der Idee der
Wissensallmende schon immer verpflichtet waren (oder sein sollten), sind
sie intrinsisch motiviert diese Technik zu nutzen.

Quellen

Alle verwendeten Links dieses Beitrages sind zuletzt geprüft worden am 11.9.2012.

Berners-Lee, Tim (2006): Linked Data. Online: http://www.w3.org/DesignIssues/LinkedData.html

Brenner, Simon (2012):
LibraryThing for Libraries . Web Widgets für die Anreicherung von
Bibliothekskatalogen mit Community-generierten Daten einer Social
Cataloging-Plattform . Online:
http://www.b-i-t-online.de/heft/2012-03/fachbeitrag-brenner.pdf

Christoph, Pascal (2012): First results using SILK to link to DBpedia. Online: https://wiki1.hbz-nrw.de/display/SEM/2012/05/03/First+results+using+SILK+to+link+to+DBpedia

Christoph, Pascal (2012): 1.2 M links to Open Library. Online: https://wiki1.hbz-nrw.de/display/SEM/2012/05/23/1.2+M+links+to+Open+Library

Dodds, Leigh; Davis, Ian (2012): Linked Data Patterns. A pattern catalogue for modelling, publishing, and consuming Linked Data. Online: http://patterns.dataincubator.org/book/

Heath, Tom; Bizer, Christian (2011): Linked Data: Evolving the Web into a Global Data Space. Online: http://linkeddatabook.com/editions/1.0/

Jansen, Heiko; Christoph, Pascal (2012): Dynamische Kataloganreicherung auf Basis von Linked Open Data. Online: http://www.slideshare.net/h_jansen/dynamische-kataloganreicherung-auf-basis-von-linked-open-data

Kreutzer, Till (2011): Open Data – Freigabe von
Daten aus Bibliothekskatalogen. Leitfaden von Dr. Till Kreutzer, i.e. -
Büro für informationsrechtliche Expertise Berlin. Hbz. Online: http://www.hbz-nrw.de/dokumentencenter/veroeffentlichungen/open-data-leitfaden.pdf 

Pohl, Adrian (2012): Provenienzinformationen. Online: https://wiki1.hbz-nrw.de/display/SEM/Provenienzinformationen

Voss, Jakob (2007) : LibraryThing: Web 2.0 für
Literaturfreunde und Bibliotheken, Mitteilungsblatt der Bibliotheken in
Niedersachsen und Sachsen-Anhalt(137), Seite 12-13. Online: http://hdl.handle.net/10760/11077

Voss, Jakob (2012): Libraries in a data-centered environment. Online: http://de.slideshare.net/nichtich/libraries-in-a-datacentered-environment

Koster, Lukas (2012): Discovery tools: a rearguard action? Online: http://de.slideshare.net/lukask/discovery-tools-a-rearguard-action

Herman, Ivan; Adida, Ben; Spoprny, Manu;
Birbeck, Mark (2013):RDFa 1.1 Primer – Second Edition.Rich Structured
Data Markup for Web Documents. Online: http://www.w3.org/TR/2013/NOTE-rdfa-primer-20130822/

1 Stefan Gradmann in „From Containers to Content to Context: the Changing Role of Libraries in eScience and eResearch “ , siehe http://conference.ub.uni-bielefeld.de/programme/abstracts/gradmann.htm

2http://openlibrary.org/

3http://meta.wikimedia.org/wiki/Wikidata/de

4
Im Linked Data Netz kann gezählt werden, wie viele Ressourcen die
eigene Ressource referenzieren. Die Menge der Referenzierungen ist
alleine schon eine neue Information. Werden jetzt diese Referenzierungen
auch noch der Ursprungsdomäne aufgeschlüsselt, z. B. nach
Universitätswebseiten oder Fernsehwebseiten, dann kann der bloßen Menge
an Referenzierungen weitere semantische Aussagen hinzugefügt werden.

5 siehe auch den Beitrag in diesem Sammelband „Open Data und Linked Data in einem Informationssystem für die Archäologie“ von Maike Lins und Hans-Georg Becker

6 Seite „Kataloganreicherung“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 5. Juli 2012, 12:41 UTC. URL:

http://de.wikipedia.org/w/index.php?title=Kataloganreicherung&oldid=105215379 (Abgerufen: 5. Oktober 2012, 13:31 UTC)

7 Das
soll nicht heißen, dass es nicht wichtig wäre, die Information über die
Herkunft der Daten oder die Benennung des Algorithums vorzuhalten
siehe dazu Abschnitt „Provenienz“.

8 ebenda

9 https://www.librarything.com/wiki/index.php/LibraryThing_APIs

10 Schließlich bedeutet das „Open“ in „Linked Open Data“, dass die Daten auch einer kommerziellen Nachnutzung offenstehen.

11 http://Open Library.org/about

12
Handelt es sich bei den Links um Daten, die über einen SPARQL-Endpoint
angeschlossen sind, so lassen sich zwar sog. „federated searches“
konstruieren (siehe hierzu auch den Abschnitt „API“), aber aus
Performanzgründen sind diese Abfragen eher nicht zu empfehlen resp. nur
eingeschränkt möglich (z.B. ist eine Suche über kontrolliertes Vokabular
vielleicht möglich, eine Freitextsuche mit Wildcards auf ein Datenset
mit 100 Millionen Triple ist aber nicht in annehmabrer Zeit
durchführbar).

13 siehe auch das Kapitel „Provenienz“

14 Im Gegensatz zu einer HTML-„Landing-Page“, die lediglich – und dies gilt leider für die meisten Dokumentenserver – wiederum nur das gewünschte Objekt maschinenunlesbar verlinkt...

15 Ein Beispiel für die Integration von Wikipedia in Primo über eine Javascript basierte DBpedia-Einbindung, findet sich unter

http://search.obvsg.at/primo_library/libweb/action/search.do (dort
z.B. nach „Harry Potter“ suchen). Ein anderes Beispiel ist lobid.org,
wo die Schlagworte aus den GND-Links mit einer SPARQL-Abfrage dynamisch
aufgelöst werden, um dem Benutzer auf der Webseite einen
menschenlesbaren Namen der URI zu präsentieren, siehe z.B.

http://lobid.org/resource/HT002948556 .

16 SPARQL ist eine graph-basierte Abfragesprache für RDF. Der Name ist ein rekursives Akronym für SPARQL Protocol And RDF Query Language, siehe :

https://en.wikipedia.org/wiki/SPARQL

17 Endpoints sind die Schnittstellen zu den Triple Stores, in denen die RDF Daten liegen..

18 Z.B
LibraryThings JSON-APIs „License: Must be run as Javascript on user’s
browser, not fetched by a server; cannot be stored, except for browser
caching.“, siehe:
https://www.librarything.com/wiki/index.php/LibraryThing_APIs

19 Z.B. „Suche Ressourcen, deren Autoren unter „Personen zu Mathematik“( http://d-nb.info/standards/vocab/gnd/gnd-sc#28p ) subsumiert sind .

20 So
sind Suchen mit Wildcards über 100 Millionen Triple in einem Triple
Store nicht performant zu haben. Für Suchen wird deshalb oft auf
Suchmaschinen oder suchmaschinenähnliche Indexe zurückgegriffen, siehe
z.B. „Virtuoso“: „Virtuoso has an optional full-text index on RDF
literals. Searching for text matches using the SPARQL regex feature is
very inefficient in the best of cases.“ (
http://virtuoso.openlinksw.com/virt_faq/“Do you support full-text search?“)

21 Siehe z. B. die Webservices von LibraryThing: ein Browsen durch Tags ist möglich, ohne die
eigenen Portalgrenzen zu verlassen. Doch dies bedingt, dass
Bestandsangaben der eigenen Bibliothek an LibraryThing weitergegeben
werden, damit eine API auf Seiten von LibraryThing die Auflösung von Tag
zu Ressource ermöglichen kann. Damit ist es notwendig, anders als in
den anderen Anreicherungsformen , dass auch auf Seiten des verlinkten
Fremdanbieters Datenintegrationsaufwand betrieben wird. Die Datenhoheit
liegt bei LibraryThing. Für ein Beispiel siehe die Dortmunder Stadt- und
Landesbibliothek:

http://katalog.dortmund.de:8080/webpac-bin/wgbroker.exe?+new+-access+top.do_intern_ger+search+open+ISBN+3423071516

22 Z.B. kann der Zeitpunkt der Erscheinung einer Ressource mit dct:issued oder isbd:P1021 angegeben sein.

23 siehe hierzu das Kapitel „Lizenzen“

24 siehe z.B. http://dx.doi.org/10.1007/978-1-4419-9443-1 und

http://edoc.vifapol.de/opus/volltexte/2012/3730/ und meinen Blog-Post http://www.dr0i.de/lib/2011/03/23/publisher_make_urls_useless.html

25 Die Smilies sind der „Open Icon Library“ entnommen, siehe: http://sourceforge.net/projects/openiconlibrary/ .

26 Was
sind eigentlich „eigene“ Daten? Die „Originärdaten“ des Katalogs
bestehen ja oft schon aus Übernahmen sog. Fremddaten. Da die Herkunft
der Quellen der Daten in den Katalogen bisher oft nicht oder nur
unzureichend festgehalten wurde, kann für einen solchen
Katalogsdatensatz nur gelten, dass er der „Originärdatensatz“
ist.

27
Z.B. können bei der Open Library Tags frei vergeben werden, und dies
zudem von Benutzern und nicht nur von Bibliothekaren. Es ist also nicht
unwahrscheinlich, dass auch Ressourcen, die sich nur am Rande z.B. mit
dem Thema „Semiotik“ beschäftigen, trotzdem dieses Tag bekommen, wenn
eine Benutzerin einen interessanten, aber kleinen Abschnitt dazu in der
Ressource gelesen hat. Im Suchindex könnten z.B. die Tags mit einem
Faktor von 0.3 gewichtet sein, sodass dieses bibliothekarische Objekt
durchaus gefunden würde bei einer Suche nach „Semiotik“, es würde aber
nicht so hoch gerankt wie eine Ressource mit dem vom Bibliothekar
vergebenen Schlagwort „Semiotik“.

28 Z. B. eine Kurzrezension über Thomas Bernhards „Auslöschung“ in RDFa: http://www.dr0i.de/lib/2012/06/03/thomas_bernhard_auslschung_ein_zerfall.html

29 Es kommt natürlich darauf an, welche Daten verknüpft werden sollen: für eine Verknüpfung von FRBR-Manifestationen ist eine ISBN alleine nicht ausreichend, hier muss z. B. noch die Auflage berücksichtigt werden.

30 zur Auflösung aller in diesem Beitrag genannten Präfixe, aka Namespaces, siehe http://prefix.cc/

31
Um eine möglichst einfache Integration der eigenen Daten in fremde
Kontexte zu ermöglichen setzt OCLC deshalb vor allem auf schema.org,
siehe dazu auch Ed Summer unter http://inkdroid.org/journal/2012/07/06/straw/.

32 Um zu entscheiden, welche Vokabularien geeignete sind siehe
auch den Beitrag in diesem Sammelband „Vokabulare für bibliographische
Daten – Zwischen Dublin Core und bibliothekarischen Anspruch“ von
Carsten Klee .

33 Sieh z. B. http://wiki.ckan.org/API

34 Seite
„Representational State Transfer“. In: Wikipedia, Die freie
Enzyklopädie. Bearbeitungsstand: 2. Oktober 2012, 05:36 UTC. URL:
http://de.wikipedia.org/w/index.php?title=Representational_State_Transfer&oldid=108774737 (Abgerufen: 9. Oktober 2012, 15:32 UTC) .

35 Z. B. liefert http://thedatahub.org/api/rest/dataset/lobid-resources die Informationen über die lobid-Ressourcen in JSON zurück.

36 https://en.wikipedia.org/wiki/Web_API

37 http://www.w3.org/2009/sparql/wiki/Feature:BasicFederatedQuery

38 Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch:

http://lod-cloud.net/

39 http://lobid.org/organisation/ .
Das Datenset ist leider (noch) nicht Open Data, doch können die
einzelnen Datensätze durchaus genutzt werden. U.a. enthält das Datenset
Geo-Informationen. Damit lassen sich Geo-Suchen durchführen (sogar über
SPARQL – siehe
https://wiki1.hbz-nrw.de/pages/viewpage.action?pageId=5144604 ),
und es lassen sich die Organisationen in einer Karte, z. B.
OpenStreetMap, einblenden. Genutzt wird lobid-organisation momentan vom
GBV (
http://uri.gbv.de/organization/ ) und vom LODUM Projekt ( http://lodum.de/post/28619267432/linking-bibliographic-resources ) .

40
lobid-organisations ist ein internationales
Linked-Data-Adressverzeichnis von Bibliotheken und verwandten
Organisation. 15.000 Einträge beschreiben Bibliotheken und Museen aus
Deutschland.

41 http://thedatahub.org/dataset/lobid-resources

42 https://code.google.com/p/google-refine/

43 http://www4.wiwiss.fu-berlin.de/bizer/silk/

44 http://culturegraph.sourceforge.net/

45 Für weitergehende Informationen wie z. B. das Silk Konfigurationsfile siehe:

https://wiki1.hbz-nrw.de/display/SEM/2012/05/03/First+results+using+SILK+to+link+to+DBpedia .

46 http://www.assembla.com/spaces/silk/wiki/Linkage_Rule

47 https://www.assembla.com/wiki/show/silk/Silk_MapReduce

48 Zum
Zeitpunkt der Erstellung der Verknüpfungen gab es einen Bug in Silk,
der nun behoben ist. Nun kann auch mit der hadoop Variante ein Filedump
verwendet werde. Somit ist es nicht mehr notwendig, die Daten in einen
SPARQL Endpoint zu laden. Damit entfällt dieser Flaschenhals. Die hier
gemachten Zeitangaben dürften sich demnach bei Verwendung des Filedumps
stark unterscheiden, so dass es sich lohnen wird, einen vorhandenen Dump
zu nutzen. Der Dump wird allerdings direkt in das RAM geladen. Deswegen
ist es zwingend erforderlich genügend RAM zu haben
.

49 Siehe Abschnitt „Verknüpfungsergebnisse“

50 Siehe Abschnitt „Postprozessierung“

51 Diese und weitere Silk-Konfigurationsdateien finden sich auf dem github Account von lobid unter https://github.com/lobid/silk-xml-configs.

52 Es
ist evident dass dieser Matchingalgorithmus zu primitiv ist und somit
viele falsche Matches produzieren wird. Das anschließende Kapitel
„Verknüpfungsergebnisse“ geht auf die notwendige Postprozessierung ein
.

53 Dies kann realistischerweise nur unter Mithilfe der Nutzer geschehen, also durch sog. „Crowdsourcing“.

54 Das Script zu dieser Disambiguierung liegt unter: https://github.com/lobid/linked-data-tools

55 siehe “dbpedia-owl:wikiPageDisambiguates“ unter z. B. http://de.dbpedia.org/resource/Helden

56 Gesetzt
den Fall, ein Bibliothekar schafft manuell für 1000 Titel am Tag
nachzuschlagen, welche Ressource den gleichen Titel haben. Daraus folgt:
16 Millionen / (200 Arbeitstage * 12 Bibliothekare * 1000 Titel pro
Tag) = 6 Jahre

57 https://github.com/lobid/Phresnel

58 https://de.wikipedia.org/wiki/FRBR

59 http://musicontology.com/#term_wikipedia

60 Ein
Phänomen von LOD ist die sog. „positive Rückkopplung“: miteinander
verknüpfte Daten sorgen potentiell auch für eine Verbesserung der
Zielressource.

61 http://lobid.org/resource/HT015016642

62 Für mehr Hintergrund siehe

https://wiki1.hbz-nrw.de/display/SEM/Provenienzinformationen

63 http://lobid.org/organisation

64 http://www.w3.org/TR/cooluris/#r303gendocument

65 http://patterns.dataincubator.org/book/named-graphs.html

66 Der
Objekt-URI ist eine sog. „Blank Node“ , also eine Referenz, die es nur
innerhalb des Triple Stores gibt bzw. nur dort gültig ist.

67 Zum
Einsatz kommt der Triple Store „4Store“, der, wie der Name schon sagt,
auch ein sog. Quad-Store ist, also mit Named Graphs arbeiten kann
.

68 Für ein SPARQL Beispiel siehe den folgenden Abschnitt „Datenintegration“.

69 Weitere Hintergrundinforrmationen zur Provenienz finden sich unter „Linked Data und Provenienzinformationen“ von Kai Eckert in diesem Sammelband .

70
Das Prädikat dbp:wikiPageWikiLink besagt eigentlich nur, dass die
Ressource auf die Wikipediaseite „Hugo_Award“ verlinkt („Link from a
Wikipage to another Wikipage“). Es könnte also auch sein, dass lediglich
eine Nominierung erwähnt wird. Es könnte sogar noch abwegigerer
Kontexte geben, in denen ein Wikipedia-Artikel auf den Hugo-Award zeigt,
z.B. weil das Buch den Preis zum Inhalt hat.
Die oben aufgestellte Behauptung, es lasse sich eine Abfrage erstellen,
die Bücher findet, die mit dem Award ausgezeichnet wurden, ist deshalb
nicht zu 100% richtig.

71 http://www.w3.org/TR/rdf-sparql-XMLres/

72 also sog. „Bookmarks“

73 Siehe z. B. die Web Services der ZBW unter http://zbw.eu/beta/econ-ws/, die zum Teil auf SPARQL-Abfragen basieren.

74 Wünschenswert
wären sicherlich kleine Web-Bausteine, die sich einfach in eine
Webseite einbauen lassen, wie die sog. „Widgets“ von LibraryThing.

75
Wegen der Offenheit und Flexibilität der Datenbeschreibung mittels RDF
änderten neu entstandene LOD-Services öfter ihr Vokabular (auch wenn
schon anfangs darauf geachtet wurde, Vokabulare zu nutzen,die möglichst
weit verbreitet sind (wie etwa Dublin Core oder bibo)). Mittlerweile
gibt es die Gruppe „DINI AG KIM Titeldaten“ in Deutschland, um eine Art
Kernelementeset zu beschreiben und damit eine stabile RDF Repräsentation
für diese Kerndaten zu erreichen , siehe

https://wiki.d-nb.de/display/DINIAGKIM/Titeldaten+Gruppe .

76 siehe hierzu auch das einführende Kapitel „API“ in diesem Beitrag

77 http://de.slideshare.net/nichtich/libraries-in-a-datacentered-environment

78 Die
Mindestvorraussetzung eines „Katalogs“ ließe sich beschränken auf eine
Liste von Identifiern, um auf die Fremddaten verweisen zu können, die
dann dynamisch eingeblendet werden.

79 Auch
diese Sicht, nämlich die Betrachtung gesamtgesellschaftlicher
Auswirkungen von (Daten-)Lizenzierung, verbindet die Open Data mit der
Open Source Bewegung, und so ist es auch kein Zufall, dass Richard
Stallmann (Gründer und Präsident von
http://gnu.org/ und http://fsf.org/ ) auf der Open Knowledge Conference 2011( http://okcon.org/2011 ) als Gastredner auftrat.

80 siehe dazu auch http://www.slideshare.net/h_jansen/dynamische-kataloganreicherung-auf-basis-von-linked-open-data, Seite 17 ff

81 siehe dazu auch http://www.culturegraph.org/

82 Eine mit RDFa angereicherte Version dieses Artikels wird unter

http://www.dr0i.de/lib/pages/Datenanreicherung_auf_LOD_Basis.html erscheinen .

83 https://www.adobe.com/devnet/xmp.html

84 https://de.wikipedia.org/wiki/Impact_Factor

85 https://en.wikipedia.org/wiki/Social_graph

86 Ein existierendes Beispiel ist „LODUM“. Dort werden Veröffentlichungen von Mitarbeitern der eigenen Universität ( https://www.uni-muenster.de/forschungaz/ )
mit lobid-Ressourcen verknüpft. Dadurch gewinnen die LODUM-Ressourcen
Bestandsangaben zu den Exemplare besitzenden Bibliotheken. Diese werden
auf einer Landkarten visualisiert (siehe z.B.
http://data.uni-muenster.de/context/cris/publication/41562 ). Im Gegenzug können die lobid Ressourcen leicht mit den durch LODUM bereit gestellten Abstracts verknüpft werden.

87 https://de.wikipedia.org/wiki/Tim_Berners-Lee

88 https://de.wikipedia.org/wiki/Wissensallmende

1 Responses to Datenanreicherung auf LOD Basis

  1. zaman says:

    Hi, Could you please help me on this topic: http://stackoverflow.com/questions/36794731/copy-an-owl-ontology-in-jena
    I came from your stackoverflow answer. I guess it is easy for you. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *


− 2 = two

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>