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.


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.


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.


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.


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).


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.


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.

Le but du projet linked.swissbib.ch de la CUS P-2 est de relier et d’enrichir quelques 20 bases de données bibliographiques de toute la Suisse avec des contenus d’autres sources telles que DBpedia et VIAF. Les défis comprennent dans ce contexte la modélisation et le mapping des données, leur interconnexion, mais également leur représentation et les interfaces utilisateur afférentes (GUI). Ce dernier point est abordé dans ce billet de blog.


L’enrichissement des données et leur nouvelle structure rendent nombre de nouvelles fonctions et fonctionnalités possibles dans l’optique de développer les catalogues de bibliothèques traditionnels. Dans le cadre de linked.swissbib.ch, c’est le Schweizerische Institut für Informationswissenschaft (SII) de la HTW Chur qui se penche sur la création de concepts d’interfaces utilisateur adaptés et sur leur implémentation (y compris des fonctionnalités de recherche). Les travaux peuvent se répartir en trois grandes étapes:

Etape 1: création d’un état de l’art des portails LOD

Au début du projet, une analyse de l’utilisation des Linked (Open) Data dans le contexte des bibliothèques et des services d’information scientifiques a été réalisée. Pour ce faire, une douzaine de portails LOD (par exemple data.bnf.fr ; datos.bne.es) ont été comparés, une analyse ensuite complétée par des recherches documentaires. En vue de la création d’un portail permettant la recherche dans les structures d’information interconnectées ainsi que leur visualisation, un état de l’art dans ce domaine a été établi de manière systématique.


Il s’agissait d’une part de développer un savoir-faire sur les scénarios possibles et les valeurs ajoutées potentielles pouvant être créés au moyen d’un modèle de données ouvert et flexible. D’autre part, le but était – grâce à l’analyse de l’état de l’art – de recueillir des informations sur la faisabilité des fonctions et de prioriser leur implémentation pour le portail linked.swissbib.ch. De cette manière, l’adéquation du modèle de données a été évaluée et des ajustements ont été entrepris dans la modélisation et dans la définition des fonctionnalités prévues.

Etape 2: prototype

Sur la base de cette analyse, un prototype interactif de la GUI a été développé au moyen du logiciel Axure RP. Il s’appuie sur le visuel et le fonctionnement du métacatalogue swissbib tel qu’il apparaît au public aujourd’hui (www.swissbib.ch). Le concept de GUI tout comme le design d’interaction du catalogue actuel ont été étendus pour prendre en compte les nouvelles possibilités offertes par l’interconnexion des données pour la mise à disposition de contenus supplémentaires.



La première version du prototype a été conçue peu après le lancement du projet, c’est-à-dire à un stade encore précoce du projet durant lequel le genre et l’étendue des données RDF (enrichies) n’étaient pas encore connus. Cela présentait l’avantage d’une réflexion et d’un processus de conception (dans cette première phase) soumis à aucune restriction. Le prototype a donc été développé sans conditionnement à une implémentation complète de toutes les fonctions et fonctionnalités au sein du projet linked.swissbib.ch. Il représente bien plus un idéal démontrant les possibilités des Linked Data dans le cadre de swissbib. Le prototypage contient déjà la détermination des informations externes requises (par exemple choix de données biographiques), mais la sélection définitive dépend fortement des données qui seront disponibles à la fin du projet, ce qui mène à des adaptations fréquentes des fonctions de l’interface.


Par la suite, sur la base de la quantité croissante de données disponibles et du feedback des partenaires du projet, le prototype d’interface a été constamment adapté et même soumis à de premières évaluations par les utilisateurs (d’un côté dans le cadre d’un cours du Bachelor en Science de l’information de la HTW Chur, d’un autre côté dans divers travaux de Bachelor).


Le prototype actuel comprend entre autres les fonctions et pages suivantes, complétant l'offre de fonctionnalités et d'informations du catalogue classique (voir figure 1 pour une vue d'ensemble):

• Une fonction d’autocomplétion élargie (voir figure 6), ne proposant pas uniquement des documents et médias, mais également des œuvres (au sens de FRBR), des personnes et des thèmes (mots-clés), chacun signalé dans la catégorie correspondante. Les données enrichies permettent de plus la recherche au moyen de pseudonymes, formes de nom alternatives, autres langues, etc.
• Des pages détaillées pour les œuvres (pages œuvres), auteurs (pages auteurs) et thèmes (pages thèmes) (voir figure 5). Il s’agit ici de pages d’agrégation avec des informations supplémentaires sur une œuvre (par ex. bref résumé du contenu), un auteur (par ex. dates de vie et de mort, mouvement ou style littéraire lié, personnes associées) ou un thème (par ex. thèmes plus généraux ou plus spécifiques). En plus de ces données additionnelles, la page contient aussi des "modules" ou des recommandations, qui renvoient d'une part vers des documents (médias à propos d'un auteur, documents traitant d'un thème, etc.) et d'autre part vers d’autres pages détaillées (auteurs avec des thèmes similaires, œuvres d’auteurs du même mouvement, thèmes d’un auteur associé).
• Des pages d’aperçu pour les œuvres, les auteurs et les thèmes, incitant à la navigation (browsing). Au moyen de filtres, l’utilisateur peut ici explorer l’ensemble des pages détaillées et restreindre sa recherche.
• Des pages de résultats clusterisées (accessibles par la recherche ou la navigation) avec quatre onglets (voir figure 3 et arrière-plan de figure 4). Elles contiennent désormais, en plus des documents et médias, des pages détaillées, avec un onglet séparé pour chaque type de contenu (Pages œuvres, Pages auteurs, Pages thèmes). Au sein de chaque onglet, les facettes sont adaptées pour permettre de filtrer des résultats en lien avec des documents, des œuvres, des auteurs, etc.
• Des knowledge cards (voir figure 4) pour les œuvres, les auteurs et les thèmes, qui s’ouvrent grâce à des icônes présentes sur diverses pages et affichent une synthèse de la page détaillée avec de brèves informations sur l’œuvre, l’auteur ou le thème en question.

Etape 3: implémentation

L’implémentation du prototype au sein de VuFind (framework Zend), l’outil d’exploration utilisé pour linked.swissbib.ch, a débuté durant l’été 2015. Elle a d’abord abouti à la création de pages web statiques (HTML, CSS) au moyen de données statiques factices. Ensuite, ces pages ont été adaptées progressivement afin d’intégrer du contenu / des données de manière dynamique par des requêtes dans l’index du moteur de recherche (Elasticsearch).


Un élément important de l’implémentation consiste en l’introduction de nouvelles fonctionnalités pour le moteur de recherche Elasticsearch, dans le but de permettre l’accès aux données liées. Ainsi a été installée, entre autres, une Multisearch, qui rend possible la recherche au moyen d’une seule requête dans plusieurs "types de données" (par ex. œuvres et personnes et thèmes) selon le même paramètre (par ex. un identifiant). Par exemple dans le cas des pages auteurs, les données enrichies (portrait, date de naissance, brève biographie, etc.) peuvent être interrogées grâce à ce mécanisme, au moyen de l’identifiant de l’auteur. En outre, un contrôleur AJAX permettant de charger des données sans devoir recharger toute la page a été intégré à swissbib. Il trouve son utilité par exemple pour les knowledge cards: si Schiller apparaît dans la page auteur de Goethe sous la rubrique "auteurs de la même époque", sa knowledge card sera remplie de données sans que la page entière ne doive être rechargée.

Un autre complément réside dans la fonction d’autocomplétion nouvellement ajoutée et améliorée. Pour celle-ci, la bibliothèque typeahead.js de Twitter a été utilisée.

Perspectives

L’autocomplétion, les pages personnes ainsi que les knowledge cards ont été traitées en priorité dans l’implémentation. Le développement de ces éléments est logiquement à un stade plus avancé. La prochaine étape abordera donc les pages et fonctions en lien avec les thèmes (pages thèmes).

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).


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.


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.


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.

Dans cet article issu de la série de contributions sur le projet CUS-P2 linked.swissbib.ch, nous souhaitons présenter les techniques mises en œuvre pour relier et enrichir le jeu de données swissbib. Ce volet du projet est réalisé par GESIS – Leibniz-Institut für Sozialwissenschaften à Cologne. Le groupe de travail, constitué de Felix Bensmann, Philipp Mayr, Benjamin Zapilko et Priyanka Dank, teste et implémente des méthodes permettant de relier les métadonnées disponibles dans swissbib avec des corpus de données ouverts de référence tels que Virtual International Authority File (VIAF) ou DBpedia. L'enjeu majeur réside dans la manipulation d'une très grande masse de données, swissbib à lui seul en comportant environ 39 GB. Ces données correspondent à environ 21 mio de documents (i.e. publications), 5,8 mio de personnes ainsi que d'autres types représentés en RDF/XML.

Introduction générale

Comme base pour notre travail, nous utilisons exclusivement les données de swissbib sur les personnes. Dans le cadre de la transformation, ces données sont exportées du swissbib "classique" avec les autres données, puis converties en format RDF/XML et traitées pour l'enrichissement.
En raison de sa nature, le Resource Description Framework (RDF) se prête particulièrement bien à l'interconnexion. Mis à disposition selon ce modèle, les jeux de données du Linked Open Data Cloud, comprenant justement DBpedia et VIAF, sont un pilier fondamental du web sémantique et des Linked Open Data (LOD). Par la suite, nous pouvons nous orienter sur des travaux existants. La restriction aux données sur les personnes nous permet en outre de mettre à l'épreuve nos méthodes sur un cas d'application concret et ciblé. Les méthodes testées doivent être transposables ultérieurement sur d'autres concepts RDF.
Après la phase d'interconnexion, lorsque les liens entre les personnes des corpus concernés sont établis, nous enrichissons les personnes de swissbib avec les informations complémentaires provenant des jeux de données externes. Enfin, les données enrichies sont reversées dans le processus de traitement global de swissbib.
Pour la première mise en production, toutes ces étapes doivent être réalisées une fois. Par la suite ne devront être retraitées quotidiennement que les données de personnes qui auront été modifiées le jour en question.
Ci-dessous, nous présentons brièvement le processus de traitement.

Pré-traitement

Le but de la première étape est de préparer les données pour l'interconnexion. Lors de cette phase, toutes les ressources concernées dans le corpus de données interne sont comparées avec toutes les ressources concernées dans un corpus externe, selon divers critères. Si tous les critères sont remplis, les deux parties comparées sont présumées identiques et un lien est généré. En présence de deux corpus de n et de m personnes, le nombre de comparaisons nécessaires et de n*m. Des outils établis, comme par exemple le framework Silkde l'Université de Mannheim ou LIMESdu groupe de recherche AKSW de l'Université de Leipzig, mettent déjà en œuvre de telles fonctions. De plus, ils proposent des méthodes avancées pour minimiser le temps de calcul nécessaire. Lors d'une interconnexion complète, les deux outils ont une empreinte mémoire énorme, saturant la mémoire plus rapidement que ne peut en libérer le ramasse-miettes (garbage collector). Par conséquence, les threads du programme sont interrompus les uns après les autres. Ainsi, une interconnexion directe des données est impossible. Pour pallier ce problème, nous divisons les données en plus petites quantités comparables. Nous utilisons pour ce faire un prototype maison d'outil en ligne de commande nommé ReshapeRDF.
Ensuite, les données du corpus sont converties en N-Triples (triplets) et regroupées dans ces fichiers. Lors de ce processus, aucune grande quantité de données ne doit être gardée en mémoire. A l'étape suivante, les N-Triples sont triés en ordre alphabétique (ordre Unicode), afin que les déclarations sur une ressource soient rassemblées (voir figure 1).


Les N-Triples triés constituent le format de sortie pour l'étape suivante, où les ressources à relier - les personnes - sont extraites, et les déclarations inutiles pour l'interconnexion sont éliminées. Ensuite, les personnes sont réparties en plusieurs fichiers. Nous utilisons ici un mécanisme de blocking. Dans ce cas, contrairement à un simple fractionnement, seuls les blocs devront être reliés entre eux (figure 2). Le critère utilisé pour la constitution des blocs est à chaque fois la première lettre du nom de famille.


Notre approche par tri de N-Triples se prête bien avant tout pour les structures de données uniformes, présentes habituellement lors de grandes quantités de données.
Notre infrastructure (192 GB RAM, processeur multi-cœurs 32x2,0 GHZ, disque dur HDD) effectue la phase de pré-traitement en environ 4h30 pour swissbib, 6h30 pour DBpedia et 17h pour VIAF. Les durées varie beaucoup en fonction du niveau d'occupation du processeur.

Interconnexion

Les personnes de chaque paire de blocs sont comparées entre elles. Des paramètres de comparaison indiquent quelles propriétés doivent être confrontées, et de quelle manière. Ces spécifications doivent être définies au préalable. La figure 3 montre un exemple de comparaison entre deux personnes.


Dans LIMES et Silk, les paramètres sont spécifiés au moyen d'un langage dédié. Par exemple, des propriétés avec des noms différents peuvent être associées l'une à l'autre, ou des métriques de similarités avec des valeurs seuil pour la comparaison peuvent être précisées. Plus nous comparons de propriétés, meilleure sera la probabilité de déterminer des liens corrects. Dans le cas présent, la confrontation s'effectue selon les valeurs des propriétés des prénoms, des noms de famille et des dates de naissance. Pour linked.swissbib.ch, nous utilisons LIMES, car celui-ci est le plus efficace du point de vue du temps d'exécution. Lorsqu'une équivalence est reconnue, une assertion owl:sameAs est créée pour représenter le lien.
Pour des raisons de performance, nous générons un fichier de configuration pour chaque comparaison de deux blocs, et lançons plusieurs comparaisons simultanément. Dans notre infrastructure, l'interconnexion avec VIAF dure environ deux heures et celle avec DBpedia environ une demi-heure.

Enrichissement et vérification

Grâce aux liens trouvés, nous extrayons des jeux de données externes les personnes correspondantes au moyen de ReshapeRDF. Cette opération est réalisée pour chaque corpus ayant été interconnecté. Ces données externes sont ensuite fusionnées avec les données des personnes du corpus interne, puis triées. Enfin, les doublons éliminés et les données sont réintégrées dans le processus de traitement global. L'enrichissement nécessite environ deux heures.
Les liens peuvent être vérifiés intellectuellement par échantillons. Dans ce but, nous avons développé une application permettant à une personne de passer en revue les ressources qui ont été reliées. Cette application, nommée Linkinspect, accède aux triplestores via SPARQL et présente les ressources équivalentes en parallèle. L'utilisateur a alors la possibilité d'afficher plus d'informations au sujet d'une ressource en naviguant dans les triplestores.

Conclusion

Cet article décrit le pré-traitement, l'interconnexion et l'enrichissement des données de personnes de swissbib avec des corpus externes disponibles en LOD tels que DBpedia et VIAF. Dans ce contexte, les grandes quantités de données et les longs temps de traitement correspondants joue un rôle considérable. Nous démontrons ici une méthode permettant d'optimiser ces temps de traitement au moyen d'un format de données spécifique et de divers outils. Par rapport à une approche naïve, nous avons pu améliorer la performance de la simple interconnexion d'un facteur 20.
Nous partons du principe que les différents pré-traitements, interconnexions et enrichissements peuvent être exécutés en parallèle. Nous voyons d'autres possibilités d'optimisation dans la réduction du degré de flexibilité et dans la mise en place d'un concept de pipeline pour le pré-traitement, comme dans Metafacture. Ceci n'est cependant que partiellement possible.
Durant les travaux, nous avons rencontré deux obstacles principaux. D'une part, nous n'avons pas pu effectué de désambiguïsation des personnes si bien que certaines personnes apparaissent plusieurs fois à la fin du traitement. D'autre part, les informations ne sont parfois pas suffisantes pour établir des liens de qualité. Nous nous limitons donc ici aux personnes comportant le plus d'informations. De ce fait, nous travaillons sur un processus permettant d'inclure dans la comparaison les informations des documents liés.