culturegraph.org

Am Freitag ging folgende gemeinsame Presseerklärung der DNB und des hbz raus:

http://www.hbz-nrw.de/dokumentencenter/presse/pm/culturegraph_de/

Wir haben in unserer Linked Open Data-Gruppe im hbz lange über Identifier für Titeldaten diskutiert. Schnell kamen wir zum Schluss, dass sich das mehrfache Prägen von Identifier für eine Ressource (z.B. ein Buch) nicht verhindern lassen kann, auch wenn man mit lobid.org eine neutrale Plattform anbieten möchte, um genau das zu tun. Verbundzentralen und Bibliotheken werden ihre Daten als Linked Data veröffentlichen und für „Harry Potter und der Stein der Weisen“ wird es zig Identifier geben.

Linked Data lebt von Verlinkung. Wichtig ist es also, diese vielen URIs zu einer Ressource miteinander zu verlinken. Erst dann kann man mit den bibliographischen Titeldaten, die jemand anders veröffentlichen auch in der eigenen Datenbank etwas anfangen, z.B. Dublettenerkennung oder Kataloganreicherung.

Und wichtig ist es auch, dass es für jeden Titel viele andere Identifier gibt, die nicht unbedingt dem URI-Schema folgen aber dennoch oft, z.B. für Mashups benutzt werden. Die ISBN ist die bekannteste, aber man denke da auch an die Nationalbibliographienummer, Library of Congress Catalog Number,  ASIN von Amazon oder Open Library Identifier. Man wird vielleicht nicht immer ein „sameAs“ benutzen wollen, aber es gibt noch andere Relatoren für solche, etwas ungenaueren Verknüpfungen. Gerade heute hat Michael Bergman in seinem Blog darüber geschrieben:

The Nature of Connectedness on the Web

culturegraph.org ist deshalb für mich eine der wichtigsten Entwicklungen in der Linked Data in Libraries-Szene. Ich hoffe, dass dieser „Hub“ von Identifiern schnell wächst und auch von anderen kulturellen Institutionen angereichert werden wird.

Linked-Open-Data-Aktivitäten im hbz-Verbund

Adrian Pohl und ich haben beim Oracle Summit für Bibliotheken am 27. Oktober in Weimar einen Vortrag zum Thema Linked-Open-Data-Aktivitäten im hbz-Verbund gehalten. Die Folien sind nun auf der Oracle-Website verfügbar:

http://www.oracle.com/global/de/events/2010/local/sun/weimar/presentations/ORACLE_10_hbz.pdf

Mein Beitrag fängt bei Folie 20 an und handelt über die Umwandlung bibliographischer Daten in RDF-Tripel.

Konvertierung bibliographischer Daten in RDF-Tripel

Am 27. Oktober 2010 hielten Adrian Pohl und ich einen Vortrag zu den Linked-Data-Aktivitäten im hbz. Hier folgt nun der Text meines Teils des Vortrags.

Das hbz hat in den letzten Monaten an einer Veröffentlichung von bibliographischen Daten als Linked Open Data gearbeitet. Über diese Arbeiten möchte ich nun berichten.

Wenn man bibliographische Daten als Linked Data veröffentlichen möchte, steht man vor vielen Herausforderungen und Fragen.Man kann sich zwar von den Kollegen in Schweden und Ungarn inspirieren lassen, aber auch sie können einem nicht die Antworten auf alles geben. Unsere Situation ist eine andere als in Stockholm und Budapest: so sind unsere Daten in der Verbunddatenbank, einem Aleph-System, im MAB2-Format und nicht in MARC21 gespeichert.

Ein zweiter Grund, warum man nicht einfach die Arbeit der Pioniere kopieren kann ist, dass weltweit immer noch Entwicklungen stattfinden, die bereits bestehende Vorgänge revolutionieren oder zumindest evolutionär anpassen. So haben wir auf die DNB gewartet, bis diese ihre Normdaten als Linked Data veröffentlicht hat.

Der Dreh- und Angelpunkt in der Formulierung von RDF-Tripel aus bibliographischen Daten ist die Frage nach dem geeigneten Vokabular. Entweder entwickelt man sein eigenes Vokabular als RDFSchema oder OWL-Ontologie oder man nutzt ein bereits bestehendes Vokabular nach. Um die Interoperabilität der Daten untereinander zu unterstützen ist es immer sinnvoll erstmal zu schauen, welche Vokabularien bereits bestehen. Im bibliographischen Bereich sind es eine ganze Menge:

–    Simple Dublin Core und Qualified Dublin Core
–    Bibliographic Ontology (BiBO)
–    MARC Ontology (MarcOnt)
–    MODS Ontology
–    RDA Vocabulary
–    FRBR
–    ISBD

Welches Vokabular wählt man nun? Die MARC- und MODS-Ontologien haben wir erstmal als Kandidaten verworfen. ISBD ist noch zu früh in der Entwicklung.

Andere Fragen, die uns beschäftigten waren:

–    Muss jedes einzelne obskure MAB-Feld als Linked Data veröffentlicht werden?
–    MAB-Daten beschreiben nicht nur bestimmte Titel, sondern es gibt auch Felder, die den Datensatz selbst beschreiben. Ein Beispiel ist Feld 001: es gibt die Nummer des Datensatzes wieder. Wollen wir den MAB-Datensätze oder die  bibliothekarische Ressourcen beschreiben? Wir entschieden uns Information über bibliothekarische Ressourcen veröffentlichen zu wollen.
–    Inwieweit spielt FRBR eine Rolle? Kann man MAB-Daten auf die verschiedenen FRBR-Entitäten wie Work, Expression, Manifestation und Item mappen?

Folgende Schritte wurden unternommen:

1. Wir haben uns aus den Daten, die als Open Data veröffentlicht werden können einfach zehn Datensätze genommen.

2. Wir analysierten, mit welchen MAB-Feldern wir es zu tun haben würden. Unsere zehn Datensätze haben die wichtigsten Felder getroffen. Unsere MAB-Expertinnen haben nur wenige Felder hinzugefügt, die sie als unabdingbar sahen.

3. Bei jedem der MAB-Felder auf der Liste entschieden wir, ob es die Ressource oder den MAB-Datensatz selbst beschreibt. In den folgenden Schritten kümmerten wir uns nur um die Felder, die mit der Ressource selbst zu tun haben.

4. Wir mappten die Felder auf Qualified Dublin Core (dcterms) und BiBO und stellten dabei fest, was wir ohnehin bereits wussten: Wenn man diese Vokabulare einsetzt, geht sehr viel Semantik verloren. Hier sehen Sie ein Beispiel.

5. Wir entschieden uns, auch ein Mapping zum RDA Vokabular vorzunehmen. Das RDA Vokabular ist sehr differenziert und berücksichtigt auch FRBR. Man wird zuerst förmlich erschlagen von den hunderten von Properties, aber wenn man erstmal einen Überblick hat, kann man es benutzen. In diesem Zusammenhang kämpften wir vor allem mit FRBR.

6. Wir konnten ein erstes RDA-Mapping abschließen, aber leider die Daten nicht mit dem RDA-Vokabular als Linked Data veröffentlichen, da der dafür zuständige Kollege für ein paar Wochen nicht verfügbar ist.

7. Wir haben allerdings Ende August die Daten hauptsächlich im BiBO-Format als Linked Data veröffentlichen können. Andere Vokabulare, die eingesetzt wurden sind: FRBR, DCTerms, FOAF, Geo, Geonames, RDF, OWL, und die Provenance Ontology. Wir wissen, dass dies nicht der Weisheit letzer Schluss ist, aber es ist ein Anfang und bietet eine Grundlage unsere aus MAB2 gemappten Daten mit denen der Schweden und Ungarn zu vergleichen.

(Eine ausführliche Beschreibung findet sich hier)

So wurden 4.896.515 Datensätze in 82.471.813 RDF-Tripel überführt.

Bei der Veröffentlichung unserer Daten legten wir vor allem sehr viel Wert auf die Verlinkung zu anderen Daten. So haben wir z.B. zu den Normdaten der Deutschen Nationalbibliothek und der DDC verlinkt. Natürlich wurden auch Über- und Unterordnungen miteinander verknüpft. Außerdem können wir einen Bezug zwischen den bibliografischen Daten und den besitzenden Bibliotheken feststellen. Dafür verlinken wir zu den Organisationsdaten, die das hbz als Linked Data veröffentlicht hat.

Mit einer anderen wichtigen Verlinkung sind wir immer noch konfrontiert:

Verlinkungen zu anderen Daten, die dieselbe Ressource beschreiben. Wenn jeder Verbund bzw. viele Bibliotheken das tun, was wir tun, werden für dieselbe Ressource viele verschiedene URIs geprägt. Das ist an sich nicht schlimm, so lange man Verknüpfungen zwischen den verschiedenen URIs herstellt.

Ein solcher Weg ist ein Projekt der DNB, bei dem das hbz als Projektpartner auftritt: culturegraph.org. Ziel des Projekts ist es verschiedene Identifikatoren, die dieselbe  Ressourcen beschreiben miteinander zu verknüpfen. Dazu gehören die http-URIs, mit denen Linked Data-Ressourcen identifiziert werden, aber auch andere Identifikatoren wie EKI, ISBN, Verbunds-IDs, Amazon ASIN, LCCN, OCLC-Identifier usw. usf. Nicht nur Identifier aus Bibliotheken sollen hier aufgenommen und miteinander verknüpft werden, sondern auch die aus anderen Gedächnisinstitutionen.

Resultat dieses Dienstes ist, dass alle bibliographischen Daten zu einer Ressource aus verschiedenen Quellen miteinander verlinkt werden können. Nur zwei mögliche Anwendungsgebiete seien hierfür genannt: Kataloganreicherung und Dublettenidentifizierung. Das sind die Anwendungsgebiete, die mir aufgrund meines Arbeitsbereiches am nächsten liegen, aber weitaus mehr, nicht nur im bibliothekarischen Bereich, ist so möglich.