Rapport de Stage - Enrichissement et peuplement d’ontologies

tonguescurlySoftware and s/w Development

Nov 17, 2012 (4 years and 7 months ago)

816 views

1

| XSD2OWL



Le2i


Laboratoire Electronique
,

Inf
o
r
matique et Image




Rapport
de Stage

Enrichissement

et peuplement d’ontologies

8 Mai 2009


Yoan Chabot

IQS4B





Projet
XSD2OWL









IUT Informatique de Dijon

Tuteur

: Christophe Cruz

2008/2009

Version
1.0



2

| XSD2OWL







Rapport

de Stage


Enrichissement

et peuplement d’ontologies

8 Mai 2009



Yoan Chabot

Version
1.0



46

pages




Résumé
:

Le
présent document

expose le travail effectué dans le cadre de mon
stage de fin de DUT. Basé sur une publication de deux chercheurs du Le2i,
ce
dossier se propose de présenter le travail d’analyse, de conception et de
développement
effectué

pour permettr
e la réalisation d’un outil assurant le
peuplement d’ontologies de façon fiable et flexible à partir de données XML

grâce à l’utilisation de règles de mapping RDF.



Mot
s
-
clés
:

Schéma

XML
,

ontologie OWL, enrichissement,
population












Yoan Chabot

3

| XSD2OWL




Remerciements






Avant toutes choses, il me paraît important de remercier les personnes qui
ont permis à
ce stage d’être un moment profitable et agréable
.


Je remercie donc M.

Christophe Cruz de m’avoir formé aux technologies du web sémantique
et aux techniques de recherche, avec

beaucoup de pédagogie, tout au
long de mon stage et de
mon projet tuteuré. Je le remercie également de m’avoir donné la chance de travailler sur ce
p
rojet qui m’a réellement passionné et qui a permis également de confirmer l’intérêt que je
porte pour le domaine de la recherche.


Merci à

M
.

Syl
v
ain Rampaceck
de

m’avoir accueilli dans son bureau et
de
m’avoir apporté
aide et
sympathie
.


Merci aux membres

de mon équipe de projet tuteuré, M
.

Emmanuelle Neret et M
.

Harbelot

Benjamin, pour leur
s

soutien
s

quotidien.


Je

remercie M
.

Romain Picot
-
Clémente, M
.
Clément Mignard
,

M
.
Christophe Nicolle

et M.
Martin Richard

pour leur présence et leur bonne humeur.


Merci à mon entourage pour leurs encouragements tout au long du stage.


Merci éga
lement au jury pour l’attention
portée à la lecture de ce rapport.









Yoan Chabot


4

| XSD2OWL

Table des matières

Introduction

................................
................................
................................
................................

6

1.

Présentation

................................
................................
................................
.........................

7

1.1

Le2i

................................
................................
................................
..............................

7

Généralités

................................
................................
................................
..........................

7

Organisation et activités du LE2I
................................
................................
........................

8

Cellule A3

................................
................................
................................
...........................

9

1.2

Contexte du pr
ojet

................................
................................
................................
.......

9

1.2.1

Web sémantique

................................
................................
................................
...

9

1.2.2

Projet CheckSem

................................
................................
................................

10

2.

Pro
jet XSD2OWL

................................
................................
................................
.............

12

2.1 Définition de la mission

................................
................................
................................
..

12

2.1.1

Présentation de l'article «

Ontology Enrichment and Automatic Population From
XML Data

»

................................
................................
................................
......................

12

2.1.2

Expression du besoin

................................
................................
..........................

15

2.1.3

Etude de l’existant

................................
................................
..............................

16

2.1.4

Technologies employés

................................
................................
......................

17

2.2 Organisation du projet

................................
................................
................................
....

20

2.2.1

Choix techniques

................................
................................
................................

20

2.2.2

Méthode de développement

................................
................................
...............

21

2.2.3

Planning

................................
................................
................................
..............

23

2.2.4

Management de projet et communications

................................
.........................

25

2.3 Analyse et conception

................................
................................
................................
....

25

2.3.1

Conception

................................
................................
................................
.........

25

2.3.2

Jeux d’essais

................................
................................
................................
.......

27

2.4
Résultat obtenus et améliorations possibles

................................
................................
...

35

3.

Conclusion

................................
................................
................................
........................

36

3.1

Apport techniques

................................
................................
................................
......

36

3.2

Ap
port personnel

................................
................................
................................
.......

37

4.

Résumé

................................
................................
................................
..............................

37

5.

Glossaire

................................
................................
................................
...........................

39

6.

Index

................................
................................
................................
................................
.

41

7.

Bibliographie

................................
................................
................................
.....................

42

Yoan Chabot

5

| XSD2OWL

8.

Annexes

................................
................................
................................
.............................

43


Table des figures


Figure 1 IUT Le Creusot

................................
................................
................................
................................
...........

7

Figure 2 ENSAM Chalon sur Saône

................................
................................
................................
..........................

7

Figure 3 Campus Auxerre

................................
................................
................................
................................
........

7

Figure 4 Faculté Mirande

................................
................................
................................
................................
........

8

Figure 5 Organigramme Le2i

................................
................................
................................
................................
...

8

Figure 6 Mon poste de travail

................................
................................
................................
................................
.

9

Figure 7 L'évolution du web

................................
................................
................................
................................
....

9

Figure 8 Raisonnement par inférence

................................
................................
................................
...................

10

Figure 9 Intervenants LE2I : Equipe SISI
................................
................................
................................
.................

11

Figure 10 Intervenants IFR Santé
-
Stic
-
Université de Bourgogne

................................
................................
..........

11

Figure 11 Intervenants Au niveau de France et International

................................
................................
...............

11

Figure 12 Projet CheckSem

................................
................................
................................
................................
....

12

Figure 13 Enrichissement et peuplement

................................
................................
................................
..............

13

Figure 14 Mapping RDF

................................
................................
................................
................................
.........

13

Figure 15 Travaux précédents

................................
................................
................................
...............................

16

Figure 16 Versio
nning

................................
................................
................................
................................
...........

22

Figure 17 Planning de début de stage

................................
................................
................................
...................

24

Figure 18 Planning prévisionnel

................................
................................
................................
............................

24

Figure 19 Planning réel
................................
................................
................................
................................
..........

25

Figure 20 Cas d'utilisations 1

................................
................................
................................
................................
.

26

Figure 22 Arbre XSD

................................
................................
................................
................................
..............

27

Figure 23 Cas n°1

................................
................................
................................
................................
...................

29

Figure 24 Cas n°2

................................
................................
................................
................................
...................

29

Figure 25 Cas n°3

................................
................................
................................
................................
...................

29

Figure 26 Cas n°4

................................
................................
................................
................................
...................

30

Figure 27 Cas n°5

................................
................................
................................
................................
...................

30

Figure 28 Cas n°6

................................
................................
................................
................................
...................

31

Figure 29 Cas n°7

................................
................................
................................
................................
...................

31

Figure 30 Cas n°8

................................
................................
................................
................................
...................

32

Figure 31 Cas n°9

................................
................................
................................
................................
...................

32

Figure 32 Cas n°10

................................
................................
................................
................................
.................

33

Figure 33 Cas n°11

................................
................................
................................
................................
.................

33

Figure 34 Cas n°12

................................
................................
................................
................................
.................

34




Yoan Chabot


6

| XSD2OWL



Introduction






Dans le cadre du DUT Informatique, nous sommes amenés à réaliser un stage au sein
d’une entreprise ou
d’une
organisation.

En accord
avec le programme pédagogique
national,
celui
-
ci nous permet de faire nos premiers pas dans le monde du travail et de mettre en
pratique les savoirs théoriques et pratiques acquis au cours des deux années passées à l’IUT.


J’ai eu la chance de vivre cette première expérience au Le2i de

Dijon au sein de la faculté des
sciences Mirande de l’université de Bourgogne

du 6 avril 2009 au 15 juin 2009
.

Encadré par
des enseignants
-
chercheurs, j’ai
pu

travailler

dans un domaine que j’avais déjà abordé par le
passé lors de mon projet tuteuré

(Conv
ertisseur OWL vers RDF/RDFS)
: le web sémantique.
Mon tuteur de stage, M
.
Christophe Cruz, m’a chargé de reprendre les travaux d’anciens
stagiaires

dans le cadre de la conception et du
développement d’un outil de peuplement
d’ontologies à partir de données

XML
.


Bien qu’étant la reprise d’un travail déjà débuté, j’ai pu aborder touts les aspects de la création
d’un outil logiciel, de l’analyse aux tests de débogage, en passant par les phases de
prospection ou encore de développement.


Le but de

ce rapport est d’exposer le contexte de mon stage par le biais d’une présentation du
Le2i dans un premier temps puis
d’une présentation

du

projet qui m’a été
confié
. Enfin je
conclu
rai

ce
document

par mes impressions sur ce stage ainsi que les
différents
enseignements
que j’ai pu en
tirer
.





Yoan Chabot

7

| XSD2OWL

1.

Présentation

J’exposerai

dans cette partie les différents pôles et les domaines de recherches du Le2i.
Dans un second temps
,
je présenterai

la cellule A3 (Système d'informations et d'images) qui
m’a accueilli pour ce stage. Enfin
, je terminerai

cette partie par une présentation du domaine
de recherche de l’équipe (Le Web sémantique
) ainsi
que
leur projet actuel

: le pro
jet
CheckSem.

1.1


Le2i

1.1.1

Généralités

Le Laboratoire d'Electronique, Informatique et Image est associé à
l'INST2I (Institut des Sciences et technologies de l'information et de
l'ingénierie) du CNRS dans le domaine des STIC (Sciences et Technologies de
l’Informa
tion et de la Communication) depuis janvier 2001 en tant que FRE
(Formations de Recherche en Évolution) puis en tant que UMR (Unité Mixte de
Recherche) depuis janvier 2003. Étant associé à un département du CNRS, le
LE2I est un organisme public de recherch
e et un établissement public à caractère scientifique
et technologique (EPST) placé


sous la tutelle du ministère de l’enseignement supérieur et de
la recherche. Il est composé d'enseignants
-
chercheurs, de collaborateurs techniques et
administratifs et de
doctorants répartis sur quatre sites géographiques que sont Dijon, Le
Creusot, Auxerre et Chalon sur Saône.


L'équipe du Creu
sot est située au sein de l'IUT le
Creusot. Elle
est spécialisée dans le contrôle qualité de produits
manufacturés par vision
artificielle (caméra). Cette thématique
intéresse particulièrement les industriels soucieux de garantir à
leurs clients la meilleure qualité de fabrication possible
.


L'équipe de Chalon sur Saône est situé au
sein de l'ENSAM (
Ecole Nationale Supérieure d'Arts et Métiers). Elle
est
spécialisée

dans le domaine de la réalité virtuelle. L'objectif de
l'équipe de

recherche est de développer un savoir
-
faire dans les
techniques d'immersion multi sensorielle pour l'interaction avec un
modèle numérique.



L'équipe d'Auxerre e
st spécialisée dans l'imagerie e
t les
mesures 3D et est situé sur le campus
universitaire de la ville.

Figure
1

IUT Le Creusot

Figure
2

ENSAM Chalon
sur Saône

Figure
3

Campus Auxerre

Yoan Chabot


8

| XSD2OWL

Equipe A

Informatique

Dijon

Cellule A1 : Algorithmique
combinatoire

Cellule A2 : Synthèse d'images et
modélisation géométrique

Cellule A3 : Systèmes d'informations
et systèmes d'image

Cellule A4 : Métamodelisation et
ingénierie de plateformes

Celulle A5 : Modélisation et
vérification formelle

Equipe B

Signal et Imagerie médicale

Dijon

Cellule B1 : Architecture

Cellule B2 : Signal et automatique
non linéaires

Cellule B3 : Imagerie médicale

Equipe C

Image, Vision, nD

Le Creusot, Auxerre, Chalon
sur Saône, Dijon

Cellule C1 : Vision 3D

Cellule C2 : Imagerie et mesures

Cellule C3 : Immersion virtuelle

Cellule C4 : Multispectral 2D+

Les 3 pôles ci
-
dessus constituent l'équipe C du Le2I.
Mon stage s'est effectué au sein du pôle de Dijon qui
accueille l'équipe A et l'équipe B travaillant
respectivement sur l'informatique g
énérale et l'imagerie
médicale ainsi qu'une partie de l'équipe C
(Mutlispectral 2D+). Le Le2I Dijon se trouve à l'
UFR
Sciences et Techniques situé au sein de la faculté des
sciences Mirande et de l'ESI
REM.

1.1.2

Organisation et activités du LE2I

Le Le2i est constitué de 224 personnes dont :



86 enseignants chercheurs



103 doctorants



18 post
-
doctorants, invités ou stagiaires



17 collaborateurs
techniques/administratifs


Comme dit précédemment, le Le2i est constitué de 3 équipes : l'équipe A : Informatique,
l'équipe B : Signal et Imagerie médicale et l'équipe C : Signal et Imagerie médicale.

Chacune
des équipes est décomposée en cellule comme le montre l'organigramme ci
-
dessous :


Afin de pouvoir exercer ses recherches, le LE2I dispose d’un budget annuel provenant de trois
sources de financement qui sont :

Figure
4

Faculté Mirande

Figure
5

Organigramme Le2i

Yoan Chabot

9

| XSD2OWL



Le ministère de l’enseignement supé
rieur et de la recherche à hauteur de 144 000
euros
.



Le CNRS à hauteur de 28 000 euros
.



Les ressources propres du laboratoire (contrats effectués) à hauteur de 600 000 euros
.

En moyenne, le laboratoire présente 200 publications par an.

1.1.3

Cellule
A
3

Dans le cadre de mon stage, j'ai pu intégrer la
cellule A3. L'équipe de cette cellule axe ses
recherches sur
les systèmes

d'informations et
d'images. Cette équipe est constituée de 9
enseignants chercheurs et d'environ 15 thésards et
post
-
doctorant
s
. Le
s recherches de cette équipe, e
t
plus parti
culièrement celles de M. Cruz et M.

Nicolle, sont axé
e
s sur le domaine du web
sém
antique et ses applications. Mon stage s'es
t
effectué sous la tutelle de M.

Cruz, qui avait été
auparavant mon tuteur de projet. J'ai ét
é accueilli
dans le bureau de M.

Rampaceck qui se trouve dans
l'aile B de la faculté Mirande.


1.2


Contexte du projet

D
ans

cette partie, je retracerai

l’histoire d’internet jusqu’à l’arrivée du web sémantique.

1.2.1

Web sémantique

Depuis sa création, Internet a connu
de nombreuses évolutions.
Dans son état
initial le web 1.0 était exclusivement
constitué de pages statiques qui étaient
rarement mise à jour par manque de
maniabilité et d’accessibilité. Petit à peti
t
internet est devenu un réseau
plus interactif.
Les données se générant dynamiquem
ent à
partir de bases de données, une grande
facilité à communiquer, le dév
eloppement
des réseaux sociaux, sont
autant de
possibilités réunies sous la bannière du web
2.0. Seulement le fond reste le même

: les
données présentées sous forme de pages par
int
ernet n’ont de sens que pour les yeux
d’un humain. Le code HTML (
HyperText
Markup Language)

des pages internet est
pris en charge par le navigateur qui a pour
rôle de traduire et d’afficher les données à
l’écran. Le web sémantique permettrait de

donner un

sens aux données via
à un système de
métadonnées

(donnée définissant une autre
donnée) afin que celle
s
-
ci puissent être traité
es

automatiquement. Le web sémantique est
Figure
6

Mon poste de travail

Figure
7

L'évolution du web

Yoan Chabot


10

| XSD2OWL

fon
dé sur les principes du web actuel et s’appuie sur ce dernier

: c’est donc une évolution et
pas un remplacement. Le rôle du web reste entier

: consulter des données rapidement.

Le concept de la sémantique étant relativement jeune sur internet, il est
encore difficile de dire
qu’elles seront les réels apports de ce dernier. Toutefois on peut déjà saisir les contours de
plusieurs applications engendrées par cette évolution
.



Le raisonnement par inférence

:

C’est une opé
ration qui consiste à tirer une
conclusion à partir de données connues. Cela permet donc de déduire de nouvelles
informations à partir de l’existant. C’est un processus de création qui permet
l’expansion des connaissances. Tirer des conclusions, faire des
déductions sont des
chose
s qui étaient jusque là réservées

aux êtres doté
s

d’un esprit permettant la logique.
Grâce à la sémantique cela pourrait s’étendre aux ordinateurs. Lorsque l’on connait la
différence de vitesse de calcul entre un
cerveau humain et
un ordinateur,
on imagine
rapidement les possibilités ouvertes par un tel phénomène.














Optimisation de la coopération
entre les machines

:

Grâce à la sémantique,
ce ne
sont plus seulement les hommes qui comprennent le sens des informations. Désormais,
La machine le
s

comprend et peut donc travailler
différemment
. A ce jour internet
permet l’accès à un énorme volume de donn
ées, la sémantique apporte aux machines
le moyen de les traiter.

Les possibilités et les libertés engendrées par le web sémantique ont permis à de nomb
reux
langages sémantiques de naî
tre. Constatant la similitude de ces derniers le W3C

(World W
ide
Web Consortium) a mis en place un groupe de travail

: WebOnt. Il en résultera deux
recommandations provenant du W3C (Le W3C n’émet pas de normes mais des
recommandations)

: Les langages RDF et OWL

notamment utilisés dans le cadre du projet
présenté ci
-
dessous
.

1.2.2

Projet CheckSem

L’évolution des systèmes distribués se caractérise par une
complexité croissante et un rôle toujours plus critique. Les logiciels
orchestrant de tels systèmes doivent réagir correctement et en
particulier face aux
situations critiques. La vérification des
propriétés

de ces systèmes est reconnue comme un problème
difficile et se heurte à plusieurs problèmes d’ordre pratique et
théorique. Un premier obstacle apparaît au niveau de la définition du la
ngage de spécification
utilisé. Si celui
-
ci est trop expressif, alors on ne peut pas, mathématiquement, l’analyser de
manière automatique. Un second obstacle est l’explosion combinatoire des états possibles des
systèmes. Le défi est donc de proposer des mo
dèles qui soient suffisamment expressifs tout en
Les voitures sont
des

véhicules

Les véhicules sont
tous rouges

Les voitures sont rouges

Figure
8

Raisonnement par
inférence

Yoan Chabot

11

| XSD2OWL

restant raisonnablement analysables. Les outils de vérification permettent de résoudre en
partie le problème de l’explosion combinatoire de l’espace d’états du système rencontré lors
de la vérification du mo
dèle. La représentation de données par des graphes est très répandue
dans les domaines du web sémantique et des méthodes formelles. Un problème majeur
concerne leur interopérabilité

: il est nécessaire d’avoir des outils logiciels permettant de
réaliser la

traduction d’un graphe décrit dans un formalisme vers le même graphe (ou une
adaptation) décrit dans un autre formalisme.

L’idée générale du projet C
heckSem

consiste à
vérifier des propriétés de graphes sémantiques. Pour cela,
l’équipe étudie

dans le cadr
e de ce
projet, différentes approches pour construire des graphes sémantiques à partir de sources
hétérogènes d’information (Fichiers IFC, grammaire et documents XML
, graphes
RDF
,
ontologies OWL, bases de données hétérogènes, modélisation conte
xtuelle, système
d’information géographique). Le projet C
heckSem

est articulé en sous
-
projets en fonction du
domaine d’application (bâtiment, médical, archéologique, space
-
planning, web) ou en

fonction du type d’approche utilisée (population d’ontologies,
indexation sémantique, méta
modélisation).

Mon sujet de stage constitue une brique du vaste projet qu'est CheckSem mené
par une équipe de chercheurs issus du Le2i et d'autres horizons
comme le montre les tableaux
ci
-
dessous
:


Nom

Statut

Origine

Christophe Cruz

IUT Dijon

Maître de conférences

Christophe Nicolle

IUT Dijon

Professeur

Sylvain Rampaceck

IUT Dijon

Maître de conférences

Romain Picot Clémente

Côté d’or touristes

䑯a瑯牡湴

Clément Mignard

Groupe Archimen

Doctorant

Haschisch
Karmacharya

Institut I3Mainz
-
Le2i

Doctorant

Bruno Binet

IUT Dijon

Past

Figure
9

Intervenants LE2I : Equipe SISI


Nom

Statut

Origine

Franck Marzani

Le2i
-
MD2+

Maître de conférences HDR

André Bouchot

IFR 100

Ingénieur de recherche

Florence Mendès

Le2i
-
Combinatoire

Maître de conférences

Zyed Belkhir

Le2i
-
Ecole doctorale

Master recherche

Figure
10

Intervenants IFR Santé
-
Stic
-
Université de Bourgogne


Nom

Statut

Origine

Radu Mateescu

INRIA
-
VASY

Chargé de
recherche HDR

Gilles Gesquière

Université de Provence

Maître de conférences

Franck Boochs

Institut I3Mainz

Professeur

Figure
11

Intervenants Au niveau de France et International


Le
projet

CheckSem se décompose en quatre sous projets :


Yoan Chabot


12

| XSD2OWL

Mon sujet de stage fait partie
intégrante du sous projet
«

Semantic Web

». Cette partie du
projet CheckSem se propose de
réaliser l'extraction de la
connaissance de fichier n'ayant pas
été conçu pour ce gen
re
d'applications à l'origine (IFC et
XML

dans notre cas). Malgré ce
fait, les fichiers IFC et XML ne
sont pas
totalement
dénués de
données sémantiques.
Les
différents modules composants la
partie «

Semantic Web

» sont donc
chargés d'extraire c
es données pour
construire des graphes RDF ou bien
des ontologies OWL. Pour ma part,
j'ai été associé à la réali
sation du
module «

XML to OWL

» que je
présenterais
plus en détail

dans ce
dossier.


2.

Proje
t XSD2OWL

Après cette présentation du contexte et de l’environnement du projet, je vais maintenant
présen
ter le sujet de mon stage. Cette parti
e est constituée de quatre sous parties. J’expliciterai

dans un premier temps la natur
e de ma mis
sion. Je présenterai

ensuite l’organisation
adoptée

pour mener à bien le projet qu
i m’a été confié. J’expliquerai

ensuite le cheminement
intellectuel accompli lors de la phase d’analyse et

de conception et je terminerai

cette partie
par une présentation de
s résultats et des améliorations possibles.

2.1

Définition de la mission


Cette partie a pour objectif d’expliciter les objectifs et l’état
actuel du projet.
J’expliquerai

dans un premier temps les principes théoriques inhérents à mon projet. Ces
principes ont

été mis en place par M.

Cruz et M
.

Nicolle dans une de leurs publications. Dans
un second temps, je présenterai

les besoins auxquels le proj
et doit répondre. Je termi
nerai

cette partie par une présentation des travaux existants et une étude des technologies
employées.

2.1.1

Présentation de l'article «

Ontology Enrichment and
Automatic
Population From XML

Data

»

Le sujet de mon stage est une mise en pratiqu
e d’une publication scientifique
purement théorique ayant pour auteurs deux chercheurs du Le2i

: M
.

Christophe Cruz et M
.
Christophe Nicolle.
Cet

article intitulé «

Ontology Enrichment and Aut
omatic Population
From XML

Data
»

pose les bases qui

ont été nécessaire à la réalisation du projet XSD2OWL
.
Cette partie a pour but de vulgariser les principes énoncés dans l’article.

Figure
12

Projet CheckSem

Yoan Chabot

13

| XSD2OWL

Ce dernier e
xpose des

principes
relatif
s

au peup
lement d’ontologies à partir de

données de
fichiers XML
.

Tout d'abord , il faut savoir que les
fichiers

XML sont composés d'une part
d’un

Schéma

XML

qui est en quelque sorte
l’organisation

que doivent respecter les
documents XML associé
s

à ce
schéma

et d'une autre part les documents XML proprement dit
qui contiennent les données. A la base XML n'a pas été prévu pour contenir des concepts de
sémantique contrairement aux ontologies qui sont q
uant à elles capable de
restituer
des
connaissances sémantique sur un domaine. Toutefois, XML n'est pas totalement dépourvu
d'éléments sémantiques. En effet les
schémas

XML
peuvent,

par l'utilisation de règles de
conversion,

fournir des éléments sémantique
s. L'intérêt d'un convertisseur
XML vers des
ontologies

est donc de pouvoir extraire
les
données

contenu
e
s dans les fichiers
XML
pour créer des instances d’une
ontologie existante
. Pour se
faire,

deux
étapes doivent être
c
omplétées comme le
montre
la figur
e 13

: l'enrichissement
puis

le peuplement de l'ontologie.

L'enrichissement co
nsiste à ajouter des
éléments (d
es
classes
,

des

propriétés

d'objets ou de types…
) dans
l'ontologie
.
Une fois cette
phase terminée, i
l devient alors possible de peupler
l’
ontologie à partir de document
s

XML si
l'on a correctement
réalisé

la phase d'enrichissemen
t (et donc que l
'ontologie
contient des
concepts similaires

aux
schéma
s

XML

utilisés
).
Il est en effet aisé d'établir un
ensemble de similitude
s

entre plusieurs
documents XML valide
s

vis à vis d'un
schéma XML qui sont en fait des
instances de celui ci et entre des instances
OWL issu
es

de classes et propriétés.
De
nombreux tr
avaux sont issus de ce
constat.

Nous étudierons les spécificité
s
de chacun d'eux dans l'étude de l'existant,
un peu plus loin dans ce dossier
. La
spécificité du projet XSD2OWL

du Le2i
par rapport aux
autres travaux

est qu'un nouvel élément
vient s'ajouter au diagramme ci
-
dessus

(Figure 14
)
: Le principe de cette solution est de réaliser l'enrichissement ontologique
manuellement et d'établir en parallèle un ensemble de règle
s

de «

mapping

»

(relations entre
deux éléments). Cette table de règl
es est en fait un ensemble de triplets RDF illustrant les
équivalences entre le schéma XML et
l’ontologie
. L'ajout de ses règles RDF permet aux
point
s

suivants de se réaliser :



La perte d'automatisme est compensée par une plus grande richesse sémantique d
u
modèle généré
.



Cette solution permet l'utilisation de plusieurs
schémas

XML

pour enrichir une même
ontologie.



L'utilisation de règles RDF permet une plus grande fiabilité du convertisseur, en
particulier lorsque le
schéma

XML

devient complexe. De plus, le peuplement de
l'ontologie s'appuie sur les règles

de mapping précédemment générées
. Cela a donc
pour avantage la simplification et l'automatisation d
e l’étape de

peuplement.

Je vais maintenant présenter plus en détail ce que

sont les règles utilisé
e
s par le convertisseur.
On

distingue plusieurs types de règles, chaque type ayant une fonction et un sens différent

:

Figure
13

Enrichissement et peuplement

Figure
14

Mapping RDF

Yoan Chabot


14

| XSD2OWL



Les liens visuels

symbolisent les relations entre les éléments d’un même langage. On
distin
gue les liens visuels « inter
-
XSD

» qui sont nécessairement des liens de type
«

SubElementOf

». Ces liens caractérisent une relation hiérarchique entre deux
éléments XSD. Les liens «

inter
-
OWL

» peuvent être de plusieurs natures

:
owl

:
R
ange
, owl

:Domain
ou owl

:SubClassOf. Les deux premiers permettent de
spécifier les classes

sujet et objet d’une propriété d’objet ou de données (Object
Property et Datatype Property). Un lien owl

:SubClassOf permet de représenter un lien
d’héritage entre de
ux classes.

Ex: Voici un exemple d'utilisation de liens visuels
:


<rdf:Description rdf:about="http://www.w3.org/2002/07/owl#APourAdresse">

<rdfs:range rdf:resource="http://www.w3.org/2002/07/owl#Adresse"/>

<rdfs:domain
rdf:resource="http://www.w3.org/2002/07/owl#Destinataire"/>

<bmr:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>

<bmr:xpath rdf:resource="http://www.w3.org/2002/07/owl#APourAdresse"/>

</rdf:Description>



Les règles de mapping avancées
(Advanced Mapping

Rules) sont utilisé
e
s pour
réaliser les jonctions entre les éléments du schéma XSD et les éléments de l’ontologie.
On distingue trois types de règles de mapping avancées

: les liens is_a, les liens de
conversion simple et
les liens de conversions complexes. Les liens is_a permettent de
spécifier que la classe OWL pointé
e

par le lien sera instancié
e

grâce à l’élément XSD
source du lien. Les règles de conversion simples et complexes permettent de réaliser
des ponts entre les
données XML

et les données contenues dans l’ontologie. Les
conversions simples sont réalisé
e
s entre un élément XML de type primitif et une
donnée ontologique de type primitif. Les conversions complexes sont utilisé
e
s pour
des transformations de

données nécessitant l’utilisation d’opérations de concaténations
ou encore l’utilisation d’expression régulières.

Ex: Voici un exemple d'utilisation de règles de mapping avancées:

<rdf:Description
rdf:about="http://www.w3.org/2001/XMLSchema#/purchaseOrder
/PurchaseOrderTyp
e/shipTo/USAddress/">

<lien:SubElementOf
rdf:resource="http://www.w3.org/2001/XMLSchema#/purchaseOrder/Purchas
eOrderType/shipTo/"/>

<amr:is_a rdf:resource="http://www.w3.org/2002/07/owl#Adresse"/>

<bmr:type
rdf:resource="http://www.w3.org/
2001/XMLSchema#TypeComplexe"/>

<bmr:xpath
rdf:resource="http://www.w3.org/2001/XMLSchema#/purchaseOrder/Purchas
eOrderType/shipTo/USAddress/"/>

</rdf:Description>



Les règles de mapping basiques (Basic Mapping

Rules) sont
utilisées

pour spéci
fier
plus finement les règles de mapping avancées. Par exemple, dans le cas d'une règle de
mapping avancées de conversion complexe, les BMR

seront utilisés pour préciser la
nature de la conversion. Il existe une multitude de BMR : xpath, xpathI
d, type,
domain, range, concat et regex. La règle xpath est
utilisée

pour spécifier le chemin
identifiant la ressource de manière unique. Cette information permet de récupérer la
ressource de façon absolue. Les règles xpathId, type, domain et range permett
ent de
Yoan Chabot

15

| XSD2OWL

spécifier respectivement l'identifiant, le type, le domaine et la cible de la ressource
décrite. Les règles concat et regex sont utilisé
e
s dans le cadre des conversions
complexes. La règle basique concat permet des opérations de concaténations et re
gex
permet l'utilisation d'expressions régulières.

Ex: Voici un exemple d'utilisation de règles basiques:


<date >

<month>12</ month >

<day>05</day >

<year>2008< /year >

</date>


:ConversionComplexe

{

:date2string bmr:conv :rule2

:rule2
bmr:type bmr:convComplex .

:rule2 bmr:domain xsd:string .

:rule2 bmr:range :date


:date . bmr:concat :sub1rule2,

bmr:concat "/" ,

bmr:concat :sub2rule2,

bmr:concat "/" ,

bmr:concat :sub3rule2 .

:sub1rule2 bmr:xpath "./date/month" .

:sub2rule2 bmr:xpath
"./date/day" .

:sub3rule2 bmr:xpath "./date/year" .

}


Une fois le
processus d'annotations terminé,
nous disposons d'une table de mapping complète
permettant de lier
de façon très précise

le
schéma

XML

avec le squelette ontologique. Une
fois ce
s «

passerelles

»
construites,

il devient alors possible de peupler l'ontologie

automatiquement
.


Nous
allons maintenant nous intéresser

aux besoins ayant motivé le projet auquel j’ai pris
part.


2.1.2

Expression du besoin

Les objectifs principaux du proje
t sont :



Proposer une solution permettant à un utilisateur d'enrichir une ontologie existante
avec de nouveaux concepts.



Permettre à cet utilisateur de charger des schémas XML

et définir des règles de
mapping entre les éléments de ce schéma et

l'ontologie. L'étape de mapping étant
manue
l
l
e
, elle devra se faire de la manière la plus simple, claire et intuitive possible.



Enfin l'utilisateur pourra, une fois les règles de mapping défini
es
, envoy
er

au logiciel
des fichiers de données XML

afin que ce dernier peuple l'ontologie automatiquement
en respectant rigoureusement les règles de mapping défini.

Je vais maintenant présenter les travaux d’autres chercheurs sur le sujet exposé. Je
présenterais ensuite le travail de deux anciens
stagiaires du Le2i sur le projet XSD2OWL
.

12/05/2008

Yoan Chabot


16

| XSD2OWL

2.1.3

Etude de l’existant

Plusieurs solutions ont été proposées pour répondre à la problématique du peuplement
automatique des ontologies. Le tableau ci
-
dessous expose les spécificités de plusieurs
projets
menés à travers le monde sur ce sujet

:


Publication

XSLT

Mapping

automatique

Peuplement

automatique

XSD
multiple

OWL
-
DL

Mapping

RDF

XSD2OWL

XML2RDF

Ferdinand

non

oui

oui

non

oui

non

oui

Garcia

non

oui

oui

non

non

non

oui

Bohring

oui

oui

oui

non

oui

non

non

Rodrigues

oui

non

oui

oui

oui

non

non

Aninic

non

non

non

non

oui

oui

non

Cruz/Nicolle

non

non

oui

oui

oui

oui

non

Figure
15

Travaux précédents

La
colonne «

XSLT

» indique que le projet utilise des feuilles de styles XSL pour le processus
de conversion. «

Mapping

automatique

» indique que l’utilisateur n’intervient pas lors de la
phase de mapping entre le schéma XML

et l’o
ntologie OWL
. «

Peuplement

autom
atique

»
indique que
les instances de l’ontologie sont
créées

de façon automatique. La colonne «

XSD
mul
tiple

» indique la possibilité d’utiliser plusieurs schémas XML pour réaliser la table de
mapping. La

colonne «

OWL
-
DL

» indique que le résultat du convertisseur est une ontologie
permettant d’utiliser le principe d’inférence. «

Mapping RDF

» signifie que le processus de
peuplement utilise RDF pour spécifier les règles de mapping. Enfin la dernière colonn
e
indique que des relations sont établies entre les schémas XML et l’ontologie et que les
données contenues dans le fichier XML sont ensuite traduites en langage RDF.

La solution de Mr Ferdinand
permet
un mapping et un peuplement automatique. Toutefois le
modèle utilisé pour le mapping et pour la création des instances étant différent, on peut
constater des incohérences entre ces instances et
le schéma ontologique. M.

Garcia propose
une solution permetta
nt également de mapper et de peupler automatiquement une ontologie.
Le domaine de cette solution est plus particulièrement les données multimédia. Leur projet ne
permet toutefois pas d’utiliser le principe d’inférence, le langage de sortie de leur outil é
t
ant
OWL
-
Full. La solution de M.

Bohring est originale car elle utilise des feuilles de style XSL
.
Toutefois cette solution entraîne la création d’une ontologie assez primitive et
sémantiquement plus pauvre que l
e schéma XML

util
isé en entrée. L
a solution de M.

Rodrigues offre la possibilité de générer des règles de mapping permettant de créer des
instances de l’ontologie par rapport à un fichier XML. La méthode proposée permet de garder
un niveau de sémantique intéressant. Toutefois cette soluti
on gère mal les cardinalités et
les
restrictions. Pour finir, M.

Aninic propose une méthode originale basée sur l’utilisation de
méta
-
modèles. Toutefois cette idée n’a pour le moment pas fait ses preuves et reste donc une
simple hypothèse.

Yoan Chabot

17

| XSD2OWL

Ma première tâch
e lors de ce stage a été la reprise de travaux existants réalisés par deux
anciens stagiaires du Le2i

: Romain Brochot et Florian Genton. Ces deux étudiants avaient
créé le parseur XSD ainsi que le squelette du plugin utilisé par le logiciel Protégé.

Après

étude
de leur travail, j’ai pu constater que celui
-
ci ne répondait pas totalement aux besoins énoncés.

Un des problèmes majeurs du résultat de leur développement est l’interface. En effet, dans
leur version du plugin, l’affichage des règles de mapping se

fait grâce à un tableau (Jtable) et
la création de celle
s
-
ci est effectuée par l’utilisateur via des menus contextuels. Après
utilisation, on se rend compte que
le besoin d’intuitivité et de clarté n’est pas rempli.
L’affichage dans un tableau est austère

et il est difficile de retrouver les informations
souhaité
e
s rapidement. La création des règles via des menus contextu
el
s et quant à elle bien
trop lourde. De plus l’utilisateur ne visualise pas néce
ssairement les conséquences de s
es
actions. Ces quelques

points ont été placés au centre de nos préoccupations pour la suite du
projet. Comme nous l’avons déjà dit, il est capital de fournir une interface agréable à
l’utilisateur lorsque celui
-
ci est amené à effectuer un grand nombre d’interactions avec le
prog
ramme.

2.1.4

Technologies employé
e
s

Je vais présenter dans cette partie les différents langages et technologies inhérentes au
domaine du projet XSD2OWL
. Je présenterais dans un premier temps les langages XML

et
XSD

ainsi que l
e langage d’interrogation X
Path

utilisé pour récupérer des données dans les
fichiers XML
. J’exposerai

ensuite les spécificités des langages sémantiques que sont OWL et
RDF.

2.1.4.1

XML

Le langage XML

entre en jeu lorsque
le convertisseur XSD2OWL

entre dans
la phase de peuplement. Les fichiers XML contiennent
les données
nécessaires

à la création d’instances ontologique.

C’
est un langage de
balisage, standardisé par le W3C
, qui définit un ensemble de règles
syntaxiques pour la présentation structurée de l'information. Ce langage n’est
donc d’aucune utilité s’il est utilisé seul. Le langage XML fut créé pour répondre aux besoins
de communications entre les programmes et de p
artages d’informations en général. La grande
force du langage XML est que tout le monde peut créer son langage à partir des règles de
syntaxes dictées par la norme. XML est un métalangage, c'est
-
à
-
dire qu’il permet d’en créer
d’autres. Les principales util
isations du langage XML sont :



L'échange de données entre applications via des fichiers de données structurés



Le stockage de données sans SGBD



Base de données XML

(Xquery)


2.1.4.2

XSD

Le langage XSD est omniprésent dans le convertisseur. Il

est principalement utilisé lors de la
phase de mapping permettant de créer des passerelles entre XML

et ontologie.

Afin d'être
déclaré valide, un document XML

doit faire référence et respecter un XML Schéma. Il s'agit
d'une norme d
u W3C

utilisée pour structurer les documents XML. Les fichiers XML Schéma
porte l'extension .xsd.

Les XML

schéma sont les successeurs des DTD (Document Type Definition). Les DTD avait
le même rôle que les fichiers .xsd : structurer

les documents XML.
Toutefois les .xsd
apportent plusieurs nouveautés qui les amènent à remplacer les DTD:

Yoan Chabot


18

| XSD2OWL



Les Schéma XML

sont des documents XML. Ainsi les outils utilisés sur les
documents XML peuvent être naturellement utilisé sur les .xsd .

Cela permet entre
autres le parsage de ceux ci ou bien encore l'utilisation d'autres outils comme Xpath …
Les DTD obligeait à passer par d'autres outils pour réaliser les opérations ci
-
dessus.



Un des autres avantages est la plus grande précision dans la d
éfinition du document
XML
. Parmi les points que DTD ne gérait pas on peut signaler la possibilité de
spécifier le nombre d'occurrences d'un élément, ou encore de «

typer

» les données
avec plus de précisions (
entier,

booléen …) . XML
schéma

permet même la création
de type personnalisé se rapprochant ainsi des concepts de l'orienté objet.



Il est possible de faire interagir plusieurs XSD entre eux grâce à l'utilisation d'espaces
de noms. Ce concept n'était pas présent dans les DTD et il était
donc impossible
d'utiliser dans un document XML

des balises définies dans un autre document.



Les XML

schéma intègre la notion d'héritage.

2.1.4.3

XPath

Le langage XPath

est utilisé lors de la phase de peuplement. Celui
-
ci permet de récupérer les
données XML

en fonction des informations contenues dans la table de mapping.

Xpath est un langage permettant d’adresser de façon unique les nœuds d’un document de typ
e
XML
. Il est utilisé dans une multitude d’autres langages tels que XSLT, XSD ou encore
XLink. XPath

offre la possibilité de récupérer des données XM
L en formulant des
expressions.


Exemple

:
Requête permettant de récupérer l’élém
ent B qui est enfant de D qui est enfant de
la racine A :












2.1.4.4


RDF/RDFS

Le langage RDF est utilisé par le moteur du convertisseur. L’utilisateur
n’est pas amené à manipuler le RDF
directement mais celui
-
ci occupe tout
de même une place primordiale. RDF est le langage utilisée par la table de
mapping pour contenir les règles liant les différents éléments entre eux.

RDF est un modèle conceptuel très élémentaire composé d’un sujet,
pré
dicat et objet. RDF est un langage formel par conséquent, il ne fait pas
intervenir tout ce qui est implicite selon le contexte. En résumé, RDF est
un modèle de métadonnées (
donné
e

servan
t à définir une autre donnée)

puissant largement accepté et utilisé mais trop limité pour formuler des
contraintes sémantiques plus riches et raisonner (d’où l’intervention de RDFS et de OWL par
la suite). RDF est le langage de base du web sémantique, il
a été conçu pour assurer une
interopérabilité entre les applications qui échangent de l’information non formalisée et non
<
A
>


<
B
/>


<
C
/>


<
B
/>


<
B
/>


<
D
>


<
B
/>


</
D
>


<
C
/>


</
A
>


<
A
>



<
B
/>


<
C
/>


<
B
/>


<
B
/>


<
D
>


<
B
/>



</
D
>


<
C
/>


</
A
>


Requête

:
/A
/D/B

Yoan Chabot

19

| XSD2OWL

structurée sur le web. Il existe différentes syntaxes sur lesquelles peut s’appuyer RDF

: RDF
-
XML
, OWL, ou encore N3 (nota
tion 3), etc…Le préfixe associé au vocabulaire RDF
est rdf
.

Exemple du fonctionnement de RDF

:

Une personne peut regarder le ciel et dire «

il pleut

». Ce qui sous
-
entend qu’il pleut des
gouttes d’eau dans le lieu où se situe la personne. Il faut donc l’ex
primer de manière explicite
en RDF

: «

Des gouttes d'eau [sujet] pleuvent [prédicat] en ce lieu [objet]

»



Le

sujet

représente la
ressource

à décrire

: par exemple une gou
tte d’eau
.




Le
prédicat

représente un type de
propriété

applicable à cette ressource:
pa
r exemple le
fait de pleuvoir.



L'
objet

représente une donnée ou une autre ressource, c'est la valeur de la propriété:
par exemple le lieu où il pleut
.

En somme RDF décrit des choses sous la forme d’une phrase avec sujet (ressource), verbe
(propriété),
complément (valeur).


2.1.4.5

OWL

Avant de commencer la définition du langage OWL destiné au Web sémantique
, il est
important de précisé quelques termes pour mieux comprendre la suite du dossier.



OWL

: Web

Ontology Language est un
dialecte XML

basé sur une
syntaxe
RDF
. Il fournit les mo
yens pour définir des ontologies web
structurées.



Ontologie
(s)

: Une ontologie est un ensemble structuré des termes et
concepts représentant le sens d'un champ d'informations, que ce soient
par les métadonnées d'un espace de noms, ou les
éléments d'un
domaine de connaissances.

Exemple d’ontologie

:
une carte électroniqu
e est un ensemble de composants. U
n
composant peut être soit un condensateur, soi
t une résistance, soit une puce. U
ne puce peut
être soit une unité de mé
moire, soit une
unité de calcul. U
ne carte électronique qui contient
une unité de calcul contient aussi au moins une unité de mémoire.



Métadonnée(s)

: Une métadonnée est une donnée servant à définir ou décrire une
autre donnée quel que soit son support.



Espace de nom

:Un espace de nom
est un ensemble de ce qui est désignable dans un
contexte donné par une méthode d'accès donnée faisant usage de noms symboliques,
plus clairement en prenant un exemple

: dans un annuaire téléphonique, l'espace de
noms asso
cié est celui des abonnés au téléphone du département concerné.



Assertion

: Une assertion de fait consiste à faire une instanciation et la description par
énonciation des propriétés

s’appliquant sur les instances.

Le langage OWL est basé

sur la recherche effectuée dans le domaine de la logique de
description. OWL permet de décrire des ontologies, c'est
-
à
-
dire qu'il permet de définir des
terminologies pour décrire des domaines concrets. Une terminologie se constitue de concepts
et de propr
iétés
. Un domaine se compose d'instance et de concepts. Comme on a vu avec
l’exemple de la carte à puce le but est de prendre un objet et d’en faire la description de
manière à lui donné un sens.

En pratique, le langage OWL est conçu com
me une extension de
RDF et de RDFS

; OWL est destiné à la description de classes

(par des constructeurs) et des
types de propriétés. De ce fait, il est plus expressif que RDF, auxquels certains reprochent une
insuffisance d'expressivité due

à la seule définition des relations entre objets par des
assertions. Aux concepts de classe, de ressource, de littéral et de propriétés des sous
-
classes,
de sous
-
propriétés, de champs de valeurs et de domaines d'application déjà présents dans
Yoan Chabot


20

| XSD2OWL

RDFS, OWL aj
oute les concepts de classes équivalentes, de propriété équivalente, d'égalité de
deux ressources, de leurs différences, du contraire, de symétrie et de cardinalité...

Il existe trois niveaux d’OWL

:



OWL Lite: pour une hiérarchie de classe et des contraint
es simples (ex: cardinalité
restreinte à 0 ou 1)



OWL DL: pour une expressivité maximum, sans perdre la vérification automatique de
complétude et de décidabilité pour les systèmes de raisonnement. OWL DL inclue
toutes les constructions OWL avec pour restric
tion la séparation des types (une classe
ne peut pas être aussi un individu et une propriété, une propriété ne peut être aussi un
individu ou une classe). OWL DL est ainsi nommé parce qu’il correspond à une
logique de description (Description Logic).



OWL F
ull: pour un maximum d’expressivité et la liberté syntaxique de RDF, mais
sans garantie pour l’automatisation. Par exemple une classe OWL peut être traitée à la
fois comme une collection d’individu et un individu unique.


Cette présentation d’OWL termine
la présentation des technologies employées.
Les grandes
lignes du projet étant maintenant données, je vais maintenant vous présenter l’organisation du
projet qui m’a permis de mener celui
-
ci à terme.

2.2

Organisation du projet

Je présenterais dans cette pa
rtie les aspects
managériaux

mis en jeu dans le cadre de mon
projet. Dans une première partie, j’exposerais les choix logiciels qui ont été effectués

et la
méthode de travail qui a été adoptée. Je présenterais ensuite mon planning prévisionnel et
réel. Dans un dernier temps, je parlerais des aspects managériaux ainsi que de la
communication entre les membres du projet.

2.2.1

Choix techniques

Ce proje
t a donné lieu à l’utilisation de nombreux outils
issus

d’un choix réfléchis ou
d’obligations.


2.2.1.1

NetBeans

NetBeans est un Environnement de Développement
Intégré

multi
-
langages (Java,
Python
,
C
,
C++

) Open
-
source développé par Sun. L’utilisation de cette EDI
m’a
été imposée. Ce choix étant justifié par les points
suivants

:



Les précédents stagiaires avaient utilisés cette
EDI. L’utilisation de NetBeans m’a donc permis
de récupérer leur travail avec facilité.



NetBeans est un EDI multi plates
-
formes.
L’ordinateur
du Le2i ayant pour système d’exploitations Mandriva 2009 (Distribution
Linux), ce point est d’une importance capitale.



Enfin NetBeans dispose de touts les outils standards qu’on peut attendre d’un EDI
(
éditeur en couleur
,

éditeur graphique d'interfaces, au
to
-
complétion…)


2.2.1.2
Protégé

Yoan Chabot

21

| XSD2OWL

Ce logiciel permet la création et la manipulation d’ontologie. Il est
clairement indispensable au projet car le convertisseur XSD2OWL

se matérialise sous la forme d’un plugin Protégé. Ce logiciel a donc
été très utilisé tout au long du développement.

2.2.1.3


Xerces

Xerces est une API
développé par la communauté Apache

permettant de parser des
documents XML
.
Cet outil a été

utilisé par les stagiaires précédents pour la réalisation du
parser XSD. Il constitue un outil efficace et assez léger.

2.2.1.4

Jena

Jena est une API permettant la manipulation de modèles ontologiques. J’ai pu, dans le cadre
de mon projet tuteuré, testé
plusieurs API utilisée pour le web sémantique. Jena s’est révélé
être la plus complète. Cet outil est très utilisé dans le convertisseur XSD2OWL
. C’est cette
API qui permet entre autres d’écrire la table de mapping ou de récupérer les infor
mations dans
cette dernière.

2.2.1.5

JGraph

JGraph a été utilisé dans le projet afin de permettre à
l'utilisateur de créer et d’éditer les règles de mapping
simplement et intuitivement. Cette API permet la création de
visualisations graphiques. Le choix d
e cette API a été
effectué en début de projet. D’
autres outils auraient pu
remplir le rôle de JGraph dans le convertisseur. Toutefois la
simplicité d’utilisations de JGraph ainsi que son importante
documentation a conforté mon choix.

2.2.1.6

GanttProject

GanttProject est un outil libre de gestion de projet. Il est a noté que celui
-
ci peut
être utilisé sur de nombreuses plates
-
formes. A l’instar de NetBeans, cela a été
un point important. Cet outil m’a permis de créer et d’éditer les plannings du
projet.

2
.2.2

Méthode de développement

Afin de satisfaire au mieux les besoins énoncés, j'ai décidé d'adopter pour mener à bien ce
projet une méthode de développement agile. Les méthodes agiles permettent grâce à une
grande implication du client, de garantir une b
onne adaptabilité et une grande réactivité à ses
demandes. Les méthodes agiles reposent sur une livraison fréquente de prototype
fonctionnelle incomplet au client. Le processus de développement agile est caractérisé par les
points suivants :



C'est une méth
ode itérative car on enchaîne les phases de conception et de
développement.



C'est une méthode incrémentale car on ajoute des fonctionnalités à l'application d'un
livrable à un autre
.



C'est une méthode adaptative car à chaque livrable, le client son avis
sur celui ci,
permettant de répondre de façon optimale à ses besoins
.

La méthode de développement choisi entraîne un découpage du projet en versions. Chaque
version cont
enant

plus de fon
ctionnalités que la précédente.
La phase d’analyse et conception
a
pu

permettre une analyse très précise des spécificités et des difficultés envisagés pour
chacune des versions

:

Yoan Chabot


22

| XSD2OWL



















Version 0.1 :

Cette première version pose les bases structurelles du plugin.
Cette version
comprend la création de la barre d'outils,

du menu...


-
Détails :




Création d'une barre d'outils mobile comprenant les boutons
permettant de supprimer
des éléments, créer des liens is_a, des liens convert_simple et des liens
convert_complex.



Création d'un menu à onglet dans la partie inférieur du plugin comprenant : un onglet
«

informations

» renseignant sur la nature de l'élément du graphe
sélectionné
, un
onglet «

gestion de la vue

» comprenant un ensemble de jComboBox permettant de
paramétre
r la vue à sa guise et un onglet «

général

» permettant de sauver/charger son
travail et débuter la phase de peuplement
.

-
Difficulté envisagées :

aucune

Version 0.3 :

Cette deuxième version démarre la création du moteur du plugin. Cette version
comprend la

g
estion de l'ajout d'entités sur le graphe via
glisser
-
déplacer et l’
établissement

des liens visuels

Détails :




Gestion de
l'ajout des entités par glisser
-
déplacer
. Lorsqu'un événement de la souris se
produit ; on récupère sa positio
n et on définit le
panneau qui a été objet du clic

et on
stocke l'élément sélectionné dans ce dernier. S
i l'utilisateur relâche le clic

à l'intérieur
de la zone du
graphe,

on ajoute l'élément dans le graphe par le biais d'une instanciation
de la classe ada
ptée
.



Suppression des doublons.



Mise à jour du graphe lors d'une suppression ou d'une modification de l'ontologie
.



Ajout de fonctions permettant la création des liens visuels

(
subElementOf,

OWL:subClassOf, OWL:range et OWL:domain) lor
s de l'ajout d'un él
ément dans le
graphe

-
Difficulté envisagées : Gestion du glisser
-
déplacer (Récupération du bon élément en fonction
de l'emplacement de la souris) et algorithme de vérification des liens avec la cellule créé
e
.

V0.1


Création du squelette du plugin : mise en place des barres d'outils,
du menu...

V0.3


Gestion de l'ajout d'entités sur le graphe via glisser
-
déplacer,
établissement des liens visuels

V0.5


Gestion des fonctions de la barre d'outils (supprimer et création de
liens), vérification de la cohérence des actions de l'utilisateur

V0.6


Gestion des barres d'outils vues et infos

V0.8


Persistence de l'espace de travail et gestion de la table de mapping

V1.0


Utilisation de la table de mapping pour peupler l'ontologie

Figure
16

Versionning

Yoan Chabot

23

| XSD2OWL

Version 0.5
:

La version 0.
5 finalise les outils permettant de créer le graphe de mapping. Cette
version comprend la g
estion des fonctions de la barre d'outils (s
upprimer et création de liens)
et la
vérification de la cohérence des actions de l'utilisateur

Détails :




Gestion
de
l’action

«

supprimer

»

(via le bou
ton ou raccourci clavier SUPPR) et de la
création des liens

is_a, convert_Simple et convert_Complex. Implémentation du drag
and drop pour
créer

les liens.
Gestion des types primitifs des cellules (Pour les
éléments XSD Sim
ple et les datatype property) via des listes déroulantes associé au
cellule. Création de la fenêtre de dialogue apparaissant lors de l'ajout d'une conversion
complexe et permettant de paramétrer cette dernière.



Ajout d'une fonction de vérification de la co
hérence sémantique des éléments du
graphe.

-
Difficulté envisagées : Cerner la totalité des cas présentant des incohérences

Version 0.6 :

Cette version termine les éléments permettant l’
interaction

avec l’utilisateur.
Cette version implémente la g
estion de
la barre d'outils
de la partie inférieure du plugin.

Détails :




Implémentation de la gestion des vues. Mise en place d'un algorithme de parcours
permettant d'afficher ou non les éléments en fonction des cases cocher par l'utilisateur



Gestion de la barre
d'outils «

informations

» : récupération des informations du
premier élément du graphe sélectionné



Ajout d'une barre de zoom

-
Difficulté envisagées : Apprentissage du système de vue
JGraph

(Pattern MVC)

Version 0.8 :

Dans cette version, la partie permettan
t la gestion de la table de mapping est
implémenté. Cette version comprend également la gestion de la sérialisation du travail
(Chargement/Sauvegarde).

Détails :




Gestion de la sérialisation des objets du graphe permettant la sauvegarde puis par la
suite l
e chargement d'un travail en cours.



Implémentation de l'algorithme de parcours de graphe générant un fichier RDF en
sortie.

-
Difficulté envisagées : Sérialisation du graphe et algorithme de parcours du graphe. La
production d'un fichier RDF fidèle
aux inf
ormations

du graphe représente également une
difficulté.

Version 1.0 :

Cette dernière version ajoute la gestion du peuplement via l’utilisation de la
table de mapping.

Détails :




Création du processus de peuplement à partir de la table RDF de mapping.



Cr
éation de la fenêtre permettant à l'utilisateur de sélectionner des fichiers XML

pour
peupler l'ontologie.



Implémentation de l'algorithme permettant la récupération des éléments dans les
fichiers XML

et la création de nouvelles instances dans l'ontologie par rapport aux
règles dictés par la table de mapping RDF.

-
Difficulté envisagées : Algorithme de peuplement

Grâce à ce découpage précis des tâches à effectuer, il est maintenant aisé de dresser un
pl
anning prévisionnel.

2.2.3

Planning

Yoan Chabot


24

| XSD2OWL

Cette partie a pour vocation de présenter la gestion de la contrainte de temps dans ce projet.
Pour se faire je présenterais plusieurs plannings. Tout
d'abord je présenterais la répartition du
temps en début de stage. Cette première période couvre les tâches d'auto
-
formation, d'analyse
et de conception etc etc. Je présenterais ensuite le planning prévisionnel du développement
des différentes versions du
projet. Pour finir, j'exposerais les différences entre mes prévisions
et le planning réel.

Plusieurs tâches ont été menées en parallèle en début de stage :



La découverte du sujet



L'auto
-
formation : cette phase a été principalement
occupée

par l'apprentiss
age de
XSD, le projet tuteuré m'ayant permis de me familiariser avec les technologies du web
sémantique.



L'étude du code existant : cette partie du stage m'a permis de comprendre le
fonctionnement du parser XSD ainsi que l'architecture d'un plugin du logic
iel
Protégé
.



L'étude de l'article : les nombreus
es relectures de l'article de M.

Cruz et M
.

Nicolle a
permis l'assimilation des concepts théoriques relatifs au projet XSD2OWL
.

Après cette semaine très théorique, j'ai pu
entamer

une phase de prospection qui a permis de
savoir si le projet était viable du point de vue technologique. Ces quelques jours de
prospection m'ont permis de découvrir les API qui seraient utilisés par la su
ite. Avec ces
acquis théoriques et pratiques, j'ai pu
proposer

une nouvelle version du plugin Protégé. Suite à
ce travail, une réunion avec M
.

Cruz a permis d'établir une liste d'améliorations et de
fonctionnalités à ajouter. J'ai pu alors démarrer la phas
e de conception. Cette phase a abouti
au découpage du projet en version et à la construction du planning prévisionnel suivant:

Figure
17

Planning de début de stage

Figure
18

Planning prévisionnel

Yoan Chabot

25

| XSD2OWL

Ci
-
dessous le planning réel du projet :

On constate que le développement de
la version 0.3 a été beaucoup plus court que prévu. La
phase de prospection ayant permis une bonne maîtrise de l'API
JGraph
, je n'ai pas rencontré
de grosses difficultés lors de cette phase. Les développements de la version 0.6 et 0.8 ont eux
aussi était c
onsidérablement réduits, la réduction du temps de développement étant dû en
partie à une surestimation de la difficulté. Il est à noté aussi que la partie concernant la
sauvegarde et le chargement du travail en cours a été abandonné pour donner la priorité

à la
version 1.0. Le délai de développement de cette version n'avait pas été évalué entièrement car
celle ci dépassé la date de fin du stage. Toutefois, le temps gagné sur les autres tâches aura
permis un avancement conséquent du processus de peuplement.

2.2.4

Management de projet et communications

Je présenterais dans cette partie les points de management n'ayant pas été mentionné
précédemment.

Mon stage a été parsemé de nombreuses rencontres avec mon tuteur M
.

Cruz. En particulier,
lors de l'achèvement d'une version, ces réunions étaient l'occasion de corriger la trajectoire du
projet lorsque cela était nécessaire, de mentionner des améliorations
éventuelles
... Ce mode de
fonctionnement permet d'éviter une gran
de insatisfaction en fin de projet lors de la remise du
livrable finale. Dans le cadre du développement agile, les réunions avec le client constitue des
«

checkpoints

». Cela m'a permis d'avancer dans le projet très sereinement avec l'assurance de
fournir
un résultat correspondant parfaitement aux attentes de mon tuteur.

Comme pour le projet tuteuré, j'ai été amené à rendre à M
.

Cruz plusieurs documents et
dossiers tout au long du stage. J'ai ainsi rédigé plusieurs rapports techniques concernant les
technologies étudiés : XSD, Xpath
...,

un rapport de
bug (Bug

dans le parser
XSD)
, un cahier
des charges, un document regroupant les
cas possibles de peuplements accompagnés des
algorithmes pouvant les traiter... Touts ces documents ont été utilisés pour la construction de
ce rapport. Dans le cas contraire, vous pourrez les trouvez en annexes de ce rapport.

1.3

2.3

Analyse et conception

Ce
tte partie présente la réflexion menée afin de proposer une solution correspondant aux
besoins énoncés. J’exposerais donc dans un premier temps le cheminement qui a permis de
créer les différents diagrammes représentatifs de l’application. Je présenterais
ensuite les
différents exemples susceptibles d’être soumis à la solution proposée. Ces différents jeux
d’essais ont permis entre autres la création d’un algorithme de peuplement robuste et efficace
dans un maximum de cas.

2.3.1

Conception

A partir des bes
oins énoncés lors de la rédaction du cahier des charges, j’ai pu esquisser un
premier diagramme de cas d’utilisations modélisant les fonctions principales de la future
application

:


Figure
19

Planning réel

Yoan Chabot


26

| XSD2OWL





























L'acteur principal est l'utilisateur de l'application. Il a la possibilité de charger un fichier XSD
qui apparaîtra alors à l'écran sous la forme d'un arbre. Il peut également utiliser une ontologie
existante ou même utiliser l'enrich
issement pour composer son ontologie. Dans le second
cas,

il peut alors ajouter des classes

et des propriétés

à l'ontologie. Une fois l'enrichissement
terminé, l'utilisateur peut alors définir des règles de mapping entre
les éléments XSD et les
éléments ontologiques. Pour ce
faire,

la visualisation graphique permet à l'utilisateur
d'importer des éléments depuis l'arbre XSD ou depuis l'ontologie. L'utilisateur peut alors
ensuite créer un certain nombre de liens entre les él
éments. Il peut ajouter des liens «

is_a

»
qui décrive une forme d'appartenance (instanciation) entre un élément XSD et un élément
ontologique ou encore des liens de
conversions simples

qui décrivent des
changements

de
type primitifs lors du passage d'un élément XSD vers un élément ontologique. L'utilisateur a
également la possibilité de définir un autre type de conversions utilisant des concaténations et
des expressions régulières. Une fois ces conversions complexes

définis,

il peut alors les
utiliser comme règle de mapping. Afin de garantir la cohérence entre la visualisation et les
modèles,

une mise à jour du graphe est effectuée à chaque modification de l'ontologie ou des
règles de mapping. L'utilisateur a égaleme
nt la possibilité de paramétrer la vue grâce à une
batterie de cases à cocher lui permettant par exemple de n'afficher que les éléments
ontologiques ou encore
seulement

les règles basiques. Une fois les règles de mapping
déterminé
es

ou bien chargé
es

(à par
tir d'un travail précédent
),

l'utilisateur peut alors démarrer
la phase de peuplement. L'utilisateur peut alors spécifier la liste des fichiers XML

qu'ils
Figure
20

Cas d'utilisations 1

Yoan Chabot

27

| XSD2OWL

souhaitent utiliser pour peupler l'ontologie. Cette phase est
réalisée

automatiquement à
partir
des règles de mapping.

Nous allons maintenant étudier les différents cas que pourrait rencontrer l’application.


2.3.2

Jeux d’essais

Je vais vous présenter dans cette partie les différents cas possibles de peuplement. Je
commencerais d'abord par le
s cas les plus simples puis nous complexifierons les exemples
graduellement. Pour chacun des exemples vous pourrez trouver
l’intitulé du cas ainsi qu’un
graphe l’illustrant
. Dans un premier temps
, je vais présenter

les fichiers utilisés po
ur cette
batterie

de tests. J’expliquerais
ensuite le principe général du processus de peuplement. Nous
verrons ensuite les différents cas de peuplements possibles.


2.3.2.1

Fichiers utilisés

Vous trouverez dans cette partie
les représentations graphiques des
fichier
s

XSD
et
OWL
utilisés pour nos travaux.


Fichier XSD

L'arbre ci
-
dessous représente le fichier XSD
utilisé

:














Figure
21

Arbre XSD

Yoan Chabot


28

| XSD2OWL

Fichier OWL

Le graphe suivant représente l'ontologie ci
-
dessus :

2.3.2.2

Principe du
processus de peuplement

On admettra dans cette partie que l'utilisateur a au préalable charger un fichier XSD, construit
l'ontologie et établit les règles de mapping entre les éléments. Dans ce cas, l'utilisateur peut
alors déclencher le processus de peupl
ement qui va être chargé de créer les instances de
l'ontologie à partir des données de fichiers XML

choisis. Le processus de peuplement
s'effectue en plusieurs étapes. Tout d'abord, il faut savoir que la table de mapping permet
d'identifier les

éléments XSD racines du graphe. Il suffit pour cela de rechercher les éléments
XSD n'ayant pas de liens SubElementOf. Un élément qui n'est pas sous élément d'un autre est
par définition une racine. C'est sur ces éléments que devra se faire l'appel de la f
onction
récursive de peuplement. La première des étapes sera donc la recherche de l'une de ces
racines. Le processus de peuplement stoppera lorsque toutes les racines de la table auront été
lues et traitées. Pour chacune de ses racines, on vérifie la prése
nce d'un lien is_a entre l'entité
et une classe OWL. Un lien is_a entraînera nécessairement la création d'une instance de la
classe pointé. Si aucun lien de ce type n'est détecté on cherchera la présence d'autres règles de
mapping avancées tel que les lien
s de conversions simples ou complexes Si un lien de
conversion simple ou complexe existe, on traite la conversion en enrichissant les données de
l'instance créée la plus proche hiérarchiquement et on passe ensuite à l'élément de même
niveau suivant. Cette
réflexion sera affinée et adapté par la suite en fonction des cas mais elle
représente globalement et assez fidèlement le processus de peuplement.

Yoan Chabot

29

| XSD2OWL

2.3.2.3


Études des cas possibles

Cas n°1

Intitulé

Peuplement

d'une classe isolée à partir

d'un élément complexe vide.

Graphe




Ce graphe contient un élément complexe XSD : item ainsi qu'une classe OWL : Objet. Ces
deux entités sont reliés par un lien is_a qui indique que des instances d'Objet
seront crées à
partir des données contenues dans les balises item du fichier XML
.

Cas n°2

Intitulé

Peuplement

de N classes

isolées à partir de N éléments complexes vides.

Graphe






Ce graphe contient trois élément complexe XSD : item, USAdress et PurchaseOrderType
ainsi qu'autant de classes

OWL : Objet, Commande et Adresse. Toutes ces entités sont reliés
par un lien is_a qui indique que des instances seront crées à partir des données contenues dans
les balises correspondantes du fichier XML
.


Cas n°3

Intitulé

Peuplement

d'une classe associé à une propriété de données à partir d'un élément complexe
contenant un élément simple ou un attribut.

Graphe






Figure
22

Cas n°1

Figure
23

Cas n°2

Figure
24

Cas n°3

Yoan Chabot


30

| XSD2OWL

Ce graphe contient un élément complexe XSD :
USAddress

ainsi qu'un élément simple ou
attribut XSD : city. Côté ontologique, le graphe contient une classe Adresse relié à une
DatatypeProperty par un lien OWL:Domain. L'entité
USAddress

est
reliée

à la classe Adresse
par un lien is_a (Indiquant que des instances

d’Adresse

seront
créées

à partir des données
contenues dans
USAddress
). Le lien SubElementOf reliant
USAddress

et city indique que
chaque balise XML

USAddress

contient une balise city. La balise city est relié par un lien de
conversion simple à la propriété de données ApourVille. Cela indique que pour chaque
nouvelle instance de Adresse créée à partir de
USAddress
, on récupérera la donnée contenue
dans city pou
r la placer dans la propriété de données ApourVille. Un lien de conversion
simple indique une conversion d'un type primitif vers un autre. Les types des datatype
property et
des éléments simples

ont été définis lors de la construction du graphe. Les
conver
sions simples sont
réalisées

automatiquement à partir des informations de types
contenues sur chacun des éléments concernés.

Cas n°4

Intitulé

Peuplement

d'une classe associé à N propriétés

de données à partir d'un élém
ent complexe
contenant N éléments simple et/ou N attributs

Graphe


Ce graphe contient un élément complexe XSD :
USAddress

et plusieurs éléments simples ou
attributs : street, zip, city, name, country. Côté ontologique, le graphe contient une classe
Adresse relié à plusieurs DatatypeProperty par des liens OWL:Domain.

Cas n°5

Intitulé

Peuplement

d'une clas
se associé à une propriété de données à partir d'un élément simple ou
d'un attribut.

Graphe


Figure
25

Cas n°4

Figure
26

Cas n°5

Yoan Chabot

31

| XSD2OWL

Ce graphe contient un seul élément simple ou attribut XSD : street. Côté ontologique, le
graphe contient une classe Adresse relié à une DatatypeProperty par un lien OWL:Domain.

Cas n°6

Intitulé

Peuplement

d'une classe associé à N propri
étés

de données à partir de N éléments simples ou
attributs.

Graphe


Le processus de peuplement ne peut pas fonctionner dans ce cas. En effet lorsque l'on créé
une instance de la classe
Adresse lors de la rencontre avec un élément street par exemple, on
ne sait ensuite quel élément country, zip et city associé à cette instance. Le comportement du
peuplement serait dans ce cas totalement imprévisible et il est donc à proscrire.

Cas n°7

Int
itulé

Peuplement

d'une classe associé à une autre classe par le biais d'une propriété d'objet à partir
d'un élément complexe vide contenant un autre élément complexe vide.

Graphe








Ce graphe contient un élément complexe : PurchaseOrderType contenant un autre élément
complexe : shipTo. Côté ontologique, le graphe contient une classe Commande et une classe
Expediteur reliée par le biais de la propriété d'objet APourExpediteur.


Figure
27

Cas n°6

Figure
28

Cas n°7

Yoan Chabot


32

| XSD2OWL

Cas n°
8

Intitulé

Peuplement

d'une classe associé à N classes

par le biais de N propriétés

d'objets à partir d'un
élément complexe vide contenant N autres éléments complexes vides.

Graphe








Ce graphe contient un élément complexe : PurchaseOrderType contenant deux autres
éléments complexes : shipTo et BillTo. Côté ontologique, le graphe contient une classe
Commande
, une

classe Expediteur et une classe Destinataire reliées respectivement par les
propriétés

d'objet ApourExpediteur et APourDestinataire
.


Cas n°9

Intitulé

Peuplement

d'une classe associé à une autre classe contenant une d
onnée par le biais d'une
propriété d'objet à partir d'un élément complexe vide contenant un autre élément complexe
contenant un élément simple ou un attribut.

Graphe










Ce graphe contient un élément complexe : ShipTo contenant un autre élément complexe :
USAddress
. Ce dernier contient un élément simple ou attribut: country. Côté ontologique, le
graphe contient une classe Expediteur et une classe Adresse reliée par le biai
s de la propriété

Figure
29

Cas n°8

Figure
30

Cas n°9

Yoan Chabot

33

| XSD2OWL

d'objet ApourAdresse. La classe Adresse contient une donnée spécifiant son pays grâce à la
DatatypeProperty ApourPays.


Cas n°10

Intitulé

Peuplement

d'une classe associé à une autre classe contenant N donnée par le bia
is de N
propriétés

d'objet à partir d'un élément complexe vide contenant un autre élément complexe
contenant N éléments simples et/ou attributs.

Graphe










Ce graphe contient un élément complexe : ShipTo contenant un autre élément complexe :
USAddress
. Ce dernier contient trois éléments simples ou attributs: country, street et zip. Côté
ontologique, le graphe contient une classe Expediteur et une classe Adres
se reliée par le biais
de la propriété d'objet ApourAdresse. La classe Adresse contient trois données spécifiant son
pays, sa rue et son code postal grâce aux DatatypeProperty ApourPays
, ApourRue et
ApourCodePostal.

Cas n°11

Intitulé

Peuplement

d'une classe contenant une donnée à partir d'un élément complexe vide contenant
un autre élément complexe contenant un élément simple ou un attribut.

L'ontologie a été
modifiée

pour ce cas. ApourPays a pour domaine Destinataire dans
cet

exemple.

Gr
aphe





Figure
31

Cas n°10

Figure
32

Cas n°11

Yoan Chabot


34

| XSD2OWL


Ce graphe contient un élément complexe : ShipTo contenant un autre élément complexe :
USAddress
. Ce dernier contient un élément simple ou attribut: country. Côté ontologique, le
graphe contient une
classe Destinataire. Cette classe contient une donnée spécifiant son pays
grâce à la DatatypeProperty ApourPays.


Cas n°12

Intitulé

Peuplement

d'une classe contenant N données à partir d'un élément complexe vide contenant
un autre élémen
t complexe contenant N éléments simples et/ou attributs

L'ontologie a été
modifiée

pour ce cas. ApourPays, ApourRue et APourCodePostal ont pour
domaine Destinataire dans
cet

exemple.

Graphe









Ce graphe contient un élément complexe : ShipTo contenant un autre élément complexe :
USAddress
. Ce dernier contient trois éléments simples ou attributs: country, street et name.
Côté ontologique, le graphe contient une classe Destinataire. Cette classe co
ntient trois
données spécifiant son pays, sa rue et son nom grâce aux DatatypeProperty APourPays,
APourRue et APourNom.

Cas n°13

Intitulé

Peuplement

d'une classe contenant une donnée associée à une autre classe contenant une
donnée par
le biais d'une propriétés

d'objet à partir d'un élément complexe contenant un
élément simple ou attribut contenant un autre élément complexe contenant un élément simple
ou attribut.


Cas n°14

Intitulé

Peuplement

d'une
classe contenant N données associée à une autre classe contenant N
données par le biais d'une propriétés

d'objet à partir d'un élément complexe contenant N
éléments simples et/ou attributs contenant un autre élément complexe contenant N
éléments
simples et/ou attributs

Figure
33

Cas n°12

Yoan Chabot

35

| XSD2OWL

1.4

2.4
Résultat obtenus et améliorations possibles

Cette partie du rapport a pour objet une prise de recul par rapport à l’état du logiciel fourni à
mon tuteur en fin de stage. J’exposerais également dans cette partie les amél
iorations et les
fonctionnalités que je n’ai pas eu le temps d’implémenter dans le logiciel.

Tout d’abord concernant les résultats, on peut dire que ceux ci sont supérieurs aux espérances
de départ. Il n’était en effet pas prévu que les dix semaines de stages nous mènent aussi loin
dans ce projet. Grâce à la version actuelle du plugin, l’utilisate
ur a déjà la possibilité de
peupler une ontologie. Mon travail s’est arrêté sur ce point du projet. J’ai pu lors des dernières
semaines de stages, commencer à identifier les différents cas de peuplement (Voir partie Jeux
d’essais) et concevoir les algorith
mes traitant ces cas. Plusieurs d’entre eux ont déjà été
implémentés, permettant ainsi une utilisation du logiciel complète dans les cas les plus
basiques.
Il reste toutefois de nombreux détails à régler et de nombreuses fonctionnalités à
implémenter

:



Con
cernant la partie «

Arbre XSD

»

:

-
Bug

:

Les arbres complexes (Comportant des multitudes d’enfants sur de nombreux
niveaux), j’ai pu constater des erreurs dans la récupération

des ressources.

-
Améliorations

:

Une modification du rendu
graphique de l’arbre peut être effectuée. Il est en
effet possible de modifier les icônes et la couleur du texte des nœuds et feuilles de
l’arbre en fonction de leurs types (Attribut ou élément déclarant). Cela permettrait une
meilleure lecture de l’arbre
par l’utilisateur.

Une fois l’amélioration ci
-
dessus, il sera alors possible de supprimer le type
des nœuds et des feuilles (attributs et élément déclarant) qui est pour le moment
explicité dans le nom de l’élément (Cette information étant utilisé par le m
oteur du
plugin, il est important de répercuter la modification dans celui
-
ci).







Concernant le graphe de mapping

:


-
Bug

:


J’ai constaté des problèmes mineurs lors de la sélection des éléments dans
l’arbre XSD et dans l’ontologie afin de les mettr
e sur le graphe (Obligation d’effectuer un
double clique, de re
-
sélectionner la ressource voulue…). Ce bug peut être régler par
l’implémentation du glisser
-
déposer.

-
Améliorations

:


Il serait bon de rajouter un bouton permettant à l’utilisateur de rafrai
chir le
graphe. En effet, si l’on ajoute des propriétés

au graphe par exemple, et que l’on vient par la
suite modifier des informations sur cette propriété (Range, domain…), celle
-
ci ne sont pas mis
à jour sur le graphe (Aucun événement
pour ce type d’actions)


Une modification du rendu graphique des éléments XSD peut être faite. Une
couleur différente peut être attribué aux éléments selon leurs types afin d’améliorer la lisibilité
du graphe.


L’implémentation du glisser
-
déposer pour ajou
ter des éléments au graphe
pourrait permettre d’augmenter encore l’intuitivité du logiciel.


Une autre amélioration intéressante serait la mise en surbrillance des éléments
dans les arbres lorsque ceux
-
ci sont sélectionnés dans le graphe. On peut même imag
iner
déployer le sous arbre de cet élément.




Concernant le processus de mapping

:

-
Améliorations

:

Yoan Chabot


36

| XSD2OWL


Toutes les conversions simples possibles n’ont pas encore été implémentées.
Dans sa version actuelle, le plug
-
in est capable de traiter touts les types inh
érents à OWL mais
pas la totalité des types primitifs composants XSD.
Il est également à noter que les
conversions sont pour le moment implémentées «

en dur

». Une solution plus souple serait
préférable.





Concernant le processus de peuplement

:

-
Bug

:



La récupération des attributs dans le fichier XML

n’est pour le moment pas
gérée entrainant la levée d’exceptions lorsque l’utilisateur utilise ces derniers dans le graphe.
Il faudrait donc modifier la requête

utilisé pour les éléments simples pour récupérer les
attributs XML afin de pallier à ce problème.

-
Améliorations

:


Lors de mes tests, j’ai pu constater que le processus de peuplement peut être
assez long lorsqu’il travaille sur un graphe de mapping éten
du ou des fichiers XML

imposants. L’implémentation d’une barre de progression (JProgressBar) permettra à
l’utilisateur de connaître l’avancement du processus.





Divers

:

-
Améliorations

:


L’implémentation des cardinalités, des conversions comp
lexes ainsi que la
notion d’identifiant sont des points importants pour les versions futurs.


Une amélioration de la gestion des vues est possible. En effet, les éléments ne
s’effacent pas tout à fait complètement.


La sérialisation de l’espace de travail

(Version 0.8) n’a pas été implémenté afin
de donner la priorité à l’implémentation des algorithmes de peuplement. Les versions
futures devront donc voir apparaitre la gestion du chargement et de la sauvegarde des
travaux en cours.

3.

Conclusion

Cette partie
achève ce rapport et à pour but d’exprimer mes ressentis

personnels

ainsi que les
apports
techniques
de cette expérience.

3.1

Apport techniques



Tout d’abord, ce stage a été pour moi l’occasion d’acquérir de nouveaux savoirs. J’ai
pu, entre autres,
approfondir les connaissances du web sémantique a
cquises lors du
projet tuteuré. Ce point est relativement intéressant car le web sémantique sera sans
doute amené à devenir une évolution importante dans le monde de l’informatique.
Avoir acquis des savoirs
dans ce domaine me donne donc un atout intéressant pour
l’avenir.



J’ai pu lors de ce stage mettre en pratique bon nombre de savoir théoriques et
pratiques acquis lors du DUT. Programmation orienté objet,
modélisation UML,
programmation Java, ou encore suiv
i de projet grâce à des diagrammes de Gantt.

En
cela, le stage a été un complément utile me permettant de consolider ces deux années
de DUT.



Ce stage a été également pour moi l’occasion de découvrir l’ambiance et
l’organisation d’une équipe de recherche.

Yoan Chabot

37

| XSD2OWL


3.2

Apport personnel



Souhaitant travailler dans le domaine de la recherche et de l’enseignement, ce stage a
été pour moi l’occasion de récolter de nombreuses et précieuses informations sur le
statut d’enseignant
-
chercheur mais également de faire plus ample
s connaissances avec
des gens du domaine.



Ce projet a été pour moi l’occasion d’être face à des problèmes en solitaire. Cela m’a
permis de mettre à l’épreuve ma pugnacité et ma motivation.



Enfin je dirais que ce stage m’a permis d’appliquer les leçons
tirés après mon projet
tuteuré et donc, de fournir un travail d’une qualité encore supérieure.


4.

Résumé

Le projet intitulé «

XSD2OWL

» est une offre du Laboratoire d’électronique, informatique et
image dans le cadre de mon stage de fin de DUT. Ce stage a po
ur but de permettre aux
étudiants de valider leurs connaissances par un stage pratique de dix semaines. J’ai pu
effectuer mon stage au sein de la cellule A3 du laboratoire, dans le bureau de M
.

Rampaceck
et j’ai été encadré tout au long de mon projet par M
.

Cruz. Cet enseignant chercheur m’a
chargé de réaliser une application permettant à un utilisateur d’enrichir une ontologie, de
charger un schéma XML, de réaliser des liaisons entre ce schéma et l’ontologie puis enfin de
lancer un processus de peuplement
à partir de fichiers XML. L’application résultante devait
répondre à la problématique suivante

: Créer des instances des concepts présents dans une
ontologie à partir de fichiers XML et de manière automatique.


De nombreuses technologies ont été utilisées
dans ce projet. Les langages XSD, XML, RDF
et OWL sont les plus importants et constituent, de ce fait, les piliers du projet. Ayant déjà eu
recours à certains de ces langages pendant mon projet tuteuré, la phase d’auto
-
formation a été
considérablement rédu
ite. J’ai également utilisé un grand nombre d’outils logiciels tels que le
logiciel
Protégé

(
éditeur d’ontologies
),

les AP
I JGraph, Jena ou encore Xerces (
permettant
respectivement de créer des visualisations graphiques, de manier des modèles sémantiques e
t
de parser des documents XSD
)
.

J’ai pu mettre en pratique
, tout au long de mon stage,
les techniques de

gestion de projet et
d’analyse
enseignées pendant les deux années de DUT. L’établissement d’un planning
prévisionnel en début de projet et une conception profonde m’a permis d’utiliser mon temps
de façon optimale.

Pour finir, ce stage m’a beaucoup apporté aussi bien sur le plan techniq
ue que personnel. J’ai
pu, au cours de ces dix semaines, approfondir mes connaissances du web sémantique et
consolider les bases acquises en DUT. Un point important pour moi a été la possibilité de
faire connaissance avec le domaine de la recherche. J’ai p
u ainsi poser de nombreuses
questions sur le domaine dont les réponses m’ont permis d’éclairer mon parcours futur.


The project «

XSD2OWL

» is an offer of Eletronic, Computer and Vision Laboratory for my
DUT profesionnal training.
This
profesionnal traini
ng

aims to enable students to validate their
knowledge through a practical course of ten weeks. I
accomplished it in the A3 cell of Le2i in
the Mr Rampaceck’s office and I was supervised by Mr. Cruz. This teacher
-
researcher asked
me to make an application

that enables an user to
add idea

an ontology, to load a XML
schema, to
link

this schema and the ontology and then to initiate a process of settlement from
files XML. The
final

application was designed to answer the following question: Creating
automatical
ly instances of concepts in
ontology

from XML files. Many technologies
have
been used in this project.
XSD, XML, RDF and OWL
languages
are the most important
tools

of the project.

The time of self
-
education has been
considerably reduced because I have

Yoan Chabot


38

| XSD2OWL

alre
ady used som
e of these languages during my

school
project. I also used a large number of
software tools such as
the
software
«

Protégé

» (
an ontology editor
), JGraph, Jena and

Xerces

(
can

respectively

permit

to create graphic visualizations, to handle models and semantic
parser of XSD documents
).
Throughout my internship,
I
was

able to practice project
managem
ent and analysis methods
taught during the two years of
DUT
. The
creation

of a
n
estimated planning

ea
rly in the project and
a good
conception
allowed me to use my time
efficiently.
Finally, this course provided me
a lot
of

technical and personal

knowledge
.

During
these ten weeks, I was able
to
improve

my knowledge of the semantic web and bases acquired
du
ring my
DUT. An important point for me was the opportunity to get
information

about
the
domain of
R
esearch. I could ask many questions about the
sector

wh
ose

the answers helped
me to
choice my profesionnal future
.

































Yoan Chabot

39

| XSD2OWL

5.

Glossaire

AMR

:

Les règles de mapping avancées (Advanced Mapping

Rules) sont utilisés pour réaliser
les jonctions entre les éléments du schéma XSD et les éléments de l’ontologie. On distingue
trois types de règles de mapping avancées

: le
s liens is_a, les liens de conversion simple et les
liens de conversions complexes.


BMR

:
Les règles de mapping basiques (Basic Mapping

Rules) sont utilisées pour spécifier
plus finement les règles de mapping avancées. Par exem
ple, dans le cas d'une règle de
mapping avancées de conversion complexe, les BMR seront utilisés pour préciser la nature de
la conversion.


Méthode

agile

:

Une
méthode agile

est une approche itérative et incrémentale, qui est menée
dans un esprit collaboratif. Elle génère un produit de haute qualité tout en prenant en compte
l’évolution des besoins des clients


Enrichissement

d’ontologie

:

L’enrichissem
ent d’une ontologie consiste à ajouter de
nouveaux concepts à cette dernière. Lors de cette phase, de nouvelles propriétés

et classes

peuvent être
greffé

à l’ontologie.


Inférence

:

L’inférence est une o
pération logique s’appliquant sur des propositions que l’on
considère vraies. Cette opération permet de déduire une nouvelle proposition à partir des
liaisons tenues avec les autres propositions.


Mapping

:

Le mapping est l’opération qui
consiste à relier des éléments XSD avec des
éléments ontologiques par le biais de règles de mapping avancées (AMR
).


Ontologie

:

Une ontologie est un modèle de données représentatif d’un ensemble de concepts
d’un domaine et d
e leurs relations.


OWL

:

Basée sur le langage RDF, OWL est un langage sémantique donnant les moyens de
définir des ontologies.


Peuplement

d’ontologie

:

Le peuplement d’une ontologie est le processus permettant de
créer de nouvelles ins
tances des concepts présents dans l’ontologie.


RDF/RDFS

:

RDF est un modèle de graphe destiné à décrire les ressources Web de façon à
permettre leur traitement automatiques de ces dernières. RDFS est un langage permettant de
structurer les ressources RDF.


Schéma XML

:

Les schémas XML sont des évolution des DTD. Ils permettent de définir de
manière très fine la structure des documents XML.


W3C

:

Le World Wide Web Consortium est un organisme de s
tandardisation des
technologies web.
Ce groupe a notamment émis des recommandations sur les langages
HTML, CSS, XML
, RDF et OWL.


Web sémantique

:

Le web sémantique est une évolution du web permettant de donner un
sens aux données via un système de
métadonnées

(donnée définissant une autre donnée) afin
que celles
-
ci puissent être
traitées

automatiquement

Yoan Chabot


40

| XSD2OWL


XML

:

XML est un langage de balisage qui définit un
ensemble de règles syntaxiques pour la
présentation structurée de l'information.


Xpath
:

est un langage permettant de définir les ressources XML

de façon unique.
Cette
propriété permet d’utiliser comme un langage de requête sur l
es fichiers XML.








































Yoan Chabot

41

| XSD2OWL

6.

Index



AMR

................................
................................
................................
............................

26, 44, 45

BMR

................................
................................
................................
................................
...

16, 44

C
lasses

................................
................................
...............

14, 15, 22, 24, 25, 26, 29, 33, 37, 45

Enrichissement

................................
................................
................................
...............

1, 2, 45

Inférence

................................
................................
................................
................................
..

45

L
iens visuels

................................
................................
................................
......................

15, 25

Mapping

................................
................................
..............................

15, 16, 17, 18, 26, 44, 45

Ontologie

................................
................................
................................
...........................

21, 45

Peuplement

................................
................................
..

17, 18, 33, 34, 35, 36, 37, 38, 39, 40, 45

P
ropriétés

................................
................................
....

12, 14, 21, 29, 34, 35, 37, 38, 40, 41, 45

Schéma XML

................................
................................
................................
..........................

14

W3C

................................
................................
................................
.............................

11, 19, 45

Web séman
tique

................................
................................
................................
.....

8, 10, 21, 45

XML

...........................

2, 7, 12, 13, 14, 15, 17, 18, 19, 20, 21, 23, 26, 30, 31, 32, 33, 34, 41, 45

XPath

................................
................................
................................
...............

19, 20, 40, 41, 45

XSD2OWL

................................
................................
......................

1, 13, 14, 17, 19, 23, 27, 52












Yoan Chabot


42

| XSD2OWL

7.

Bibliographie

Ontology Enrichment and Automatic Population From XML Data


Auteur

: Christophe Cruz, Christophe Nicolle


Le2i



Site

: http://vision.u
-
bourgogne.fr/le2i/


Projet CheckSem


Site

: http://iutdijon.u
-
bourgogne.fr/checksem/


World Wide Web Consortium et ses
recommandations


Site

:
http://www.w3.org/


Traductions de plusieurs recommandations du W3C


Site

:

http://www.yoyodesign.org/


Manuel

d’utilisation de l’API JGraph


PDF

:
http://www.jgraph.com/pub/jgraphmanual.pdf


Java pour le développement de clients lourds


Auteur

: Mickaël Baron


PDF

: http://mbaron.ftp
-
developpez.com/javase/javavisu.pdf


API Jena

Site

:
http://jena.sourceforge.net/


Divers


http://www.developpez.com/

http://www.siteduzero.com/

http://www.w3schools.com/




Yoan Chabot

43

| XSD2OWL

8.

Annexes

Rapport de bug : Parser XSD

Vendredi 15 mai

Descriptif du bug:

Lors du traitement d'un document XSD par le module de parsage du plugin XSD2OWL, une
erreur peut survenir dans certains cas de fichiers. Lors d'un fonctionnement normal, le
programme est censé restituer à l'écran la structure du fichier XSD via un arbre Jt
ree. Les
screenshots suivant montrent une utilisation normale :













Si l'utilisateur soumet au module de parsage un fichier présentant les caractéristiques évoqués
dans la suite de ce dossier, l'erreur suivante se produit :


Yoan Chabot


44

| XSD2OWL

L'affichage de l'a
rbre XSD ne s'effectue pas :


1.5


1.6


1.7


1.8


1.9


1.10


Comment reproduire le bug?

L'exception java.lang.StackOverFlowError indique un dépassement de mémoire causé par un
cycle de références au sein du fichier XSD.

Par exemple, nous pouvons trouver le cas suivant dans le fichier source du bug:

<xs:element name="sup">

<xs:complexType mixed="true">

<xs:choice>

<xs:element ref="sub" />

<xs:element ref="sup" />

<xs:element ref="i" />

<xs:element ref="tt" />

<xs:element
ref="ref" />

</xs:choice>

Yoan Chabot

45

| XSD2OWL

</xs:complexType>

</xs:element>

<xs:element name="tt">

<xs:complexType mixed="true">

<xs:choice>

<xs:element ref="sub" />

<xs:element ref="sup" />

<xs:element ref="i" />

<xs:element ref="tt" />

<xs:element ref="ref" />

</xs:choice
>

</xs:complexType>

</xs:element>

On s'aperçoit que les éléments font références à eux même et que l'élément sup fait référence
à l'élément tt qui lui même fait référence à l'élément sup dans sa définition. La boucle infini
entraînée par ces cycles entraîn
e la levée de l'exception cité ci
-
dessus.



















Yoan Chabot


46

| XSD2OWL






































Projet
XSD2OWL

Le2i

Le2i


Laboratoire Electronique, Inf
o
r
matique et Image, Dijon, France