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“).
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.
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.
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.
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.
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
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.
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.
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.
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.
Diese Konfiguration beschreibt folgenden natürlichsprachlich ausgedrückten Matchingalgorithmus:
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.
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.
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> .
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.
<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>
_:b108c6c05000000c2 opmv:wasControlledBy <http://lobid.org/person/pc> .
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/
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
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
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.
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:
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
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
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:
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:
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.