V. Conception - evalactisem

carriagespinInternet and Web Development

Oct 22, 2013 (3 years and 8 months ago)

79 views

Catégorisation et sémantisation de flux d’api



1


UNIVERSITE VINCENNE
-
SAINT DENIS

PARIS 8





DEPARTEMENT Langages Informatique Technologie




MASTER PROFESSIONNEL Informatique des Métiers et Applications

Spécialité Technologie de l’Hypermédia




PROJET FIN D’ETUDE



Catégorisation et sémantisation d’un f
lux d’api





Organisation d’accueil

: Mundigo


Réalisé par

: Mlle Amel BOURENANE


Encadré par

:
Samuel Szoniecky






Année universitaire

: 2007/2008



Catégorisation et sémantisation de flux d’api



2


Table des matières

TABL
E DES FIGURES

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

3

I.

INTRODUCTION

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

4

II. PRESENTATION DU
MUNDIGO

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

5

II.1. PRESENTATION
DE L’ENTREPRISE

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

5

III. PRESENTATION DE

PROJET

:

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

8

III.1.

A
CTEURS DU PROJET

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

9

III.2.

D
EFINITION DE LA CIBL
E

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

9

IV.
ÉTAT DE L’ART

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

9

IV.1

XML

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

10

IV.1.1 Les avantages de XML

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

11

IV.1.2 Inconvénients

:

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

11

IV.2

RDF

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

12

IV.2.1 Schéma RDF

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

13

IV.2.2 Avantages

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

14

IV.2.3 Inconvénients

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

14

IV.2.4 Sparql

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

15

IV.3

O
WL

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

18

IV.3.1

O
NTOLOGIE

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

18

IV.3.2 Avantages

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

20

IV.4.

T
AG ONTOLOGIE

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

20

IV.5.

SCOT

(S
OCIAL
S
EMANTIC
C
LOUD OF
T
AGS
)

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

21

IV.6

MOAT

(M
EANING OF A
T
AG
)

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

23



IV.7 Conclusion


24

V.
CONCEPTION

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

26

V.1

D
IAGRAMME DES CAS D

UTILISATION

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

26

V.2

D
IAGRAMM
E DE SEQUENCE

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

31

V.3

L
A METHODE CONCEPTION

M
ERISE

:

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

34

V.3.1

P
RESENTATION DE LA ME
THODE
M
ERISE

:

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

34

V.3.1 Etude préalable

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

34

VI.
ARCHITECTURE FONCTIO
NNELLE

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

40

VI.1

A
CTEURS PRINCIPAUX DE

PROJET

ET ROLE

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

40

VI.2

C
ONCEPTS

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

40

VII.
ARCHITECTURE TECHNIQ
UE

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

40

VII.
1

G
ENIALITE

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

40

VII.1.4

C
HOIX D

IMPLEMENTATION

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

41

VII.2

S
CHEMA GENERAL
&

DESCRIPTION DES FLUX

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

45

VII.3.

B
ASE DE DONNEES POUR
E
VAL
A
CTI
S
EM

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

46

La réponse de API del.icio.us est ce forme d’XML, la classe php le récupère, le parse et stocke le résultats
dans la
base de données.

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

50

VIII.
DESCRIPTION DES L’I
NTERFACES

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

51

VIII.1.

I
NTERFACES LOGICIELS

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

51

IX.
CHARTE GRAPHIQUE

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

55

IX

.1.

R
EPARTITIONS DES DIFF
ERENTS ESPACES D
'
INFORMATION A L
'
ECRAN

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

56

IX

.2
.

C
OULEURS UTILISEES

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

57

IX

.3.

E
LEMENTS DE STYLE

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

57

IX

.4.

LES GRAPHIQUES

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

57

X.
CHARTE EDITORIAL

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

57

XI.
CHARTE FONCTIONNELLE

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

58

Catégorisation et sémantisation de flux d’api



3


XI.

1

A
RCHITECTURE HYPERTEX
TUELLE

:

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

58

XII.
CONCLUSION

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

72

Table des figures

Figure 1

: Sémantisation et visualisation du flux de l’API del.icio.us

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

8

Figure 2

: Différente couches de web sémantique.

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

10

Figure 3:

F
olksonomie simplifie dans le modèle
SCOT.

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

23

Figure 4

:
S
ignification globale et locale des tags en MOAT

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

25

Figure 5

: Diagramme des cas d’utilisation.

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

27

Figure 6

: Diagramme de séquence pour la récupération du flux.

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

32

Figure 7

: Diagramme de séquence pour la traduction de flux.

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

32

Figure 8

: Diagramme de séquence pour la traduction de flux

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

33

Figure 9

: Diagramme de séquence pour la suppression du compte

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

33

Figure 10

: Diagramme de séquence pour la mise à jour du compte IEML
.............................

34

Figure 11

: Modèle conceptuel des données

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

36

Figure 12

: Modèle logique des données

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

37

Figure 13

: Diagramme de flux d’information

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

37

Figure 14

: Le modèle conceptuel
des traitements.

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

39

Figure 15

: Premier niveau d’articulation Ieml

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

43

Figure 16

: Deuxième niveau d’articulation Ieml.

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

43

Figure 17:

Schéma générale et description des flux.

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

45

Figure 18

: les table de la base de données.

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

47

Figure 19

: Gabarié de la page d’accueille de l’application.

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

56

Figure 20

: Architecture hypertextuelle de l’application.

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

58

Figure 21

:
C
opie d’écran de la page d’accueille.

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

59

Figure 23

: Interface pour le choix des requêtes del.icio.us

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

60

Figure 24

: Table de flux

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

61

Figure 25

: Table de flux pour les requêtes de type post.

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

61

Figure 26

: tag en

fonction des count

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

62

Figure 27

: Bundles en fonction de Tags.

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

62

Figure 28

:
B
outons pour la mise à jour et la traduction du f
lux.

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

63

Figure 29

:
I
nterface de traduction.

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

63

Figure 30

:
T
able des tags avec une seule traduction.

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

64

Figure 31

: Table des tags avec plusieurs traductions.

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

65

Figure 32

: Table tags sans traduction.

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

65

Figure 33

: dictionnaire IEML.

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

66

Figure 34

: Cycle IEML

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

66

Figure 35

:
R
eprésentation graphique pour le flux trad
uit.

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

67

Figure 36

: Boussole IEML.

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

68

Figure 37

: Les différentes couches de la boussole

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

69

Figure 38

: Bouton points.

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

71






Catégorisation et sémantisation de flux d’api



4


I.

Introduction


Le Social bookmarking (ou "Marque
-
page social", en français) est une façon pour les
internautes de stocker, classer, chercher et partager leurs lie
ns favoris." selon Wikipédia

Rendu populaire par des sites tels que "Mister Wong" ou encore "del.icio.us", le social
bookmarking permet aux internautes la sauvegarde de leurs bookmarks (signets, liens favoris)
directement sur un site web public de "social

bookmarking service".Les internautes gèrent
leurs bookmarks grâce à des mots
-
clés (tags ou libellés) et peuvent partager, avec les autres
utilisateurs.


Les internautes peuvent, aussi, effectuer des recherches parmi les bookmarks sociaux via les
tags afin

de trouver de nouveaux articles ou sites. Fréquemment, un "tags cloud" (nuage de
tags) aide à la recherche.


Les intérêts du social bookmarking

:



Le social bookmarking permet d'externaliser les bookmarks et de les centraliser
sur un service accessible de

n'importe où.



Les tags des ressources sont choisis par les internautes qui comprennent le
contenu contrairement aux moteurs de recherche. Ceci fournit des étiquettes
classées "sémantiquement".



Les internautes sauvegardent et partagent les ressources qu’il
s jugent les plus
utiles.



Généralement, les sites de Social bookmarking permettent de s’abonner à des
flux RSS afin de s'informer des derniers favoris partagés,



et permettent, aussi, d'exporter / importer les favoris vers d'autres sites
vers

votre navigate
ur.



Sauvegarder et classer les bookmarks selon le principe de
folksonomie
1

ce qui
permet de

:



Améliorer la recherche d'information dans sa collection de ressources
personnelles ;



Constituer un vecteur de sérendipité ;



Donner aux autres utilisateurs une idé
e du contenu de sa collection de
ressources ;




1


Un système de classification col
laborative décentralisée spontanée
.

Catégorisation et sémantisation de flux d’api



5




Faire apparaître des réseaux sociaux implicites par l'utilisation commune
de tags entre différents utilisateurs.


L’utilisation des tags pour la sauvegarde et le classement des bookmarks
présent

les
inconvénien
ts suivants

:



Le tag n'est qu'une chaîne de caractères dont le sens exact est connu du seul «
taggueur » qu'un autre utilisateur peut éventuellement appréhender, mais en
aucun cas une machine qui se repose uniquement sur la morphologie du tag
pour l'exploi
ter.



En plus les inconvénients liés au
folksonomie

:



Impossibilité d'organiser les tags entre eux sous la forme d'une
taxinomie
2

ou d'un thésaurus
3

;



Deux utilisateurs peuvent partager un tag identique, mais en avoir une
conception différente ;



la folkson
omie n'est pas multilingue, c'est à dire qu'il n'existe
aujourd'hui pas de moyens pour relier le même tag exprimé en anglais
et en français ;



Deux tags différents peuvent être synonymes voire identique ou
presque (fautes d'orthographe), sans qu'on puisse l
es relier.


C’
est pour résoudre le problème de la non standardisation de la structure des tags
que ce
présent travail

va essaye de résoudre en proposant
l
’ajout d’
une couche séman
tique
.

II
.
Présentation du Mundigo



II.1. Présentation de l’entreprise


MUNDIGO est une structure de production et de distribution audiovisuelle dédiée à la culture

et l’art, au voyage et à l’information ainsi qu’au divertissement.

MUNDIGO travail également
sur les nouvelles technologies avec une équipe d’ingénieurs

spécialisés.







2

science de la classification
.

3

sorte de dictionnaire hiérarchisé ; un vocabulaire normalisé sur la base de

termes génériques et de termes
spécifiques à un domaine.

Catégorisation et sémantisation de flux d’api



6


II.1.1 La Charte

MUNDIGO est une structure de production et distribution de programm
es culturels :
documentaires et fictions audiovisuels, éditions musicales, spectacles vivants favorisant la
découverte et l’échange entre les cultures.



MUNDIGO recherche constamment la qualité des contenus afin de respecter ses objectifs
premiers et de m
ontrer le plus grand respect à l’égard du Public. C’est dans ce but que nous
nous interrogeons toujours sur l’intérêt didactique et pédagogique de nos produits
pluriculturels sans pour autant négliger leur dimension divertissante et ludique.



MUNDIGO enco
uragera toujours à travers le monde, dans la mesure de ses moyens, toute
initiative dans le domaine de la création et de l’innovation.




MUNDIGO s’engage à communiquer le savoir, à informer et à promouvoir les différents
talents dans le monde.



MUNDIGO c
’est le relais avec des structures génératrices d’informations et de contenus.




MUNDIGO c’est le partenariat avec des structures et des indépendant solidaires de l’aventure.


II.1.2. L’équipe

Mehdi KAHTANE est responsable du développement international
et créatif de la société.
Elevé sous le signe de la double culture franco
-
marocaine et, dès le plus jeune âge, à
l’ouverture aux langues étrangères, Mehdi Kahtane, après un cursus scientifique, a fait des
études en ethnologie, en langues étrangères avant d
’effectuer une formation sur le Commerce
International. Mehdi Kahtane est un professionnel de la distribution de programmes
audiovisuels. Il a été responsable des ventes dans les meilleures structures de distribution en
France (ICTV, AMPERSAND), avant de r
ejoindre l’Espagne où il a pris la direction des
coproductions et des nouveaux projets pour Canal Vacaciones
-
VTV. Il fonde Mundigo en
2002.



Samuel SZONIECKY cultive de front son travail de consultant spécialiste dans le
développement de solution informat
ique et ses recherches en science de l’information où il
conçoit des outils pour modéliser l’univers cognitif d’un individu, d’une famille, d’une
Catégorisation et sémantisation de flux d’api



7


institution. Après l’étude du musée imaginaire de la gravure au XVIIIe siècle et des
recherches sur l’influenc
e de l’artiste contemporain John Cage (maîtrise et DEA d’histoire de
l’art), il expérimente une méthode d’écriture philosophique qui utilise les technologies du
chaos. Cette démarche le méne à élaborer une thèse sur des agents informatiques capables de
pro
duire automatiquement des documents adaptatés aux besoins de leurs utilisateurs. Pour
MUNDIGO, Samuel Szoniecky s’occupe du développement informatique concernant entre
autres la mise en place d’un outil de publication de contenu pour internet (SPIP), le pr
ojet
"Evaluer la violence" à destination des collégiens et lycéens, le projet d’archéologie populaire
autour de l’enrichissement des photos anciennes par de nouvelles perspectives.


Jean
-
Marc LAUNAY étudie et pratique la photo et la sémiotique de l’image a
u service des
métiers de l’édition. Après une école de photographie, il collabore à une société d’édition où il
s’occupe de la mise en valeur du contenu à travers la présentation de l’image. Il travaille dès
les débuts de l’Internet au premier journal en l
igne destiné à l’actualité du patrimoine culturel.
Ces expériences professionnelles lui permettent de maîtriser complètement la chaîne
éditoriale de bout en bout. Il rejoint l’équipe de MUNDIGO où il intervient en tant qu’expert
éditorial.



Patrick KERS
ALE a travaillé dans une quarantaine de pays d’Europe, d’Afrique, d’Amérique
et d’Asie pour photographier, enregistrer, filmer les musiciens traditionnels et étudier leur
musique. Musicien et ethnomusicologue, auteur d’une soixantaine de disques consacrés
aux
musiques traditionnelles à travers le monde, directeur de la collection de CD "Peoples" et de
la collection de livres
-
disque “Parole d’Ancêtre” consacrée aux traditions orales parlées,
auteur d’ouvrages pédagogiques, d’articles, de diaporamas, de films

pédagogiques et
télévisuels sur les musiques traditionnelles et les croyances. Nombre de ses publications ont
été saluées et récompensées par la presse spécialisée. Patrick Kersalé déploie, depuis plus de
dix ans, toute son énergie pour sauvegarder et pré
server ces musiques traditionnelles pour la
plupart en voie de disparition. Il publiera en 2002 une somme originale de ses dix dernières
années de voyages musicaux. Il assure lui
-
même les tournages, écrit les scénarios, parfois en
collaboration avec des ex
perts, supervise le montage.

Catégorisation et sémantisation de flux d’api



8


III
.
Présentation de Projet

:



Dans le cadre du développement d’
IEML

(cf. www.ieml.org), une équipe de chercheurs se
met en place pour mettre à la disposition du public des outils Open Source utiles pour
l’organisation séman
tique de l’information.


En partenariat avec le laboratoire Paragraphe de l’université Paris 8, MUNDIGO propose de

développer une application générique utilisant IEML pour donner une représentation

sémantique d’un flux d’information. Dans cette première ph
ase, un exemple fonctionnel

utilisant l’API del.icio.us (http://del.icio.us/help/api
/)

comme source d’un flux d’information

sera traduit semi automatiquement en IEML pour en donner une représentation graphique et
sémantique (SVG).


Plusieurs objectifs sont

fixés dans le cadre de ce projet :



Mettre en place une plateforme de développement Open Source



Développer des modules informatiques pour :



Gérer le flux provenant de l’API del.icio.us.



Traduire semi automatiquement un flux en IEML.



Représenter le parsing
d’une expression IEML en graphique SVG
dynamique.




Publier les développements sur une plateforme de publication de code
.


Cet exemple permet de montrer concrètement comment IEML permet de mieux se repérer
dans un l’espace sémantique issue d’une folksonomi
e del.icio.us.








Figure
1

: Sémantisation et visualisation du flux de l’API del.icio.us



Catégorisation et sémantisation de flux d’api



9


III
.
1.

Acteurs du projet




Equipe de conception

o

Prof. Pierre Lévy, titulaire de la Chaire de Recherche du Canada en
Intelligence Collect
ive.

o

Samuel Szoniecky, ingénieur sémantique

o





Equipe de réalisation

o

Samuel Szoniecky

o

Amel

Bourenane


III
.
2.

Définition de la cible

Ce projet est destiné aux utilisateurs du bookmark social del.icio.us, il leurs offre une
interface utilisateur riche pour v
isualiser et traduire leurs tags. Les chercheurs intéressés par
les applications du langage IEML et plus généralement par le web sémantique, pourront
trouver là, la première application qui utilise ce langage pour l’ajout d’une couche
sémantique.

IV.
État
de l’art

A sa création par Tim Berners Lee
,

l'objectif du web était de permettre

des échanges rapides
de savoirs entre individus distants. C'est dans ce but qu'a été créé le

langage HTML,
autorisant une mise en forme aisée et rapide

des

documents en ligne.


Dix ans plus tard, au début du XXIème siècle, la « balkanisation » du Web a bien eu lieu, si
on

me permet d'emprunter un terme

consacré par OpenWeb
. Tant au niveau de la

présentation
que du balisage ou du respect des standards, les documents présents sur

le web

ne constituent
plus, de par leur hétérogénéité, une source de savoir fiable et agréable à

consulter. Les
connaissances que proposent les pages Web ont peu à peu été enfermées, au

grès des modes,
dans une couche présentationnelle qui, si elle n'a pa
s dénaturé l'information,

l'a en tout cas
rendue moins accessible.


Depuis plusieurs années, toutefois, une nouvelle idée du Web prend corps : celle d'un Web

Catégorisation et sémantisation de flux d’api



10


Sémantique. Peu à peu, le World Wide Web Consortium (W3C) se dote de nouveaux
langages

et d'outils

plus performants : XML, RDF, OWL, n'en sont que des exemples. Tous
ont pour

objectif commun de participer à une formalisation des savoirs, en permettant ainsi un

meilleur partage et une transmission plus aisée. Les champs d'application éventuels sont

vast
es : raisonnement automatique, résolution de problèmes par inférences, représentation de

do
n
nées structurées, traduction automatisée, etc.








Figure
2

: Différente couches de web sémantique.

IV
.1
XML

Sans avoir la prétention
de remplacer HTML, XML émerge au moment propice du
développement des nouvelles technologies et propose des aspects complémentaires à HTML
permettent de palier un certain nombre de ses carences. Séparation des données et de
représentation, format de données

orienté objet, nombreuses technologies associées telles que
la mise en forme et la validation syntaxique, portabilité sur tous les systèmes d’exploitations
et utilisation possible dans tous les langages de programmation sont autant d’atouts qui font
d’XML

non pas une simple mode mais bien une technologie qui a sa palace dans les
applications d’aujourd’hui et de demain.



X
ML (eXtensible Markup Language)

est un standard mis en place par le World Wide Web
Consortium (W3C). “
Il définit une syntaxe gé
n
é
riq
ue utilis
é
e

pour marquer les donn
ées
avec
un balisage simple et lisible par les humains.”

.La structure est repr
é
sent
é
e en XML par des
é
l
é
ments, contenant des attributs, du

texte ou d’autres
é
l
é
ments. Les
é
l
é
ments ne peuvent pas
se chevaucher. Le choix du

nom des
é
l
é
ments structurants et des attributs, ainsi que
l’organisation des
é
l
é
ments

entre eux, est laiss
é à

la libre volont
é

de l’auteur. C’est pourquoi
on dit que le langage

XML est g
é
n
é
rique.

OWL


RDF + RDF Schéma

XML+Schéma XML

Logique

(Méta) données

Syntaxe

Catégorisation et sémantisation de flux d’api



11


IV
.1.1

Les avantages de XML

L objectif principale du XML Wo
rking Group au moment de sa formation est de créer une
technologie universelle pour structurer l’information, cette technologie se devait d être
particulièrement adaptée à la diffusion et à l’échange d’information, notamment à travers
Internet. Il ne faut

pas percevoir XML comme une application, mais bien comme une forme
d’expression standardisée caractérisée par des règles de grammaire. Le langage XML est un
standard ouvert, gratuit, libre de droit, adapté au web et indépendant des plates
-
formes, des
lan
gages et des systèmes d’exploitation.


Le langage XML, avec sa volonté de fournir une information structurée et s’autodécrivant,
favorise l’organisation des éléments et leur sémantique. Néanmoins, il conserve le même
esprit que HTML

: utilisation des balis
es, simplicité et adaptabilité au web. Le langage met a
disposition un moyen de séparer le fond et la forme. Sa capacité à décrire les données et leurs
relations entre elles lui promet de devenir un vecteur d’information potentiel sur le web,
d’autant plus

que les documents XML sont des documents enregistrés au format texte, format
exploitable par les systèmes d’exploitation.


L’utilisation du langage XML dans nous projets informatiques fournit une garantie d’
interopérabilité de nous applications. A condit
ion de faire un peu attention au type d’encodage
utilisé par nous fichiers, le format texte est compréhensible par tous les systèmes
d’exploitation, ce qui rend possible la communication entre des applications fonctionnant sur
des plates
-
formes potentielle
ment différentes et écrites dans des langages hétérogènes. L’un
des arguments clés des promoteurs du langage est de prôner la lisibilité des documents décrits
avec le langage XML. Dans la mesure ou le concepteur de la grammaire d’un document XML
définit de
s balises possédant des noms explicites, le document sera lisible par n’importe quel
être humain et exploitable par la machine

; d’autre part le langage en lui
-
même est facile à
apprendre.

IV
.1.2 Inconvénients

:

L’o
bjectif initial

de XML

est de faciliter l
'échange automatisé de contenus entre systèmes
d'informations hétérogènes (interopérabilité)

donc il donne une structure aux informations
mais pas de sens.
XML permet aux utilisateurs d'ajouter une structure arbitraire à leurs
documents sans rien dire de l
a signification des structures
.


Catégorisation et sémantisation de flux d’api



12


Comment savoir que deux documents produits par des auteurs qui ne se connaissent pas ont
effectivement des choses en commun ? Par exemple, une balise <titre> désigne
-
t
-
elle le titre
du document, celui d’un ouvrage dont parl
e le document, un titre de noblesse ? XML ne
résout pas le problème clé du web sémantique : celui, précisément, de la sémantique, c’est
-
à
-
dire un schéma conceptuel décrivant la structure des
données

[
13]
.

IV
.2
RDF

A sa création par Tim Berners Lee, au déb
ut des années 1990, le web était exclusivement

destiné à partager des informations sous forme de pages html, affichables par un logiciel

«
navigateur web », et généralement destinées à être lues par un utilisateur humain.

Très rapidement, on s'est rendu co
mpte que cette conception du web était bien trop limitée,

et
ne permettait pas un réel partage du savoir : tout au plus cela permettait
-
il de présenter

des
connaissances, mais en aucun cas de les rendre directement utilisables.


L'arrivée de XML, en 1998,
a donné un cadre à la structuration des connaissances, rendant

ainsi possible la création de nouveaux langages web destinés non plus à un rendu graphique à

l'écran pour un utilisateur humain, mais à un réel partage et à une manipulation des savoirs.

C'est
dans cet esprit qu'a été créé en 1999 RDF.



Le développement de RDF par le W3C a été entre autres motivé par la perspective des
applications suivantes :



manipulation et classification des métadonnées Web, afin de fournir des
informations sur les ressourc
es Web et les systèmes qui les utilisent.



développement de modèles d'information ouverts plutôt que fixés pour certaines
applications (par exemple les activités de planification, de description de
processus organisationnels, d'annotation de ressources web,

etc.)



faire avec l'information traitable par machine ce que le Web a fait pour
l'hypertexte, en permettant aux informations d'être manipulées en dehors de
l'environnement particulier dans lequel elles ont été créées, éventuellement à
l'échelle d'Internet.

C'est le concept d'interopérabilité des savoirs.



optimisation de la coopération entre applications, en permettant de combiner les
données de plusieurs applications, pour générer de nouvelles informations.



faciliter le traitement automatique de l'informati
on du Web par des agents
logiciels, transformant ainsi le web d'un regroupement d'informations
Catégorisation et sémantisation de flux d’api



13


uniquement destinées aux humains, en un état de réseau de processus en
coopération.

Pour ce faire, RDF procède par une description de savoirs (données tout comm
e
métadonnées) à l'aide d'expressions de structure fixée. En effet, la structure fondamentale de
toute expression en RDF est une collection de triplets, chacun composé d'un sujet, un prédicat
et un objet. Un ensemble de tels triplets est appelé un graphe R
DF. Ceci peut être illustré par
un diagramme composé de noeuds et
d'arcs dirigés, dans lequel chaque triplet est représenté
par un lien noeud
-
arc
-
noeud (d'où le terme de "graphe").

Exemple

L’expression du fait « Paris est en France » se fait par le biais d
e l’écriture d’un triplet
RDF, que l’on peut représenter sous la forme d’un graphe sujet
-
prédicat
-
objet :










La sérialisation en RDF
-
XML de l’assertion "Paris est située en France" pourrait s’écrire de la
manière suivante :



<rdf:Description about="#paris">

<schema:pays>France</schema:pays>


</rdf:Description>

IV
.2.1 Schéma RDF

Les déclarations RDF définissent des relations entre des objets (nœud d’un graphe) qui
appartiennen
t à un univers sémantique. A chacun de ces univers sémantiques correspond un
domaine nominal, identifié par un préfixe particulier. Un tel domaine, pour lesquels sont
définies des propriétés spécifiques et des catégories conceptuelles, est appelé un schéma
.


Tout utilisateur a la possibilité de créer un nouveau schéma, de modifier, et notamment
d’enrichir et d’affiner un schéma existant, de créer ce faisant un nouveau schéma
Paris

France

Est_situé_en

Obj
et

Prédicat

Sujet

Catégorisation et sémantisation de flux d’api



14


personnalisé, et d’utiliser un schéma pour décrire les propriétés d’objets ayant un
e existence
dans ce schéma.


RDFS (pour « RDF Schéma ») offre les moyens de définir un modèle (ou bien encore un
schéma) de méta données qui permet de :



donner du sens aux propriétés associées à une ressource ;



formuler des contraintes sur les valeurs asso
ciées à une propriété afin de lui
assurer aussi une signification.


Par exemple, si l’on a une propriété qui représente un auteur, on peut exiger que les valeurs de
cette propriété soient une référence à une personne (et non pas une voiture ou une maison).

On peut aussi vouloir restreindre quelles sont les propriétés s’appliquant à une ressource. Cela
n’a probablement aucun sens d’autoriser une propriété « date de naissance » à être appliquée à
un morceau de musique
[7]
.


IV
.2.2 Avantages

1.

il fournit l'inter
opérabilité entre les applications qui échangent de l'information non
compréhensible par les machines sur le Web. RDF augmente la facilité de traitement
automatique des ressources Web.

2.

RDF peut être utilisé dans une variété de champs d'application ; par ex
emple : dans la
découverte de ressources pour fournir une meilleure efficacité aux moteurs de
recherche, dans le catalogage pour décrire le contenu et les relations entre les contenus
disponibles sur un site Web particulier, sur une page, ou sur une biblio
thèque
numérique, dans l'évaluation du contenu, en décrivant des ensembles de pages qui
représente un simple et unique "document", pour décrire les droits sur la propriété
intellectuelle des pages Web, et pour indiquer les préférences de confidentialité d'
un
utilisateur aussi bien que les politiques de confidentialité d'un site Web.

3.

RDF avec les signatures numériques sera la clé pour construire un "Web de confiance"
pour le commerce électronique, les collaborations, et d'autres applications.

IV
.2.3 Inconvén
ients

1.

RDFS

: range définit le domaine de valeurs d’une propriété quelle que soit la classe
concernée. Par exemple, il ne permet pas d’exprimer que les vaches ne mangent que
de l’herbe alors que d’autres sortes d’animaux mangent également de la viande.

Catégorisation et sémantisation de flux d’api



15


2.

RDF
S ne permet pas d’exprimer que deux classes sont disjointes. Par exemple, les
classes des hommes et des femmes sont disjointes.

3.

RDFS ne permet pas de créer des classes par combinaison ensembliste d’autres classes
(intersection, union, complément). Par exem
ple, on veut construire la classe Personne
comme l’union disjointe des classes des hommes et des femmes.

4.

RDFS ne permet pas de définir de restriction sur le nombre d’occurrences de valeurs
que peut prendre une propriété. Par exemple, on ne peut pas dire qu
’une personne a
exactement deux parents.

5.

RDFS ne permet pas de définir certaines caractéristiques des propriétés : transitivité
(par exemple : estPlusGrand
-
Que), unicité (par exemple : estLePèreDe), propriété
inverse (par exemple : mange est la propriété i
nverse de estMangéPar).

IV
.2.4 Sparql


SPARQL (protocole SPARQL et langage de requête RDF) en informatique est un langage de
requête, devenu le 15 Janvier 2008, dans le cadre de l'activité Web sémantique du W3C, une
recommandation W3C.


Le langage SPARQL d
éfinit la syntaxe et la sémantique nécessaire à l'expression de requêtes
sur une base de données de type RDF et la forme possible des résultats.

SPARQL est adapté à la structure spécifique des graphes RDF, et s'appuie sur les triplets qui
les constituent.
En cela, il est différent du classique SQL (langage de requête qui est adapté
aux bases de données de type relationnelles), mais s'en inspire clairement dans sa syntaxe et
ses fonctionnalités. Il a aussi quelques traits de ressemblance mineurs avec Prolog.

SPARQL permet d'exprimer des requêtes interrogatives ou constructives :

Une requête SELECT, de type interrogative, permet d'extraire du graphe RDF un sous
-
graphe
correspondant à un ensemble de ressources vérifiant les conditions définies dans une clause
W
HERE.

Une requête CONSTRUCT, de type constructive, engendre un nouveau graphe qui complète
le graphe interrogé.

Par exemple sur un graphe RDF contenant des informations généalogiques, on pourra par une
requête SELECT trouver les parents ou grands
-
parents d
'une personne donnée, et par des
requêtes CONSTRUCT ajouter des relations frère
-
sœur, cousin
-
cousine, oncle
-
neveu, qui ne
seraient pas explicitement déclarées dans le graphe initial

[8][9]
.

Catégorisation et sémantisation de flux d’api



16


Exemple de requête SPARQL retournant une liste de photos avec le n
om de la personne
qu'elles représentent et une description, à partir d'une base de données de type RDF utilisant
l'ontologie (vocabulaire) FOAF (une des plus connues et utilisée pour décrire les personnes et
les liens entre elles).



Extrait du graphe RDF (é
criture XML) d'exemple

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#"


xmlns:foaf="http://xmlns.com/foaf/0.1/"


xmlns:rss="http://purl.org/rss/1.0/"


xmlns:dc="http://purl.org/dc/elements/1.1/">


<foaf:Person rdf:about="http://
example.net/Paul_Dupont">


<foaf:name>Paul Dupont</foaf:name>


<foaf:img rdf:resource="http://example.net/Paul_Dupont.jpg"/>


<foaf:knows rdf:resource="http://example.net/Pierre_Dumoulin"/>


</foaf:Person
>


<foaf:Person rdf:about="http://example.net/Pierre_Dumoulin">


<foaf:name>Pierre Dumoulin</foaf:name>


<foaf:img rdf:resource="http://example.net/Pierre_Dumoulin.jpg"/>


</foaf:Person>


<foaf:Image rdf:a
bout="http://example.net/Paul_Dupont.jpg">


<dc:description>Photo d'identité de Paul Dupont</dc:description>


</foaf:Image>


<foaf:Image rdf:about="http://example.net/Pierre_Dumoulin.jpg">


<dc:description>Photo
d'identité de Pierre Dumoulin</dc:description>


</foaf:Image>

</rdf:RDF>



La
requête

SPARQL :

PREFIX rdf: <http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#>

PREFIX foaf: <http://xmlns.com/foaf/0.1/>

PREFIX dc: <http://purl.org/dc/elements/1.1/>

SELECT DIS
TINCT ?nom ?image ?description

WHERE {


?personne rdf:type foaf:Person .


?personne foaf:name ?nom .


?image rdf:type foaf:Image .

Catégorisation et sémantisation de flux d’api



17



?personne foaf:img ?image .


?image dc:description ?description

}

On remarque la déclarat
ion des espaces de noms en début, suivis de la requête proprement
dite. Le nom des variables est précédé d'un point d'interrogation ?.


La ligne SELECT permet de sélectionner l'ensemble des tuples, ou lignes de variables (nom,
image, description) correspon
dant aux contraintes de la clause WHERE.


La première ligne de la clause WHERE se lit : la variable personne est de type Person au sens
de l'ontologie FoaF. La seconde ligne permet de définir la variable nom en tant que propriété
name de la variable person
ne.



Le résultat SPARQL :

<sparql xmlns="http://www.w3.org/2005/sparql
-
results#">


<head>


<variable name="nom"/>


<variable name="image"/>


<variable name="description"/>


</head>


<results
ordered="false" distinct="true">


<result>


<binding name="nom">


<literal>Pierre Dumoulin</literal>


</binding>


<binding name="image">



<uri>http://example.net/Pierre_Dumoulin.jpg</uri>


</binding>


<binding name="description">


<literal>Photo d'identité de Pierre Dumoulin</literal>



</binding>


</result>


<result>


<binding name="nom">


<literal>Paul Dupont</literal>

Catégorisation et sémantisation de flux d’api



18



</binding>


<bindi
ng name="image">


<uri>http://example.net/Paul_Dupont.jpg</uri>


</binding>


<binding name="description">


<literal>Photo d'identité de Paul Dupont<
/literal>


</binding>


</result>


</results>

</sparql>

IV
.3 Owl

On a vu que RDF et RDFS permettent de définir, sous forme de graphes de triplets, des
données ou des métadonnées. Cependant, de nombreuses limitati
ons bornent la capacité
d'expression des connaissances établies à l'aide de RDF/RDFS. C'est ce manque que se

propose de combler OWL

.

IV
.3.1
Ontologie

Web Ontology Language (
OWL
) doit son nom au terme « ontologie », un mot emprunté à la

philosophie qui,
s'il est d'origine grecque, ne fut manifestement créé qu'au XVIIe siècle.

« Discours sur l'être en tant qu'être » selon Aristote, l'ontologie prend un tout autre sens en

informatique, où le terme désigne un ensemble structuré de savoirs dans un domaine de

connaissance particulier.

On distingue généralement deux entités globales au sein d'une ontologie. La première, à

objectif terminologique, définit la nature des éléments qui composent le domaine de

l'ontologie en question. La seconde partie d'une

ontologie

explicite les relations entre
plusieurs instances de ces classes définies dans la partie

terminologique.


Ainsi, au sein d'une ontologie, les concepts sont définis les uns par rapport aux autres (modèle

en graphe de l'organisation des connaissances), ce q
ui autorise un raisonnement et une

manipulation de ces connaissances.


Il existe de nombreux langages

informatiques, plus ou moins récents, spécialisés dans la
création et la manipulation

d'ontologies. En voici quelques exemples
:

Catégorisation et sémantisation de flux d’api



19




Open

Knowledge Base Conne
ctivity

: OKBC 2.0, publié en 1997, est une API
permettant

d'accéder à des bases de connaissance (Knowledge Representation
System).




Knowledge Interchange Format

est un langage destiné à faciliter des échanges
de savoirs

entre des systèmes informatiques d
isparates. Son objectif n'est pas de
permettre une

interaction avec l'être humain (bien que cela reste possible), mais
plutôt une

coopération entre systèmes hétérogènes.




LOOM

est un langage de représentation des connaissances dont le but avoué
est de

« p
ermettre la construction d'applications intelligentes ».



DARPA Agent Markup Language
: fondé sur XML et RDF, DAML
-
ONT est
apparu en Octobre

2000 suite à un effort du DARPA (Defense Advanced
Research Projects Agency), afin

d'autoriser l'expression de class
es RDF plus
poussées que ce que permettait à l'époque

RDFS. Le programme DAML se
poursuit encore à l'heure actuelle.


En réaction à l'apparition de ces nombreux langages poursuivant pour la plupart des buts

communs, le
World Wide Web Consortium

(W3C) a mi
s sur pieds, en Novembre 2001, le
groupe

de travail « WebOnt », chargé d'étudier la création d'un langage standard de
manipulation

d'ontologies web. Le premier Working Draft «
OWL Web Ontology Language

1.0 Abstract

Syntax » paraît en Juillet 2002 et, au fi
nal, OWL devient une Recommandation
du W3C le 10

Février 2004.


OWL est

tout comme RDF, un langage XML profitant de l'universalité syntaxique de XML.

Fondé sur la syntaxe de RDF/XML, OWL offre un moyen d'écrire des ontologies web. OWL
se

différencie du co
uple RDF/RDFS en ceci que, contrairement à RDF, il est justement un
langage

d'ontologies. Si

RDF et RDFS apportent à l'utilisateur la capacité de décrire des
classes (ie.

avec des contructeurs) et des propriétés, OWL intègre, en plus, des outils de
compara
ison des

propriétés et des classes : identité, équivalence, contraire, cardinalité,
symétrie, transitivité,

disjonction, etc.


Ainsi, OWL offre aux machines une plus grande capacité d'interprétation du contenu web que

RDF et RDFS, grâce à un vocabulaire pl
us large et
à une vraie sémantique formelle
[
1
][
2
]
.


Catégorisation et sémantisation de flux d’api



20


IV
.3.2 Avantage
s




apporte une meilleure intégration, une évolution, un partage et une inférence
plus facile des ontologies
,





ajoute les concepts de classes équivalentes, de propriété équivalente, d'éga
lité
de deux ressources, de leurs différences, du contraire
, de symétrie et de
cardinalité,




grâce à sa sémantique formelle basée sur une fondation logique largement
étudiée, permet de définir des associations plus complexes des ressources ainsi
que les pr
opriét
és de leurs classes respectives,




est adéquat pour le Web sémantique, car il offre une syntaxe définie
strictement, une sémantique définie strictement et selon le niveau peut
permettre des raisonnements automatisés sur les inférences et conclusions d
es
connaissances
,




le partage et l'échange dans ses formats est facile
.


Ils

existent actuellement des applications qui reposent sur les ontologies et RDF pour ajouter
une couche sémantique aux tags.
On
peut

citer:

IV
.4.
Tag ontologie



Tag Ontology
déc
rie la relation entre un agent, une ressource arbitraire et une ou plusieurs
tags. Dans cette ontologie, les trois concepts de base Taggers, Taggings, et Tags sont utilisés
pour décrire l’activité de tagging. L’ontologie est implémentée en OWL, elle est d
isponible
sur le web et elle est utilisée dans certain projet comme Revyu.com
4
, un site web combinant le
web 2.0 et le web sémantique.

Dans cette ontologie les tags sont représentés par des instances de la classe
tags

: Tag

aux
qu’elles des labels personn
alisées sont affectés c’est
-
à
-
dire des strings représentant les tags
comme vues pas l’utilisateur et aux tags sont affectés des URIs

. De cette manière, les tags
identifies par des URIs peuvent être liés l’uns aux autres et les utilisateurs peuvent repr
ésentés
les connections et les similarités entre les tags. Pour cela l’ontologie introduit la propriété
Tags

: related
. Cette propriété n’est pas très sémantique, car elle ne définie pas la nature de
la relation c'est
-
à
-
dire s’il s’agit d’une variation

linguistique
ou que

les tags relies

identifie
nt

un sujet similaire. Une autre limitation est que l’ontologie ne définie aucune
ou



4

http://www.revyu.com

Catégorisation et sémantisation de flux d’api



21


que les tags relies identifient un sujet similaire. Une autre limitation est que l’ontologie ne
définie aucune contrai
nte sur le nombre de label qui peut avoir un tag. Ceci peut pauser des
problèmes puisqu’elle permet à un tag d’avoir deux labels complètements disjoints (une
instance de tag avec des labels RDF et Paris). Ce qui n’a pas de sens de point de vue tagging.


Cette ontologie réutilise le vocabulaire prédéfini de web sémantique, ce qui la rend
compatible avec les standards existants. DublinCore
5

est utilisé pour représenté les données
d’une action de tagging, avec la subpropriété
dc

: data
. L’ontologie est
relie à FOAF pour
identifier le tagger grâce à la classe
foaf : Person
.

[3]
.

IV
.5

SCOT (Social Semantic Cloud of Tags)

L’ontologie SCOT
à pour but la représentation de la structure
et de la sémantique
des données
d’une action de tagging et d’offrir une i
nteropérabilité social des données provenant de
sources
hétérogène
.


L
a classe
de
s nuages de

tag
s

et
la classe des
tags

jouent un rôle pour être capable de
représenter le contexte sémantique et social de tagging. Puisque les deux classes incluent les
u
tilisateurs, les tags, et les ressources et des informations supplémentaires pour cla
rifier la
sémantique des tags.


scot:TagCloud

a

des propriétés qui décrivent l’utilisateur, l’espace de tag, le nombre de tags,
les posts, et les co
-
occurrences et le
urs fréquences.
La propriété
scot:contains

relie
scot:TagCloud


à un ensemble d’instance de
scot:Tag
.
scot:Tag

une sous
-
classe de
t
ags

:
T
ag

de
tag
ontology
,

décrie
un
tag

qu est agrégé


à partir de
s


activité
s

individuelle
s

de tagging.
Cette classe a
plusieurs propriétés
comme
scot:spelling_variant, scot:synonym

pour résoudre
l’ambiguïté des tags
. Ces propriétés s’appellent ‘propriétés linguistiques’

parce qu elles
s’intéressent à la représentation
de la signification des relations entre les tags de p
oint de vue
linguistique. En plus cette classe a des propriétés pour décrire les occurrences des tags

(
i
.
e
scot

: frequency
)
.
Ces propriétés
s’appelles ‘propriétés
numériques’.


Il est important de noter que
SCOT

utilise le modèle de Newman. La classe Tag
ging
représent
e

les tags, les ressources qui sont taggés
, et l’utilisateur qui
a
crée ces
tags



5

un système de méta donnée
s pour le classement bibliographique.

Catégorisation et sémantisation de flux d’api



22


(
tags:taggedBy
).
La classe
scot
:Tagcloud

est

connecté

aux instances de
tag

: taggings

par l
a
propriété

scot:tagging_activity

[3]
.


SCOT

permet l’échange de se
mantic tag metadata pour les réutilisés dans des applications
social et permet l’interopérabilité entre sources de données, services, ou agents dans un
espace de tagging. Ces caractéristiques sont nécessaires pour être capable d’identifier et
formaliser
une conception commune de l’activité de tagging à un niveau sémantique.

Exemple des données
SCOT

au format
RDF/XML

<scot:Tagcloud>

<scot:tagging_activity>

<tags:Tagging

rdf:about="http://blogweb.co.kr/scot/tagging/12">

<tags:taggedResource

rdf:resource=
"http://blogweb.co.kr/?r=1"/>

<tags:taggedBy

rdf:resource="http://blogweb.co.kr=sioc/user/1"/>

<tags:associatedTag

rdf:resource="http://blogweb.co.kr/tag/web"/>

<tags:taggedOn>2008
-
02
-
17</tag:taggedOn>

</tags:Tagging>

</scot:tagging_activity>

<scot:contain
s>

<scot:Tag rdf:about="http://blogweb.co.kr/scot/tag/web">

<tags:name>web</tags:name>

<scot:own_afrequency>113</scot:own_afrequency>

<scot:own_rfrequency>38.70</scot:own_rfrequency>

<scot:last_used>2008
-
01
-
30</scot:last_used>

<scot:aggregated_tag

rdf:reso
urce="http://blogweb.co.kr/tag/web"/>

<scot:tag_of rdf:resource="http://blogweb.co.kr/?1=6"/>

</scot:Tag>

<scot:contains>

</scot:Tagcloud>







Catégorisation et sémantisation de flux d’api



23














Figure
3
:
F
olksonomie

simplifie dans le modèle
SCOT
.

IV
.6
MOAT (
Meaning o
f a Tag
)

Le but de MOAT est de
fournir un modèle pour définir la signification des tags de une
manière automatique. Pour cela, MOAT défini




signification globale d’un tag
c'est
-
à
-
dire

la liste des significations qui peut
avoir un tag dans une
folksonomi
e

complète.



signification locale d’un tag
c'est
-
à
-
dire

la signification d’un tag d’une action
particulière de tagging.

En effet,

pour une instance, le tag ‘paris’ peut signifie selon l’utilisateur, le contexte et
d’autre facteur

: une ville en France, u
ne ville en USA ou même une personne. Lors que un
utilisateur l’utiliser dans une action de tagging, il a une signification locale, par exemple la
capitale français. Ainsi, MOAT étend le modèle de triplé habituel au modèle de quadruplé
suivant

:
Taggin
g (User; Resource; Tag; Meaning).
on utilisant MOAT, ces significations
(locale et globale) peuvent être définie par l’utilisateur son ambiguïté. MOAT fourni un
format compréhensible par la machine en utilisant une ontologie particulière. Il se basant sur
d
es URI des concepts de bases de connaissances comme
DBpedia
6
,
GeoNames
7

pour les
définir.



MOAT permet d'associer à un tag une URI. Une description de la notion du tag encodée en
RDF est associée à cette URI. Ainsi, le tag n'est plus seulement une ch
aîne de caractères, mais



6

http://dbpedia.org

7

http://geonames.org


Catégorisation et sémantisation de flux d’api



24


possède une véritable
signification

donné
e

par l'ensemble des triples RDF qui décrit la notion
utilisée en tag. Par exemple, si
on taggue

un

billet avec le tag « Web sémantique »,
on peut

l'associer à l'URI « http://dbpedia.org/res
ource/Semantic_Web » qui correspond à la
description de la notion de Web sémantique dans Dbpedia. Sont ainsi résolus, entre autres, les
problèmes liés à l'orthographe de la notion et à la langue, puisque les tags « Web sémantique
», « Semantic Web » ou « s
emweb » sont reliés à la même notion via l'URI.


A chaque

fois que
on associe

un tag à une URI, une notification est envoyée à un serveur.
Ainsi, d'autres personnes peuvent à leur tour associer cette URI à leur tag, et ainsi, partager
les mêmes notions. Le

serveur permet aussi de centraliser l'utilisation de l'URI. Ainsi, non
MOAT peut être intégré via une API dans n'importe quelle service qui offre la possibilité de
taguer

[12]
.

Exemple:


<tags:RestrictedTagging>

<tags:taggedResource rdf:resource="http:/
/apassant.net/drupal
-
5.5/?q=node/6"/>

<sioc:has_creator

rdf:resource=
"http://apassant.net/drupal
/?q=sioc/user/1%23_
user
/>


<tags:associatedTag

rdf:resource="http://tags.moat
-
project.org/tag/sparql"/>

<moat:tagMeaning

rdf:resource="http://dbpedia.org/reso
urce/SPARQL"/>

</tags:RestrictedTagging>

Chaque tag est lie à un ou plusieurs
instance de
moat:Meaning

qui représente le(s) sens du
tag sans aucun contexte. Chaque
meaning

doit avoir un URI unique qui l’identifie

(exp

:http://dbpedia.org/resource/Paris)
.

Et être lie à l’agent qui a définir le sens, relie à
FO
AF
8
. De cette manière, dans l’espace de
folksonomie
, le sens du tag est lie à l’URI des
gens qui l’ont
attribut Meaning (Tag) =
{
(Meaning;
{
User
}
)
}.












8

FOAF (Friend of a friend, que l'on peut traduire par « l'ami d'un ami ») est un vocabulaire RDF permettant de
décrire des personnes et les relations qu'elles entretiennent
entre elles

Catégorisation et sémantisation de flux d’api



25














Figure
4

:
S
ignification globale et locale des tags en MOAT


IV.7

Conclusion

Les techniques citées précédemment visent à tirer profit de la contribution des internautes à
l’indexation des ressources. Ce qui accrois et accélère la production de l’information
contrairement aux systèmes d’indexation classique qui s’inscrivent dans un processus plus
longs. L’inconvénient major des folksonomies est que les tags aux les mots clés sont en
langages naturels et l’utilisation des outils existants de web sémantique (ont
ologie, rdf, xml)
ne résous pas entièrement le problème

lie au nuance de langage naturel et l’incapacité des
machine à le comprendre

car les inconvénients relatifs à ces outils reste présents. Les
inconvénients de ces outils sont

:



Une ontologie est spéci
fique à un demain particulier,



Les ontologies sont incompatibles entre elles, si deux utilisateurs utilisent deux
ontologies différentes pour leurs bookmarks par exemple
SCOT

et
MOAT

ils ne
peuvent pas partagés ou échangés leurs tags il faut passer par d
es
transformations pour relier les concepts des deux ontologies c'est
-
à
-
dire définir
les relations entre les concepts des deux ontologies,



Les ontologies sont écrites en langage naturelle de plus les ontologies
considérées comme structures de relation ne
sont pas traductibles les unes aux
autres. OWL permet seulement l’exécution d’inférences automatiques au sein

Catégorisation et sémantisation de flux d’api



26


d’une même ontologie. La même remarque peut être faite au sujet de RDF, dont
la lacune tient à la formulation en langue naturelle du contenu des d
ocuments.



L’objectif initial de XML est de faciliter l'échange automatisé de contenus entre
systèmes d'informations hétérogènes (interopérabilité) donc il donne une
structure aux informations mais pas de sens. XML permet aux utilisateurs
d'ajouter une stru
cture arbitraire à leurs documents sans rien dire de la
signification des structures.


L’utilisation d’Ieml comme un méta
-
langage pour décrire les folksonomie va permettre de :




Regrouper

d’une façon automatique

les Tags qui représente le même concept.



Eff
ectuer des opérations logiques sur ce
s

groupe
s
.



Données un adresse aux

Tags


dans l’espace sémantique
ce qui permis d’effectuer des
opérations sémantiques (tri, décomposition, analyse, composition ..
.
).



On traduisant le flux dans le langage
IEML

cela faci
lite la traduction de ce flux dans
des langues différentes, car
IEML

peut être traduit dans n’importe quelle langue
naturelle. Ce la est très important car del.icio.us est un site social qui offre le partage
des données entre les utilisateurs et le fait d
e pouvoir traduire ces données
facilement

présent un grand intérêt.

V.
Conception

V.1
Diagramme des cas d’utilisation

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour donner une
vision globale du comportement fonctionnel d'un sy
stème logiciel. Un cas d'utilisation
représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un
système.









Catégorisation et sémantisation de flux d’api



27





















Figure
5

: Diagramme des cas d’utilisation.



1. Récupération du
flux

:

Précondition

:

-

L’application doit être connectée
à internent pour qu’
elle puisse
communiquée avec l’api del.icio.us.

-

L’utilisateur doit posséder un compte del.icio.us.


Début

:

La récupération du flux commence lorsque l’utilisateur choisi

le type de requête qu il veut
exécuter (type de données
à

récupérer) et la validation de son choix on cliquant sur la bouton
Affiche Flux
.


Traduction e du
flux

Récupération du
flux

Authentification

<<include>>

API de
l
.icio
.us

Parseur

Mise a jour du
compte Ieml

Supprimer mon
compte

Utilisateur

Représentation
graphique du flux

Catégorisation et sémantisation de flux d’api



28


Fin

:

Lorsque l’
API

d
el
.
icio
.
us répond à la requête envoyée

par l’application
.

Postcondition

:

Si l
a récupération
du flux est terminée avec succès. Le flux sera sauvegardé dans une base de
données ainsi que dans un fichier xml et il sera visualisé a
vec une table et un
camember


Déroulement normal

:

1.

l
’utilisateur saisie son login et son mot de passe del.icio.us.

2.

l’u
tilisateur

choisit le type de requête qu il veut effectué (le type du flux).

3.

l’utilisateur
choisit le type de graphique.

4.

l’utilisateur
clic sur le bouton
Afficher les données
.

5.

le système

envoie une requête à l’API del.icio.us.

6.

si le login et le mot de pas
se saisie sont corrects l’API delicious envoie le flux
au

système
.

7.

le système

compare le flux récupéré avec le flux sauvegardé.

8.

le système

créer les représentations et les affiches.


Variantes

:



login ou mot de passe incorrects

: si le login ou le mot de p
asse saisie par
l’utilisateur sont incorrects un message d’erreur est affiché, l’utilisateur doit
saisir le login et le mot de passe de nouveau.



Problème de connexion

: si le système n’arrive pas a ce connecté à l’API
del.icio.us, un message d’erreur s’a
ffiché. L’utilisateur doit vérifie qu il est
connecté à Internet.


2. Traduction du flux

:

Précondition


Il faut

y
avoir un flux déjà récupéré et stocké dans la base de données.


Début

L’utilisateur clic sur le bouton
T
raduction.

Fin

:

L’utilisateur re
vient à l’interface principale.

Postcondition

:

Des mises
à

jour des tables
de la base de données seront

effectués après que l’utilisateur ait
effectue de nouvelles traduction.

Catégorisation et sémantisation de flux d’api



29


Déroulement

:

1.

l’utilisateur clic sur le bouton
Tr
aduction

le système

consul
te le dictionnaire
pour traduire le flux.

2.

si
le système

trouve des traductions,
il

associe au tag le code
Ieml

ainsi que son
descriptif et
il

les affiche
s

dans la table
Tags
t
raduits
.

3.

si a un tag correspond plusieurs traductions l’utilisateur choisi la

traduction qui
lui semble pertinente on cliquant sur la traduction voulu dans la
table Tag avec
plusieurs
t
raduction
en suit il clic sur la bouton
Ajouter
.

4.

dans le cas où il n’existe pas de traduction correspondante
à

un tag. L’utilisateur
a deux moyens

pour traduire le tag

:



le dictionnaire Ieml, dans ce cas il clic sur le tag qu il veut traduire dans la
table
Tags sans
t
raduction

ensuit sur la traduction
Ieml

dans le
dictionnaire

et enfin il valide son choix en cliquant sur le bouton
Ajouter
.



La bouss
ole Ieml

et les tables des cycles: l’utilisateur peut utiliser la
boussole pour traduire un tag. Pour cela il choisi
t

la couche
à

partie du
quelle il va choisir la traduction (primitives, éventements, relation,…)
ensuit il choisi
t

le pôles (pragmatique,
sémantique, énergie…) et enfin la
traduction. A chaque fois que l’utilisateur clic sur la boussole les tables
des cycles
se mettent à jour

pour afficher que les mots correspondant aux
choix de l’utilisateur pour lui faciliter la traduction.

Invariants

:



lors de l’étape 1 si aucun mot ni sélection un message s’affiche invitant
l’utilisateur a sélectionné
une traduction.


3. Représentation graphique

:

Précondition


Il faut
qu’
il existe une sauvegarde du flux récupéré dans un fichier Xml ainsi qu une
trad
uction en
Ieml

de ce flux.

Début


L’utilisateur clic sur le bouton
Afficher le graphique

ou il sélection une représentation dans le
menu de l’arbre
Tags Traduits
.



Catégorisation et sémantisation de flux d’api



30


Fin

La construction de la représentation graphique à partir des expression
s

ieml parser

ou du flux
original (flux non traduit).

Postecondition

Si l’expression
Ieml

est valide un flux
XML

est retourné par le
StarPaser
, ce flux contient les
différents niveaux
Ieml

qui constituent cette expression.

Déroulement

1.


l’utilisateur clic sur le bouton
Graphique,

2.

le système crée une expression
Ieml selon une syntaxe spécifique,

3.

envoie l’expression
Ieml

au parser
Ieml

pour que
ce dernier la parse,

4.

à partir de réponse fournie par le parser
Ieml
, le système crée la représentation
graphique et
l’affiche.

Va
riante

Si l’expression
I
eml ni pas valide, un message d’erreur est affiché.


4. Mise à jour d
u

compte IEML

:

Précondition

:

L’utilisateur

doit être connecté à Internet et qu’il a des tags traduits.

D
é
but

Le service démarre à la demande c'est
-
à
-
dire lors
que l’utilisateur appuie sur le bouton «

Mise
à jour de compte Ieml

»



Fin

Le service se termine
lorsque touts les tags de l’utilisateur on été ajoutés au compte Ieml.

Déroulement



l’utilisateur clic sur le bouton
Mise à jour du com
p
te Ieml
,



le systè
me se connecte à l’API del.icio.us et mise à jour les posts avec
les tags traduits en Ieml.



Le système affiche un message indiquant à l’utilisateur la fin du
processus de mise à jour.

Postcondition

Pas de condition


Catégorisation et sémantisation de flux d’api



31


Invariants

:

Si le système n’arrive p
as à ce connecter
à l’API un message sera affiche pour indiqué à
l’utilisateur l’échec de la mise à jour.


5.
Suppression du compte

Postcondition

L’utilisateur

doit être connecter au système c'est
-
à
-
dire être déjà authentifie.

Début

Le service démarre
à la demande c'est
-
à
-
dire
l’utilisateur clic sur le bouton
Supprimer mon
compte
.

Fin

Après la suppression des données concernant l’utilisateur.

Postcondition

Mise à jour de la base de données.

Déroulement

1.

l’utilisateur choisi
t

de supprimer son compte,

2.

le système affiche un message indiquant à l’utilisateur la fin de la procédure de
suppression.

Invariants

:

Si

un problème ce produit au cours

de suppression un message indiquant à l’u
tilisateur que la
suppression n’
a peut s’effectue.

V.2
Diagramme de s
équence

1.

R
écupération de flux

La

récupération du flux s’effectue automatiquement, lorsque l’utilisateur s’authentifie
. L
e
système se connecte à l’API del.icio.us
et récupère les données concernant l’utilisateur. Ce
flux est sauvegarde dans un fichier XML
pour faciliter son utilisation.







Catégorisation et sémantisation de flux d’api



32

















Figure
6

: Diagramme de séquence pour la récupération du flux.


2.

T
raduction de flux

La

traduction est semi
-
automatique. Le système consulte d’abord le dictio
nnaire Ieml

s’il
trouve une traduction il l’associe au tag. S’il trouve plusieurs
traductions il propose à
l’utilisateur de choisir la traduction qui lui parait pertinent dans le cas ou il n’existe pas de
traduction le système propose à l’utilisateur de
choisir une traduction
dans le dictionnaire
ou à
p
artir des cycles.