Intégration d’Hydra dans RDF-REST

Raphaël Cazenave-Lévêque
février 2015
Résumé : Ce document présente ma contribution à la version JavaScript du frame-
work RDF-REST. Mon projet avait pour but d’utiliser des descriptions Hydra pour
construire des Cores RDF-REST, mais suite à la nécessité de déployer de RDF-REST
sur navigateur et sur serveur, mon projet s’est porté sur des aspects plus proche du
génie logiciel. Je traiterai donc de mes recherches concernant la modularisation de code
JavaScript et sur les questions engendrées par le caractère ubiquitaire du framework.
Mots-clés : Linked Data, RDF, REST, Hydra, JSON-LD, JavaScript.

1 Introduction
Ce projet de recherche, est proposé par Pierre-Antoine Champin et Michael Mrissa, maîtres de
conférences en informatique à l’IUT de l’Université Claude Bernard Lyon 1, respectivement membres
de l’équipe TWEAK (Traces, Web, Education, Adaptation, Knowledge) et de l’équipe SOC (Service
Oriented Computing) du LIRIS. Ce travail de recherche porte sur le framework RDF-REST conçu
et réalisé par Pierre-Antoine Champin lors de ses travaux au LIRIS. Ce framework est utilisé dans
le cadre d’une application implémentant le concept de Système de Gestion de Base de Traces 1 .
Ce framework été utilisé plus récemment dans le contexte de l’agrégation de données sémantiques
[Médini et al., 2014], et sera utilisé par l’application Sympozer et par une application de gestion
d’avatars pour le Web des objets.

2 Contexte
2.1 Des Web APIs à Linked Data

A l’origine le Web était constitué de documents textuels, et chaque document pouvait faire
référence à d’autres documents via des liens hypertextes. Puis années après années les utilisateurs
du Web, en particulier les entreprises, se sont mis à publier massivement des données sur le Web.

2.1.1 Les données sur le Web

Chaque service Web (par exemple Amazon, Twitter, BBC) qui désire rendre accessible des don-
nées sur le Web expose une Web APIs. Il s’agit conceptuellement d’un point d’accès à des données,
auxquels on accède avec des requêtes sur le Web, à l’aide du protocole HTTP.
Les données brutes publiée sur le Web n’ont pas toujours de représentation naturelle pour l’hu-
main. C’est pourquoi il est courant que ces données soient intégrés dans des documents HTML.
Cette intégration peut être réalisée de plusieurs façon, depuis des métadonnées HTML4 jusqu’aux
microdatas de HTML5 en passant par RDFa.
Cela conduit donc à un Web dans lequel les données sont fragmentées, à la fois disponible sur
le Web, mais isolés les unes des autres, sans liens [Heath and Bizer, 2011]. Le Web par définition
est une interconnexion d’éléments, et ainsi ce Web des APIs n’est pas à proprement parlé un Web.
C’est pourquoi depuis quelques années on cherche à construire le Web des Données, un Web où les
données sont vraiment réutilisables et reliées.

2.1.2 Linked Data

Linked Data désigne l’utilisation d’un modèle de donnée commun pour les données, et l’utilisation
des standards du Web. Voici les principaux points définissant Linked Data [Berners-Lee, 2006] :
1. La notion de trace modélisée et la notion de Système de Gestion de Base de Traces font partie d’un des thèmes
d’étude de l’équipe SILEX du LIRIS
M1if - UCBL 2014-2015

• Utiliser des URL HTTP pour identifier les ressources

• Respecter les standards pour transmettre les informations
• Exprimer des relations entre les données, à l’aide d’URL

2.1.3 RDF
RDF est un modèle de donnée utilisant des graphes, pour représenter des ressources ainsi que
leurs relations [W3C, 2014]. Ces relations prennent la forme de triplets (sujet, prédicat, objet).
Chaque ressources dans RDF est identifiée par une URI (Uniform Ressource Identifier). Sur la
Figure 1, les ressources sont représentées en vert, les flèches représentent les prédicats, et les objets
désignés par les flèches sont soit d’autres ressources soit des littéraux. RDF offre aussi un mécanisme
de typage des ressources à l’aide d’URI. En pratique, notamment quand on utilise RDF avec des
ressources Web, les URI sont des URL. Par exemple en logique classique on dira que Socrate est un
Homme, en RDF on pourra dire dbpedia:Socrate rdf:type dbpedia:Person .

Figure 1: Graphe RDF représentant Eric Miller[Manola and Miller, 2004]

RDF est de plus en plus utilisé à la fois par les entreprises géantes du Web, mais aussi par les
états souhaitant rendre accessible leurs données, par le organisations comme l’ Union Européenne.
Il convient de faire la différence entre entre ce que l’on appelle l’Open Data qui consiste à rendre
des données publiques, et RDF. Néanmoins le format de donnée RDF est un des meilleurs choix
pour rendre des données publiques. C’est un format non-propriétaire, très flexible, avec une grande
capacité d’expressivité, c’est d’ailleurs pour ces qualités que la Bibliothèque Nationale de France
[Bertails, 2013], l’Union Européenne 2 , l’état Français, ont choisi RDF comme format de donnée.
Les données au format RDF sont généralement accessibles via un point d’accès (endpoint),
sur lequel on peut effectuer des requêtes avec le langage SPARQL. Par contre ces données sont
généralement disponible en lecture-seule.
Il existe de très nombreux format de données pour représenter des données RDF (Turtle, RDF/XML,
N-Triples, JSON-LD).

2.1.4 JSON-LD (JavaScript Object Notation for Linked Data)

JSON-LD est un format de donnée permettant de représenter des données liées, tout en étant
compatible avec le format JSON. Celui-ci étant un des formats de donnée les plus utilisé actuelle-
ment, JSON-LD est un choix pertinent pour favoriser la généralisation des données liées dans les
Web APIs.
2. https://open-data.europa.eu/en/about

Rapport de TER de Raphaël Cazenave-Lévêque 2

M1if - UCBL 2014-2015

JSON-LD implémente la désambiguisation des propriétés 3 via un champs contenant le contexte

de la donnée. Cela permet d’éviter d’utiliser de longues URL comme nom de propriété, tout en
préservant cette information de typage des propriétés.
Il existe différentes formes pour un même document JSON-LD, mais ces formes sont toutes
équivalentes d’un point de vue sémantique 4 .

2.2 REST

REST [Fielding, 2000] désigne un ensemble de contraintes imposées sur la conception d’un sys-
tème pour garantir un certain nombre de propriétés. Typiquement, REST consiste à utiliser des URL
pour définir les entités, à utiliser la sémantique des verbes HTTP selon la définition du protocole,
puis à exprimer dans les données des liens hypermedia [Fowler, 2010].
Lorsque que l’on écrit une API REST, on manipule les ressources via des représentations [Cham-
pin, 2013]. Cette manipulation s’effectue via une interface uniforme, celle définie par les verbes dans
le protocole HTTP (POST, GET, PUT, DELETE). Disposer d’une interface uniforme d’accès aux
données est très appréciable quand on raisonne en terme de Web des Données. En effet, quand on
souhaite accéder aux données en relation avec une donnée, le fait d’avoir une interface uniforme
permet de pouvoir aussi manipuler ces données avec la même interface. Il existe toutefois la ques-
tion de savoir quelles sont les mutations disponibles sur celles-ci, c’est là que les descriptions Hydra
seront utiles.

2.3 Le Framework RDF-REST

Le Framework RDF-REST proposé par Pierre-Antoine Champin, permet d’exposer une interface
uniforme de manipulation de données liées. Initialement conçu pour servir de socle architectural à
un système à base de traces 5 , la généricité de RDF-REST le rend utilisable en tant que framework
pour de nombreux cas d’utilisations.
Les Cores RDF-REST implémentent l’interface uniforme d’accès aux données, tandis que les
Wrappers RDF-REST permettent une manipulation des données dans un style orienté-objet.

2.4 Hydra

Hydra est un vocabulaire pour JsonLD TODO

3 Etat de l’art
3.1 JavaScript et programmation asynchrone

3.1.1 JavaScript, un langage conçu pour les navigateurs

Pour comprendre les caractéristiques de JavaScript, il faut prendre en considération qu’il à été
conçu pour répondre à une problématique d’exécution dans un navigateur. Dans un navigateur, le
moteur d’exécution JavaScript est monothreadé 6 . Plus simplement il n’y a pas d’exécution parallèle
au sein d’un même code JavaScript. Une des raisons est la nécessité de pouvoir synchroniser le rendu
d’une page HTML et les éventuels traitements que pourrait y faire un code JavaScript.
Comme il est nécessaire de pouvoir effectuer de la concurrence, JavaScript utilise une Event
Loop 7 . C’est cette Event Loop qui permet à JavaScript d’être monothreadé et asynchrone. Il est
nécessaire de respecter ce caractère asynchrone quand on programme en JavaScript, autrement on
3. Cette désambiguisation utilise la notion de vocabulaire, elle-même définie dans les spécifications de RDF
4. On peut facilement visualiser des exemples avec les différentes formes sur http://json-ld.org/playground/
5. kTBS, Un noyau générique pour les systèmes à base de traces : http://liris.cnrs.fr/sbt-dev/tbs/doku.
php?id=tools:ktbs
6. On peut constater que certains navigateurs comme Google Chrome utilise une instance du moteur d’exécution
par onglet, et que cette pratique devient la norme
7. Il s’agit d’une boucle qui gère le flot d’exécution d’un code

Rapport de TER de Raphaël Cazenave-Lévêque 3

M1if - UCBL 2014-2015

s’expose à des problèmes de blocages de l’interface dans le cas d’une application dans un navigateur,
ou a des temps de réponse très élevés dans une application serveur.
Ensuite vient le concept d’entrées-sorties non-bloquantes (non-blocking I/O). Parce que JavaS-
cript n’utilise qu’un seul thread, on n’utilise que des appels à des fonctions non-bloquantes. On
parle alors de non-blocking event loop pour caractériser le mode d’exécution de JavaScript.
Ainsi on peut se poser la question de ce qu’est au plus bas niveau d’un système une fonction
non-bloquante, mais il s’agit d’une question assez complexe que je ne saurais pas traiter ici. Cela
n’est néanmoins pas une problème à partir du moment où l’on accepte que certaines fonction bloque
le contexte d’exécution pour fournir un résultat, et d’autres le libère immédiatement puis effectuent
les traitements quand la non-blocking event loop lui accorde du temps. Dés lors on peut introduire le
concept de CPS (Continuous Passing Style) qui est une des techniques pour effectuer une exécution
non-bloquante. C’est cette technique qui est utilisée dans JavaScript et qui se matérialise par des
fonctions qui ont en dernier argument une autre fonction qui sera exécutée lorsque le résultat sera
prêt. On nomme ces fonctions des callbacks ou fonctions de rappel.
Ce mode de programmation est très efficace pour un moteur d’exécution car il permet de toujours
pouvoir réagir à un nouvel événement, c’est d’ailleurs un des avantages de Node.js en tant que
langage coté serveur, mais pour un développeur cela implique une façon de penser très différente de
celle que l’on utilise généralement quand on écrit des algorithmes.

3.1.2 Les Promises

C’est ainsi que mon encadrant à choisi d’utiliser les Promises. Les Promises 8 sont des objets
permettant d’utiliser un style de programmation lisible pour représenter un traitement asynchrone.
Une Promise est un objet encapsulant un traitement, et cet objet possède un état (réalisée, non-
réalisée, échouée). Il existe des fonctions pour composer de façon non-bloquante des Promises, et
pour effectuer un traitement après une réalisation.
Les patterns de code induit par l’utilisation des Promises sont très élégants, permettent une
bonne lecture des aspects métiers d’un code. Par contre, mon expérience en tant qu’utilisateur
novice de cette façon de programmer m’a conduit à réfléchir sur la notion de typage d’un langage
de programmation, ou plus pragmatiquement sur le typage dynamique de JavaScript.

3.1.3 Le typage dynamique

Je tiens à parler du typage dynamique dans ce document car le fait que JavaScript soit dyna-
miquement typé à été pour moi un frein pour ma tâche d’écriture de code dans RDF-REST, et je
pense que c’est un sujet intéressant dans le contexte des framework comme RDF-REST.
Il existe deux approches de typage, le typage statique qui est effectué lors d’une phase de com-
pilation, et le typage dynamique qui s’effectue à l’exécution 9 . Alors que le typage statique permet
d’exprimer une sorte de contrat sur le comportement des fonctions d’un programme, le typage
dynamique permet d’écrire du code plus flexible et plus abstrait. Le typage dynamique nécessite
beaucoup plus d’attention de la part du programmeur, et une méthodologie plus stricte d’écriture
de tests.
On peut naturellement s’interroger sur la nécessité d’avoir un typage dynamique quand on utilise
un langage dynamique. Hélas la notion de langage dynamique est assez controversée, et bien souvent
il est admit qu’un langage dynamique est dynamiquement typé. En observant des langages de
programmations émergeant, comme Dart 10 , on constate qu’un langage ayant la même vocation
8. Nous avons utilisé la spécification la plus standard des Promises, https://promisesaplus.com/, il est à noter
qu’il existe une autre spécification qui n’est pas terminée mais qui sera celle d’EcmaScript6 : http://people.mozilla.
org/~jorendorff/es6-draft.html#sec-promise-objects
9. Il existe d’autres notions concernant le typage, les typages dits forts, faibles, l’inférence des types, mais cela
n’est pas l’objet de ce rapport
10. Dart est un langage de programmation conçu par Google et dont les objectifs sont très proches de ceux de JavaS-
cript, et comme ce dernier, il possède une spécification Ecma, http://www.ecma-international.org/publications/

Rapport de TER de Raphaël Cazenave-Lévêque 4

M1if - UCBL 2014-2015

que JavaScript peut bénéficier d’un typage explicite.

Dans le cas de RDF-REST l’objectif est d’avoir un code sans surcouche, qui puisse être utilisé
dans n’importe quelle application manipulant des données liées, ainsi le choix de JavaScript est
naturel.

3.2 Exposition des bibliothèques

En JavaScript il existe de nombreuses manières d’exposer et d’utiliser des modules. Malgré le

fait que JavaScript suive en théorie les spécifications EcmaScript [ECMA International, 2011] (la
version actuelle de JavaScript, 1.8.5, est basée sur les spécifications EcmaScript 5.1), il existe de
nombreuses implémentations différentes dans les navigateurs Web. Il existe une solution pour spé-
cifier à un environnement d’exécution JavaScript que l’on souhaite n’utiliser que le sous-ensemble
de ses fonctionnalités qui respecte strictement la spécification ES5. Il s’agit du mot clé use strict
écrit en commentaire. 11
L’exposition d’une bibliothèque JavaScript peut se faire de trois manières différentes :
• Selon la spécification CommonJS
• Selon la spécification AMD (Asynchronous Module Definition)
• A l’aide de variables globales
La spécification CommonJS 12 est celle que l’on utilise lors de l’écriture de code JavaScript destiné
à être exécuter sur un serveur dans un environnement Node.js. La spécification AMD 13 est plus
récente et définie une façon plus moderne et mieux adaptée aux codes que l’on utilise dans un
navigateur Web. L’exposition d’une bibliothèque en utilisant des variables globales est une pratique
à éviter, car on pollue l’environnement d’exécution, ce qui provoque de multiples problèmes.
Il existe une solution qui allie les avantages de AMD et de CommonJS, il s’agit de UMD (Universal
Module Definition 14 ). L’idée est de construire des modules exposant à la fois une interface AMD
destinée aux navigateurs Web et une interface CommonJS pour les environnements serveurs. C’est
cette solution que nous avons retenu pour RDF-REST.

3.3 Manipulation de triplets RDF

4 Travail réalisé
Lorsque j’ai commencé ce projet, il m’a fallu arriver à comprendre le framework RDF-REST. Mais
aussi savoir délimiter les rôles de RDF-REST dans des applications, afin d’être capable d’expliquer
RDF-REST aux groupes de TER qui travaillent sur Sympozer et sur les avatars pour le Web des
objets (projet ASAWoO) et qui ont pu commencer durant ces 6 semaines à utiliser RDF-REST.
Les longues discussions que j’ai eu avec ces groupes m’ont aussi permit de mieux cerner les besoins
d’une application en qui concerne les modèles de donnée.

4.1 Ecriture de parseurs pour RDF-REST

La première de mes tâches fût d’écrire des parseurs pour RDF-REST. Les parseurs permettent de
construire une représentation RDF en mémoire à partir de données sérialisées. Une version simplifiée
de ces parseurs existait déjà dans RDF-REST, mais ils ne traitaient qu’un sous-ensemble des formats
de données. Alors ce fût pour moi l’occasion de me documenter sur les formats de sérialisation de
RDF, plus précisément JSON-LD et N-Triples. J’ai alors utilisé deux bibliothèques open-source, celle
de Ruben Verborgh pour manipuler N-Triples, et celle de DigitalBazaar pour manipuler JSON-LD.
files/ECMA-ST/ECMA-408.pdf
11. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
12. http://wiki.commonjs.org/wiki/CommonJS
13. https://github.com/amdjs/amdjs-api/wiki/AMD
14. https://github.com/umdjs/umd

Rapport de TER de Raphaël Cazenave-Lévêque 5

M1if - UCBL 2014-2015

La seconde bibliothèque fût intéressante pour moi, car étant donné que son interface ne permettait
pas exactement de faire ce que l’on souhaitait, j’ai eu l’occasion d’étudier son fonctionnement interne
pour récupérer les informations dont on avait besoin.
C’est lors de cette phase de travail, et après plusieurs discussions ensemble, que le groupe de
TER travaillant sur Sympozer à choisit JSON-LD. La principale motivation fût le fait qu’il s’agisse
d’un format compatible avec JSON et que nous avions déjà une implémentation fonctionnelle dans
RDF-REST.

4.2 Construction d’un graphe RDF mutable à partir d’une source de donnée

Ensuite, et afin d’améliorer aussi bien ma compréhension de RDF-REST et pour avoir des
exemples d’utilisations pour expliquer le fonctionnement du framework, j’ai créé un projet d’exemple 15
dont je me suis servis de fil rouge tout au long de ce projet de recherche.
Dans ce projet j’utilise RDF-REST dans une application cliente utilisant AngularJS afin de
pouvoir afficher et d’éditer un graphe RDF provenant d’une API REST servant des documents au
format JSON-LD.

4.3 Abstraction de l’interface de RDF-REST

Il a été nécessaire d’abstraire l’interface du code, afin qu’il soit utilisable aussi bien coté client
et serveur. De plus, étant donné que deux autres groupes de TER utilisent RDF-REST dans leurs
projets, il a été obligatoire de spécifier l’interface qu’ils allaient utiliser, et de leurs fournir un moyen
cohérent d’utiliser le framework. Après de nombreuses discussions, nous avons sélectionné UMD
pour l’exposition de l’interface de RDF-REST.
Au moment où nous avons travaillé sur cette question, le code de RDF-REST était écrit sui-
vant la spécification CommonJS. Nous avons commencé par encapsuler les modules existants avec
une définition AMD, mais rapidement nous nous sommes rendu compte que cela impose trop de
contraintes sur la nature des bibliothèques utilisées en tant que dépendances.
Ainsi nous avons effectué des recherches sur ce que font les développeurs actuellement pour
résoudre cette problématique. Et nous en sommes arrivé à la solution d’utiliser l’outil Browserify
qui permet de construire un fichier JavaScript contenant à la fois le code de notre framework et le
code des dépendances.

4.3.1 Identification d’un bug dans une bibliothèque tierce

Lorsque nous avons utilisé l’outil Browserify, nous nous sommes aperçu d’un comportement
anormal d’une des bibliothèques tierce que nous utilisions pour parser le format de donnée JsonLD.
Cela à été l’occasion de soumettre ce bug à la société 16 qui édite ce code, ce rapport de bug à
conduit à une release mineure de jsonld.js (v0.3.22).

5 Conclusion
Références
Lionel Médini, Pierre-Antoine Champin, Michaël Mrissa, and Amélie Cordier. Towards semantic
resource mashups. In Services and Applications over Linked APIs and Data (SALAD), workshop
at ESWC, CEUR, pages 6–9, May 2014. URL http://liris.cnrs.fr/publis/?id=6685.

Tom Heath and Christian Bizer. Linked Data : Evolving the Web into a Global Data Space. Morgan
& Claypool, 1st edition, 2011. ISBN 9781608454303. URL http://linkeddatabook.com/.

Tim Berners-Lee. Linked data. World wide web design issues, July 2006. URL http://www.w3.
org/DesignIssues/LinkedData.html.
15. Disponible sur github : https://github.com/StatelessCat/Hydra-RDF-REST-bugtracker
16. https://github.com/digitalbazaar/jsonld.js

Rapport de TER de Raphaël Cazenave-Lévêque 6

M1if - UCBL 2014-2015

W3C. RDF 1.1 Concepts and Abstract Syntax, 2014. URL http://www.w3.org/TR/
2014/REC-rdf11-concepts-20140225/. http ://www.w3.org/TR/2014/REC-rdf11-concepts-
20140225/.

Frank Manola and Eric Miller. Rdf primer, 2004. URL http://www.w3.org/TR/2004/
REC-rdf-primer-20040210/.

Alexandre Bertails. Le web sÉmantique avec alexandre bertails, 2013. URL http://nipcast.com/
nipdev-11-le-web-semantique-avec-alexandre-bertails/.

Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures.
PhD thesis, 2000. AAI9980887.

Martin Fowler. Richardson maturity model : Steps toward the glory of rest. 2010. URL http:
//martinfowler.com/articles/richardsonMaturityModel.html.

Pierre-Antoine Champin. RDF-REST : A Unifying Framework for Web APIs and Linked Data.
In Services and Applications over Linked APIs and Data (SALAD), workshop at ESWC, 1056,
pages 10–19, Montpellier (FR), France, May 2013. URL https://hal.archives-ouvertes.fr/
hal-00921662.

ECMA International. Standard ECMA-262 - ECMAScript Language Specification. 5.1 edition, June
2011. URL http://www.ecma-international.org/publications/standards/Ecma-262.htm.

Rapport de TER de Raphaël Cazenave-Lévêque 7