Donnerstag, 22. Dezember 2016

More than two million scientific journal articles available

Deutsche Version Version française English version

Möchten Sie auf über 2 Millionen wissenschaftliche Artikel aus allen Fachgebieten zugreifen und haben Sie einen ständigen Wohnsitz in der Schweiz?
Drei elektronische Zeitschriftenarchive stehen ab sofort der ganzen Schweizer Bevölkerung zur Verfügung:
  • Cambridge University Press (Artikel veröffentlicht von 1770 bis 2015)
  • De Gruyter (Artikel veröffentlicht von 1826 bis 2015)
  • Oxford University Press (Artikel veröffentlicht von 1895 bis 2015)
Durchsuchen Sie die Archive direkt via Swissbib.
Registrieren Sie sich für den kostenlosen Zugriff: www.nationallizenzen.ch/anmeldung

Auch ohne Anmeldung können Sie auf die Zeitschriftenarchive zugreifen, wenn Sie eine der berechtigten Bibliotheken (zum Beispiel Universitäts- oder Kantonsbibliotheken) besuchen. Weitere Details zu den Zugriffsmöglichkeiten finden Sie auf www.nationallizenzen.ch/zugriff.

Inhalte aus dem Jahr 2016 werden nach zwei (De Gruyter), drei (Oxford University Press) und fünf (Cambridge University Press) Jahren Embargo verfügbar sein. Dieselbe Regelung kommt auch in zukünftigen Jahren zur Anwendung.

Weiterführende Information finden Sie unter www.nationallizenzen.ch.

Dieses Angebot wird vom Konsortium der Schweizer Hochschulbibliotheken mit Unterstützung von swissuniversities ermöglicht.

Donnerstag, 21. Juli 2016

Swissbib data goes linked Teil 4: Hydra Web API for smarter clients

Deutsche Version Version française

Serie "Swissbib data goes linked"
Teil 1 | Teil 2 | Teil 3 | Teil 4

Im vierten und letzten Teil der Artikelserie zum SUK P-2-Projekt linked.swissbib.ch möchten wir uns der Web API für maschinelle Clients widmen. Ziel dieses Teilprojektes ist es, die verlinkten Datenstrukturen über eine REST Schnittstelle in verschiedenen RDF Formaten zur Verfügung zu stellen.

Illustration 1: REST API als Schnittstelle für swissbib Services
Die REST API soll dabei eine einheitliche Schnittstelle nach aussen anbieten und gegen innen die Möglichkeit verschiedene Dienste anzubinden. Für Clients der Schnittstelle soll die dahinterliegende Infrastruktur transparent sein.

REST

REST (REpresentational State Transfer), ein Programmierparadigma für verteilte Systeme, hat sich in den letzten Jahren gegenüber anderen Ansätzen (z.B. SOAP) aus verschiedenen Gründen durchgesetzt. REST ist leichtgewichtig, skalierbar, einfach verständlich für Menschen und auch relativ einfach zu implementieren für Clients in jeglichen Programmiersprachen. Die Grundsätze eines REST Service sind vereinfacht:
  • Client – Server
    Es gibt eine klare Trennung zwischen Client und Server. Der Client steuert die Interaktionen und der Server verarbeitet Daten oder liefert diese aus.
  • Stateless
    Der Server benutzt nur Daten aus einem einzelnen HTTP Request um die Anfrage zu beantworten und nutzt keine weiteren Kontextinformationen.
  • Cacheable
    Der Inhalt einer Server-Antwort muss implizit oder explizit als cachebar oder nicht cachebar gekennzeichnet sein.
  • Layered System
    Für Server und Client ist transparent ob das Gesamtsystem aus mehreren Abstraktionsschichten besteht oder nicht.
  • Uniform interface
    • Jede Ressource (z.B. eine bibliographische Ressource) ist über eine URL ansprechbar.
    • Eine Ressource kann syntaktisch und semantisch verstanden werden anhand der enthaltenen Daten und Metadaten aus einer Antwort. Das beinhaltet unter anderem die Information in welchem Format (z.B. JSON-LD) die Antwort ist.
    • Wenn ein Client eine Ressource abgefragt hat, hat er damit genug Informationen um die Ressource zu bearbeiten oder zu löschen (vorausgesetzt er hat das Recht dazu).
    • HATEOAS (Hypermedia as the Engine of Application State)
Diese letzte Anforderung (HATEOAS) ist eine der wichtigsten und doch am meisten vernachlässigte bei vielen REST APIs. Kurz gesagt besagt HATEOAS, dass die API selbstbeschreibend sein muss. Das heisst ein maschineller Client sollte über einen einzigen Einstiegspunkt in der Lage sein zu verstehen welche Aktionen auf welchen Ressourcen über die API ausgeführt werden können. Abstrakt betrachtet stellt ein HATEOAS-konformer REST-Service einen endlichen Automaten dar, dessen Zustandsveränderungen durch die Navigation mittels der bereitgestellten URLs erfolgen.

Hydra (hypermedia-driven web APIs)

REST selbst schreibt keinen Standard vor, wie eine selbstbeschreibende API aufgebaut sein soll. Genau an diesem Punkt setzt Hydra an mit dem Versuch das Vokabular für Hypermedia-getriebene Web APIs zu standardisieren. Das Hydra Core Vocabulary ist noch ein inoffizieller Entwurf, der von Google Mitarbeiter Markus Lanthaler vorangetrieben wird und sich besonders im Linked Data Umfeld bereits grosser Beliebtheit erfreut. Das gesamte Vokabular ist schon relativ umfangreich. Um das Prinzip zu veranschaulichen möchten wir hier deshalb nur zwei Beispiele betrachten.

hydra:entrypoint
Der Hydra:Entrypoint ist der Startpunkt jeder API. Der Entrypoint selbst, sowie die gesamte API Dokumentation, ist im Format JSON-LD. Im Entrypoint enthalten sind alle weiterführenden Links (zur Zeit noch relative Links) zu den Ressourcen. Im Falle unseres Prototyps sind dies erst die bibliographischen Ressourcen (bibliographicResource). Der Entrypoint unseres Prototyps ist unter folgender URL zu finden: http://sb-vf16.swissbib.unibas.ch/web/

Illustration 2: hydra:entrypoint des swissbib REST API Prototyps
(Für Google Chrome Benutzer empfiehlt sich folgendes Plugin: https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc)

hydra:collection
Eine Hydra:Collection ist die Sicht auf eine Menge von zusammenhängenden Ressourcen. In unserem Fall könnte das eine Liste der Suchresultate für bibliographische Ressourcen sein. Da eine solche Menge von Ressourcen sehr schnell sehr gross werden kann gibt es im Hydra Vocabulary die Hydra:PartialCollectionView. Diese beschreibt eine Sicht auf eine Untermenge aller Elemente einer Collection. In einer Hydra:PartialCollectionView können Links (hydra:first, hydra:last, hydra:next und hydra:previous) enthalten sein um alle Elemente dieser Sicht abzufragen. Die Ressourcen selbst befinden sich im Feld "hydra:member". Ein Beispiel für eine solche Abfrage findet sich unter folgender URL: http://sb-vf16.swissbib.unibas.ch/web/bibliographic_resources?dct:title=linked%20data

Illustration 3: Die Ausgabe einer hydra:collection des swissbib REST API Prototyps

Diese Standardisierung mittels des Hydra Core Vocabulary erlaubt es nun einen generischen Client zu schreiben, der die möglichen Interaktionen mit der Web API auflisten kann. Einen solchen generischen Client zum Entdecken der API hat Markus Lanthaler bereits entwickelt: http://www.markus-lanthaler.com/hydra/console/ (URL: http://sb-vf16.swissbib.unibas.ch/web)

Prototyp

Nachdem wir bereits die ersten Resultate des Prototyps gesehen haben, möchten wir noch etwas auf dessen Implementierung eingehen. Eine erste Hydra Referenzimplementierung wurde von Hydra Schöpfer Markus Lanthaler als SymfonyBundle in der Programmiersprache PHP entwickelt. Daraus entstanden vor allem in diesem Umfeld weitere Entwicklungen im Zusammenhang mit Hydra. Unter anderem entstand das Framework APIPlatform. Das Framework wurde zum ersten Mal im Juni 2015 in Version 1 veröffentlicht und steht kurz vor seinem Release in der nächsten Major Version 2.0. Das Framework bietet umfangreiche Hydra Unterstützung. Innerhalb dessen ermöglicht es relativ einfach eigene Datenquellen (DataProvider) anzubinden sowie weitere Serialisierungsformate (über Responder) in der Ausgabe anzubieten. In unserem Prototypen haben wir einen eigenen einfachen DataProvider implementiert, der die verlinkten Daten im Format JSON-LD aus einem Elasticsearch Server lädt. Mit eigens implementierten Responder-Klassen lassen sich dann je nach Anfrage des Clients die Daten in andere RDF Format serialisieren und ausgeben. Die folgende Grafik stellt eine vereinfachte Darstellung des Prozesses dar:


Der Code des Prototyps ist auf Github einsehbar: https://github.com/linked-swissbib/hydra-swissbib.ch/tree/prototype_v2

Fazit

Wir sind überzeugt mit Hydra ein Vokabular für Hypermedia-getriebene Web APIs gefunden zu haben, dass optimal zu unseren verlinkten Daten passt. Mit der Entwicklung des Prototyps konnten wir uns vom Framework API Platform überzeugen und werden In den nächsten Wochen auf Basis des Prototyps die Entwicklung der REST API vorantreiben. Der Aktuelle Stand der Entwicklung kann auf Github verfolgt werden: https://github.com/linked-swissbib/hydra-swissbib.ch

AutorInnen des Beitrags:

Dienstag, 19. Juli 2016

Mid-project report : Metadata Management National Licences

  • How will the articles from National Licences be integrated in Swissbib ?
  • How will private users from Switzerland be able to access this content ?
  • What are the plans regarding the implementation of the green open access clauses of National Licences ?
Curious ? Have a look at the Mid-Project Report : Metadata Management Swiss National Licences.

General Information about the National Licences project is available on http://www.nationallicences.ch.

Freitag, 20. Mai 2016

Swissbib data goes linked 3: Präsentation der angereicherten Daten / Présentation des données enrichies

Deutsche Version Version française

Serie "swissbib data goes linked"
Teil 1 | Teil 2 | Teil 3 | Teil 4

Das SUK P-2-Projekt linked.swissbib.ch hat zum Ziel, die Daten aus etwa 20 Schweizer Such- und Datendiensten zu verlinken und mit Inhalten aus anderen Quellen wie z.B. DBpedia und VIAF anzureichern. Zu den Herausforderungen in diesem Kontext gehören die Datenmodellierung und das Mapping, die Verknüpfung der Daten, aber auch deren Darstellung bzw. die dazugehörigen Benutzeroberflächen (GUI). Letzteres ist Thema dieses Blogbeitrags.

Abb. 1: Übersicht über die für linked.swissbib erstellten Features und Seiten gegliedert nach Inhaltstyp (Instanz, Werk, Autor, Thema) sowie nach Seitentyp (Startseite, Übersichtsseiten, Trefferseiten, Detailseiten, Knowledge Cards)

Die Erweiterung der Daten und deren neuartige Struktur ermöglichen eine Vielzahl neuer Features und Funktionen, um welche konventionelle Bibliothekskataloge erweitert werden können. Im Projekt linked.swissbib.ch setzt sich das Schweizerische Institut für Informationswissenschaft (SII) an der HTW Chur mit der Erstellung geeigneter Benutzerschnittstellen-Konzepte sowie deren Implementierung (inkl. Suchfunktionalitäten) auseinander. Die Arbeiten können grob in drei Schritte unterteilt werden:

Schritt 1: Ermittlung des State-of-the-Art von LOD-Portalen


Zu Beginn des Projekts wurde eine Analyse der Nutzung von Linked (Open) Data im Kontext von Bibliotheken und wissenschaftlichen Informationsdiensten durchgeführt. Hierfür wurden rund ein Dutzend LOD-Portale (z.B. data.bnf.fr; datos.bne.es) verglichen und Literaturrecherchen realisiert. Mit Hinblick auf die Erstellung eines Portals, das die Suche in den vernetzten Wissensstrukturen sowie deren Visualisierung zulässt, wurde so systematisch der State-of-the-Art in diesem Bereich erhoben.

Abb. 2: Auswahl von Autosugget-Funktionen verschiedener LOD-Portale im bibliothekarischen Bereich

Dabei ging es einerseits darum, Know-How hinsichtlich Einsatzszenarien und potentiellen Mehrwerten aufzubauen, die sich mit einem offenen, flexiblen Datenmodell realisieren lassen. Andererseits war es das Ziel, auf der Basis der State-of-the-Art-Analyse Hinweise zur Realisierbarkeit von Features zu gewinnen und Prioritäten für die Umsetzung von Funktionalitäten für das Portal linked.swissbib zu definieren. Gleichzeitig konnte so auch die Eignung des vorgesehenen Datenmodells überprüft sowie Abstimmungen des Datenmodells und des geplanten Funktionsumfangs vorgenommen werden.

Schritt 2: Prototyp


Auf Basis dieser Analysen wurde mit Hilfe der Software Axure RP ein interaktiver Prototyp des GUI entwickelt. Dieser orientiert sich am Look-and-Feel des Metakatalogs swissbib, wie er heute für die Öffentlichkeit zur Verfügung steht (www.swissbib.ch). Das GUI-Konzept sowie das Interaktionsdesign des bestehenden Katalogs wurden erweitert, um den neuen Möglichkeiten, die sich aus der Datenverlinkung für die Bereitstellung von zusätzlichen Inhalten ergeben, Rechnung zu tragen.

Abb. 3: Für jede Seite des Prototyps wurde im Rahmen der Erstellung des Interaktionskonzepts ein Clickstream visualisiert, welcher wiedergibt, was bei einem Klick auf ein bestimmtes Element geschieht. Auf diesem Beispiel ist der Clickstream für eine Trefferseite (Tab Autorenseiten) abgebildet.

Die erste Version des Prototyps entstand kurz nach Projektstart, also einem noch frühen Stadium des Projekts, zu welchem die Art und der Umfang der (angereicherten) RDF-Daten noch nicht vorlagen bzw. noch nicht bekannt waren. Dies barg den Vorteil, dass ohne Einschränkungen entworfen werden konnte und der Designprozess (in dieser ersten Phase) keinen Einschränkungen unterworfen war. Der Prototyp wurde daher entwickelt ohne Anspruch auf eine vollständige Umsetzung aller Features und Funktionen innerhalb des Projekts linked.swissbib und stellt vielmehr ein Ideal dar, welche die Möglichkeiten von Linked Data im Rahmen von swissbib aufzeigen soll. Der Prototyp beinhalt bereits eine Festlegung der Angaben (z.B. Auswahl biografischer Daten etc.), die definitive Auswahl hängt jedoch stark davon ab, welche Daten am Ende des Projekts vorhanden sein werden, was zu ständigen Anpassungen der Oberflächenfunktionen führt.

Abb. 4: Via Klick auf ein Icon, welches sich in diesem Fall auf der Trefferliste (Tab Themenseiten) befindet, wird eine Kurzform der Detailseite des Themas "Historische Geografie" einblendet.

Die prototypische Benutzeroberfläche wurde entsprechend im weiteren Verlauf auf Basis der wachsenden Datengrundlage sowie aufgrund des Feedbacks der Projektbeteiligten kontinuierlich weiterentwickelt und auch bereits ersten Benutzer-Evaluationen unterzogen (einerseits im Rahmen einer Lehrveranstaltung im Bachelor-Studiengang Information Science der HTW Chur andererseits in mehreren Bachelor-Arbeiten).

Abb. 5: Detailseite Autor: Diese Seite aggregiert Angaben zu einem Autor (z.B. Lebensdaten, assoziierte Bewegung oder Stilrichtung, verwandte Personen), welche grösstenteils in einem Akkordeon ("Mehr Details anzeigen") untergebracht sind. Zusätzlich bieten Untermodule Links zu Medien sowie anderen Detailseiten und Knowledge Cards.

Der aktuelle Prototyp umfasst unter anderem folgende Features und Seiten, welche das Funktions- und Informationsangebot des bisherigen Katalogs erweitern (siehe Abb. 1 für eine grafische Übersicht):
  • Eine erweiterte Autocomplete-Funktion (siehe Abb. 6), welche nicht nur Literatur und Medien aufführt, sondern auch (FRBR-) Werke, Personen und Themen (Schlagworte) und diese als solche kennzeichnet. Die verlinkten und angereicherten Daten ermöglichen ausserdem die Suche in Pseudonymen, alternativen Schreibweisen, anderen Sprachen etc.
  • Detailseiten für Werke (Werkseiten), Autoren (Autorenseiten) und Themen (Themenseiten) (siehe Abb. 5). Hierbei handelt es sich um Aggregationsseiten mit zusätzlichen Angaben zu einem Werk (z.B. Kurzzusammenfassung des Inhalts), Autor (z.B. Lebensdaten, assoziierte Bewegung oder Stilrichtung, verwandte Personen) oder Thema (z.B. über- und untergeordnete Begriffe). Neben den Zusatzangaben sind hier auch „Module“ bzw. Empfehlungen vorhanden, welche zum einen auf Literatur (Medien über einen Autor, Literatur zu einem Thema etc.), aber auch auf andere Detailseiten verweisen (Autoren mit ähnlichen Themen, Werke von Autoren derselben Bewegung, mit einem Autor in Verbindung gebrachte Themen etc.).
  • Übersichtsseiten für Werke, Autoren und Themen, welche als Browsing-Einstieg dienen sollen. Der Nutzer kann hier im Pool von Detailseiten stöbern und die Suche mittels Filter weitereinschränken.
  • Geclusterte Trefferseiten (erreichbar via Suche oder Browsing) mit vier Tabs (siehe Abb. 3 und Hintergrund von Abb. 4): Neu können in der Trefferliste nicht nur Literatur und Medien aufgelistet werden, sondern auch die Detailseiten, wobei für jeden Typ Detailseite (Werkseiten, Autorenseiten und Themenseiten) ein eigenes Tab zur Verfügung steht. In jedem Tab sind die Filter mit Bezug auf Literatur und Medien, Werke, Autoren bzw. Themen angepasst.
  • Knowledge Cards (siehe Abb. 4) für Werke, Autoren und Themen, welche via Klick auf ein Icon eine Kurzform der Detailseite (des entsprechenden Werks, Autors oder Themas) einblenden. Dies ermöglicht eine schnelle Orientierung zu Werk, Autor oder Thema.

Schritt 3: Implementierung


Im Sommer 2015 wurde damit begonnen den Prototyp innerhalb des für linked.swissbib.ch genutzten Discovery Systems VuFind (Zend-Framework) zu implementieren. Die Umsetzung erfolgte dabei zunächst in Form von statischen Webseiten (HTML, CSS) mittels statischer Dummy-Daten. Anschliessend wurde damit begonnen, die Seiten so zu adaptieren, dass deren Inhalte/Daten dynamisch über Abfragen des Suchmaschinenindex‘ (Elasticsearch) aufgebaut werden.

Abb. 6: Erweiterte Autocomplete-Funktion, die Treffer geclustert nach Literatur und Medien, Werke, Autoren sowie Themen vorschlägt und auf eine Trefferliste (grün, "Alle Ergebnisse anzeigen") oder direkt auf Detailseiten (grau) verlinkt.

Ein wichtiger Bestandteil der Implementierung ist die Integration neuer Suchfunktionalitäten für die Elasticsearch Suchmaschine, welche die Präsentation der verlinkten und angereicherten Daten überhaupt erst zulassen. So wurde beispielsweise eine Multisearch implementiert, welche es erlaubt, mit einer einzigen Abfrage in mehreren "Datentypen" (also z.B. Werk und Person und Thema) nach dem gleichen Suchparameter (z.B. einer ID) zu suchen. So können zum Beispiel im Falle der Autorenseite anhand der Autoren-ID auch verknüpfte Daten abgerufen werden (z.B. Bild, Lebensdaten, Kurzbiografie). Zusätzlich wurde ein AJAX-Controller in linked.swissbib integriert, welcher es ermöglicht, Daten ohne einen kompletten Page Reload nachzuladen. Anwendung findet dieser beispielsweise in der Knowledge Card: Wird Schiller auf Goethes Autorenseite im Modul „Autoren derselben Epoche“ aufgeführt, kann Schillers Knowledge Card mit Daten befüllt werden, ohne dass die komplette Seite neu geladen werden muss.

Eine weitere Ergänzung, welche bereits implementiert ist, stellt die neu eingebaute bzw. verbesserte Autocomplete-Funktion dar. Hierfür wurde die Bibliothek typeahead.js von Twitter verwendet.

Ausblick


Das Autocomplete, die Personenseiten sowie die Knowledge Cards wurden bei der Umsetzung prioritär behandelt. Diese Elemente sind in der Entwicklung entsprechend am weitesten fortgeschrittenen. In einem nächsten Schritt werden nun Seiten und Funktionen mit Bezug zu Themen (z.B. Themenseite) in Angriff genommen.

Donnerstag, 28. April 2016

Swissbib data goes linked 2: Verlinkung und Anreicherung / Interconnexion et enrichissement

Deutsche Version Version française

Serie "Swissbib data goes linked"
Teil 1 | Teil 2 | Teil 3 | Teil 4

In diesem Beitrag aus der Artikelserie zum SUK P-2-Projekt linked.swissbib.ch möchten wir die eingesetzten Techniken zu Verlinkung und Anreicherung des swissbib-Datensatzes vorstellen. Mit diesem Arbeitspaket beschäftigt sich GESIS – Leibniz-Institut für Sozialwissenschaften in Köln. Die Arbeitsgruppe, bestehend aus Felix Bensmann, Philipp Mayr, Benjamin Zapilko und Priyanka Dank, erprobt und implementiert Methoden, um die in Swissbib vorhandenen Metadaten mit bekannten quelloffenen Datenkorpora wie z.B. der Virtual International Authority File (VIAF) oder DBpedia zu verknüpfen. Die besondere Herausforderung besteht dabei im Umgang mit den sehr großen Datenmengen, allein der Bestand von Swissbib liegt bereits mit ca. 39 GB vor. Diese entfallen auf ca. 21 Mio. Dokumente (i.S.v. Publikationen), ca. 5,8 Mio. Personen und weitere Typen in RDF/XML-Repräsentation.

Überblick


Als Ausgangspunkt für unsere Arbeiten verwenden wir ausschließlich die Personendaten aus Swissbib. Diese werden im Rahmen der Metadatentransformation aus dem klassischen Swissbib mit den übrigen Daten exportiert, in das RDF/XML-Format überführt und für die Anreicherung weiterverarbeitet.
Das Resource Description Framework(RDF) eignet sich auf Grund seiner Natur besonders für die Verlinkung. Als grundlegender Baustein des Semantic Web, zu dem auch die Linked Open Data (LOD) gehören, liegen die Korpora der Linked Open Data Cloud und eben auch DBpedia und VIAF in diesem Datenmodell vor. In der Folge können wir uns an bestehenden Arbeiten orientieren. Die Eingrenzung auf Personendaten ermöglicht uns außerdem, unsere Methoden an einem abgeschlossenen Anwendungsfall zu erproben. Die erprobten Methoden sollen später auf weitere RDF-Konzepte übertragbar sein.
Nachdem die Verlinkung stattgefunden hat und die Links zwischen den Personen der beteiligten Korpora vorliegen, reichern wir die Personen in Swissbib mit den Zusatzinformationen der Personen aus den externen Korpora an. Abschließend werden die Personendaten in den übergreifenden Verarbeitungsprozess zurückgeleitet.
Bei der ersten Inbetriebnahme ist der Vorgang einmalig für alle Personendaten zu durchlaufen, danach sollen täglich nur noch die Personendatensätze verarbeitet werden, die zwischen den Durchläufen verändert wurden.
Im Weiteren wollen wir den Verarbeitungsprozess kurz vorstellen.

Vorprozessierung


Das Ziel im ersten Schritt ist es, die Daten für die Verlinkung vorzubereiten. Bei der Verlinkung werden alle fraglichen Ressourcen des internen Korpusses mit allen fraglichen Ressourcen eines externen Korpus anhand verschiedener Kriterien verglichen. Wenn alle Kriterien erfüllt sind, wird angenommen, dass die beiden Vergleichspartner identisch sind und es wird ein Link ausgegeben. Bei zwei Korpora mit n und m Personen sind n*m Vergleiche notwendig. Etablierte Werkzeuge wie beispielsweise das Silk-Frameworkder Universität Mannheim oder LIMESder AKSW Research Group der Universität Leipzig, setzen diese Funktionen bereits um. Darüber hinaus bieten sie weit entwickelte Methoden um den Vergleichsaufwand zu minimieren. Bei einer Vollverlinkung weisen beide Werkzeuge einen enormen Memory footprint auf, was dazu führt, dass der Arbeitsspeicher schneller befüllt wird, als der Garbage-Collector Speicherplatz freigeben kann, in der Folge werden die Threads der Programme einer nach dem anderen von der JVM beendet. Eine direkte Verlinkung der Daten ist somit nicht möglich. Um dem entgegenzuwirken, teilen wir die Daten in kleinere Vergleichsmengen auf. Hierfür verwenden wir ein selbstentwickeltes prototypisches Kommandozeilenwerkzeug mit dem Namen ReshapeRDF.
Zunächst werden die Daten der Korpora jeweils in N-Tripleskonvertiert und in je einer Datei zusammengefasst. Bei diesem Vorgang müssen keine größeren Datenmengen im Arbeitsspeicher gehalten werden. Im nächsten Schritt werden die N-Triples alphabetisch sortiert (Unicode-Order), sodass die Statements einer Ressource direkt aufeinander folgen (s. Abb. 1).

Abb. 1: Sortierte N-Triples

Die sortierten N-Triples stellen das Ausgangsformat für die nachfolgenden Schritte dar. Darin werden die zu verlinkenden Ressourcen, Personen, extrahiert und Statements, welche für die Verlinkung nicht benötigt werden, werden entfernt. Anschließend werden die Personen auf mehrere Dateien aufgeteilt. Hierzu wenden wir ein einfaches Blocking an. Im Gegensatz zu einer einfachen Aufteilung müssen hier später nur noch die einander entsprechenden Blöcke verlinkt werden (s. Abb. 2). Als Kriterium für die Blockbildung wird jeweils der Anfangsbuchstabe des Nachnamens verwendet.

Abb.2: Verlinkung mit einfacher Aufteilung (l) im Vergleich zu Blocking (r)

Unser Ansatz mit sortierten N-Triples eignet sich vor allem für regelmäßige Datenstrukturen, wie wir sie bei größeren Datenmengen erwarten. Die Vorprozessierung dauert auf unserem System (192 GB RAM, 32x2,0 GHZ Multicore-Prozessor, HDD-Festplatte) etwa 4,5 Stunden für Swissbib, 6,5 Stunden für DBPedia und 17 Stunden für VIAF. Die Zeiten schwanken je nach Rechnerauslastung stark.

Verlinkung


Es werden die Personen zweier Blöcke kreuzweise mit einander verglichen. Eine Vergleichsvorschrift gibt an, welche Properties der Personen auf welche Weise miteinander verglichen werden sollen. Diese muss vorab von einem Anwender definiert werden. Abb. 3 zeigt ein Beispiel für den Vergleich zweier Personen.

Abb. 3: Vergleichsvorschrift für die Verlinkung

Bei LIMES und Silk kann die Vorschrift mit Hilfe einer domänenspezifischen Sprache angegeben werden. Beispielsweise können Properties mit unterschiedlichen Namen einander zugeordnet werden, oder es können Ähnlichkeitsmetriken mit Schwellwerten für den Vergleich angegeben werden. Je mehr Properties wir vergleichen, desto höher ist die Wahrscheinlichkeit korrekte Links zu finden. Im vorliegenden Fall geschieht der Vergleich anhand der Werte der Properties für die Vornamen, Nachnamen und Geburtsdaten. Wir setzen LIMES ein, da dieses bei uns das bessere Laufzeitverhalten zeigt. Wird Gleichheit erkannt, dann wird ein owl:sameAs-Statement ausgegeben, das den Link repräsentiert.
Aus Gründen der Performanz generieren wir für jeden Vergleich zweier Blöcke eine Konfigurationsdatei und starten mehrere Vergleiche simultan. Auf unserem System dauert die Verlinkung mit VIAF etwa zwei Stunden und die mit DBpedia etwa eine halbe Stunde.

Anreicherung und Verifikation


Mit Hilfe der gefundenen Links extrahieren wir mit ReshapeRDF die zugehörigen Personen aus dem externen Korpus. Dies machen wir für jeden externen Korpus gegen den wir verlinken. Diese externen Daten werden mit den Personendaten des internen Korpus zusammengeführt. Abschließend werden alle Daten sortiert, Duplikate werden entfernt und die Daten werden in den übergreifenden Verarbeitungsprozess zurückgeführt. Die Anreicherung nimmt ungefähr zwei Stunden in Anspruch.
Die Links können stichprobenartig intellektuell überprüft werden. Dazu haben wir eine Benutzeranwendung entwickelt, die es Anwendern erlaubt, die Ressourcen, welche durch einen Link verknüpft sind, zu inspizieren. Die Anwendung mit Namen Linkinspect greift dazu via SPARQL auf Triplestores zu und stellt die Ressourcen einander gegenüber. Der Nutzer hat dabei die Möglichkeit mittels Browsing in den Triplestores zusätzliche Informationen zu einer Ressource anzuzeigen.

Fazit


Dieser Artikel beschreibt die Vorprozessierung, Verlinkung und Anreicherung von Personendaten in Swissbib mit Informationen aus externen Korpora der LOD wie DBpedia und VIAF. Hierbei spielen die großen Datenmengen und die damit verbundenen langen Prozessierungszeiten eine besondere Rolle. Wir zeigen einen Ansatz, wie mit Hilfe eines speziellen Datenformats und verschiedenen Werkzeugen, diese Zeiten optimiert werden können. Im Vergleich zu einem naiven Ansatz konnten wir uns bei der reinen Verlinkung um den Faktor 20 verbessern.
Wir gehen davon aus, dass die einzelnen Vorprozessierungen, Verlinkungsprozesse und Anreicherungen, weitestgehend parallel zueinander ausgeführt werden können. Weitere Optimierungsmöglichkeiten sehen wir darin, den Grad der Flexibilität reduzieren und in der Vorprozessierung ein Pipelining-Konzept, wie in Metafacture, einsetzen. Dies ist aber nur teilweise möglich.
Bei der Bearbeitung sind wir auf zwei wesentliche Hürden gestoßen: Zum einen können wir im vorgegebenen Zeitraum keine Personendisambiguierung vornehmen, sodass in der Ausgabe Personen mehrfach aufgeführt werden, zum anderen sind teils nicht ausreichend Informationen vorhanden um hochwertige Links zu erstellen. Hier beschränken wir uns auf Personen über die mehr Informationen vorliegen. Darüber hinaus arbeiten wir an Verfahren die Information verbundener Dokumente miteinbeziehen.

Mittwoch, 13. April 2016

Swissbib data goes linked 1: Metadatentransformation, Modellierung, Indexierung / Transformation des métadonnées, modélisation, indexation

Deutsche Version Version française

Serie "Swissbib data goes linked"
Teil 1 | Teil 2 | Teil 3 | Teil 4

Das SUK P-2-Projekt linked.swissbib.ch baut auf Basis der bestehenden Datensätze von swissbib eine angereicherte und im Sinne des Semantic Web verlinkte Metadatenstruktur auf (Abstract, Präsentation). Den Benutzerinnen und Benutzer des Bibliothekskataloges wird ein Mehrwert geboten, indem durch die Anreicherung von bibliographischen Informationen mit Daten aus weiteren Quellen (DBPedia, VIAF) neue explorative Suchmöglichkeiten zur Verfügung gestellt werden. Durch die Verlinkung mit Referenzdatensätzen des Semantic Web wird zudem die Weiternutzung der Daten auch über die bibliothekarische Domäne hinaus begünstigt.

Dieser und eine Reihe weiterer Artikel sollen einen Überblick über den Stand der Arbeiten im bis Anfang 2017 laufenden Projekt geben. Der Fokus liegt primär auf den verwendeten Applikationen und Techniken sowie auf ausgewählten Details der Implementierung. Die Abfolge der Texte richtet sich ungefähr nach dem konzipierten Workflow für linked.swissbib.ch, welcher folgende Teilschritte vorsieht (s. Abb. 1):
  1. Transformation der swissbib-Metadaten in ein RDF-Serialisat sowie deren Aufteilung in verschiedene bibliothekarische Konzepte
  2. Indexierung der transformierten Daten
  3. Datenanreicherung durch Verlinkung mit weiteren Quellen (im Moment DBPedia und Viaf) mithilfe von LIMES und reshaperdf
  4. Präsentation der angereicherten Daten in der VuFind-basierten Suchoberfläche
  5. Web API als maschinell nutzbare Schnittstelle zum Index

Übersicht Workflow linked.swissbib.ch
Abb. 1: Übersicht Workflow linked.swissbib.ch (Stand April 2016)

Teil 1: Metadatentransformation, Modellierung und Indexierung

Metadatentransformation
Grundlage für das linked-swissbib-Projekt bilden die circa 21 Millionen Datensätze im MARC-XML-Format, welche aus einem vorgelagerten Clustering sehr ähnlicher bis identischer Katalogisate resultieren. MARC ist zwar ein weltweit verbreitetes Datenformat, sein Einsatzgebiet ist jedoch auf die Bibliotheken beschränkt. Um eine Weiternutzung auch über diese Domäne zu ermöglichen, ist es daher notwendig, die Daten in einem Format anzubieten, das agnostisch gegenüber einer bestimmten Verwendung ist. Das Resource Description Framework RDF bietet eine solche Möglichkeit. RDF gibt einen Rahmen vor, in dem über beliebige Dinge (Ressourcen) logische, das heisst maschinell ableitbare Aussagen gemacht werden können. Dadurch, dass in RDF auch Aussagen über Aussagen möglich sind (Reifikation), können domänenspezifische Vokabularien erstellt und diese wiederum miteinander verknüpft werden.
Als Modell gibt RDF ein syntaktisches Schema für Aussagen vor - eine solche entspricht immer einem gerichteten Graphen mit einem Subjekt, einem Prädikat und einem Objekt -, aber kein spezifisches Format. In linked-swissbib haben wir uns für JSON-LD als Zielformat entschieden, einem JSON-Dialekt für Linked Data. Das offen standardisierte JSON-LD ist ein relativ versatiles, je nach Verwendungszweck verschieden serialisierbares Format und eignet sich insbesondere auch für maschinenlesbare Schnittstellen.
Um die MARC-Datensätze zu transformieren, benutzen wir Metafacture, das ursprünglich im Rahmen der Culturegraph-Plattform entwickelt wurde. Der grosse Vorteil der Open-Source-Applikation besteht neben ihrer Performanz - Datensätze werden grundsätzlich parallel verarbeitet - in der Möglichkeit, dass MetadatenspezialistInnen ohne Programmierkenntnisse und mit wenig Erfahrung in XML nach kurzer Zeit in der Lage sind, auch komplexe Transformationsregeln zu definieren. Dabei sind zwei Aspekte zentral: Erstens lassen sich mithilfe der domänenspezifischen Sprache Flux sogenannte Metafacture-Commands - die für einzelne Teilschritte in der Transformation stehen, beispielsweise das Einlesen einer Datei oder das Parsen eines bestimmten Formats - zu einer Pipeline zusammenstecken (s. Abb. 2). Die Existenz entsprechender Commands vorausgesetzt, lassen sich so Input- und Outputformat fast beliebig kombinieren. Die eigentlichen Transformationsregeln können dann zweitens in sogenannten Morph-Definitionen (XML-Syntax) auf Ebene der einzelnen Datenfelder deklariert werden. Die Möglichkeiten sind auch hier sehr vielfältig, erfordern aber bei der Transformation von komplexeren Datenstrukturen ein systematisches Ausprobieren. Damit auch Sonderfälle in den MARC-XML-Daten berücksichtigt werden konnten, wurden in linked-swissbib Qualitätskontrollen mit Stichproben durchgeführt. Die Konversion konnte so inkrementell getestet und verbessert werden.

Metafacture-Workflow
Abb. 2: Metafacture-Pipeline (vereinfacht)

Für das Projekt haben wir Metafacture mit verschiedenen Commands erweitert. Bislang sind das u.a. eine verbesserte Serialisierung von Dokumenten in JSON-LD, die Implementierung eines Batch-Mechanismus zur Indexierung auf dem Suchserver und Methoden zur Interaktion mit einer Graphendatenbank zum Verfolgen von Veränderungen an der Datenstruktur.

Modellierung
Neben der Transformation werden die monolithischen bibliographischen Datensätze in verschiedene Konzepte aufgeteilt. Diese Modellierung hat zum Ziel, sowohl auf die Bedürfnisse der Endnutzer nach verlinkten Daten zu berücksichtigen als auch die Möglichkeiten und Beschränkungen der zur Verfügung stehenden Daten in Betracht zu ziehen. Zu diesem Zweck wurden Use Cases entwickelt und zwei wichtige bibliographische Datenmodelle evaluiert: FRBR und BIBFRAME. Ergebnis waren sechs distinkte Konzepte, die partielle Anreicherung sowie die Verknüpfung der Daten - miteinander und mit externen Quellen erlauben (in Klammern angegeben sind die in der Suchmaschine verwendeten types, die den sechs Konzepten entsprechen, s.u.):
  • Aufnahme (bibliographicResource): Bibliographische Daten zur Aufnahme
  • Metadaten zur Aufnahme (document): Metadaten zum Datensatz
  • Holdings (item): Exemplardaten
  • Werk (work): Zusammenzug von bibliographischen Daten verschiedener Manifestationen
  • Personen (person): Autoren
  • Organisationen (organisation): Körperschaften und Kongresse

Prozentualer Anteil der sechs Konzepte
Abb. 3: Prozentualer Anteil der sechs Konzepte

Aus den 21 Millionen ursprünglichen Datensätze werden so momentan 97 Millionen Dokumente (s. Abb. 3), wobei der grösste Teil auf die Holdings sowie die Aufnahmen und deren Metadaten entfällt. Einige kodierte oder normalisierte Felder erlaubten es, schon in der Modellierungsphase und vor jeder Interlinkingoperation, Links zu externen Referenzdatensets automatisch zu erstellen: Geonames für Publikationsländer und -kantone, RDA für Medien- und Inhaltstypen und Lexvo für Sprachen. Zudem wichtig für die Weiternutzung der Daten ist die Verwendung von URI (Uniform Resource Identifiers) für die eindeutige Identifizierung von RDF-Ressourcen (was der ersten der sogenannten vier Linked-Data-Regeln von Tim Berners-Lee entspricht). Im Projekt konnte für die Generierung solcher URI auf bereits existierende ID in den MARC-XML-Daten oder aber auf auf Feldwerten basierende Hashes zurückgegriffen werden.

Relationen der einzelnen Konzepte untereinander
Abb. 4: Relationen der einzelnen Konzepte

Zwischen den einzelnen Konzepten bestehen verschiedene Referenzierungen (s. Abb. 4), so dass es jederzeit möglich ist, die ursprüngliche bibliographische Ressource wieder zu erzeugen. Jeder Konzept wird mit verschiedenen Eigenschaften in Details beschrieben. Eine statistische Analyse der Datenheiten (Frequenz der Felder und Unterfelder in den MARC-XML-Daten) diente zur Bestimmung der wichtigsten Informationen, die nach RDF überführt werden sollten. Um eine hohe Wiederverwendbarkeit der RDF-Repräsentationen der Daten sicherzustellen, wurden vorwiegend RDF-Properties aus bekannten Fachontologien (Dublin Core, BIBO, FOAF, RDA, usw.) verwendet.

Indem die Ressourcen fragmentiert indexiert werden, lassen sich aber auch unkompliziert einzelne, eventuell zusätzlich angereicherte Konzepte für aggregierte Themenseiten, beispielsweise zu einer bestimmten Autorin, aus dem Index auslesen.

Index
Das zentrale Element der linked.swissbib.ch-Infrastruktur ist unser Suchindex. Sowohl die Suchoberfläche wie auch die Web API werden im produktiven Betrieb direkt auf diesen Index zugreifen, daher sind hohe Verfügbarkeit, performante Indexierung und geringe Latenz bei Suchanfragen entscheidende Faktoren. Im Testbetrieb befindet sich der Index auf einem Elasticsearch-Cluster mit drei Knoten auf drei verschiedenen Hosts, wobei ein horizontales Skalieren problemlos möglich wäre. Um eine genügend hohe Indexierungsrate zu erzielen, betten wir die Daten in das Bulk-Format von Elasticsearch ein, welches Batch-Uploads von mehreren Tausend Dokumenten zulässt. So dauert eine Vollindexierung der 97 Millionen Dokumente auf unserem Cluster 6 bis 8 Stunden. Schliesslich arbeitet Elasticsearch intern mit sogenannten shards (Bruchstücke), in die der Index aufgesplittet wird und die ihrerseits über die verschiedenen Knoten im Cluster verteilt werden. Da der Server zudem auf den verschiedenen Knoten Replikate der shards erstellt, kann die Rechenlast bei Abfragen über die Hosts verteilt werden.

Elasticsearch basiert ebenso wie das von "classic" swissbib verwendete Solr auf Lucene. Im Gegensatz zu Solr serialisiert Elasticsearch Dokumente intern im JSON-Format, womit unsere JSON-LD-Dokumente ohne weitere Anpassungen indexiert und über eine integrierte REST-Schnittstelle auch wieder ausgegeben werden können. Die Konzepte werden im Suchindex in jeweils einem eigenem type gespeichert. Ein type ist eine Klasse von Dokumenten (Datensätzen) mit einer Schnittmenge an gleichnamigen Feldern (Schlüssel-Wert-Paaren) und mit einer geteilten Definition (Mapping), wie diese Felder indexiert und analysiert werden müssen. Einzelne Dokumente eines bestimmten types müssen nicht für jedes im Mapping definierte Feld ein Schlüssel-Wert-Paar liefern, anderseits werden aber auch nur diejenigen Paare indexiert, zu denen eine Definition im Mapping existiert. Dies ermöglicht es, auch unterschiedlich vollständige Aufnahmen ohne grossen Aufwand zu indexieren.