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

Rückstellung tub.find

Leider waren wir wohl etwas zu voreilig. Trotz sorgfältiger Tests fiel heute Nachmittag noch ein kleiner, aber gemeiner Fehler im umgestellten tub.find auf, durch den wir uns gezwungen sahen, die Umstellung erstmal rückgängig zu machen, da sich das Problem nicht auf die Schnelle beheben ließ. Der Fehler trat bei Vormerkungen auf, bei Titeln mit mehreren […]

Weiterlesen

EXIT – leaving black boxes behind!

In diesem Jahr fand die 40ste Konferenz der European Library Automation Group statt. Auch die UB Leipzig war diesmal mit zwei Beiträgen vertreten. Martin Czygan leitete ein vierstündiges Bootcamp unter dem Titel “Build your own aggregated discovery index of scholarly eresources”. Die Workshop-Teilnehmer hatten die Gelegenheit, auf einem mitgebrachten Laptop einen eigenen kleinen aggregierten Index … EXIT – leaving black boxes behind! weiterlesen

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