UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

TAGNY NGOMPE GILDAS

LE PROJET “AGRONOMIC LINKED DATA
(AGROLD)”
DỰ ÁN AGROLD (MÔ HÌNH DỮ LIỆU AGRONOMIC)

MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE

HANOI – 2015


UNIVERSITE NATIONALE DU VIETNAM, HANOI
INSTITUT FRANCOPHONE INTERNATIONAL

TAGNY NGOMPE GILDAS

LE PROJET “AGRONOMIC LINKED DATA
(AGROLD)”
DỰ ÁN AGROLD (MÔ HÌNH DỮ LIỆU AGRONOMIC)
Spécialité: Systèmes Intelligents et Multimédia
Code: Programme pilote

MEMOIRE DE FIN D’ETUDES DU MASTER INFORMATIQUE

Sous la direction de:
Dr. Pierre LARMANDE – Ingénieur IRD, responsable de l’AXE Intégration de
Données de l’Institut de Biologie Computationnelle
Dr. Aravind VENKATESAN - Chercheur post-doctorant, IBC

HANOI – 2015


ATTESTATION SUR L’HONNEUR
J’atteste sur l’honneur que ce mémoire a été réalisé par moi-même et que les
données et les résultats qui y sont présentés sont exacts et n’ont jamais été
publiés ailleurs. La source des informations citées dans ce mémoire a été bien
précisée.

LỜI CAM ĐOAN
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả nêu trong Luận văn là trung thực và chưa từng được
ai công bố trong bất kỳ công trình nào khác. Các thông tin trích dẫn trong Luận
văn đã được chỉ rõ nguồn gốc.

TAGNY NGOMPE GILDAS


Table des matières

Table des matières
Remerciements

v
vi

Résumé

vii


Abstract

viii

Liste des figures

x

Liste des tableaux

xi

INTRODUCTION

1

Chapitre 1

PROBLÉMATIQUE DU PROJET AGROLD

3

1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.2 Système existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4


1.3 Problématique du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.4 Contraintes et résultats attendus . . . . . . . . . . . . . . . . . . . . . . .

6

Chapitre 2

PUBLICATION DES DONNÉES LIÉES ET OUVERTES

7

2.1 Le web des données liées et ouvertes . . . . . . . . . . . . . . . . . . . . .

7

2.2 Publication de données des sciences du vivant . . . . . . . . . . . . . . .
2.2.1 Données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9
10
11

2.3 Systèmes d’interrogation du web des données . . . . . . . . . . . . . . .
2.3.1 Aide à la construction de requêtes . . . . . . . . . . . . . . . . . .
2.3.2 Recherche d’informations spécifiques . . . . . . . . . . . . . . . .


11
12
14

2.4 Intégration de données de sources multiples . . . . . . . . . . . . . . . .

17

Chapitre 3

SOLUTION PROPOSÉE

20

3.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Paradigmes de recherche sémantique . . . . . . . . . . . . . . . .
3.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20
20
21

3.2 Prototype implémenté . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Intégration et adaptation de systèmes existants . . . . . . . . . . .
3.2.2 Développement de nouvelles fonctionnalités . . . . . . . . . . . .

22
22
23


iv


Chapitre 4

EXPÉRIMENTATIONS ET ANALYSE DES RÉSULTATS

4.1 Utilisation de l’application web AgroLD par des utilisateurs humains
4.1.1 Entrée des requêtes et expressivité . . . . . . . . . . . . . . . .
4.1.2 Exécution des requêtes et temps de réponse . . . . . . . . . . .
4.1.3 Présentation des résultats . . . . . . . . . . . . . . . . . . . . .

28
.
.
.
.

.
.
.
.

28
29
31
31

4.2 Utilisation des informations de la base AgroLD dans des applications . .

4.2.1 Utilisation de l’API pour la programmation . . . . . . . . . . . . .
4.2.2 Utilisation de l’API dans les workflows . . . . . . . . . . . . . . .

32
32
33

CONCLUSION

36

Références

37

Annexes

40

v


Remerciements
Nous adressons nos remerciements à tous ceux qui ont contribué à la réalisation du
travail présenté dans ce document, en particulier :
— à Pierre LARMANDE et Aravind VENKATESAN, nos superviseurs de stage ;
— aux responsables et membres du personnel de notre établissement l’Institut Francophone International ;
— aux structures qui nous ont encadré : l’Université Nationale du Vietnam à Hanoï
(UNVH), l’Université de Montpellier, l’Institut de Recherche pour le Développement (IRD), l’Institut de Biologie Computationnelle (IBC), le Laboratoire d’Informatique, de Robotique et de Micro-électronique de Montpellier (LIRMM), le
Centre de coopération International en Recherche Agronomique pour le Développement (CIRAD) ;

— à Nordine El Hassouni, ingénieur du CIRAD.

vi


Résumé
Le web des données liées offre une grande opportunité d’intégration de données
de sources et domaines divers. Cependant, il présente une rareté des données issue
de la recherche en biologie des plantes. Des chercheurs de l’IBC construisent actuellement la base de connaissance AgroLD en convertissant les données de la base de
données SouthGreen qu’ils lient à des ontologies et d’autres sources de données du
web des données. AgroLD est destinée à l’usage des biologistes et des bioinformaticiens. Ces groupes d’utilisateurs présentent des niveaux de compétences variées par
rapport aux technologies du web sémantique. Il s’agissait principalement pour nous
de leur proposer des moyens pour faciliter la recherche d’information dans AgroLD
et dans des services externes. Notre solution est de mettre à leur disposition sur une
même plateforme plusieurs fonctionnalités d’utilisabilité et d’expressivité différentes.
Les utilisateurs pourront choisir les systèmes de recherche qui leur conviennent et passer facilement de l’un à l’autre. Il a été aussi pris en compte l’activité de développement
d’applications des bioinformaticiens. Nous avons proposé une API de services REST
pour exposer les informations correspondant à des questions biologiques. Cette API
présente l’atout d’être facilement utilisable pour la programmation d’application et
dans le gestionnaire de workflows bioinformatiques Galaxy. Nous avons notamment
utilisé cette API et d’autres services web pour faire de l’agrégation de connaissances
au sein d’un formulaire dynamique dans notre prototype.
Mots clés : Intégration de données agronomiques, agrégation de connaissance, systèmes de recherche sémantique, interaction homme-machine, services REST

vii


Abstract
The web of linked data provides great data integration opportunity from various
sources and areas. However, it lacks data of research in plant biology. IBC’s researchers

are currently building the knowledge base AgroLD converting data base SouthGreen
data they bind to ontologies and other sources of web of data. AgroLD is intended
for use by biologists and bioinformaticians. These users groups have different levels
of skills by compared to semantic web technologies. For us, It were about to suggest
to them, ways to facilitate the search for information in AgroLD and external services.
Our solution is to provide them, on the same platform, several features with different
usability and expressivity. Users can choose which search systems that suit them and
easily switch from one to another. It was also considered the applications development
activity of bioinformaticians. We have proposed a REST service API to expose the information corresponding to biological questions. This API has the advantage of being
easily usable for application programming and in bioinformatics workflows manager
Galaxy. We used particularly the API and other web services to make knowledge aggregation in a dynamic form in our prototype.
Keywords : Integration of agronomic data, aggregation of knowledge, semantic
search systems, human-computer interaction, REST services

viii


Liste des figures

1.1
1.2

Lien entre deux ressources de sources distantes et différentes sur AgroLD
uri non déréférencé participant à des triplets dans AgroLD . . . . . . . .

2.1

2.4
2.5
2.6

2.7

Exemple de graphe de données liées (source : http://linkedlifedata.
com/about) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ensembles de données des sciences de la vie dans le nuage des données
liées et ouvertes (source : ) . . . . . . . . . . . . .
Ressources biologiques RDF liées à UniProtKB (uniprot.rdf), la base principale de UniProt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Différence entre les filtres et la navigation à facettes . . . . . . . . . . . .
Avantages des services RESTful sur les services basées sur SOAP (WS-*)
Architecture d’Open PHACTS Discovery Plateform . . . . . . . . . . . .
Architecture standard des applications de données liées et ouvertes . . .

3.1
3.2
3.3
3.4

Architecture proposée pour l’application web d’AgroLD
Editeur de requêtes textuelles SPARQL . . . . . . . . . . .
Module serveur de l’API d’AgroLD . . . . . . . . . . . . .
Activités de navigation avec le formulaire dynamique . .

2.2
2.3

4.1
4.2
4.3
4.4
4.5

4.6
4.7
4.8
4.9

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.


.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Scénario 1 : entrée de la requête . . . . . . . . . . . . . . . . . . . . . . . .
Scénario 2 : entrée de la requête dans le fomulaire dynamique . . . . . .
Scénario 2 : entrée de la requête dans l’éditeur de requête SPARQL . . .
Scénario 3 : entrée de la requête dans le fomulaire dynamique . . . . . .
Scénario 4 : entrée de la requête . . . . . . . . . . . . . . . . . . . . . . . .
Scénario 1 : présentation des résultats avec la recherche rapide par mot-clé
Scénario 2 : présentation des résultats . . . . . . . . . . . . . . . . . . . .
Scénario 3 : présentation des résultats . . . . . . . . . . . . . . . . . . . .
Scénario 4 : Relations découvertes entre le gène "adenosylmethionine decarboxylase" (AT3G25570) et les deux pathways "spermine biosynthesis"
et "spermidine biosynthesis" . . . . . . . . . . . . . . . . . . . . . . . . . .

4.10 Utilisation du service de recherche de gène par mot-clé dans un programme JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 documentation du service de recherche des protéines associées à un identifiant ontologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
5

8
10
10
14
16
17
18
21
24
25
27
29
29
30
30
30
31
32
32

33
33
34


ix


4.12 Intégration de la liste des gènes participant au pathway CALVIN-PWY
dans Galaxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.13 Workflow d’extraction des colonnes 1, 2 et 4 d’un tableau dans Galaxy . 35
4.14 Résultat de l’extraction des colonnes "geneId", "geneName" et "taxon_name" 35

x


Liste des tableaux

2.1

Catégories et exemples d’API . . . . . . . . . . . . . . . . . . . . . . . . .

15

A.1 Comparaison de clients SPARQL . . . . . . . . . . . . . . . . . . . . . . .

40

xi


INTRODUCTION
L’activité principale du projet IBC est le développement de méthodes et logiciels
innovants pour analyser, intégrer et contextualiser des données biologiques à grande
échelle dans le domaine de la santé, de l’agronomie et de l’environnement. Une des

principales problématiques abordées est l’intégration des données biologiques et en
particulier celles des plantes.
Par l’intégration de données provenant de plusieurs sources, les experts biologistes
peuvent obtenir une information plus riche à laquelle ils peuvent lier leurs propres
résultats pour la compléter. La difficulté d’intégration intervient régulièrement. Les
sources de données étant indépendantes et isolées, les fournisseurs n’adoptent pas toujours les mêmes formats de description, types d’information, et modèles de données
lors de la conception des bases de connaissance. Ceci introduit des hétérogénéités [1,2]
structurelles, sémantiques et syntaxiques entre les sources de données. L’import dans
un entrepôt central des données des sources différentes (intégration matérialisée) et
la fédération de requêtes vers des sources aux structures différentes au moyen d’interface de médiation (intégration dématérialisée) sont les principales solutions jusqu’alors
appliquées. Malheureusement, elles conservent toujours les données fermées et se focalisent généralement sur un domaine particulier.
Cette situation a poussé le W3C à proposer une évolution du web avec des technologies standards devant faciliter l’accès et l’intégration des données disponibles sur
internet. Cette évolution du web est appelé le web des données ouvertes et liées [3]. Elle
vise non seulement le libre accès aux données mais surtout une description sémantique
explicite de tout entité concrète ou abstraite. Les technologies proposées dans ce sens
ont pour but de permettre aux fournisseurs de données, la possibilité de structurer de
manière standard leur base de données et par là de faciliter la liaison des données à
d’autres données de sources distantes, et l’automatisation de leur interprétation et de
l’extraction de l’information.
Pour plusieurs disciplines scientifiques, des sources de données ont été converties
en RDF et liées à d’autres sources. Des ontologies RDFS et OWL ont été définies pour
formaliser explicitement la sémantique des ressources et des liens existant entre elles.
Malheureusement, ce travail est presque inexistant pour les données sur les plantes.
La base de connaissance AgroLD est donc conçue pour palier à cette rareté de données
liées et ouvertes agronomiques.
La question principale à l’origine de notre travail est celle de savoir comment facili-

1



ter l’utilisation d’AgroLD par les potentiels utilisateurs de la base de connaissance. La
solution doit leur permettre d’obtenir l’information la plus significative et riche possible. Les critères à prendre en compte sont principalement leur contexte d’utilisation
(workflow par exemple), le type d’information recherchée et leur niveau de connaissance des technologies du web sémantique.
Plus précisément, d’une part, il était question de proposer un ensemble de services
sur une plateforme web permettant non seulement une recherche plus aisée des informations mais aussi un développement plus facile de nouvelles applications répondant
aux besoins des experts. D’autre part, notre travail devait contribuer à la construction
de la base de connaissance en l’enrichissant automatiquement avec de nouvelles données et en corrigeant les URI non résolus dans la base.
Nous essayons donc d’évaluer les résultats de notre travail sur des aspects tels que
le temps et la séquence d’actions nécessaires pour une recherche, et la satisfaction de
l’utilisateur par rapport aux résultats retournés et son utilisation du système.
Ce mémoire est divisé en quatre chapitres. Le premier donne plus de détails concernant le contexte et la problématique du sujet. Le second fait un état de l’art de la recherche d’information dans le web des données. Ensuite, le troisième chapitre décrit
l’architecture proposée, les outils choisis et l’implémentation réalisée. Enfin, le dernier
chapitre présente l’expérimentation et l’analyse des résultats obtenus.

2


Chapitre 1
PROBLÉMATIQUE DU PROJET AGROLD

1.1

Contexte

L’IBC 1 est un projet multidisciplinaire soutenu depuis 2012 par l’initiative française "Investissement d’Avenir". Son but est le développement de logiciels et méthodes
innovantes pour analyser, intégrer et contextualiser les données biologiques dans les
domaines de la santé, l’agronomie et l’environnement. Le développement des concepts
et outils fait appel à diverses branches de recherche tels que l’algorithmique (combinatoire, numérique, hautement parallèle, stochastique), et la gestion de données et
la recherche d’information (intégration, workflows, cloud). Par ailleurs, leurs validations utilisent des applications de la biologie (transcriptomique, structure and fonction
des protéines, développement morphogénèse), de la santé (pathogènes, cancer, cellules souches), et de l’environnement (dynamique de la population, biodiversité). Le

projet IBC est divisé en cinq composantes complémentaires appelées "Work-package"
(en français : "groupe de travail") :
1. "WP1-HTS : Methods for high-throughput sequencing analysis" (en français :
"Méthodes d’analyse de séquençage à haut débit")
2. "WP2-Evolution : Scaling-up evolutionary analyses" (en français : "Amélioration
de l’accès aux analyses évolutives")
3. "WP3-Annotation : Structural and functional annotation of proteomes" (en français : "Annotation structurale et fonctionnelle des protéomes")
4. "WP4-Imaging : Integrating cell and tissue imaging with Omics data" (en français : "Intégration de l’imagerie cellulaire et tissulaire avec des données omiques")
5. "WP5-Databases : Biological data and knowledge integration" (en français : "Intégration des données et connaissances biologiques")
Le projet AgroLD 2 fait partie du composant "Intégration des données et connaissances biologiques". D’un point de vue global, AgroLD a pour rôle d’appliquer les
technologies web sémantiques pour fournir une base de connaissance intégrée des
données agronomiques. Ses objectifs définis jusqu’ici sont de :
1. IBC :
2. AgroLD : :8080/agrold/

3


— construire une base RDF à partir de sources de données concernant les plantes ;
— fournir un point d’accès central aux experts du domaine à Montpellier ;
— répondre aux questions complexes du domaine qui n’étaient pas accessibles par
les méthodes traditionnelles ;
— permettre l’extensibilité de la base ;
— permettre l’intégration dans les plateformes de workflows ;
— rendre la base de connaissance partageable et comme faisant partie du nuage
des données liées ("Linked Data Cloud") ;
— Enregistrer la base de connaissance dans des registres tels que CKAN et BioCatalogue pour accroitre sa visibilité.

1.2


Système existant

Dans la première phase du projet AgroLD, il est question de mettre en place une
première version de la base de connaissance. Ce travail est effectué par le développement d’un système de conversion automatique en RDF des bases de données de
SouthGreen 3 à partir des fichiers au format textuel tabulaire. La base comprend des
graphes RDF d’ontologies et des informations de sources de première importance ; les
bases de données Gramene 4 et SouthGreen qui incluent les espèces Oryza et Arabidopsis Thaliana. Pour les versions suivantes, la base de connaissance sera mise à jour
avec des informations additionnelles telles que l’information de microréseaux comme
RiceXPro, et l’information du facteur de transcription du riz comme Grassius.
La base de connaissance d’AgroLD est en effet organisée 5 en plusieurs graphes de
données et d’ontologies. En plus des ontologies externes, d’autres classes et propriétés
à AgroLD ont été définies, donnant ainsi un vocabulaire spécifique à AgroLD. La base
est liée à des sources distantes par des triplets liant des ressources (représentées par
leur URI) de sources différentes. La figure 1.1 montre un exemple de lien décrivant le
fait qu’un gène, identifié sur Ensembl, encode une protéine identifiée sur Uniprot.
Cependant, ils existent aussi des liens auxquels participent des URI non référencées c’est-à-dire qui ne renvoient directement à aucune page de description. Mais en
fait ils correspondent à des descriptions sur des sources distantes qui ne sont généralement pas RDF. C’est le cas par exemple dans ce triplet, de la figure 1.2, où la ressource
gramene_association:AQAC042_EO_0007403 n’est pas reconnu sur le serveur SouthGreen pourtant elle fait partie de ses bases de données.
Au démarrage de notre travail, les graphes de données sont hébergés sur le gestionnaire de base de données OpenLink Virtuoso installé sur un serveur du CIRAD 6 .
L’accès à AgroLD n’est possible que par un point d’accès SPARQL (celui fourni par dé3.
4.
5.
6.

SouthGreen :
Gramene :
http ://volvestre.cirad.fr :8080/agrold/documentation.jsp
CIRAD :

4



@prefix agrold_vocabulary:< .
@prefix ensembl:< .
@prefix uniprot:< .
ensembl:AT4G32600

agrold_vocabulary:encodes uniprot:Q8VY23 .

Figure 1.1 – Lien entre deux ressources de sources distantes et différentes sur AgroLD

@prefix agrold:< .
@prefix gramene_association:< />association/> .
@prefix gramene_qtl:< .
gramene_qtl:AQAC042 agrold:has_annotation
gramene_association:AQAC042_EO_0007403 .

Figure 1.2 – uri non déréférencé participant à des triplets dans AgroLD

faut par OpenLink Virtuoso) avec une interface simple permettant d’interroger la base
de connaissance en exécutant des requêtes SPARQL.

1.3

Problématique du sujet

Le langage SPARQL permet de construire des requêtes sous forme de motifs de
graphe pour interroger une ou plusieurs bases de connaissance RDF. L’éditeur de
requête SPARQL fourni par Virtuoso est un outil simple pour exécuter des requêtes
simples. Sa principale limite vient du langage SPARQL. En effet, l’écriture de requêtes

SPARQL n’est pas toujours aisée surtout lorsqu’on n’y est pas habitué. C’est le cas des
biologistes et bioinformaticiens qui constituent un groupe aux niveaux de compétences
assez variés en ce qui concerne l’interrogation des bases de connaissance RDF. Pour fi-

5


nir, les bioinformaticiens écrivent souvent séparément des requêtes plus ou moins optimales pour rechercher les mêmes informations. Ces informations sont généralement
des réponses aux questions courantes en biologie.
La problématique de notre sujet est donc celle de savoir comment faciliter la recherche d’information dans la base de connaissance AgroLD en prenant en compte le
profil de l’utilisateur et tout en lui retournant un résultat aussi complet que possible.
En d’autres termes, il s’agit premièrement de permettre aux utilisateurs d’exécuter des
requêtes plus rapidement en fonction de ce qu’ils connaissent déjà des technologies du
web, et plus particulièrement de celles du web sémantique. Enfin, il est question de
joindre aux résultats provenant de la base centrale AgroLD, d’autres données en sollicitant des services externes susceptibles d’apporter un complément d’information aux
données de la base.

1.4

Contraintes et résultats attendus

Les biologistes et bioinformaticiens utilisent généralement le web pour effectuer
des recherche d’information. Ils utilisent aussi les données biologiques dans des workflows conçus dans des systèmes telles que Galaxy 7 [4] (très couramment utilisé en
bioinformatique).
Le résultat attendu est donc un portail web d’accès public aux données et de recherche d’information dans AgroLD par les bioinformaticiens, les experts biologistes
et les développeurs potentiels d’applications. Ce portail web disposera notamment de
divers systèmes aux fonctionnalités différentes pour répondre aux questions plus ou
moins complexes utiles aux experts.
Différentes approches d’interrogation de la base devaient être explorées. Cependant, ce mémoire ne traite pas des approches de traitement du langage naturel car
elles font l’objet d’un autre stage de fin d’études de Master réalisé au même moment

que le présent projet. Ce stage est notamment à l’origine d’un vocabulaire spécifique au
domaine (plus accessible aux utilisateurs), que nous devrions utiliser pour mettre en
place un des systèmes proposés. Par ailleurs, notre travail est réalisé pendant la mise
en place de la base. Ceci nous contraint à partir des approches les moins dépendantes
de la structure de la base vers celles qui le sont le plus, et aussi à revenir régulièrement
vérifier et modifier l’implémentation de nos systèmes.

7. https ://galaxyproject.org/

6


Chapitre 2
PUBLICATION DES DONNÉES LIÉES ET OUVERTES

2.1

Le web des données liées et ouvertes

Le web des données liées et ouvertes est la première étape d’une vision future du
web, appelée le web sémantique. Ce dernier restructure le web sur cinq aspects principaux [5] visant l’interprétation, l’exploitation, la publication et le traitement automatique de l’information par la machine :
1. l’expression explicite du sens des contenus de pages Web ;
2. la représentation logique des connaissances afin d’utiliser des règles d’inférence sur les données et effectuer des traitements automatiques ;
3. l’usage d’ontologies pour définir les relations entre les termes (objets ou classe
d’objets, règles d’inférence) ;
4. l’assistance des internautes par des agents intelligents qui peuvent collaborer,
échanger des informations et effectuer des raisonnements automatiques ;
5. et enfin, la possibilité pour un groupe d’individus, travaillant autour d’un concept
de faire évoluer sa connaissance vers la connaissance des termes propres à
d’autres groupes travaillant de manière indépendante et séparée sur le même

concept.
C’est en fait en standardisant la structure et la sémantique des ensembles de données publiques qu’est construit le web des données. La publication des données devrait
alors suivre quelques règles [6] :
— Identifier les entités par des URI.
Les URI ici ont la même syntaxe que les URL. Mais à la différence de ces derniers
qui sont des adresses de pages web, les URI identifient des descriptions d’entités
du monde (personne, animal, objet, concept, ...) appelées dans ce cas ressources.
— Ces URI doivent être déréférençables via le protocole HTTP [7] pour permettre
qu’on puisse accéder aux descriptions des ressources identifiées.
— Lors de l’accès par ces URI, des métadonnées décrivant la ressource référencée
doivent être retournées, en suivant les standards RDF [8] et SPARQL [9].
Parmi les URI définis dans la base AgroLD, certaines ne sont pas encore déréférençables par le protocole HTTP comme présenté dans l’exemple de la figure

7


1.2, à la différence des URI de ressources externes de la figure 1.1 qui retourne
bien la description identifiée par cette URI.
— Inclure d’autres URI dans le jeu de données publiées pour permettre qu’on
puisse découvrir d’autres données. Comme on l’a vu à la figure 1.1 où des identifiants de ressources externes à AgroLD sont utilisés pour compléter l’information contenu dans la base.
Remarquons que deux standards, RDF et SPARQL sont recommandés dans ces
règles. En effet, RDF est la syntaxe de description des ressources du web et de structuration des ensembles de données. Son idée est de décrire les ressources et représenter
les bases de connaissances sous forme de graphes (figure 2.1) à partir du concept de
triplet de la forme (sujet, prédicat, objet). Dans ces triplets, l’objet est la valeur de la propriété du sujet définie par le prédicat. Le sujet est la ressource décrite (donc identifié
par une URI). Le prédicat est identifié par une URI qui identifie la propriété. L’objet lui
peut être un littéral (entier, chaîne de caractère, date, ...) ou même une autre ressource
(URI). En liant, par un triplet, deux nœuds deux graphes distants l’un de l’autre, un
graphe plus grand est établi.

Figure 2.1 – Exemple de graphe de données liées (source : http: // linkedlifedata. com/ about )


SPARQL quant à lui est à la fois un protocole et un langage d’interrogation des
bases RDF. Sa syntaxe est proche de celle de SQL pour les bases de données relationnelles. La requête suivante, par exemple, détermine les noms des gènes qui encodent
une protéine dont l’identifiant est connu (d’après le graphe de la figure 2.1).
# Quels sont les noms des gènes qui encodent la protéine Q4H1F1 ?
BASE
< />PREFIX uniprot:< />SELECT ?labelGene

8


WHERE{
?gene

rdf:type
:Gene ;
<hasProtein> uniprot:Q4H1F1 ;
rdfs:label
?labelGene .

}

Par ailleurs, les ontologies aident à décrire la sémantique des ressources en définissant les classes et les types de propriétés à l’aide des standards OWL ou RDFS. Par
exemple sur la figure 2.1, l’ontologie "Gene Ontology" (GO) uniformise les concepts et
propriétés biologiques concernant les gènes. Les ontologies permettent d’inférer des
énoncés (raisonnement) en appliquant des règles d’inférences logiques lors de l’interrogation des données.
Le web des données liées et ouvertes est donc une immense base de connaissance,
accessible à tous, et liant les données d’un grand nombre de domaines. Le développement d’application web n’exige plus que toutes les données que l’on manipule se
trouvent isolées mais les données locales peuvent être liées à d’autres données publiques et distantes. Les applications peuvent ainsi accéder à plus d’informations et
surtout en découvrir automatiquement.


2.2

Publication de données des sciences du vivant

L’informatique a longtemps contribué au renforcement du progrès scientifique en
proposant plusieurs technologies. Cette croissance a produit d’énormes quantités de
données. Les ensembles de données sont stockés de manière isolée suivant les équipes
de recherche. La problématique ici n’est pas le stockage ni l’accès aux données, mais,
pour le scientifique, comment percevoir la connaissance autour des données de différentes sources et partager cette perception avec d’autres chercheurs [10].
Du fait de l’hétérogénéité et l’isolation des bases de données, plusieurs fournisseurs
proposent aujourd’hui de publier leur données à travers les technologies web sémantiques. Cela peut se faire soit en convertissant les bases existantes en base de triplets
(materialisation des données [1]), soit en traduisant les requêtes SPARQL (réécriture
des requêtes [1]) des utilisateurs dans le langage liée à la structure des données (par
exemple SQL pour les base de données relationnelles). Les sciences de la vie font partie
des divers groupes (géographie, réseaux sociaux, gouvernance,...) de domaines fournissant des données dans le web des données (figure 2.2).
Dans le domaine particulier de la biologie, plusieurs ontologies et bases de connaissance existent.

9


Figure 2.2 – Ensembles de données des sciences de la vie dans le nuage des données liées et ouvertes (source :
http: // lod-cloud. net )

2.2.1

Données

UniProt 1 [11] fournit des données sur les protéines (fonction, classification, références croisées) 2 . Cette source intègre les données provenant des bases de données de
protéines Swiss-Prot, TrEMBL, PIR. Nécessitant un standard mieux défini que XML et

les format textuels tabulaires comme TSV ou CSV pour l’intégration des données, UniProt a opté pour la conversion en RDF de ses trois ensembles de données : UniProt Archive (UniParc), UniProt Knowledge Base (UniProtKB) et UniProt Reference (UniRef).
Le lien avec d’autres ressources biologiques (figure 2.3 [12]) est par là explicitement
exprimé et peut être utilisé pour découvrir d’autres données.

Figure 2.3 – Ressources biologiques RDF liées à UniProtKB (uniprot.rdf), la base principale de UniProt

Le centre de recherche NCBI 3 maintient en ligne plusieurs bases de données qu’il
publie non pas en RDF mais via des services web. Parmi ces bases, on peut citer entre
1. UniProt :
2. UniProt FTP : />3. NCBI :

10


autres la base centrée d’information sur les gènes, Entrez Gene, et la base de références
bibliographiques PubMed. Ces dernières, en plus d’UniProt et d’autres bases biologiques ont été converties en RDF avec des URIs normalisés dans le cadre du projet
Bio2RDF [13]. L’idée est de proposer une intégration et un accès centralisés aux différentes bases de données inter-reliées des sciences de la vie. Le but était de permettre
une interrogation plus aisée de plusieurs bases en une seule requête. D’autre part, l’Institut Européen de Bioinformatique (EBI) a développé « EBI RDF Platform » [14], une
plateforme intégrant les différentes bases de données de l’EBI. Cette plateforme permet ainsi d’adresser des questions complexes nécessitant des informations provenant
de plusieurs sources RDF comprenant des identifiants similaires et un point d’accès
SPARQL. Pour l’intégration des sources, EBI utilise un schéma uniforme pour les URI
des ressources des différentes sources, des ontologies pour annoter les données et des
vocabulaires (Dublin Core, Data Catalog Vocabulary, Vocabulary of Interlinked Datasets) pour la description d’ensembles de données par méta-données.

2.2.2

Ontologies

La signification des liens établis entre les éléments dans une base de données n’est
pas exprimée explicitement (par exemple, utilisation de clés étrangères dans les bases

relationnelles) [10]. Les ontologies aident ainsi à spécifier les concepts et leurs propriétés afin que l’expert comprenne la sémantique entre les données pour en tirer des
interprétations.
Les ontologies utilisées dans AgroLD ont chacune des domaines de la biologie
qu’elle spécifie. Nous avons déjà cité plus haut l’ontologie des gènes, "Gene Ontology 4 " (GO) qui décrit de manière consistante les produits des gènes entre les bases de
données biologiques (indépendamment des organismes). AgroLD utilise aussi entre
autres les aspects "Anatomie" et "Développement" de l’ontologie des plante, "Plant
Ontology" (PO), et la terminologie des environnement spécifique d’expérimentation
de "Plant Environment Ontology" (EO).

2.3

Systèmes d’interrogation du web des données

De manière standard, pour interroger une base de triplets, il faut faire exécuter
des requêtes SPARQL par des points d’accès SPARQL (« sparql endpoint »). Les points
d’accès SPARQL ont l’avantage de fournir une API standard. Même si le langage SPARQL
est assez efficace pour construire les requêtes (maximise l’expressivité des requêtes
[15]), il reste difficile à prendre en main vue sa large variété de fonctionnalités. SPARQL
propose en effet de nombreuses fonctionnalités aussi bien pour manipuler les données
que pour effectuer des recherches. Pour aider à la recherche sémantique, certains outils sont souvent proposés soit pour assister les utilisateurs dans la construction de
4. GO :

11


leurs requêtes, soit pour cacher le langage SPARQL et fournir une interface plus facile
à utiliser pour l’interrogation des bases cibles.

2.3.1


Aide à la construction de requêtes

2.3.1.1

Editeur textuel de requêtes SPARQL

Les fournisseurs de données RDF proposent une interface web pour l’édition et
l’exécution de requêtes SPARQL sur leurs données. Les systèmes de gestions de graphes
RDF tels que OpenLink Virtuoso propose déjà un formulaire HTML simple pour indiquer les paramètres d’exécution au point d’accès SPARQL, parmi lesquels :
— "query" : le texte de la requête SPARQL ;
— "default-graph" : le graphe particulier à interroger ;
— "timeout" : le délai maximal de temps pour l’exécution ;
— "format" : le format dans lequel seront retournés les résultats (tableau HTML,
XML, CSV, RDF/XML, RDF/Turtle, ...)
Certains publieurs de données améliorent l’utilisabilité de leurs clients SPARQL en
intégrant des librairies d’édition de code (texte de la requête) et de gestion des résultats.
Par exemple, UniProt 5 et « linked life data » 6 joignent une grammaire de SPARQL
à la librairie CodeMirror 7 pour proposer la coloration et vérification syntaxique, et
l’auto-complétion. Parmis les librairies les plus avancées (voir figure A.1), on retrouve
YASQE, de la famille YASGUI [16], qui est basées aussi CodeMirror mais propose un
éditeur adapté à la syntaxe SPARQL. YASR [16] associé à YASQE permet de gérer les
messages d’erreur et de mieux afficher les résultats des requêtes.
Des interfaces fournissant plus de fonctionnalités, comme YASGUI 8 et Flint SPARQL
Editor 9 , sont disponibles en ligne pour interroger n’importe quel serveur SPARQL.
YASGUI propose par exemple, l’interrogation simultanée de plusieurs serveurs SPARQL,
la recherche de SPARQl endpoint, la conservation d’une requête entre deux sessions
web.
2.3.1.2

Les langages visuels de requête


Il s’agit des systèmes permettant aux utilisateurs d’effectuer les requêtes de manière
graphique. Leur but commun est d’augmenter l’intuitivité et l’utilisabilité du langage
SPARQL. Leur principe est de construire les requêtes SPARQL en passant par des représentations graphiques.
Parmi les systèmes les plus récents et avancés, nous pouvons citer ReVeaLD [17]
et QueryVOWL [18]. ReVeaLD 10 est un système d’interrogation fédérée de données
5.
6.
7.
8.
9.
10.

Point d’accès SPARQL d’UniProt : />Point d’accès SPARQL de « linked life data » : />CodeMirror : />YASGUI : />Flint SPARQL Editor : />ReVeaLD : />
12


des recherches sur le cancer. Son principe est de partir d’un langage graphique, extensible, avec des concepts et liens spécifiques au domaine (supposés connu de la majorité
des experts), pour permettre à l’utilisateur de représenter des questions complexes de
son domaine. Un serveur SPARQL central reçoit donc la requête SPARQL construite,
puis la traduit en plusieurs requêtes fédérées pour les différents serveurs de données.
Par contre, QueryVOWL 11 est définit par une représentation graphique des différents
concept du langage SPARQL (Concepts, individus, disjonction, filtre, ...). Le graphe
construit par l’utilisateur, dans ce cas, ne représente pas la requête mais un patron des
données. Chaque nœud correspond à une requête SPARQL et donc renvoie une certaine information par rapport à cet unique nœud. Le serveur SPARQL est interrogé régulièrement pour assister l’utilisateur avec la liste des valeurs possibles pour un nœud,
ou la description d’un individu par exemple. Ces systèmes ne couvrent pas toutes les
fonctionnalités du langage SPARQL mais peut servir à la construction rapide du début
d’une requête complexe. L’utilisateur pourrait affiner cette dernière par la suite dans
un éditeur textuel. L’avantage de ReVeaLD par rapport à QueryVOWL c’est qu’il propose plus de flexibilité dans la sélection des informations à retourner (QueryVOWL
par exemple ne retourne pas des lignes de résultats où on peut voir la relation entre

les différentes valeurs des variables de requête, mais uniquement le label du nœud
sélectionné).
SPARQLGraph 12 [19], comme ReVeaLD [17], a été développé dans le contexte des
sciences du vivant en prenant en compte leur spécificité. Sa particularité est de laisser
le soin à l’utilisateur de choisir la source pour une certaine information, d’intégrer luimême les différents services dans sa requête. A la différence de ReVeaLD qui passe
par un médiateur de requête SPARQL, SPARQLGraph permet d’interroger plusieurs
sources simultanément à partir d’une seule requête fédérée SPARQL. En plus, il permet
un partage de requêtes visuelles et une collaboration entre les experts biologistes.
2.3.1.3

Interrogation basée sur les phrases en langage naturel

Les systèmes basés sur le langage naturel assiste l’utilisateur dans l’interrogation
des bases de données en acceptant des questions en langage naturel. Ainsi, l’utilisateur
n’a besoin de connaitre que la terminologie des données, et non plus d’apprendre le
langage complexe SPARQL.
Dans le prototype actuel de LODQA 13 [20] par exemple, l’utilisateur fournit une
question sur un domaine de connaissance préalablement sélectionnée. La question
passe ensuite par des étapes de traitement de langage naturel et de représentation intermédiaire. Les identifiants (URI) correspondant aux mots clés de la question sont
recherchés dans des sources ontologiques ou de données spécifiques. Si ces URI sont
11. QueryVOWL : />12. SPARQLGraph :
13. LODQA : />
13


trouvés, le système génère enfin plusieurs requêtes SPARQL, pouvant peut-être correspondre à la question posée.
D’autre part, Sparklis 14 [15] assiste de manière interactive l’utilisateur dans la construction de sa requête en langage naturelle. Le point d’accès SPARQL est interrogé à chaque
étape pour orienter l’utilisateur avec des informations possibles pour compléter la requête. La requête SPARQL est construite en arrière-plan. La difficulté pour l’utilisateur
est de retrouver à chaque étape l’information à sélectionner car la quantité proposée est
souvent très grande. Mais, l’avantage est l’exploration à facettes personnalisées que le

système propose.

2.3.2

Recherche d’informations spécifiques

2.3.2.1

Exploration interactive

Pour rechercher de l’information, on a généralement recourt à la navigation dans
un ensemble de données. Généralement, le temps requis pour trouver l’information
recherchée dépend des critères fournis au système. La recherche basée sur les mots
clés, par exemple, peut se faire suivant deux modes : les filtres et les facettes. Ces deux
modes, par principe, analysent un grand ensemble de contenu et excluent les éléments
qui ne respectent pas un certain critère. Comme on peut le comprendre d’après la figure 2.4 [21], la navigation par facette utilisent plusieurs filtres pour donner différentes
vues afin que l’utilisateur ait une meilleur compréhension des données. Par ailleurs, la
réalisation des facettes demande plus d’effort que celle des filtres.

Figure 2.4 – Différence entre les filtres et la navigation à facettes

Le service web Virtuoso Facets facilite le développement d’application web sémantique de navigation à facettes. La requête et la réponse étant sous forme d’arbre XML,
la partie de la requête SPARQL nécessaire à la navigation à facettes est mieux précisée [22] que dans le cas d’une requête en simple texte (SPARQL).
14. Sparklis : />
14