lib
library dr0ide
About
dr0i icon
I am a chartered librarian, helping to heave the data of libraries into the net. The text on this blog is licensed under CC-0.
creative commons CC0

Artikel "Datenanreicherung auf LOD-Basis" erschienen

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 obligatorisch 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), deutsch „Schnittstelle 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 FRBR58-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 Organisationen63 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 geschickt 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, deren 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 HTML82 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 htsstps://de.wikipedia.org/wiki/Wissensallmende