# G-OWL: Vers un langage de modélisation graphique, polymorphique et typé pour la construction d'une ontologie dans la notation OWL

Michel Héon, Roger Nkambou

► To cite this version:

Michel Héon, Roger Nkambou. G-OWL: Vers un langage de modélisation graphique, polymorphique et typé pour la construction d'une ontologie dans la notation OWL. IC - 24èmes Journées francophones d'Ingénierie des Connaissances, Jul 2013, Lille, France. hal-01104001

HAL Id: hal-01104001

https://inria.hal.science/hal-01104001v1

Submitted on 15 Jan 2015

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
# G-OWL : Vers un langage de modélisation graphique, polymorphique et typé pour la construction d'une ontologie dans la notation OWL

Michel Héon¹, Roger Nkambou²

¹Université du Québec à Montréal, Montréal, Canada
heon@cotechnoe.com

²Université du Québec à Montréal, Montréal, Canada
nkambou.roger@uqam.ca

**Résumé** : Le Web Ontology Language (OWL) standardisé par le W3C a pour objectif d'offrir un langage de conception d'ontologies pour le web sémantique. L'ingénierie d'une ontologie est une activité complexe nécessitant une habilité peu accessible à des experts de contenu. En revanche, pour modéliser du contenu métier, la modélisation graphique semi-formelle est une technique souvent employée pour offrir un outil de représentation des connaissances à des experts de contenu peu familier au processus de conception d'une ontologie. Dans cet article, nous présentons de quelle manière l'usage du polymorphisme et le typage des symboles du vocabulaire graphique permettront de concevoir le langage G-OWL, un langage graphique qui vise à permettre la représentation de connaissances métiers dans le formalisme OWL pour des non-experts de l'ingénierie ontologique.

**Mots-clés** : OWL, ontologie, modèle graphique, langage ontologique graphique, langage graphique, ontologie graphique, cartographie de connaissances, web sémantique.

## 1 Introduction

La construction d'une ontologie de type OWL est une activité formelle difficilement accessible à un expert de contenu. En revanche, la modélisation graphique semi-formelle est une solution souvent envisagée pour permettre à des experts de contenu de représenter graphiquement leur connaissance métier. Pensons par exemple à l'utilisation des langages tels que : le *Mind Mapping* (Buzan & Buzan, 1994), le *Concept Mapping* (Novak & Cañas, 2006) ou encore le langage de *Modélisation par Objets Typés* (MOT) (Paquette, 2010) qui ont su démontrer leur efficacité dans la représentation de connaissances. Le langage graphique semi-formel est parfois employé pendant l'étape de conception d'un système (Rumbaugh *et al.*, 1999) ou encore pour favoriser le transfert de connaissances dans les organisations (Basque & Pudelko, 2010) ou
l'apprentissage dans des situations éducatives (Kinshuk et al., 2008; Paquette, 2002). Il est aussi employé pour susciter les échanges pendant une séance de remue-méninges (Buzan & Buzan, 1994) ou plus simplement pour représenter graphiquement un énoncé. Certaines études (Basque & Pudelko, 2010) tendent à démontrer que l'usage de langage semi-formel facilite l'explicitation de connaissances tacites puisque la spontanéité n'est pas bloquée par une charge cognitive trop lourde associée à une formalisation de la pensée. Le désavantage de l'utilisation d'un langage semi-formel est que la carte de connaissances produite avec ce langage ne peut pas être directement exploitée par un système automatique de traitement de la connaissance sans que celle-ci soit préalablement désambiguïsée.

Deux besoins sont ainsi confrontés. D'une part, le besoin de l'expert de contenu qui aspire à l'utilisation d'un langage de représentation de connaissances qui soit expressif, simple d'usage et qui stimule sa créativité, et d'autre part, le besoin du cogniticien, d'utiliser un langage de représentation de la connaissance de degré formel pour la conception de systèmes logiciels intelligents ou d'une mémoire formelle d'entreprise.

Dans cet article, nous proposons un langage qui vise à réduire l'apparent espace qui sépare le besoin de l'expert de contenu de celui du cogniticien. Le but de G-OWL (acronyme de *Graphic OWL*) est de fournir un langage, qui est : graphique, simple d'usage (en comparaison avec l'usage directe du OWL) et qui permet de produire une ontologie formelle dans le formalisme de l'OWL.

## 1.1 Historique

Actuellement, quelques langages permettent l'édition graphique d'ontologies formelles. L'*Ontology Definition Metamodel* de Gašević et al. (2006) et son implantation informatique l'*EMF Ontology Definition Metamodel (EODM)* (Yang, 2006) sont des métamodèles de représentation d'OWL dans le formalisme UML. Les éléments syntaxiques d'OWL sont cartographiés en UML par l'attribution de « *stéréotypes* » aux classes et aux relations utilisées. Le modèle UML est ensuite converti en OWL.

De même, dans le domaine des graphes conceptuels (GC), les travaux de Sowa (1999) ont permis la mise au point d'un langage formel et graphique de représentation d'ontologies. Le GC appuie la représentation graphique d'ontologie sur la logique des prédicats du premier ordre qui va bien au-delà de la logique des descriptions (Baader et al., 2007) sur laquelle se fonde l'OWL. À l'instar du graphe *entité-relation* de Chein (2008), une notation en graphe du OWL couramment utilisée consiste à représenter la classe et l'individu en entité du graphe et représenter le prédicat en relation du graphe (voir l'exemple de la figure 1a, section 4).
En fait, de notre point de vue, cette représentation en graphe comporte
quelques manquements importants : d'abord, elle ne met pas en évidence
la distinction marquée entre : des entités et des relations qui sont propres
au langage ontologique, des entités et des relations associés à la
sémantique du domaine (par ex. : *rdf:type versus vin:hasColor*). Ensuite,
cette notation est mal adaptée à la représentation signifiante des
restrictions ou des axiomes.

Bien que l'ODM, le GC et le graphe entité-relation soient des
langages de représentation d'une ontologie de type graphique, ils ne sont
pas des langages simples d'usage pour un non-informaticien. À vrai dire,
leur usage fondé sur la représentation formelle du domaine du discours
impose, à l'utilisateur, la connaissance approfondie de l'ingénierie
logicielle et de la modélisation formelle.

D'un autre côté, il existe des méthodes et des outils qui visent à
construire une ontologie reposant sur la représentation graphique et semi-
formelle de la connaissance. Par exemple, Eskridge (2006) propose une
technique de formalisation OWL à partir d'une représentation en
*Concept mapping*. Plus récemment OntoCASE (Héon, 2010, 2012)
présente une méthodologie assistée par un outil logiciel qui formalise un
modèle MOT semi-formel en une ontologie OWL. Il contient un éditeur
de modèle MOT (eLi), un système expert à la désambiguïsation ainsi
qu'un système expert à la conversion du modèle MOT en ontologie. Le
point à souligner de ces méthodes est qu'à l'étape de formalisation du
modèle semi-formel, l'humain doit intervenir pour compléter le
processus de désambiguïsation du symbole semi-formel. Le processus de
formalisation ne peut donc pas être complètement automatisé.

## 1.2 Hypothèse

Une caractéristique importante qui assure la convivialité d'un langage semi-formel est le nombre restreint de symboles combiné à une simplification des règles grammaticales. En contrepartie, ces simplifications engendrent un coût au niveau de l'expressivité du langage. Ce coût est compensé par la polysémie (surcharge sémantique) des symboles qui permet d'accroître l'expressivité du langage. Lorsque la polysémie est trop forte, la désambiguïsation du langage se complexifie. Après un certain point, la désambiguïsation *ne peut plus être automatisée*. C'est à partir de ce point que le langage porte la dénomination de *semi-formelle*.

Deux techniques permettront d'accroître la polysémie de G-OWL afin
de maintenir au minimum le nombre de symboles tout en conservant une
expressivité identique à celle du OWL, et sans pour cela, que G-OWL
devienne un langage semi-formelle:
1) le **polymorphisme** permettra de donner plusieurs significations à un symbole graphique. Le symbole pourra ultérieurement être désambiguïsé par leur agencement topologique. Par exemple : si un *LienS* est entre deux concepts, alors il sera désambiguïsé en *subClassOf*. Tandis que si le *LienS* est entre deux attributs il sera désambiguïsé en *subPropertyOf*.

2) l'assignation **typologique** est la technique qui limite le nombre de symboles en lui assignant un type. Cette technique, employée pour la conception du langage MOT attribut un type aux entités et relations du langage. De plus, à chaque type correspond un nombre limité de significations. Pendant la modélisation, ce typage offre l'avantage de clairement distinguer la sémantique associée au langage de la sémantique associé au domaine représenté dans le modèle. Lors de la formalisation, le type sert de guide au processus de désambiguïsation.

## 2 Spécification de G-OWL

La spécification de G-OWL définit le vocabulaire graphique du langage G-OWL. Elle identifie les entités typées ainsi que les relations typées qui constituent l'alphabet du vocabulaire. La deuxième partie de la spécification permet de définir, en fonction de la polysémie, le polymorphisme et le typage ontologique du vocabulaire de G-OWL. Pour chaque élément et relation du vocabulaire, on associe un nombre fini de constructeurs OWL possibles.

### 2.1 Vocabulaire graphique de G-OWL

Présenté au tableau 1 ainsi qu'au tableau 2, l'alphabet de G-OWL se compose d'entités typées graphiques ainsi que de relations typées qui permettent de relier les entités d'un modèle.

Les entités sont regroupées en deux niveaux d'abstraction, le niveau *abstrait* et le niveau *factuel*. Le niveau abstrait renvoie à l'idée de la *Terminological Box* (TBox) en logique de description (DL) (Baader, et al., 2007). La TBox est l'espace de modélisation qui permet de représenter le niveau terminologique d'un sujet. On pourrait aussi dire qu'il fait référence aux abstractions d'un domaine du discours. Par exemple, pour le domaine de la *Famille*, c'est dans le niveau abstrait que se définissent les concepts tels que : *Père*, *Mère*, *Enfant*, *Parent*, et les propriétés telles que : *estEnfantDe*, etc. Quant au niveau factuel, qui renvoie en DL à l'idée de l'**Assertional Box** (ABox), il permet de représenter les *faits* et les *prédicats* qui unissent les faits concernant un domaine du discours. Le fait est une entité observable de la réalité. Ainsi, toujours dans l'exemple du domaine de la *Famille*, l'alphabet du niveau factuel est utilisé pour représenter des faits tels que *MARIE*, *MARC*, etc.
Le niveau factuel permet aussi de représenter la mise en relation de deux faits par la déclaration d'un énoncé selon la structure *Sujet/Prédicat/Objet* (par exemple : *MARC estEnfantDe MARIE*).

<table><caption>Tableau 1 : Alphabet des entités de G-OWL</caption><thead><tr><th></th><th>Type d'entité</th><th>Alphabet graphique</th><th>Signification</th></tr></thead><tbody><tr><td rowspan="4">Niveau abstrait</td><td>gowl:Concept</td><td>« Espace de nom »<br/>Nom du concept</td><td>Le rectangle est utilisé pour représenter un Concept qui désigne le « quoi » des choses</td></tr><tr><td>gowl:Restriction</td><td>Type de restriction<br/>Concept, Fait,<br/>Valeur C1<br/>Attribut P1</td><td>Le rectangle conteneur est utilisé pour représenter une Restriction universelle, existentielle ou de valeur. Il est aussi utilisé pour représenter la cardinalité associée à une propriété.</td></tr><tr><td>gowl:Collection</td><td>Type de collection<br/>Concept, Fait<br/>ou Restriction<br/>C1<br/>... Cn</td><td>Le rectangle conteneur est aussi utilisé pour représenter une collection de connaissances déclaratives.</td></tr><tr><td>gowl:Attribut</td><td>(Type d'attribut)<br/>« Espace de nom »<br/>Nom de l'attribut</td><td>L'hexagone est utilisé pour représenter un attribut qui définit la propriété entre des concepts.</td></tr><tr><td rowspan="2">Niveau factuel</td><td>gowl:Fait</td><td>« Espace de nom »<br/>Nom du fait</td><td>Le rectangle pointillé est utilisé pour représenter un fait, un objet observable de la réalité, un individu OWL</td></tr><tr><td>gowl:Donnee</td><td>(Type de donnée)<br/>Valeur</td><td>Le rectangle pointillé est aussi utilisé pour représenter une donnée de type entier, réel, caractères, etc.</td></tr></tbody></table>

Pour chaque élément graphique qui composent l'alphabet de G-OWL, on peut attribuer un nom qui sert d'identifiant unique. Dans la plupart des cas, il est permis d'attribuer un espace de nommage pour identifier au besoin le domaine d'appartenance du sujet représenté. La restriction, la collection ainsi que l'attribut sont des éléments du vocabulaire qui sont typés. Les valeurs possibles de chaque type sont présentées au tableau 4.

Le vocabulaire du niveau abstrait comprend un alphabet de quatre entités graphiques:

* Le `gowl:Concept` représente le « quoi » des choses, il sert à décrire l'essence d'un objet concret. Le concept est identifié par le nom du concept et optionnellement par l'indication de l'espace de nommage auquel il appartient.

* Le `gowl:Restriction` est utilisé pour caractériser les individus d'une classe. La restriction est un concept anonyme qui met en relation un attribut un concept et un fait selon le cas. Le tableau 4 présente les types de restrictions possibles.

* Le `gowl:Collection` est utilisé pour définir un regroupement de concepts. Le regroupement peut être conditionné par un
opérateur logique tel que l'union ou l'intersection. Les types de collection sont définis au tableau 4.

* Le `gowl:Attribut` désigne les propriétés qui existent entre des concepts, des restrictions ou des relations. L'identification de l'attribut est réalisée par le nom de l'attribut et optionnellement par l'identification de l'espace de nom. Il existe plusieurs types d'attributs qui sont présentés par les symboles du tableau 4.

Le vocabulaire du niveau factuel comprend quant à lui deux entités graphiques :

* Le `gowl:Fait` représente un élément de la réalité observable. Il est l'instance d'un concept. Le fait est identifié par le nom du fait et il peut aussi appartenir à un domaine qui est identifié par l'espace de nom.

* Le `gowl:Donnee` sert à représenter une donnée de type Entier, Réelle ou une Chaîne de caractères. Le type de donnée est indiqué entre parenthèses '()'. Le libellé du rectangle représente la valeur de la donnée.

Chaque élément alphabétique du langage G-OWL peut être relié à un autre élément alphabétique par une relation typée prédéfinie ou dynamiquement définie par l'association du nom du lien à un attribut déjà existant. Le tableau 2 présente les différentes relations typées ainsi que leur signification alors que le tableau 3 présente la synthèse des règles d'utilisation des liens typés de G-OWL.

<table><caption>Tableau 2 : Vocabulaire des relations de G-OWL</caption><thead><tr><td>Type de relation</td><td>Signification</td></tr></thead><tbody><tr><td>gowl:LienS<br/>--- S --></td><td>Le lien de <i>Spécialisation</i> associe deux connaissances de niveau abstrait de même type dont le premier est une spécialisation de la seconde.</td></tr><tr><td>gowl:LienDS<br/>(LienS<br/>doublement<br/>orienté)<br/> <-- S --></td><td>Le lien de <i>synonymie</i> associe deux connaissances de niveau abstrait de même type ou deux faits. Elle indique que la première connaissance est l'équivalent (ou le synonyme) de la seconde.</td></tr><tr><td>gowl:LienA<br/>--- A --></td><td>Le lien d'attribution associe un attribut à un concept, une restriction ou une collection afin de préciser l'image ou le domaine d'une propriété.</td></tr><tr><td>gowl:LienNT<br/>--- nom d'un<br/>Attribut -></td><td>Le lien <i>NonTypé</i> est utilisé pour associer un prédicat entre un fait et une connaissance de niveau factuel. Le nom du prédicat est associé à un attribut existant par le nom <i>DunAttribut</i>.</td></tr><tr><td>gowl:LienI<br/>--- I --></td><td>Le lien d'instanciation associe un concept à un fait qui caractérise une instance de cette connaissance.</td></tr><tr><td>gowl:LienD<br/>---D--></td><td>Le lien de <i>Différence</i> est utilisé pour indiquer la disjonction entre deux connaissances déclaratives abstraites. Il est aussi utilisé pour différencier deux faits.</td></tr><tr><td>gowl:LienIO<br/>---'1--></td><td>Le lien <i>Inverse</i> associe un attribut inverse à un attribut déjà existant.</td></tr></tbody></table>
L'usage des relations typées est conditionné par des règles d'utilisation de la relation. Par exemple, l'emploi du LienS (sorte de) est conditionné par une règle qui indique que la connaissance à la source et à la destination du LienS doivent être toutes les deux du même type. En se référant au tableau 3 on peut déduire qu'un concept peut être lié par un LienS à un autre concept, à une restriction ou une collection.

<table><caption>Tableau 3 : Synthèse des règles d'utilisation des relations typées de G-OWL</caption><thead><tr><th>Destination</th><th>Concept</th><th>Attribut</th><th>Fait</th><th>Restriction</th><th>Collection</th></tr></thead><tbody><tr><td>Source</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Concept</td><td>S, DS, I, D</td><td>A</td><td>I</td><td>S, DS, D</td><td>S, DS, D</td></tr><tr><td>Attribut</td><td>A</td><td>S, DS, -1</td><td></td><td>A</td><td>A</td></tr><tr><td>Fait</td><td></td><td></td><td>NT</td><td></td><td></td></tr><tr><td>Restriction</td><td>S, DS</td><td>A</td><td>I</td><td></td><td></td></tr><tr><td>Collection</td><td>S, DS</td><td>A</td><td>I</td><td></td><td></td></tr></tbody></table>

## 2.2 Polysémie et polymorphisme ontologique de G-OWL

Grâce à la polysémie et au polymorphisme, G-OWL restreint son alphabet à l'usage de cinq entités et de sept relations conditionnées par des règles d'usage explicitement définies en comparaison avec le langage OWL qui étend son usage à une trentaine de constructeurs dont la manipulation nécessite l'usage de règles implicites. Le tableau 4 présente la polysémie des éléments du vocabulaire de G-OWL.

Pour chaque élément de l'alphabet de G-OWL, il existe un ensemble restreint et fini de symboles qui permet de *typer* l'élément afin de le désambiguïser. La désambiguïsation peut aussi être réalisée de manière automatique par l'identification de la nature des éléments qui sont mis en relation (désambiguïsation topologique). Figuré à la fig.1, un synonyme (le *gowl:LienDS*) sera désambiguïsé par *owl:sameAs* si le lien relie deux faits (*gowl:Fait*) alors qu'il sera désambiguïsé par *owl:equivalentClass* s'il relie deux concepts (*gowl:Concept*) ou un concept à une restriction.

<figure><img src="image_2.png" /><figcaption>Fig. 1 - Polymorphisme du LienDS</figcaption></figure>
<table><caption>Tableau 4 : Polysémie de l'alphabet de G-OWL</caption><thead><tr><th>Alphabet polymorphique de G-OWL</th><th>Polysémie dans la notation OWL</th><th>Désambiguïsation de type et topologique</th></tr></thead><tbody><tr><td>gowl:Concept</td><td>owl:Class</td><td></td></tr><tr><td>gowl:Attribut</td><td>owl:DatatypeProperty<br>owl:ObjectProperty<br>owl:TransitivProperty<br>owl:SymmetricProperty<br>owl:FunctionalProperty<br>owl:InverseFunctional</td><td>si le codomaine est une donnée<br>si le codomaine est un fait<br>T<br>S<br>F<br>I</td></tr><tr><td>gowl:Fait</td><td>xsd:Boolean<br>xsd:string<br>xsd:integer<br>xsd:float<br>individu</td><td>Bool<br>String<br>Int<br>Float</td></tr><tr><td>gowl:Restriction</td><td>owl:Restriction<br>owl:someValuesFrom<br>owl:allValuesFrom<br>owl:hasValue<br>owl:minCardinality<br>owl:maxCardinality<br>owl:cardinality<br>owl:onProperty</td><td>∃<br>∀<br>∃<br>≤<br>≥<br>=</td></tr><tr><td>gowl:Collection</td><td>owl:intersectionOf<br>owl:unionOf<br>owl:oneOf<br>owl:DataRange<br>owl:complementOf<br>owl:distinctMembers<br>owl:AllDifferent</td><td>∩<br>∪<br>[]<br>[]<br>⊺<br>≠</td></tr><tr><td>gowl:LienS</td><td>rdfs:subClassOf<br>rdfs:subPropertyOf</td><td>si le lien est entre deux concepts<br>si le lien est entre deux propriétés</td></tr><tr><td>gowl:LienDS</td><td>owl:equivalentClass<br>owl:equivalentProperty<br>owl:sameAs</td><td>Si le lien est entre deux attributs<br>Si le lien est entre deux attributs<br>Si le lien est entre deux faits</td></tr><tr><td>gowl:LienA</td><td>rdfs:domain<br>rdfs:range</td><td>Si la source du lien est concept et que sa destination est un attribut<br>Si la source du lien est attribut et que sa destination est un concept</td></tr><tr><td>gowl:LienNT</td><td>Prédicat</td><td>Une chaîne de caractère</td></tr><tr><td>gowl:LienI</td><td>rdfs:typeOf</td><td>I</td></tr><tr><td>gowl:LienD</td><td>owl:disjointWith<br>owl:differentFrom</td><td>Si le lien est entre deux concepts<br>Si le lien est entre deux faits</td></tr><tr><td>gowl:LienIO</td><td>owl:inverseOf</td><td>-1</td></tr></tbody></table>
# 3 Test d'expressivité de G-OWL

Le but de ce test est de démontrer qu'il est possible de décrire l'ensemble des éléments d'expressivité soutenu par l'OWL. Pour ce faire, la section est structurée selon la classification des constructeurs tels que présentés par McGuinness (2004) et Yu (2011) en utilisant l'ontologie *Wine.owl* (Deborah L. McGuinness et al., 2004) en tant qu'exemple présenté par l'auteur afin d'illustrer les divers aspects de l'expressivité d'OWL.

Dans l'ontologie sont emmagasinés les éléments qui servent à représenter le domaine du discours. On y retrouve la classe, la propriété, la restriction sur les propriétés telle que la restriction universelle et existentielle, la restriction de cardinalité ou encore la restriction de valeur; la relation de synonymie; la collection sur les opérateurs booléens tels que l'intersection ou l'union de classes; la disjonction et l'énumération d'objets. Finalement, la représentation des faits du domaine du discours.

## 3.1 Éléments de base en G-OWL : la classe et la propriété

Le tableau 5¹ présente en G-OWL ainsi qu'en OWL N-3 la définition de *CabernetSauvignonGrape*. Selon l'ontologie, le *CabernetSauvignonGrape* est un *WineGrape* qui lui-même est une sorte de *Grape*. Le *gowl:Concept* *Grape* est défini dans l'espace de nommage *food*. Lors de la traduction du modèle G-OWL en ontologie OWL, les *gowl:Concept* *WineGrape* et *Grape* seront traduits en classe nommée (*owl:Class*); le *gowl:Fait* *CabernetSauvignonGrape* sera traduit en ressource *rdf*; le *gowl:LienS* sera traduit par la propriété *owl:subClassOf* et le *gowl:LienI* par *rdf:type*.

Le *gowl:LienS*, qui uni ces propriétés, est traduit en *rdfs:subPropertyOf* par la règle de désambiguïsation topologique qui stipule qu'un *gowl:LienS* entre deux *gowl:Attribut* sera traduit en *rdfs:subPropertyOf*. Le *gowl:LienA* est aussi utilisé de manière polysémique pour unir un *gowl:Attribut* à un *gowl:Concept* et *vice-versa*. La polysémie de ce lien est levée par l'application de la règle de désambiguïsation topologique qui stipule qu'un *gowl:LienA* ayant à sa source un *gowl:Concept*, et à sa destination un *gowl:Attribut* sera traduit par *rdfs:range* alors qu'il sera traduit par *rdfs:domain* dans le cas où la source et la destination du *gowl:LienA* sont inversées.

<footnote n="1">¹ Les tableaux de l'expérimentation sont divisés en trois sections : la représentation de l'énoncé en G-OWL à gauche, sa représentation en notation N3 à droite et sa représentation en langage naturel en bas. Dans la section de l'énoncé en G-OWL apparaît d'une part, la représentation graphique puis, pour fin d'information, la sémantique de l'objet graphique. Dans l'exemple du tableau 5, les objets graphiques *Grape* et *WineGrape* sont traduit en *owl:Class*.</footnote>
<figure><img src="image_3.png" /><figcaption>Tableau 5: Exemple d'une classe nommée simple, d'un individu et la distribution hiérarchique</figcaption></figure>

WineGrape est une sorte de Grape du domaine food.

Le CabernetSauvignonGrape est un WineGrape

En OWL, la propriété peut servir à mettre en relation les individus appartenant à deux classes. Le tableau 6 présente la définition des propriétés hasWineDescriptor et hasColor qui sont identifiées par le gowl:Attribut.

<figure><img src="image_4.png" /><figcaption>Tableau 6 : Définition de propriétés</figcaption></figure>

WineColor est une sorte de WineDescriptor

la propriété hasColor est une sorte de propriété hasWineDescriptor

Wine hasWineDescriptor WineDescriptor

Wine hasColor WineColor

## 3.2 Restrictions sur les propriétés

Pour représenter une restriction, le langage G-OWL utilise un conteneur pour agglomérer les diverses entités nécessaires. Dans le cas des restrictions universelle et existentielle (voir le tableau 7), le conteneur agglomère trois éléments soit : un type de restriction (∀ ou ∃), un et un seul gowl:Attribut ainsi qu’un et un seul gowl:Concept. En OWL, la restriction est une classe anonyme qui doit être associée à une classe nommée par la propriété rdfs:subClassOf ou par la propriété rdfs:equivalentClass. Lors de la traduction en OWL, le conteneur sera traduit en classe anonyme de type owl:Restriction. De même, en se référant à l'exemple du tableau 7, la restriction sera associée à la propriété hasMaker par la propriété owl:onProperty ainsi qu'à la classe Winery par la propriété owl:someValuesFrom ou owl:allValuesFrom selon le type de restriction choisi.
<table><caption>Tableau 7 : Restriction universelle et existentielle de propriétés</caption><tr><td><pre>owl:allValuesFrom
    rdfs:subClassOf
    <div>owl:Restriction</div>
    <div>owl:someValuesFrom</div>
    <div>owl:equivalentClass</div></pre></td><td><pre>:PotableLiquid rdf:type owl:Class .<br/>:Wine rdf:type owl:Class ;<br/>rdfs:subClassOf :PotableLiquid ;<br/>owl:equivalentClass<br/>[ rdf:type owl:Restriction ;<br/>owl:onProperty :hasMaker ;<br/>owl:someValuesFrom :Winery ] ;<br/>rdfs:subClassOf<br/>[ rdf:type owl:Restriction ;<br/>owl:allValuesFrom :Winery ;<br/>owl:onProperty :hasMaker ] .</pre></td></tr></table>

- Wine est une sorte de PortableLiquid

- Pour tous les Wine, s'ils sont associés à un producteur (hasMaker) alors chaque (∀) producteur est une sorte d'Etablissement Vinicole (Winery)

- Pour tous les Wine, il y a au moins un (∃) producteur (hasMaker) qui est une sorte d'Etablissement Vinicole (Winery)

Au sujet des restrictions de cardinalité et de valeur (voir le tableau 8), le conteneur agglomère un type de restriction associé à la cardinalité (<=, <, ≥) ou encore, associé à la représentation d'une valeur (э). Dans ces cas, le conteneur agglomère aussi un gowl:Attribut ainsi qu'un gowl:Fait.

Dans le cas d'une restriction de cardinalité, le gowl:Fait est stéréotypé avec la mention « int » pour indiquer que la valeur représentée dans le gowl:Fait est un rdfs:datatype de type xsd:integer. Cette mention permettra de désambiguïser hasVintageYear en owl:DatatypeProperty

<table><caption>Tableau 8 : Restriction de cardinalité et de valeur</caption><tr><td><pre>owl:cardinality Vintage<br/>owl:resource="sDry"<br/>owl:hasValue 1<br/>owl:Restriction Dry<br/>owl:hasSugar 1</pre></td><td><pre>:Vintage rdf:type owl:Class ;<br/>rdfs:subClassOf<br/>[ rdf:type owl:Restriction ;<br/>owl:cardinality 1^xsd:nonNegativeInteger ;<br/>owl:onProperty :hasVintageYear ].<br/>:Burgundy rdf:type owl:Class ;<br/>rdfs:subClassOf<br/>[ rdf:type owl:Restriction ;<br/>owl:hasValue :Dry ;<br/>owl:onProperty :hasSugar ] .<br/>:hasSugar rdf:type<br/>owl:ObjectProperty .<br/>:hasVintageYear rdf:type<br/>owl:DatatypeProperty .<br/>:Dry rdf:type owl:Thing .</pre></td></tr></table>

- Pour tous les Vintage, il existe un et un seul prédicat hasVintageYear

- Pour tous les Burgundy, il existe au moins un prédicat hasSugar associé à l'individu Dry

## 3.3 Collection

La collection (gowl:Collection) est utilisée pour agglomérer un ensemble fini de gowl:Concept, de gowl:Restriction ou encore un ensemble de gowl:Fait (voir le tableau 9 et le tableau 10). La collection est entre autres utilisée pour représenter l'intersection de classes (owl:intersectionOf) et l'union de classes (owl:unionOf).
<figure><img src="image_5.png" /><figcaption>Tableau 9 : Collection</figcaption></figure>

## 3.4 Énumération et disjonction

Le tableau 10 présente quelques exemples d'utilisation de l'énumération et de la disjonction. L'énumération, qui est en fait une sorte de collection d'individus, est utilisée pour construire un ensemble d'individus (`owl:oneOf`) ou pour distinguer un ensemble d'individus les uns des autres (`owl:distinctMembers`). Quant au `gowl:LienD`, il est utilisé pour indiquer que les faits d'un concept ne peuvent pas appartenir au concept pointé par le lien. Dans l'exemple, les faits du concept *Pasta* ne peuvent pas être des faits de la classe *Meat*. Le `gowl:LienD`, est traduit en OWL par `owl:disjointWith`.

<figure><img src="image_6.png" /><figcaption>Tableau 10 : Énumération et disjonction</figcaption></figure>
## 4 Résultat

Pour mettre en évidence la qualité représentationnelle de G-OWL, nous avons choisis, à partir d'un fragment de l'ontologie *wine.owl*, de comparer la représentation du fragment dans sa représentation en N3, dans sa représentation en graphe et dans sa représentation en G-OWL (voir la fig. 2).

La représentation de comparaison de type graphe a été choisi puisqu'il s'agit d'une représentation couramment employée par les éditeurs d'ontologie tel que *Protégé* et *TopBraid Composer*. De plus, cette représentation en graphe est l'une des seules représentations qui permet de représenter des individus, des classes, des axiomes et des propriétés dans un même diagramme.

<figure><img src="image_7.png" /><figcaption>Fig. 2 – Ontologie partielle du Sauterne Château d'Yquem en représentation graph, G-OWL et N3, extrait de *wine.owl* (Deborah L. McGuinness, et al., 2004)</figcaption></figure>

Le fragment de l'ontologie présentée à la fig. 2 représente l'idée qu'un Château d'Ychem Sauterne est un vin blanc de Sauternes. Pour représenter cette idée, il est inscrit dans l'ontologie que l'individu *ChateauDYchemSauterne* est de type *Sauternes*. Le *Sauternes* est la conjonction d'un *Wine* et de quelque chose qui est de couleur (*hasColor*)
White. La propriété hasColor a pour domaine wine et à pour co-domaine (le rdfs:range) WineColor. White est une instance de WineColor.

Pour l'évaluation, le tableau 11 présente le dénombrement des différents éléments graphiques de chaque représentation. On constate que pour chaque critère, G-OWL comporte un nombre d'éléments inférieur au nombre d'éléments du graphe et ceci, qu'il s'agisse du nombre de type d'éléments ou du nombre total d'éléments. Sans être une garantie formelle de simplicité d'usage, ces indicateurs laissent présager une tendance vers une simplification et une convivialité de l'usage de G-OWL.

<table><caption>Tableau 11 : Table de comparaison des représentations graphiques graphe et G-OWL</caption><thead><tr><td>Critère</td><td>Graphe</td><td>G-OWL</td></tr></thead><tbody><tr><td>Nombre de sorte d'entités</td><td>6</td><td>5</td></tr><tr><td>Nombre de sorte de relations</td><td>8</td><td>3</td></tr><tr><td>Nombre total d'entités</td><td>13</td><td>9</td></tr><tr><td>Nombre total de relations</td><td>13</td><td>5</td></tr></tbody></table>

Au niveau de l'intuitivité, l'usage de relations de type rdf:rest, rdf:first nécessaire à la construction grammaticale de l'ontologie, est en revanche contre-productif pour un expert de contenu qui désire interpréter l'ontologie au vue de son domaine du discours. Ces restrictions grammaticales tournées vers l'exploitation automatique d'une ontologie OWL se trouve donc camouflé en G-OWL, qui lui, s'attarde sur l'utilisation de symbole signifiants en termes de représentation d'un domaine de discours.

## 5 Conclusion

Cet article a présenté G-OWL, un langage graphique pour la construction d'une ontologie dans le formalisme OWL qui repose sur l'hypothèse qu'un langage graphique, polysémique, polymorphique et typé offre une convivialité d'utilisation accrue par rapport à un langage formel textuel comme l'OWL ou encore un langage graphique n'utilisant pas de polysémie comme le graphe ou l'UML. Le vocabulaire graphique de G-OWL ont été définis et mis en contexte d'utilisation par plusieurs exemples illustrant l'expressivité d'OWL. La présentation de la modélisation graphique partielle de l'ontologie Wine.owl démontre qu'il est possible de représenter une ontologie relativement complexe, contenant plusieurs éléments d'expressivité d'OWL dans un seul schéma qui en synthétise la représentation. La comparaison avec une représentation en graphe a démontré que G-OWL utilise moins d'entités, de relations et de sorte d'entités et de sorte de relations. Cette diminution dans l'usage des symboles combinée à l'hypothèse (démontrée dans des travaux de recherches antérieures) que la simplicité d'usage d'un langage
est liée à la limitation du nombre de symboles nécessaire pour soutenir
une certaine expressivité, laisse fortement présager que G-OWL est plus
simple d'usage qu'un langage non polysémique.

Bien que G-OWL soit à une étape avancée de la définition de ses
spécifications, il est nécessaire de poursuivre sa validation afin d’en
assurer la cohérence, la complétude et la convivialité d’usage. G-OWL
doit donc être utilisé pour construire d’autres ontologies et il doit être mis
à l’essai sur le terrain lors de séances d’élicitation et de remue-méninge.
De plus, la cohérence et la complétude du langage pourront être
formellement validées par la construction d’un logiciel d’édition
d’ontologies en G-OWL. Le caractère systématique et formel du
processus d’implantation d’un tel éditeur permettra de relever plusieurs
points d’incohérence et de non-complétude du langage. Pour ce qui est
de la validation d’usage, il serait nécessaire, après une formation
adéquate sur le langage G-OWL, de demander à des experts de contenu
de construire des ontologies de leur domaine avec G-OWL. Cette
validation d’usage permettra de mesurer la capacité de G-OWL à être
utilisé de manière intuitive.

Grâce à son vocabulaire polysémique exprimé de manière graphique, polymorphique et typé, qui allège le processus mental de conception, nous pensons que G-OWL pourrait-être utilisé par des experts de contenus pour l’élicitation de connaissances et la production d’ontologies qui pourraient être validé « à chaud » si l’éditeur G-OWL est couplé avec un moteur d’inférence. Les conclusions produites par le moteur d’inférence pourraient être présentées directement et de manière graphique à l’expert lui permettant de valider la représentation de la connaissance qu’il se fait de son domaines du discours. G-OWL pourrait être utilisé, par exemple, dans des activités de transferts de connaissances ou pour la construction de bases de connaissances de systèmes experts dans une représentation accessible à l’expert de contenu.

# 6 Références

Baader, F., Calvanese, D., McGuinness, D. L., Nardi, D., & Patel-Schneider, P. F. (2007). *The Description Logic Handbook: Cambridge University Press*.

Basque, J., & Pudelko, B. (2010). *Modeling for Learning*. In G. Paquette (Ed.), *Visual Knowledge and Competency Modeling - From Informal Learning Models to Semantic Web Ontologies*. Hershey, New York: IGI Global.

Buzan, T., & Buzan, B. (1994). *The Mind Map Book: How to Use Radiant Thinking to Maximize Your Brain's Untapped Potential*: E P Dutton.

Chein, M., & Mugnier, M.-L. (2008). *Graph-based Knowledge Representation* London: Springer.

Eskridge, T., Hayes, P., & Hoffman, R. (2006). *Formalizing The Informal: A Confluence Of Concept Mapping And The Semantic Web*. Paper presented at the Second Int. Conference on Concept Mapping San José, Costa Rica.
Gašević, D., Djurić, D., & Devedžić, V. (2006). *Model Driven Architecture and Ontology Development*. New York, Inc.: Springer-Verlag.

Héon, M. (2010). *OntoCASE: Méthodologie et assistant logiciel pour une ingénierie ontologique fondée sur la transformation d'un modèle semi-formel*. Unpublished Thèse, Université du Québec à Montréal, Montréal.

Héon, M. (2012). *OntoCASE un outil CASE d'élicitation et de conception d'une ontologie OWL*. Retrieved 20 février 2012, 2012, from http://www.cotechnoe.com/ontocase

Kinshuk, H. H. A., Pawlowski, J. M., & Sampson, D. (2008). *Handbook for Education and Training on Information Technologies (Second edition ed.)*. Heidelberg: Springer-Verlag.

McGuinness, D. L., & Harmelen, F. v. (2004). OWL Web Ontology Language Overview Retrieved 30 mai, 2006, from http://www.w3.org/TR/owl-features/

McGuinness, D. L., Patel-Schneider, P. F., Thomason, R. H., Abrahams, M. K., Resnick, L. A., Cavalli-Sforza, V., et al. (2004). Wine Ontology, OWL Web Ontology Language Guide. 2011, from http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine.pdf

Novak, J. D., & Cañas, A. J. (2006). The origins of the concept mapping tool and the continuing evolution of the tool. *Information Visualization*, 5, 175–184.

Paquette, G. (2002). *L'ingénierie pédagogique*. Sainte-Foy (Québec): Presses de l'Université du Québec.

Paquette, G. (2010). *Visual Knowledge and Competency Modeling - From Informal Learning Models to Semantic Web Ontologies*. Hershey, PA: IGI Global.

Rumbaugh, J., Jackson, I., & Booch, G. (1999). *The Unified Modeling Language Reference Manual*.

Sowa, J. F. (1999). Conceptual Graph. In P. Bernus, G. Schmidt & K. Mertins (Eds.), *Handbook on Architectures of Information Systems* (pp. 834): Springer-Verlag New York, Inc.

Yang, Y. (2006). EMF Ontology Definition Metamodel. 2008, from http://wiki.eclipse.org/MDT-EODM

Yu, L. (2011). OWL: Web Ontology Language. In Springer (Ed.), *A Developer's Guide to the Semantic Web* (pp. 155-239): Springer Berlin Heidelberg.