0AA6D8C1d01

5/9/2018 0AA6D8C1d01 - slidepdf.com

http://slidepdf.com/reader/full/0aa6d8c1d01 1/12

OTES : Une ontologie pour l’annotation de servicesWeb sémantiques

Yassin Chabeb, Samir Tata et Djamel Belaid

TELECOM et Management SudParis, Institut TELECOM, UMR CNRS SAMOVAR

9 rue Charles Fourier, 91000 Evry, France

{Yassin.Chabeb, Samir.Tata}@it-sudparis.eu

Abstract. L’objectif de ce papier est de définir une ontologie technique de

services pour le langage de description de service Web sémantiqueYASA4WSDL. Cette ontologie intègre des concepts utiles du méta-modèle de

WSDL et des ontologies OWSL-S et WSMO. L’intégration de ces ontologies

est réalisée avec différentes techniques d’appariement conformément un

processus de mapping d’ontologies. L’ontologie résultante offre une couverture

sémantique des concepts spécifiques aux services Web.

Keywords: Services Web sémantique, Ontologie.

1. Introduction

Les travaux menés autour de la description des services Web utilisent de plus en plusles ontologies pour fournir une représentation de l’information sémantique, à la fois,

détaillée, riche et facile à manipuler par les machines. Afin de profiter des avantages

des ontologies et pour particulièrement améliorer la découverte et la composition de

services Web, nous avons développé le langage YASA4WSDL[1] qui étend le

langage SAWSDL. Cette extension vient combler un manque au niveau de la

spécification de la nature de l’annotation sémantique dans SAWSDL[11]. La

description YASA4WSDL est enrichie par des références portées sur des concepts

techniques de services tels que précondition, effet, opération, etc. Ces concepts

proviennent d’une ontologie dite « technique ». L’objectif de ce papier est de

continuer les travaux autour de YASA4WSDL par la définition d’une « Ontologie

Technique de Services ». Nous proposons de développer une telle ontologie par

l’intégration des concepts de services des ontologies de OWL-S[2] et WSMO[4], du

méta-modèle de WSDL[12] et de concepts retenus des différents travaux derecherche.

Ce papier est organisé comme suit. Dans la section 2, nous présentons une brève

revue des ontologies de services. La section 3 présente le contexte et les motivations

de notre contribution. La section 4 présente les techniques et systèmes de mapping

utiles pour l’intégration d’ontologies. Dans la section 5, nous montrons comment ces

techniques seront utilisées pour la construction d’une ontologie technique pour lelangage YASA4WSDL. La dernière section est consacrée à la conclusion et aux

perspectives de ce travail.



2. Revue des ontologies de services

Nous présentons dans ce qui suit une revue des approches de description et de

modélisation de services. Nous nous basons sur cette revue pour identifier le besoin

de définition d’une ontologie de services.

2.1. OWL-S

OWL-S [2, 3, 4] est un langage de description et une ontologie OWL[5] de

services Web. La structuration de l’ontologie supérieure de OWL-S (voir Fig.2) est

motivée par la nécessité de fournir trois types d’information essentiels pour un

service, à savoir :

- Que fait le service : cette information est donnée dans le Service Profile pardes propriétés : serviceName, textDescription (brève description de ce que le

service offre et requiert), ContactInformation (responsables du service).

- Comment utilise-t-on le service : cette information est fournie dans le Service

Model. Trois types de processus existent : les processus atomiques

(AtomicProcess), simples (SimpleProcess) et composites (CompositeProcess).

Un AtomicProcess représente le niveau le plus fin pour un processus et

correspond à une action que le service peut effectuer en une seule interaction

avec le client. Les CompositeProcess sont décomposables en d’autres

processus (composés ou non) ; Un SimpleProcess est utilisé pour fournir une

vue d’un processus atomique ou une représentation simplifiée d’un processus

composite ;

- Comment accède-t-on au service : cette information est donnée dans le Service

Grounding. Celui-ci indique comment accéder concrètement au service et

fournit les détails concernant les protocoles, les formats de messages et les

adresses physiques.

2.2. WSMO.

WSMO[4] est une ontologie de services basée sur WSMF[6, 4] (Web ServiceModelling Framework) qui spécifie les éléments principaux pour décrire les services

Web sémantiques tels que ontologies, objectifs, services Web et médiateurs. Les

ontologies définissent la terminologie, utilisée par les autres éléments, en termes de

concepts, relations, fonctions, instances et axiomes. Les buts indiquent ce que

l’utilisateur attend du service. La description du service Web définit les

fonctionnalités offertes par le service. Les médiateurs lient les différents éléments afin

de permettre l’interopérabilité entre les composants hétérogènes. Le langage

WSML[7] est utilisé pour décrire formellement tous les éléments de WSMO.

2.3. Autres méta-modèles

Il existe d’autres méta-modèles qui proposent des concepts dont certains ne

peuvent pas être toujours renseignés et d’autres qui sont proches des concepts offerts



par le méta-modèle de WSDL, SAWSDL, OWL-S et WSMO. Dans [13], les conceptsdu vocabulaire de “Composite Capabilities/Preference Profiles” (CC/PP)[14] est

étendu afin d’ajouter plus d’information sémantique dans la description. Ce standard

proposé par la W3C s’est doté de nouveaux concepts (type de service, qualité de

service, location, etc.). Par ailleurs, il existe d’autres de sémantique de services telle

que celle proposée dans [15, 16], à travers la « DIANE Service Description » (DSD)

et les « DIANE Elements » (DE). Ce travail met en pratique des concepts additionnels

que WSMO et OWL-S ne mettent pas en œuvre. Dans [16, 17], les auteurs décrivent

comment DSD utilise une ontologie afin d’exprimer des concepts tels que la

précondition et l’effet.

3.

Contexte et motivations

Nous présentons dans cette section le contexte de notre contribution à savoir le

langage YASA4WSDL et nous identifions les besoin de la définition d’une ontologie

de service pour YASA4WSDL.

3.1. YASA4WSDL

L’idée de YASAWSDL est d’étendre SAWSDL afin d’améliorer l’expressivité de

la description de service. Dans SAWSDL et pour chaque élément WSDL, on peut

référencer plusieurs concepts d’une ontologie de domaine. Mais, il n’y aurait aucune

spécification de la nature des informations sémantiques. L’annotation d’une opération

par un concept d’un domaine métier est une annotation à gros grain, puisque elle nedistingue pas s’il s’agit d’une précondition, d’un effet ou un d’un résultat de

l’opération. Ainsi, nous avons proposé YASA4WSDL qui ajoute dans le système

d’annotation des descriptions de service Web SAWSDL, un nouvel attribut nommé

serviceConcept. Cet attribut permet l’annotation de plusieurs aspects d’un élément

WSDL en utilisant des concepts techniques d’une ontologie de service qui

correspondent des concepts d’une ontologie d’un domaine métier référencés dans

l’attribut « modelReference » de SAWSDL.

Prenons l’exemple de Fig. 1. Nous utilisons deux types d’ontologie. La première

ontologie est dite « ontologie technique ». Elle décrit la sémantique de plusieurs

concepts des services Web (ex. precondition et effect ). La deuxième ontologie est dite

« ontologie de domaine ». Dans l’exemple de Fig.1, c’est une ontologie de réservation

de vols. L’exemple présente l’annotation sémantique d’une opération nommée

reserveFlight . L’attribut modelReference référence deux concepts de l’ontologie dedomaine : validFlightInfo et reservationInfo. L’attribut serviceConcept offre la

capacité de distinguer les rôles joués par les deux concepts validFlightInfo et

reservationInfo, référencés par l’attribut modelReference. Pour cela, serviceConceptspécifie que ces deux concepts correspondent respectivement aux concepts de

services : precondition et effect . L’ordre est important, puisque on associe le premier

concept technique ( precondition) au premier concept de domaine (validFlightInfo), le

second concept technique au second concept de domaine, et ainsi de suite.



Fig 1. Système d’annotation dans YASA4WSDL

En plus du renforcement de l’expressivité de la description sémantique, un autre

avantage est à souligner dans cette approche : dans YASA4WSDL, nous concevons

une ontologie technique de services avec la possibilité de l’étendre à tout moment :

par de nouveaux concepts, en intégrant de nouveaux élément de description ou des

concepts plus précis, etc. L’avantage offert par l’approche est que ces extensions et

ces enrichissements n’auront aucun impact sur le système d’annotation. L’ontologie

ne sera pas limitée. Ainsi, cela le système continuera à être indépendant, d’une part,

du langage et l’ontologie assurant la représentation du domaine, et d’autre part, du

langage et l’ontologie assurant la représentation de la sémantique des services Web.

Cet aspect de YASA4WSDL offrira une flexibilité à la communauté des développeurs

afin de choisir leurs ontologies techniques et leurs langages de représentation

sémantique favoris, ceci leurs permettra de réutiliser leurs ontologies techniques etd’annoter les descriptions avec plusieurs ontologies.

3.2. Besoin d’une ontologie technique de services

Les principaux objectifs des approches de description sémantique de service sont

l’automatisation et l’amélioration de la découverte, la composition et l’invocationservices. Nous observons que ces objectifs sont atteints par OWL-S et WSMO

puisque ces approches décrivent d’une façon ou d’une autre les profils de services

pour la découverte, le comportement des services pour la composition et le grounding

pour l’invocation. Néanmoins, OWL-S et WSMO, sont des approches qui dépendent

de langages de description d’ontologies spécifique, OWL et WSML, se limitent à un

ensemble de concepts bien définie.SAWSDL s’intéresse à la découverte et l’invocation automatique des services mais

il ne s’occupe pas de la composition. Il permet d’utiliser tous types d’ontologies

(OWL, WSML, UML, etc.) et étant proche de WSDL, SAWSDL ne nécessite pas

beaucoup d’efforts pour les développeurs habitués à WSDL. Par contre SAWSDL ne

permet ni la composition ni la découverte de service basée sur propriétés non

fonctionnelles. Ce défaut est principalement du de la limite d’expressivité du méta-modèle de WSDL. Ce constat est à l’origine de la proposition de YASA4WSDL qui

permet d’annoter une description WSDL non seulement par des concepts métier mais

aussi par des concepts de services définis dans une ontologie de technique de service.



YASA4WSDL étant une extension de WSDL permet d’utiliser tous typesd’ontologies et facile à utiliser par les développeurs habitués à WSDL. Par contre,

YASA4WSDL permettra l’automatisation et l’amélioration de la découverte, la

composition et l’invocation services, si l’ontologie de technique de services utilisés

par l’annotation contient des concepts permettant ces opérations tels que le profil, le

comportement et le grounding de service. Ainsi l’objectif de ce papier est de définir

une ontologie technique de services pour YASA4WSDL qui intégrera des concepts

utiles du méta-modèle de WSDL, de l’ontologie supérieur OWSL-S et de WSMO.

4. Techniques de mapping

Les correspondances ou « mappings » sont les relations entre les éléments de deuxreprésentations (ontologies, schémas de bases de données, etc.), indiquant une

similarité relative selon une mesure donnée [10]. Le « matching » ou appariement est

le processus de définition d'un ensemble de fonctions permettant de spécifier des

correspondances entre les termes[8]. Ceci peut être réalisé par un ou plusieurs

méthodes de comparaison dites « matcher » ; ce sont des fonctions utilisées pour

calculer la distance entre deux entités. Les matchers sont les techniques combinées

dans le processus de matching.

Les différentes méthodes d’appariement de concepts (matchers) sont organisées

selon la classification de la Fig.2 qui montre ces matchers suivant le type d’entités à

comparer et la méthode utilisée pour calculer la similarité. Par exemple, le matcher

syntaxique compare deux concepts suivant leurs égalité de leur noms (ex. les labels

des concepts).

Fig. 2. Classification des techniques de matchings individuelles.

Pour intégrer les ontologies de service, nous nous basons sur le système

d’appariement OMIE[18] qui propose une approche faisant face à certaineslimitations des systèmes évoqués précédemment. OMIE ne nécessite pas

l’introduction préalable d’un ensemble d’appariements pour différents concepts des

deux ontologies à apparier, contrairement à certains systèmes (ex. Anchorprompt[9]).

OMIE réduit l’implication directe de l’utilisateur dans le processus de validation,



alors que dans les systèmes existants, l’utilisateur intervient directement pour validerou refuser les mapping proposés.

Afin de produire un mapping entre deux ontologies, OMIE exécute un processus qui

contient plusieurs étapes, chaque étape comprend une ou plusieurs mécanismes de

comparaison :

- Etape 1. (Calcul des similarités) : les appariements à base des comparaisons

syntactiques et linguistiques sont appliqués sur des couples de concepts, afin

de mesurer leur similarité terminologique.

- Etape 2. (Combinaison et génération des mappings candidats) : les valeurs de

similarité retournées dans l'étape précédente sont alors combinées afin deproduire une seule valeur de similarité.

- Etape 3. (Filtrage des hypothèses de mapping): une fois l’ensemble deshypothèses de mapping est généré, des méthodes de filtrage sont employées

afin d'éliminer les hypothèses de mapping les moins pertinentes. Ces méthodes

sont basées sur les relations structurales et sémantiques entre les concepts etsur les mapping déjà validés. Un seuil est également utilisé pour écarter des

hypothèses de mapping contient une valeur de similarité très basse.

- Etape 4. (Le processus de validation) : l’ensemble des hypothèses de mapping

fournies après la phase de filtrage sera ordonné suivant les valeurs de

similarité. Ensuite l’utilisateur choisi la plus pertinente à sa requête, ce retour

de l’utilisateur (appelé feedback ) sera sauvegardé pour le réutiliser.

5. Construction de l’ontologie OTES

Pour construire l’ontologie qui intègre les ontologies OWL-S, WSMO, et le méta-

modèle WSDL, nous commençons par effectuer le mapping des ces différentes

ontologies. Cela correspond à identifier les correspondances entre les entités des

ontologies à apparier. Pour le mapping, nous utilisons des techniques de matching

pour calculer la meilleure correspondance entre des couples d’entités. Elles peuvent

maximiser la détection du nombre des couples similaires et réduire le nombre de ceuxqui sont dissimilaires. Table 1 présente les principaux concepts à mapper.

5.1. Calcul de similarité et mapping

Matching terminologique. Après une normalisation des termes (suppression decaractère inutile, normalisation des mots composés, etc.), nous adoptons ici la

définition du matcher à base de la distance de Levenshtein. Elle mesure la similaritéentre deux chaînes de caractères et de savoir précisément le nombre minimal

d'insertions et de suppressions de caractères requis pour transformer une chaine en

une autre. Table 2 présente le résultat de matching entre quelques concepts de Table 1

(le tableau n’indique que les valeurs d’ordre des longueurs des termes sinon « ! » pour

les grandes valeurs et « # » pour les concepts d’une même ontologie).



Table 1. Principaux concepts à mapper.

OWL-S WSMO WSDL Autres

Effect Choreography Description Comment

ServiceModel Orchestration InterfaceFault CategoryPrecondition Capability Interface Community

Process Goal InterfaceOperation Version

AtomicProcess Interface Operation StatusSimpleProcess Effect Service Business

CompositeProcess Assumption BindingOperation Actor

Parameter Service Endpoint ProviderProfile Postcondition Input Constraint

Local Precondition BindingFault Capacity

Participant WebService Binding PortInput Documentation

Output OutputResult

Service

Table 2. Extrait des résultats après application de matching terminologique.

InputOWLS ServiceWSDL InterfaceWSMO Capacity OutputOWLS Result Precondition …

Input WSDL 0 ! ! ! 5 7 ! …InterfaceWSDL 8 # 0 ! ! ! ! …Precondition # ! ! ! # # 0 …Postcondition ! ! # ! ! ! 5 …InterfaceFault ! # 5 ! ! ! ! …WebService ! 3 # ! ! ! # …Capability ! ! # 4 ! 12 # …OutputWSDL 5 # ! ! 0 8 ! …

. . . . . . . . . . . . . . . . . . . . . . . . …

On affecte au matcher un degré de confiance Conf η 1 = 1 et on définit des règles pour

calculer la valeur de similarité SV retournée pour un couple de concepts comparables

(0 pour ! et #). Table 3 résulte de l’application des règles (2), (3) et (4) :

SV=1 ssi Distance=0 (2)

SV=1/1+Distance-Min(nom(C1),nom(C2)) si Distance> Min(nom(C1),nom(C2)) (3)

Sinon SV=0.7 (4)

Table 3. Extrait des résultats après application de matching terminologique.


Input WSDL 1 0 0 0 0.7 0.5 0 …InterfaceWSDL 0.25 0 1 0 0 0 0 …Precondition 0 0 0 0 0 0 1 …Postcondition 0 0 0 0 0 0 0.7 …InterfaceFault 0 0 0.7 0 0 0 0 …WebService 0 0.7 0 0 0 0 0 …Capability 0 0 0 0.7 0 0.1 0 …OutputWSDL 0.7 0 0 0 1 0.5 0 …. . . . . . . . . . . . . . . . . . . . . . . . …



∑=

i

iConf ConfHp η

Table 4. Extrait des résultats après application de matching linguistique.


Input WSDL 1 0 0 0 0 0 0 …InterfaceWSDL 0 0 1 0 0 0 0 …Precondition 0 0 0 0 0 0 1 …Postcondition 0 0 0 0 0 0 0 …InterfaceFault 0 0 0 0 0 0 0 …WebService 0 0.5 0 0 0 0 0 …Capability 0 0 0 1 0 0 0 …OutputWSDL 0 0 0 0 1 0 0 …

Matching linguistique à base des informations auxiliaires. Nous adoptons ici la

définition du matcher à base du dictionnaire WordNet : nous nous basons sur les liens

sémantiques entre les termes en langage naturel pour calculer la valeur de similaritéSV : les synonymes sont des entités équivalentes (SV=1), les hyponymes sont des

entités recouvrantes (SV=0.5) sinon pas de lien (SV=0). On affecte au matcher un

degré de confiance Conf η1=2. Table 4 présente les valeurs de similarités.

Combinaison des matchers et génération des hypothèses de mapping. Nous

utilisons la combinaison parallèle des matchers, le résultat des différents matchersindividuels (listés ci-dessus) sera combiné (voir Table 5) pour identifier un seul

mapping candidat (appelé aussi hypothèse de mapping) entre chaque couple de

concepts. Chacune de ces hypothèses de mapping (Hpi) contient cinq-tuples :

Hp <R, c, c’, ConfHp, SVHp> avec :

• R : Relation identifiée par les matchers entre le couple de concepts : c et c’,

• Le degré de confiance de l’hypothèse de mapping Hp est :

• Valeur de similarité produite par combinaison des matchers

∑

∑ ×

=

i

i

iConf

iSV iConf

SVHpη

η η

Table 4. Extrait des résultats de la combinaison des valeurs de similarités.


Input WSDL 1 0 0 0 0.2 0.1 0 …InterfaceWSDL 0.25 0 1 0 0 0 0 …Precondition 0.08 0 0 0 0 0 1 …Postcondition 0 0 0 0 0 0 0.2 …InterfaceFault 0 0 0.2 0 0 0 0 …WebService 0 0.56 0 0 0 0 0 …Capability 0 0 0 0.9 0 0.03 0 …

OutputWSDL 0.2 0 0 0 1 0.1 0 …

Le mapping est basé sur ce tableau puisque les hypothèses de mapping en résultent :

Hp<≡,Input,Input,3,1>

Hp<≡,Input,Result,3,0.1>

Hp<≡,Input,Output,3,0.2>Hp<≡,Interface,Input,3,0.25>

Hp<≡,Interface,Interface,3,1>

Hp<≡,Precondition,Input,3,0.08>

Hp<≡,Precondition,Precondition,3,1>

Hp<≡,Postconditon,Preconditon,3,0.2>

Hp<≡,InterfaceFault,Interface,3,0.2>

Hp<≡,WebService,Service,3,0.56>Hp<≡,Capability,Capacity,3,0.9>

Hp<≡, Capability,Result,3,0.03>

Hp<≡, Output,Result,3,0.1>

Hp<≡, Output,Output,3,1> . . .



Matching sémantique. Nous utilisons aussi les trois matchers sémantiques : (i) lematcher sémantique Top-Down (voir Fig.3), (ii) le matcher sémantique Bottom-up et

(iii) le matcher sémantique de voisinage. Nous définissons les variables utilisées dans

les algorithmes par :

• R est la relation sémantique définie dans les deux ontologies O et O’ ;

• |V-Child(c)|R= Ndr-OfSem-Child(c,R) est le nombre des concepts fils reliés au

concept c par la relation non-symétrique R, (c.-à-d., la partie ‘Rang’ de la relationR) ;

• |V-Father(c)|R= Ndr-OfSem-Father(c,R) est le nombre des concepts pères reliés

au concept c par la relation non-symétrique R, (c.-à-d., la partie ‘Domain’ de la

relation R) ;

• |V(c)|R= Ndr-OfSem-Concept(c,R) est le nombre des concepts reliés au concept cpar la relation symétrique R ;

• ConfSem-R représente le degré de confiance de la relation sémantique R.

Fig. 3. Matcher sémantique « Top-Down » d’une relation non-symétrique.

Exemple. On a Hp <≡,Capability,Result,3,0.03>, Map<≡,Effect,Effect,3,1>,et Conf sem-R=1 et R:hasEffect. On applique la règle du matcher sémantique :

On a : C5:Effect, D4:Effect, Conf η1=1, SV1=1, C3:Capability, D2:Result,

Conf η2=2, SV2=0.03

Donc : SV2 = SV2 + (SV1 / min(1,1))= 0.03 + 1/1 = 1.03

Conf η2 = Conf η1+ Conf sem-R = 3 + 1 = 4

d’où, Hp<≡,Capability,Result,4,1.03>

Matching structurel. Chacune des règles, du matching structurel, donnera une idéesur la similarité entre deux entités, mais typiquement aucune d’elle ne produit le

mapping toute seule. Chaque règle appliquée nous fournit un poids de similarité entre

deux entités comparées (concept ou relation). Un seuil est défini sur les valeurs de la

similarité pour identifier la correspondance ou la non-correspondance.

Afin d’apporter plus de précision au niveau des valeurs de similarité, nous utilisons

aussi les deux matchers structuraux : « Top-Down » et « Bottom-up » qui ont les



mêmes principes des règles du matching sémantique, sauf qu’on s’intéresse à la

relation hiérarchique entre les concepts. La propriété transitive de la relation

hiérarchique mène à définir des fils (respectivement des pères) directs et d’autres

indirects. Faute d’espace, nous ne pouvons présenter en détails ces règles.

5.2. Filtrage

Il existe trois types de filtres : structuraux, sémantiques et à base de seuil :

− Avec les filtres structuraux, nous pouvons utiliser les mappings générés

précédemment (pour réaliser un croissement avec un mapping), ou faire un

croissement inter-hypothèses ou finalement éliminer les divergences avec le

mapping existants.

− Avec les filtres sémantiques, nous exploitons également les relationssémantiques des ontologies basant sur leurs propriétés. Par conséquent, nous

utilisons deux filtres sémantiques selon le type de la relation : symétrique ou

non-symétrique. Nous ne présentons pas ces règles en détails par souci

d’espace.

− Avec les filtres à base de seuil, nous définissons un seuil (Th) sur les valeurs

de similarités au-dessous desquels les hypothèses ne sont pas considérées

(voir (5)), la valeur de Th pourrait être modifiée par l’administrateur du

système à travers un interface graphique.

Pour chaque Hp <≡ ,c,d,Conf,SV> SI (SV<Th) ALORS (éliminer Hp) ( 5)

Finalement nous appliquons l’ensemble des filtres nécessaires sur les hypothèses ;

Par exemple, dans un filtre à base de seuil, nous trions en ordre décroissant les

hypothèses selon la valeur de leurs SV et nous éliminons les hypothèses de mapping

les moins pertinentes. A ce stade, il ne reste qu’à valider le mapping et exporter

l’ontologie résultat. Nous n’avons pu insérer l’arbre de l’ontologie technique de

services vu la taille de la figure.

Le filtrage et la validation des hypothèses de mapping permettent de générer desmappings :

Map<≡,Input,Input>

Map<≡,Interface,Interface>

Map<≡,Precondition,Precondition>

Map<≡

,WebService,Service>Map<≡,Capability,Capacity>

Map<≡,Output,Result>

Map<≡,Output,Output>

Voici la liste des principaux concepts de l’ontologie technique après validation des

mappings :

Effect ServiceModel Precondition



Process

AtomicProcess

SimpleProcess

CompositeProcess

Parameter

Profile

Local

Participant

Input

Output

Result

Service

Choreography

Orchestration

Capability

Goal

Interface

Effect

Assumption

Postcondition

Description

InterfaceFault

InterfaceOperation

Operation

BindingOperation

Endpoint

BindingFault

Binding

Documentation

Comment

Category

Community

Version

Status

Business

Actor

Provider

Constraint

Port

6. Conclusion et perspectives

Dans ce papier, nous avons présenté une brève revue des ontologies de services et

les techniques et systèmes de mapping, utiles pour l’intégration d’ontologies. Nous

avons construit une ontologie technique de service comment intégration des

ontologies OWL-S, WSMO et le méta-modèle WSDL et d’autres concepts, à travers

l’identification des correspondances entre les concepts de ces différentes ontologies.

Dans YASA4WSDL, l’annotation de la description du service, peut être faite

« manuellement » ou à travers une interface graphique afin d’assister l’utilisateur en

important les ontologies et en exposant les concepts des ontologies, tout en exigeant

des contraintes d’annotation (vu que tout élément descriptif ne peut être annoté par

n’importe quel concept, d’où un ensemble de contraintes d’annotation qui reste àdéfinir et à implémenter avec l’interface d’annotation). Le travail que nous sommes

entrain de mener consiste à formaliser ces contraintes et de mettre en œuvre un outil

d’aide à l’annotation des descriptions YASA4WSDL.

Références

1. Chabeb, Y., Tata, S. : Yet Another Semantic Annotation for WSDL (YASA4WSDL). In :

Proceedings of the IADIS WWW/Internet 2008 Conference. (2008) 437–441

2. Martin, D., Paolucci, M., Mcilraith, S., Burstein, M., Mcdermott, D., Mcguinness, D., Parsia,

B., Payne, T., Sabou, M., Solanki, M., Srinivasan, N., Sycara, K. : Bringing Semantics to

Web Services : The OWL-S Approach, Springer (2004) 26–42

3. Claro, D.B., Albers, P., Hao, J.K. : Approaches of Web Services Composition - Comparison

between BPEL4WS and OWL-S. In : ICEIS (4). (2005) 208–213

4. Lara, R., Roman, D., Polleres, A., Fensel, D. : A Conceptual Comparison of WSMO and

OWL-S. In : ECOWS 2004. Volume 3250 of LNCS., Springer (2004) 254–269

5. Smith, M.K., Welty, C., McGuinness, D.L. : OWL Web Ontology Language Guide.

http ://www.w3.org/TR/2004/RECowlguide20040210/ (2004)

6. Fensel, D., Bussler, C. : The Web Service Modeling Framework WSMF. Electronic

Commerce Research and Applications 1 (2002) 113–137

7. de Bruijn, J., al. : The Web Service Modeling Language WSML. WSML Final Draft.

http ://www.wsmo.org/TR/d16/d16.1/v0.21/ (2005)



8. He, B., Chang, K.C.C. : Statistical Schema Matching across Web Query Interfaces. In :

SIGMOD Conference. (2003) 217–228

9. Noy, N., Musen, M. : Anchor-PROMPT : Using non-local context for semantic matching. In

: In Proc. IJCAI 2001 workshop on ontology and information sharing. (2001) 63–70

10. Klein, M.C.A. : XML, RDF, and Relatives. IEEE Intelligent Systems 16 (2001) 26–28

11. Farrell, J., Lausen, H. : Semantic annotations for WSDL and XML schema.

http ://www.w3.org/TR/2007/REC-sawsdl-20070828/ (2007)

12. W3C : Web Services Description Language (WSDL). http ://www.w3.org/TR/wsdl/ (2001)

13. Li, H., Wang, H. : A Method of Service Description and Discovery in Pervasive Computing

Environments. Pervasive Computing and Applications, 2006 1st International Symposium

on (2006) 604–607

14. Klyne, G., al. : Composite Capability/Preference Profiles (CC/PP) : Structure and

Vocabularies 1.0. http ://www.w3.org/TR/CCPP-struct-vocab/ (2004)

15. Klein, M., Konig-Ries, B., Mussig, M. : What is needed for semantic service descriptions ?

A proposal for suitable language constructs. Int. J. Web Grid Serv. 1 (2005) 328–36416. Kuster, U., Konig-Ries, B. : Semantic Mediation between Business Partners - A SWS-

Challenge Solution Using DIANE Service Descriptions. In : WI-IATW ’07 : Proceedings of

the 2007 IEEE/WIC/ACM International Conferences on Web Intelligence and Intelligent

Agent Technology -Workshops,Washington, DC, USA, IEEE Computer Society (2007)

139–143

17. Klan, F. : Context-aware service discovery, selection and usage. In : 18th GIWorkshop on

the Foundations of Databases, Wittenberg, Saxony-Anhalt. (2006)

18. Elbyed, A. : Ontologie mapping pour l’intégration des données hétérogènes. PhD thesis,

TELECOM et Management SudParis, Evry, France (2008)

0AA6D8C1d01

Documents

Transcript of 0AA6D8C1d01