• Aucun résultat trouvé

Partie II : Approche proposée

Chapitre 3 : Approches d’aide à la décision se basant sur le RàPC et les ontologies

4.5. Développement de l’ontologie

Comme nous l’avons vu dans la section 2.2.5, la littérature propose plusieurs méthodologies de construction d’ontologies. Certains auteurs ont proposé des méthodologies inspirées de leur expérience de construction d’ontologies (Fernandez M. et al, 1997), (Uschold M. et Grüninger M., 1996) et (Nagypál G., 2005).

Dans le cadre de notre travail, nous utilisons comme convenu une approche utilisée dans (Abou-Assali A. et al., 2008) qui s’inspire largement de la méthodologie Methontology de (Fernandez M. et al. 1997).

Le cycle de développement adopté décrit également dans (Maalel A. et al., 2011), fait intervenir quatre principales étapes consécutives (Figure 4.10).L’étape de formalisation dans Methontology (voir section 2.2.5.2) fait partie désormais de l’étape de conceptualisation :

Figure 4.10. Cycle de développement d’ontologie (Abou-Assali A. et al., 2008).

Spécification

Cette phase consiste à donner une description générale de l’ontologie. Deux aspects sont pris en considération :

- Les principes de conception de l’ontologie qui tiennent compte de recommandations telles la normalisation des noms, etc. (voir section 2.2.8) ;

- La spécification de l’ontologie qui décrit le but, la portée, et les concepts essentiels de l’ontologie.

Conceptualisation

Cette phase consiste à produire le modèle conceptuel de l’ontologie qui contient les concepts du domaine et leurs propriétés (voir section 4.4.2 : le modèle conceptuel) :

- La définition des concepts : il s’agit d’identifier les concepts à partir des ressources qui ont été spécifiées au départ dans la phase de spécification. Ceci à pour but de recenser les connaissances de domaine de la sécurité ;

- Hiérarchisation des concepts : il s’agit d’organiser les concepts dans une hiérarchie qui exprime la relation de Spécialisation/Généralisation entre les concepts.

Implémentation

Cette phase consiste à passer du modèle conceptuel à un modèle implémenté dans l’un des langages d’ontologie comme l’OWL, RDF etc. L’éditeur d’ontologies Protégé est utilisé alors pour implémenter notre ontologie. Parmi les raisons qui ont motivé le choix de Protégé, nous citons :

- Protégé est un éditeur open source et gratuit ;

- Il permet d’importer et d’exporter des ontologies dans les différents langages d’implémentation d’ontologies (RDF-Schéma, OWL, DAML, OIL,...etc.) ; - Il possède une interface modulaire, ce qui permet son enrichissement par des

modules additionnels (plugins) ;

- Il permet l’édition et la visualisation d’ontologies ;

contraintes.

Dans ce qui suit, nous allons utiliser quelques règles de transformation pour la traduction du modèle UML vers le modèle OWL. Ces règles ont été utilisées par Hadj-M’tir (Hadj-M’tir R., 2010) qui s’est basée sur l’article « La Création d’Ontologies Web Sémantique avec Protégé-2000 1 » :

- Une classe UML est traduite en une classe OWL ;

- Les attributs de classe UML sont traduits en propriétés OWL ;

- Les relations de généralisation UML sont traduites en relations de sous-classe OWL ;

- Pour les relations d’agrégation et de composition UML qui ne sont pas supportées par le langage OWL. Celles-ci pourront être traduites tout simplement en relations de sous-classe OWL de type « composé de » ou « partie de ».

Le tableau 4.1 présente les différentes transformations que nous venons de présenter.

UML OWL

Classe owl : Class

Nom de la classe rdf : ID

Relation de généralisation rdfs : subClassOf

Attribut de la classe owl : DatatypeProperty

Type d’attribut rdf : datatype

Relation binaire / relation unidirectionnelle

owl : ObjectProperty

Classe source d’une relation rdfs : domain Classe cible d’une relation rdfs : range

Cardinalités 1 owl : cardinality 1

0..* owl : minCardinality 0 0..1 owl : minCardinality 0 owl : maxCardinality 1 N owl : cardinality n M..N owl : minCardinality m owl : maxCardinality n

Tableau 4.1. Les différentes transformations du langage UML vers OWL (Hadj-M’tir R, 2010)

Chaque classe dans le modèle conceptuel (section 4.4.2) de l’ontologie est traduite à une classe OWL portant la même identification. Si nous prenons par exemple la classe «Concept », elle est définie avec OWL comme suit :

<owl:Class rdf:ID="Concept">

Pour la relation d’agrégation/composition, nous proposons de la représenter tout simplement sous forme d’une relation (de type « composé de » ou « partie de ») entre classe et sous-classe. Selon (Hadj-M’tir R., 2010), la sous-classe joue le rôle d’un composant ou d’une partie de la classe.

Prenons par exemple la relation d’agrégation donnée par la Figure 4.11 qui montre qu’une cause d’un accident potentiel peut être formée par un ou plusieurs causes liées à l’environnement.

Figure 4.11. Représentation d’une relation d’agrégation.

Cette relation peut être représentée avec OWL par une relation nommée « composé_de » entre la classe « Cause» et la sous-classe « Environnement » avec une cardinalité de type 1..N de côté de la sous-classe «Environnement » : <owl:Class rdf:ID="Cause"/> <owl:Class rdf:ID="Environnement"> <rdfs:subClassOf> <owl:Restriction> <owl:minCardinality rdf:datatype=http://www.w3.org/2001/XMLSchema#int>1</owl:minCardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="composé_de"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf rdf:resource="#Cause"/> </owl:Class> <owl:ObjectProperty rdf:about="#composé_de"> <rdfs:domain rdf:resource="#Cause"/> <rdfs:range rdf:resource="#Environnement"/> </owl:ObjectProperty>

Les figures 4.12 et 4.13 présentent successivement la hiérarchie des classes de l’ontologie dans l’éditeur protégé et à travers le plugin OWL-Viz :

Figure 4.13. Une partie de l’ontologie de domaine avec le plugin OWL-Viz (Maalel A. et al, 2011).

Maintenance :

Cette phase consiste à maintenir l’ontologie. Nous pouvons ainsi mettre à jour, ajouter et même supprimer des concepts. La maintenance désigne la modification apportée à l’ontologie après sa mise en œuvre, pour en corriger les fautes et améliorer son efficacité. Au cours de l’implémentation de l’ontologie, cet aspect de maintenance a été sollicité plusieurs fois ce qui a permis d’aboutir enfin à une ontologie exploitable.