swissbib mit Personen- und Themeninformationen / Des informations sur les personnes et les sujets dans swissbib

Deutsche Version Version française

Auf swissbib.ch stehen drei neue Elemente zur Verfügung, die das Funktions- und Informationsangebot deutlich erweitern.

  • Knowledege Cards für Personen und Themen können während der Recherche über Info-Buttons aufgerufen werden und ermöglichen eine schnelle Orientierung zu einer Person oder einem Thema.
    Zum Beispiel bei dieser Aufnahme: http://www.swissbib.ch/Record/404663893
  • Personen- und Themenseiten enthalten weiterführende Informationen zu einer Person oder einem Thema. Neben den zusätzlichen Angaben sind hier auch Sucheinstiege vorhanden, die eine explorative Suche ermöglichen. So können zum Beispiel Personen mit dem gleichen Genre oder Medien zu untergeordneten Themen entdeckt werden.
    Zum Beispiel:
    Personenseite von Dámaso Alonso
    Themenseite zu Historisches Drama
  • Erweiterte Autocomplete-Funktion, die bei der Eingabe neben Titeln auch VerfasserInnen sowie Themen zur Suche vorschlägt und direkt die Suche in diesen Feldern ermöglicht.

Diese Elemente wurden im Rahmen des Projekts linked.swissbib.ch erarbeitet und wurden nun in Zusammenarbeit mit der Firma Outermedia in swissbib.ch integriert.
Basis dafür ist die Transformation der swissbib-Daten in ein RDF-Serialisat sowie die Verlinkung und Anreicherung der Daten. Datenquellen für die angereicherten Daten zu Personen sind DBpedia und VIAF, sofern sie auf akzeptablem Qualitätsniveau sind. Für die Themen werden die Angaben aus der Gemeinsamen Normdatei (GND) bezogen.
Weitere Hintergrundinformationen für Interessierte finden Sie im swissbib Wiki unter Integration linked.

Wir wünschen Ihnen viel Spass beim Entdecken der neuen Möglichkeiten und sind gespannt auf Ihre Rückmeldungen!

Trois nouvelles fonctionnalités sont disponibles sur swissbib.ch. Elles élargissent les possibilités de recherche et de découverte d’informations.

  • Knowledge Cards pour des personnes et des sujets (thèmes). Pendant la recherche, en cliquant sur les boutons d’informations (i) vous pouvez consulter de brèves informations sur la personne ou le sujet.
    Par exemple: http://www.swissbib.ch/Record/404663893
  • Pages de personnes ou de sujets. Ces pages contiennent des informations détaillées sur des personnes ou des sujets. Vous y trouverez aussi des recherches apparentées, qui permettent une recherche exploratoire. Par exemple, il est possible de trouver des auteurs du même genre (par exemple science-fiction) ou de faire des recherches sur des sujets plus précis.
    Page de personne
    Page de sujet
  • Amélioration des suggestions lors de la frappe. Lorsque vous entrez des caractères dans le champ de recherche, des suggestions vous sont proposées comme titre, auteur/contributeur ou sujet.

Ces éléments ont été développés dans le cadre du projet linked.swissbib.ch et ont été intégrés dans swissbib.ch en collaboration avec l’entreprise Outermedia.

La Transformation des métadonnées, leur modélisation et indexation ainsi que leur Interconnexion et enrichissement sont la base de ces nouvelles fonctionnalités. Les sources de données pour les enrichissements de personnes sont DBpedia et VIAF, à condition qu’ils soient à un niveau de qualité acceptable. Pour les sujets, les informations sont actuellement tirées de la Gemeinsamen Normdatei (GND) de la bibliothèque nationale allemande. Ceci explique pourquoi les intitulés des sujets sont en allemand. Nous étudions actuellement la possibilité d’étendre ce mécanisme à des sujets francophones (par exemple RAMEAU).

Des informations additionnelles pour les personnes intéressées se trouvent sur le Wiki swissbib : Integration linked (en allemand seulement).

Nous vous souhaitons une bonne découverte et n’hésitez pas à nous faire part de votre feedback.

Weiterlesen

Was ist neu in swissbib? / Quoi de neuf dans swissbib?

Deutsche Version Version française

Liebe Blogleserinnen und Blogleser
In diesem Jahr war es relativ ruhig auf unserem Blog! Dabei gibt es eine Menge neue Funktionen, die wir schon längst vorstellen wollten. Mit dem hier folgenden Überblick holen wir das nun nach. Wir freuen uns auf eure kundige Einschätzung und euer Feedback.

Datenquellen

Die Dokumente der folgenden Quellen sind neu in swissbib zu finden:

Bis zum Jahresende werden wir ausserdem noch die folgenden Quellen integrieren:

  • Die im Volltext frei zugänglichen Dokumente der Forschungsplattform Alexandria der Universität St. Gallen.
  • Der Bestand der Kantonsbibliothek Thurgau

Nationallizenzen

Seit einigen Monaten haben Nutzer mit einem ständigen Wohnsitz in der Schweiz Zugang zu über 6 Millionen Dokumenten aus dem Projekt Nationallizenzen. Der Zugang und die Registrierung erfolgt über swissbib, in Partnerschaft mit dem Projekt SWITCH edu-ID (in swissbib anschauen).

Über die Nationallizenzen wird zudem die Open-Access-Publikation von Artikeln ermöglicht, die von Autoren, die einer Schweizer Institution angegliedert sind, verfasst wurden. Die betroffenen Metadaten und Volltexte wurden von swissbib aufbereitet und über RERO DOC veröffentlicht. Die Daten stehen auch für die Integration in die Institutionellen Repositories der Schweizer Hochschulen zur Verfügung.

Weitere Informationen sind in unserem Schlussbericht zum Projekt Nationallizenzen zu finden.

Linked Open Data

Das Projekt linked.swissbib.ch wurde Ende April 2017 abgeschlossen. Wir sind gegenwärtig damit beschäftigt, die Projektergebnisse im Hinblick auf eine Integration in swissbib zu konsolidieren.

Ein wichtiger Schritt war die Identifizierung und Kennzeichnung der offenen Metadaten. Wir freuen uns, dass inzwischen 85 % aller Daten von swissbib als Public Domain zugänglich sind (anschauen).

Für die Neugierigen unter euch: Werft gerne einen Blick auf data.swissbib.ch und linked.swissbib.ch, um zu sehen, was euch zukünftig erwartet. Die Portale sind aber erst als Beta-Version veröffentlicht. Wir befinden uns noch in der Konsolidierungsphase.

In einer Artikelserie in unserem Blog haben wir die verschiedenen Prozesse beschrieben. Ausserdem wurde ein Artikel zum Thema Interlinking Large-scale. Library Data with Authority Records publiziert.

Neue Funktionen

  • Verbesserte Facettensuche: Es ist neu möglich, Suchbegriffe durch Klicken auf das Kreuz rechts des Begriffs auszuschliessen. Mehrere gewählte Themen werden durch UND verknüpft. Die anderen Begriffe (Autoren, Sprache usw.) werden durch ODER verknüpft. Die gewählten sowie die ausgeschlossenen Suchbegriffe sind im Bereich «Filter löschen» sichtbar (weitere Informationen).
  • Verbesserte Anzeige der Hierarchie in den Archivbeständen: Zahlreiche Archivbestände sind in einer hierarchischen Struktur geordnet. In bestimmten Fällen kann diese Struktur im Reiter «Archive/Bestände» in swissbib angezeigt werden. (Beispiel).

Informationen zum System

  • Unser Datenverarbeitungstool CBS läuft inzwischen auf Version 8.
  • Das Update zur Version 4 unseres Discovery Tools VuFind ist praktisch abgeschlossen.
  • Alle unsere Server laufen nun unter Ubuntu 16.04.
  • Wir haben ein neues Statistik-Tool eingeführt, das auf der Analyse der Logs mit Elastic, LogStash und Kibana basiert.
  • Wir haben Sahi für automatisierte Tests der Web-Interfaces eingeführt.

Strategie und Zukunft von swissbib

Ende März 2018 wird die Finanzierung von swissbib durch swissuniversities auslaufen. Gegenwärtig sind wir dabei ein Modell der direkten Finanzierung durch die Bibliotheken einzuführen. Ausserdem planen wir die Integration von swissbb in die Swiss Library Service Platform (SLSP).

In diesem Rahmen:

Und zum Schluss noch einige Zahlen

swissbib zählt heute:

  • Über 30 Millionen Dokumente
  • Über 100 Millionen Exemplare, die in Schweizer Bibliotheken, Archiven oder online zugänglich sind
  • 90’000 Besucherinnen und Besucher pro Monate, die in dieser Zeitspanne 1,3 Millionen Seiten besuchen
  • 5 Personen, die am Projekt arbeiten (das Pensum entspricht 3 Vollzeitstellen)
Bonjour à tous !
Notre blog a été assez silencieux cette année. Néanmoins, nous avons mis en œuvre toute une série de nouvelles fonctions pour vous. Voici un petit récapitulatif.

Sources de données

Les sources suivantes ont désormais leurs documents dans swissbib:

De plus, les sources suivantes seront intégrées d’ici fin 2017:

Licences nationales

Depuis quelques mois, tous les habitants de la Suisse ont accès à plus de 6 millions de documents provenant du projet Licences Nationales. L’accès et l’inscription se déroulent sur la plateforme swissbib, en partenariat avec le projet SWITCH edu-ID (voir dans swissbib).

Par ailleurs, comme ces licences contiennent des conditions sur la publication en open access des articles écrits par des auteurs affiliés à une institution suisse, swissbib a préparé les métadonnées et les fulltexts qui ont été publiés sur RERO DOC. Ces métadonnées et documents sont aussi disponibles pour une intégration dans les archives institutionnelles suisses.

Plus d’informations dans le rapport final sur la contribution de swissbib au projet Licences Nationales.

Linked Open Data

Le projet Linked swissbib s’est terminé fin avril 2017. Nous sommes en train de consolider les résultats du projet pour une intégration en production.

Une étape importante était l’identification des métadonnées ouvertes (complètement libres de droit) dans swissbib. Au final 85% des notices de swissbib sont dans le domaine public (les voir dans swissbib).

Les curieux peuvent déjà regarder rapidement les portails data.swissbib.ch et linked.swissbib.ch pour avoir une idée de ce qui va venir. Néanmoins, nous sommes encore en phase de consolidation de ces portails. Ils ne sont pas encore terminés et sont actuellement en version Beta.

Une série d’articles de ce blog décrit les différents processus. De plus, un article a été publié à ce sujet : Interlinking Large-scale Library Data with Authority Records.

Nouvelles Fonctionnalités

  • Meilleures facettes: Il est désormais possible d’exclure des termes de recherche en cliquant sur la petite croix à droite du terme en question. Les différents Sujets choisis sont associés par ET. Les autres termes (Auteurs, Langue, …) sont associés par OU. Les termes choisis ainsi que les exclusions sont visibles dans la section „Effacer les filtres“. (Plus d’information en allemand)
  • Meilleur affichage de la hiérarchie des fonds d’archives: Beaucoup de fonds d’archives sont classés dans une arborescence hiérarchique. Il est désormais possible dans certains cas de la visualiser dans swissbib via l’onglet „Archives/Fonds“ (Exemple).

Système

  • Nous sommes passés à la version 8 de notre outil de traitement des données CBS
  • Le passage à la version 4 de notre outil de découverte VuFind est quasiment terminé
  • Tous nos serveurs tournent désormais sous Ubuntu 16.04
  • Nous avons implémenté un nouvel outil de statistiques basé sur l’analyse des logs avec Elastic, LogStash et Kibana
  • Nous avons mis en place une de tests automatisés de l’interface web en utilisant Sahi.

Stratégie, vision à long terme, futur de swissbib

Fin mars 2018, le financement central de swissbib par swissuniversities sera terminé. Nous sommes en train de mettre en place un modèle de financement par les bibliothèques directement ainsi que de réfléchir à l’intégration dans Swiss Library Service Platform (SLSP).

Dans ce cadre:

Quelques chiffres

Aujourd’hui, swissbib c’est:

  • Plus de 30 millions de documents
  • Plus de 100 millions d’exemplaires de ces documents, en ligne ou dans les bibliothèque et archives suisses
  • 90’000 visiteurs uniques par mois qui visitent 1.3 million de pages dans le même temps
  • L’équivalent de 3 personnes à temps-plein travaillent sur le projet (actuellement réparti sur 5 personnes)
Weiterlesen

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 RDFFormaten 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:

Serie „Swissbib data goes linked“
Partie 1 | Partie 2 | Partie 3 | Partie 4

Dans ce quatrième et dernier article de la série sur le projet CUS P-2 linked.swissbib.ch, nous nous consacrons à l’API web pour clients informatiques. Le but de ce sous-projet est de mettre à disposition les structures de données liées à travers une interface REST, en diverses sérialisations RDF.

Figure 1: API REST comme interface pour les services de swissbib

L’API REST doit fournir une interface homogène vers l’extérieur, et rassembler à l’interne la possibilité de plusieurs services. L’infrastucture sous-jacente doit être transparente pour les clients de l’interface.

REST

REST (REpresentational State Transfer), un paradigme de programmation pour systèmes distribués, s’est imposé ces dernières années par rapport à d’autres approches (telles que SOAP), pour diverses raisons. REST est léger, extensible à de grandes quantités de données, facile à comprendre par les humain et également relativement simple à implémenter pour des clients de tout langage de programmation. Les bases d’un service REST sont, de manière simplifiée:

  • Client-serveur
    Il existe une séparation nette entre client et serveur. Le client dirige les interactions et le serveur traite les requêtes et livre les données.
  • Stateless
    Pour répondre, le serveur n’utilise que les données d’une seule requête HTTP, et ne se sert d’aucune autre information de contexte.
  • Cacheable
    Le contenu d’une réponse du serveur doit être marquée de manière implicite ou explicite comme pouvant être stockée dans le cache ou pas.
  • Layered system
    Les couches d’abstraction du systèmes global sont transparentes pour le serveur et pour le client.
  • Uniform interface
    • Chaque ressource (par exemple une ressource bibliographique) est accessible par une URL.
    • Une ressource peut être comprise syntaxiquement et sémantiquement selon les données et métadonnées incluses dans la réponse. Ceci inclut entre autres l’indication du format (par exemple. JSON-LD) de la réponse.
    • Quand un client interroge une ressource, il reçoit les informations suffisantes afin de pouvoir traiter ou supprimer (à condition qu’il en ait le droit) cette ressource.
    • HATEOAS (Hypermedia as the Engine of Application State)

Cette dernière exigence (HATEOAS) est l’une des plus importantes et néanmoins le plus souvent négligée par beaucoup d’APIs REST. En bref, HATEOAS demande que l’API soit auto-descriptive. Cela signifie qu’un client informatique devrait être en mesure de comprendre, à partir d’un point d’entrée unique, quelles sont les actions possibles et les ressources à disposition à travers l’API. D’une perspective abstraite, un service REST conforme à HATEOAS représente un automate fini, dont les transitions d’états surviennent par la navigation au moyen des URLs mis à disposition.

Hydra (hypermedia-driven web APIs)

REST lui-même ne prescrit aucun standard sur la manière dont doit être construite une API auto-descriptive. C’est là qu’intervient Hydra, en tentant de standardiser le vocabulaire pour les APIs web hypermédia. Le Hydra Core Vocabulary, encore au stade de version préliminaire, est développé sous l’impulsion du collaborateur Google Markus Lanthaler et fait déjà preuve d’une grande popularité auprès de la communauté Linked Data. Le vocabulaire complet est déjà relativement vaste. Nous proposons ici deux exemples permettant d’illustrer le principe:

hydra:entrypoint
hydra:entrypoint est le point de départ de toute API. Toute la documentation ainsi que le point d’entrée lui-même sont au format JSON-LD. Le point d’entrée comprend tous les liens (liens relatifs pour l’instant encore) vers les ressources. Dans le cas de notre prototype, il s’agit avant tout des ressources bibliographiques (bibliographicResource). Le point d’entrée de notre prototype est accessible à l’URL suivante: http://sb-vf16.swissbib.unibas.ch/web/

Figure 2: hydra:entrypoint du prototype d’API REST de swissbib
(Pour les utilisateurs de Google Chrome, il est recommandé d’utiliser le plugin suivant:
https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc)

hydra:collection
Une hydra:collection est une vue sur une quantité de ressources liées. Dans notre cas, ceci pourrait être une liste de ressources bibliographiques en tant que résultats d’une recherche. Etant donné qu’une telle quantité de ressources peut vite devenir très importante, le vocabulaire Hydra propose hydra: PartialCollectionView; cet élément décrit une vue d’un sous-ensemble des objets d’une collection. Il peut contenir des liens (hydra:first, hydra:last, hydra:next et hydra:previous) afin de pouvoir atteindre tous les éléments de la vue. Les ressources elles-mêmes se trouvent dans le champs „hydra:member“. L’URL suivante propose un exemple d’une telle requête: http://sb-vf16.swissbib.unibas.ch/web/bibliographic_resources?dct:title=linked%20data

Figure 3: L’affichage d’une hydra:collection dans le prototype d’API REST de swissbib

Cette standardisation au moyen du vocabulaire Hydra permet dès lors d’écrire un client générique, qui peut lister les interactions possibles avec l’API web. Markus Lanthaler a déjà développé un tel client générique pour explorer l’API: http://www.markus-lanthaler.com/hydra/console/ (URL: http://sb-vf16.swissbib.unibas.ch/web).

Prototype

Après avoir vu les premiers résultats du prototype, nous souhaitons encore abordé l’aspect de son implémentation. Le développer Markus Lanthaler a créé une première implémentation Hydra de référence, SymfonyBundle, dans le langage de programmation PHP. Sur cette base ont émergé de nouveaux développements en lien avec Hydra, entre autres le framework APIPlatform. Ce dernier a été lancé pour la première fois en juin 2015, en version 1, et la prochaine version majeure 2.0 est sur le point d’être publiée. Le framework propose une bonne prise en charge de Hydra, avec notamment la possibilité de relier entre elles des sources de données relativement simples (DataProvider) ainsi que de sérialiser divers formats de sortie (à travers Responder). Dans notre prototype, nous avons implémenté notre propre DataProvider, simple, qui charge les données liées au format JSON-LD depuis un serveur Elasticsearch. Avec des classes Responder que nous avons développées, les données peuvent – selon les requêtes du client – être sérialisées et diffusées dans d’autres formats RDF. Le graphique ci-dessous illustre ce processus.

Le code source de ce prototype peut être consulté sur Github: https://github.com/linked-swissbib/hydra-swissbib.ch/tree/prototype_v2

Synthèse

Nous sommes persuadés d’avoir trouvé avec Hydra un vocabulaire pour les APIs web hypermédias qui conviendra parfaitement à nos données liées. La plateforme de framework API nous a convaincus et, dans les prochaines semaines, nous travaillerons activement sur le développement de l’API sur la base de ce prototype. L’état actuel du développement peut être suivi sur Github: https://github.com/linked-swissbib/hydra-swissbib.ch

Auteurs du texte:

Weiterlesen

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.

Serie „swissbib data goes linked“
Partie 1 | Partie 2 | Partie 3 | Partie 4

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.

Figure 1: aperçu des fonctions et pages créées pour linked.swissbib.ch, selon le type de contenu (instance, œuvre, auteur, thème) et le type de page (page d’accueil, pages d’aperçu, pages de résultats, pages détaillées, knowledge cards)

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.

Figure 2: sélection de fonctions d’autocomplétion issues de différents portails LOD du domaine des bibliothèques

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.

Figure 3: Dans le cadre de la création du concept d’interaction, un flux de clics (clickstream) a été créé pour chaque page du prototype, illustrant ce qui se passe lors d’un clic sur un élément particulier. Cet exemple montre le flux de clics d’une page de résultats (onglet „Pages auteurs“).

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.

Figure 4: Lors du clic sur une icône, qui se trouve dans ce cas au sein d’une liste de résultats (onglet „Pages thèmes“), une fenêtre avec une synthèse de la page détaillée sur le sujet „Historische Geografie“ s’ouvre.

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

Figure 5: Page auteur détaillée: cette page agrège des informations sur un auteur (par ex. dates de vie et de mort, mouvement ou style littéraire lié, personnes associées), placées pour la plupart dans un menu en accordéon („Afficher plus de détails“). D’autres modules proposent en plus d’autres pages détaillées, des knowledge cards et des liens vers des médias.

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

Figure 6: fonction d’autocomplétion élargie, proposant des résultats clusterisés selon les catégories „Documents et médias“, „Œuvres“, „Auteurs“ et „Thèmes“, menant vers une page de résultats (en vert „Alle Ergebnisse anzeigen“) ou directement vers une page détaillée (en gris).

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

Weiterlesen

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, 32×2,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.

Serie „swissbib data goes linked“
Partie 1 | Partie 2 | Partie 3 | Partie 4

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

Figure 1: N-Triples triés

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.

Figure 2: Interconnexion avec simple fractionnement (gauche) et avec mécanisme de blocking (droite)

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 32×2,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.

Figure 3: Paramètres de comparaison pour l’interconnexion

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.

Weiterlesen

Swissbib data goes linked, Partie 1: Transformation des métadonnées, modélisation, indexation

Deutsche Fassung

Swissbib data goes linked

Partie 1 | Partie 2 | Partie 3 | Partie 4

Le projet CUS P-2 linked.swissbib.ch met en place, sur la base des notices de swissbib, une structure de métadonnées enrichies et reliées selon les principes …

Weiterlesen

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

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.

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

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.

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.

Serie „Swissbib data goes linked“
Partie 1 | Partie 2 | Partie 3 | Partie 4

Le projet CUS P-2 linked.swissbib.ch met en place, sur la base des notices de swissbib, une structure de métadonnées enrichies et reliées selon les principes du web sémantique (abstract et présentation – en allemand). Grâce à l’enrichissement des données bibliographiques avec des informations provenant d’autres sources (DBpedia, VIAF), de nouvelles fonctions de recherche exploratives seront mises à disposition, offrant une plus-value aux utilisateurs du catalogue de bibliothèque. La réutilisation des données, également au-delà du domaine des bibliothèques, sera ainsi favorisée par l’interconnexion avec d’autres jeux de données de référence du web sémantique.

Ce texte et une série d’autres articles donneront un aperçu de l’état des travaux au sein du projet, dont l’échéance est prévue début 2017. L’accent est mis avant tout sur les applications et techniques utilisées ainsi que sur certains détails de l’implémentation. Les différentes contributions de ce blog seront structurées plus ou moins selon le workflow de conception de linked.swissbib.ch, prévoyant les étapes suivantes (figure 1):

  1. Transformation des métadonnées de swissbib en une sérialisation RDF et décomposition en différents concepts
  2. Indexation des données transformées
  3. Enrichissement par l’interconnexion avec d’autres sources (pour l’instant DBpedia et VIAF), au moyen de LIMES et reshaperdf
  4. Présentation des données enrichies dans l’interface de recherche basée sur VuFind
  5. API web comme interface vers l’index destinée à d’autres machines
Figure 1: Aperçu du workflow de linked.swissbib.ch (état avril 2016)

Partie 1: transformation des métadonnées, modélisation, indexation

Transformation des métadonnées
Les près de 21 millions de notices bibliographiques de swissbib en format MARC-XML, résultat d’une agrégation de notices quasi ou totalement similaires, servent de base au projet linked.swissbib.ch. Bien que MARC soit un format de données utilisé dans le monde entier, son domaine d’application en demeure limité aux bibliothèques. Pour permettre une réutilisation également en-dehors de ce domaine, il est donc nécessaire de proposer les données sous un autre format ne dépendant pas d’une application particulière. RDF (Resource Description Framework) offre une telle possibilité; il donne un cadre dans lequel des assertions logiques, c’est-à-dire traitables par ordinateur, peuvent être faites sur des choses (des ressources). Par le fait que, en RDF, des assertions peuvent aussi être faites sur d’autres assertions (réification), des vocabulaires spécifiques à un domaine peuvent être créés et, entre eux, interconnectés.
En tant que modèle, RDF définit un schéma syntactique pour des assertions – une assertion correspond toujours à un graphe dirigé contenant un sujet, un prédicat et un objet – , mais pas de format spécifique. Dans linked.swissbib.ch, nous avons sélectionné JSON-LD comme format de destination. Dialecte de JSON pour le Linked Data, JSON-LD est un format relativement évolutif, pouvant se structurer différemment selon les utilisations souhaitées, et particulièrement bien adapté aux interfaces de programmation.
Pour transformer les notices MARC, nous utilisons le logiciel Metafacture, qui a été développé à l’origine dans le cadre de la plate-forme Culturegraph. Le principal avantage de cette application Open Source réside, à côté de sa performance – en substance, les notices sont traitées parallèlement –, dans son accessibilité à des spécialistes en métadonnées avec une certaine expérience de XML mais sans connaissances préalables en programmation qui, après une courte étape de familiarisation, sont en mesure de définir des règles de transformation même complexes. Deux éléments sont alors à considérer. Premièrement, le langage dédié FLUX permet de joindre bout à bout des commandes Metafacture (figure 2), qui effectuent les diverses étapes de la transformation, comme la lecture d’un fichier ou l’analyse d’un format particulier. Du moment que ces commandes existent, presque n’importe quelles combinaisons de formats d’entrée et de sortie sont possibles. Deuxièmement, les règles de transformation à proprement parler sont exprimées dans des définitions Morph (en syntaxe XML) au niveau de chaque champ de données. Ici également, les possibilités sont très variées, mais nécessitent des tests systématiques lors de la transformation de structures de données complexes. Afin que les cas particuliers dans les données MARC-XML soient aussi pris en considération dans linked.swissbib.ch, des contrôles qualité ont été effectués avec des échantillons. Ainsi, la conversion a pu être testée et améliorée de manière incrémentale.

Figure 2: Pipeline Metafacture (simplifié)

Pour les besoins du projet, nous avons enrichi Metafacture de plusieurs commandes. Il s’agit jusqu’à présent de commandes pour la sérialisation améliorée de documents en JSON-LD, pour l’implémentation d’un mécanisme pour l’indexation par lots sur le serveur de recherche et pour l‘interaction avec une base dedonnées en graphe afin de suivre les modifications de la structure des données.

Modélisation
En plus de la transformation, les notices bibliographiques monolithiques sont décomposées en différents concepts. Le but de cette modélisation est de satisfaire l’utilisateur qui veut des données liées tout en prenant en considération les possibilités et limites des données de base. A cet égard, des use cases ont été développés et deux modèles de données importants ont été évalués: FRBR et BIBFRAME. Cela a résulté en un modèle composé de six concepts distincts, permettant un enrichissement ciblé ainsi qu’une interconnexion des données – entre elles et avec des sources externes (entre parenthèses sont indiqués ci-dessous les types utilisés dans le moteur de recherche, qui correspondent aux six concepts):

  • Instance (bibliographicResource): notice bibliographique
  • Métadonnées sur l’instance (document): métadonnées sur une notice bibliographiques
  • Exemplaire (item): données d’exemplaires
  • Personne (person): auteurs
  • Organisation (organisation): collectivités et congrès
Figure 3: Part en pourcentage des six concepts

Des 21 millions de notices bibliographiques originales en résultent pour le moment 97 millions de documents (figure 3), dont la plus grande part correspond aux exemplaires ainsi qu’aux instances et leurs métadonnées. Certains champs codés ou normalisés permettent, déjà dans la phase de modélisation et avant toute opération d’alignement, de créer des liens de manière automatisée vers des référentiels externes: Geonames pour les pays et cantons de publication, RDA pour les types de médias et de contenus, et Lexvo pour les langues. L’utilisation d’URI (Uniform Resource Identifiers) pour l’identification unique des ressources RDF – correspondant au premier des quatre principes des Linked Data de Tim Berners-Lee – est également importante en vue de la réutilisation des données. Dans le projet, la génération de ces URI se base sur des identifiants préexistants dans les données MARC-XML ou sur des valeurs de hachage créées d’après le contenu de certains champs. Grâce aux références liant les différents concepts entre eux (figure 4), il est toujours possible de reconstituer une notice bibliographique originale. Chaque concept est décrit en détails par plusieurs propriétés. Une analyse statistique des unités de données (fréquence des champs et sous-champs dans les données MARC-XML) a servi à déterminer les informations les plus importantes qui devaient être transformées en RDF. Des propriétés RDF provenant des vocabulaires les plus connus (Dublin Core, BIBO, FOAF, RDA, etc.) ont été préférées afin de garantir une bonne réutilisabilité des représentations RDF des données.

Figure 4: Relations de chaque concept avec le concept „instance“

Comme les ressources sont indexées de manière fragmentée, les concepts individuels et simples, parfois enrichis, sont facilement accessibles au sein de l’index, par exemple pour générer des pages d’agrégation autour d’un auteur particulier.

Indexation
L’élément central de l’infrastructure de linked.swissbib.ch est son index de recherche. Aussi bien l’interface de recherche que l’API web accèdent, dans le service en production actuel, directement à cet index. C’est pourquoi une haute disponibilité, une indexation performante et une faible latence sont des facteurs décisifs lors des requêtes. Dans la version test, l’index se trouve dans un cluster d‘Elasticsearch à trois nœuds sur trois hosts différents de telle manière qu’une scalabilité horizontale serait tout à fait possible. Pour atteindre un taux d’indexation suffisamment élevé, nous intégrons les données au format BULK d’Elasticsearch, qui permet des uploads par lots de plusieurs milliers de documents. Ainsi, une indexation complète des 97 millions de documents dans notre cluster dure de 6 à 8 heures. Enfin, Elasticsearch travaille à l’interne avec des shards (fragments), dans lesquels l’index est fractionné et qui de leur côté sont répartis sur les différents nœuds du cluster. Comme le serveur crée des reproductions des shards dans les différents nœuds, la charge de calcul lors de requêtes peut être répartie entre les hosts. Elasticsearch se base, tout comme Solr pour swissbib classique, sur Lucene. Néanmoins, contrairement à Solr, Elasticsearch sérialise les documents à l’interne au format JSON. Nos documents JSON-LD peuvent donc être indexés sans autres adaptations et rediffusés par une interface REST intégrée. Chaque concept est enregistré dans un type propre au sein de l’index de recherche. Un type est une classe de documents (de records) partageant une majorité de champs identiques (paires clé-valeur) et contenant une même définition (mapping) précisant comment ces champs doivent être indexés et analysés. Les documents d’un type particulier ne doivent pas contenir une paire clé-valeur pour chaque champ défini dans le mapping par contre, seuls les paires contenant une définition dans le mapping sont indexées. Ceci permet ainsi d’indexer sans trop de difficulté des notices dont l’exhaustivité varie.

Weiterlesen

Considerations for the development of an infrastructure to enable the project linked.swissbib.ch (part 1)


The proposal “linked.swissbib.ch” was accepted by SUC P2 – („Scientific information: access, processing and safeguarding“) as one of the projects for building the future infrastructure to access scientific digital information.

The application was submitted by Haute école spécialisée de Suisse occidentale HES-SO -Haute Ecole de Gestion, Genève in cooperation with HTW Chur and Universitätsbibliothek Basel (project swissbib).

One of the aims of the project is the transformation of the current swissbib content into a Semantic Data format (RDF) to enable and simplify the linking of swissbib data with external information.

Finally the created services by linked.swissbib.ch should run on the infrastructure provided by swissbib.ch to facilitate scientists and general library users access to the linked information. Additionally the infrastructure should be available and usable for any other project or service who wants to work on similar questions (catchphrase: “swissbib as a working bench”)

This first blog contribution reflects my current considerations and experiments for the selected tools part of the future infrastructure. Of course this is a work in progress. Contributions and suggestions are always welcomed.

I. General requirements for future tools and the infrastructure to be created by linked.swissbib.ch (and swissbib classic)

a) The software has to transform any kind of meta-data structure into another (meta-data) structure.

b) In general the chosen software should be reusable and expandable. The used development tools should be state of the art and future-proof (if this is at all possible in the software world…)

c) The software has to be Open Source – otherwise it is often difficult or nearly impossible for other parties or services to (re)-use it.

d) The software shouldn’t be in a phase of its infancy. Because of our really restricted resources we can’t afford to build a new software just from scratch. It should be demonstrated that it is already used by institutions in a similar way that we intend to use it with linked.swissbib.ch.

e) Ideally there should exist a community around the system which enables further development in the future.

f) The software for meta-data transformation should be usable not only by software developers.
People related to meta-data transformations in the library world (scripting knowledge is helpful but not necessary) should be able to define work-flows for their own purposes – recently I heard that the phrase “biblio information scientist” is sometimes used as an expression for such a group of people.

g) The software tools should be very scalable.

The mechanisms should be available on a desktop (for example a person in development of a workflow for metadata transformations) and at the same time it should be possible to use the same artifact on a cluster to process millions of items in reasonable time. Actually the classic swissbib content consists of around 20 million records (merged). We are in charge to include licensed article meta-data in the swissbib data-hub. This content (potentially between 30 -150 million descriptions) should also be transformed and serialized into a semantic RDF format.

II. Possible software alternatives to reach the defined goals


A. Infrastructure developed by the Culturegraph project (German National library)
 

One of the main components provided by Culturegraph is called MetaFacture which in turn comprises of three main parts: Framework, Morph and Flux. You can find a more detailed explanation of these parts on the Wiki of the software on Github .

To get to know and to evaluate the component I created my own repository on Github. There I included the sources of the lobid project

1) How are the main components of Culturegraph related to the general requirements defined above?

a) Framework:

The framework makes the solution re-usable and expandable. It defines general classes and interfaces which could be used by others (swissbib too) to extend the solution in a way it is required for their aims.

As an example for this: The metafacture-core component provides commands which are combined to FLUX – workflows (we will see the description of this later). These commands were extended by HBZ by some commands of their own to serve their needs.

Beside new commands being part of the workflow you can define new types as functions being part of the Metamorph domain specific language.

The same mechanism to write specialized functionality with dedicated commands beside the metafacture-core commands is used by the Culturegraph project itself. There already exist connectors for SQL databases, NoSQL stores like the often used Mongo store and to include Mediawiki content as part of the meta-data transformations.  All these repositories are available on Github

b) (Meta)-Morph transformation language

Morph is a Domain Specific Language to define Meta-Data transformations using XML. Hereyou can find a larger example for a morph script which was build by HBZ to transform bibliographic MAB descriptions into RDF. For the result of this transformation (done by myself with the evaluation repository on Github)  look here

My guess (at the moment – I’m still in the phase of evaluation): Metamorph enables you to define at least most of the transformation required for our needs.
For most of the work,knowledge of programming languages isn’t necessary. You have to know your meta-data structures and how you want to transform it.

General potential of Meta-Morph:
In the mid-term perspective I have in mind to use this kind of solution not only for transformations into RDF but for already existing processes in the classic swissbib service too (CBS FCV transformations and Search Engine – SOLR / Elasticsearch – document processing for example)

c) FLUX – create workflows for transformation processes

I would describe FLUX as a “macro language” (similar to macros in office programs) for the definition of processing pipelines.Here you can find an example.

The following picture will give you an overview and idea how heterogeneous article meta-data (provided by publishers) could be normalized in processes based on Metafacture.

 

To support the creation of FLUX work-flows (especially for non developers) HBZ implemented an Eclipse extension. This extension gives you suggestions for commands (together with their arguments) as part of whole work-flows. Additionally you can start a FLUX process under control of the extension. Fabian Steeg (HBZ and creator of the extension) wrote a helpful summary of the
metafacture-ide and metafacture-core out of his point of view.

2) Additional relations to the defined goals

As I tried to describe: the main parts of Metafacture (and extended components based on the core framework) addresses the requirements of the goals in a), b) and f)
(meta-data transformation / reusable, expandable and future proofed / not only for software developers)

But what about the other defined goals:

– The software is Open Source, originally developed by the Deutsche Nationalbibliothek and available via Github and Maven

– The software (Metafacture) isn’t in itsphase of infancy and a community has been established around it. Currentlydeployed as version 2.0,it is the heart of the linked data service provided by DNB. It is already re-used by other institutions for their services (especially HBZ for lobid.org serviceand SLUB Dresden for their EU financed “Data Management Platform for the Automatic Linking of Library Data„)

– The infrastructure should have the potential being very scalable.
Transformation processes of meta-data are currently often based on traditional techniques like relational databaseswhich is proven and mature. E.g. a lot of sophisticated meta-data transformation processes were created by swissbib classic in the last 5 years.
We don’t have in mind to throw away
thesepossibilities and collected experiences in the past. And even for the remarkable larger amount of meta-data for licensed articles we think it makes sense and it is possible to use it by increasing our (virtual) hardware.
But (probably soon) there comes the point in time where newer possibilities should be used (at least in parallel). These possibilities are often labeled with the catchphrase “Big Data” and behind these catchphrases are mostly Hadoop for distributed processing and distributed (NoSQL) storages like Hbase.

Because the Metafacture work-flows are stream-based (combining several modules in a chain) it is well prepared to run on a Hadoop Cluster. Culturegraph has already done this with their component called metafacture-cluster.
This technique made it possible for them to bring together all the bibliographic resources of all the library networks in Germany and to build clusters of equal or similar data (which is a foundation of their Linked Data service) – really fast. This is actually done by swissbib classic within our current data-hub based on traditional technologies (see above). Here you can find a more detailed view on the architecture of the current swissbib.
We have to keep this aspect (processing of really large amounts of data) in mind. Perhaps not immediately when it comes to article data but with greater probability if research data should be incorporated into a data-hub like swissbib.

B. Toolset developed by LibreCat (with Catmandu as the Backbone)



I don’t have any experience with LibreCat.

I spoke with a colleague (who is involved in the community) about the current status of the project and we tried to compare it on a very high level.

One sentence I still have in my mind:
Because Culturegraph is based on Java they (Culturegraph) use a lot of XML while Librecat (implemented in Perl) can do the same pretty much faster directly in the code.

 
I guess it’s true as long asit’s true… there are some misconceptions from my point of view:

a) There is no use of XML because the core of Metafacture is implemented in Java. Java and XML aren’t correlated in any way. Metafacture uses XML because it’s the mean (not more) to express the DSL (Domain Specific Language – Metamorph) used to define meta-data transformations. This makes it possible for people without advancedprogramming skills to define such transformations on a higher level.

b) a clear separation of implementation and definitions for meta-data transformations (the rules) is not unimportant to make the system in the long term better maintainable although it’s probably faster and easier to understand ‚for the developer itself‘ to implement transformations in Perl.
– maybe a very subjective point of view:
Today I wouldn’t implement a system with Perl. If a dynamic scripting language my recommendation would be something like Python or Ruby. Although things change pretty fast nowadays my impression is that Perl isn’t often used by younger people. It might be different in the ‚current‘ library world. But my assumption is it’s going to change in the future.
– Especially when it comes to the processing of large amounts of data – I wouldn’t use dynamic scripting languages. Execution performance is one thing. The other: the integration with clusters for large amounts of data is less supported.

Nevertheless: we should keep an eye on the development in the project. A noticeable group of people (able to contribute) is interested in the project and as I tried to depict it in my picture above:
I guess we could integrate it (if reasonable) in an infrastructure like Metafacture.

Another aspect: If it is possible to re-use the work for normalization of licensed article meta-data done by GBV we have to be “Java compatible”. If I’m not wrong the work is done on the basis of this programming language.

Weiterlesen