Un outil d’aide à la construction d’ontologies pré-consensuelles : le projet Towntology Abdel Kader Keita (1), Catherine Roussey (2), Robert Laurini (1)

(1) LIRIS Laboratoire d'InfoRmatique en Image et Systèmes d'information UMR5205 CNRS INSA, Campus de la Doua, Bâtiment Blaise Pascal (501), 20 avenue Albert Einstein 69621 VILLEURBANNE CEDEX [email protected] [email protected] (2) LIRIS Laboratoire d'InfoRmatique en Image et Systèmes d'information UMR5205 CNRS Université Claude Bernard Bâtiment Nautibus (710), 43, Boulevard du 11 Novembre 1918 69622 VILLEURBANNE CEDEX [email protected] RÉSUMÉ.

Dans cet article nous décrivons notre travail sur la conception d’ontologies urbaines sous forme visuelle, réalisé dans le cadre du projet TOWNTOLOGY. Notre contribution porte sur le développement d’un outil de conception d’ontologie préconsensuelle pour aider les experts du domaine (dans notre cas les urbanistes) à décrire leur connaissance. Notre travail se situe dans les premières phases de développement d’une ontologie, lorsque le consensus n’est pas encore atteint. Plus exactement, nous proposons un outil permettant lors de la phase d’acquisition des connaissances à des experts du domaine de modéliser les différences de points de vue sur le sens des termes. Ainsi nous construisons un premier prototype d’ontologie appelé ontologie pré consensuelle. Contrairement aux ontologies post consensuelles, les différentes définitions d’un même terme sont conservées. Un format XML est proposé pour stocker et acceder à l’ontologie. ABSTRACT. In this article we describe our work on the design of urban ontologies in visual form, realized within the framework of the TOWNTOLOGY project. Our contribution relates the development of a design tool of pre-consensual ontology, to help the experts of the field (in our case urban planners) to describe their knowledge. The visual tools are an asset for the collaborative design of domain ontology implying the expert actors of the field of study but neophytes in the field of ontology design. An XML format is proposed to store and access ontology. MOTS-CLÉS: construction d’ontologie urbaine, réseau sémantique, consensus, outil visuel. KEY WORDS:

urban ontology, semantic network, consensus, visual tool.

1. Introduction Une ontologie possède deux définitions différentes suivant le domaine auquel on s’intéresse, en l’occurrence la philosophie ou l’informatique :


Du point de vue philosophique, une ontologie se définit comme la science de ce qui existe.




Du point de vue informatique et plus particulièrement ingénierie des connaissances, la définition la plus communément admise est celle de (Gruber, 1993 ) : « une ontologie est une spécification explicite d’une conceptualisation d’un domaine ». La conceptualisation permet d'identifier par un processus d'abstraction les concepts essentiels référencés par les termes du domaine et la spécification rend explicite le sens associé à ces concepts en leur associant une définition. Ces définitions peuvent être formelles ou non.

Dans le cadre d’une manipulation de l’ontologie par des agents humains, des définitions de concept en langage naturel sont nécessaires ; en revanche si l’ontologie est utilisée par des systèmes à bases de connaissances, il faut associer à chaque concept une définition formelle écrite dans un modèle de représentation des connaissances. De manière générale, une ontologie contient un vocabulaire formalisé regroupant pour une discipline donnée, l'ensemble des concepts, et de leurs relations. Les définitions associées à chaque concept sont issues d’un consensus entre les différents acteurs et futurs utilisateurs de l’ontologie. Construire des ontologies est un processus complexe, dont la complexité augmente si les développeurs doivent implémenter directement l’ontologie dans un langage formel, sans avoir à leur disposition un outil d’aide à la construction. Pour faciliter cette tâche, les premiers environnements de construction d'ontologies ont été créés au milieu des années 90. Ces derniers fournissent des outils qui aident des utilisateurs à effectuer certaines des tâches principales du processus de développement d'ontologie, telles que la conceptualisation, l'implémentation, le contrôle de cohérence, et la documentation. Ces dernières années, le nombre d'outils pour le développement d’ontologies a considérablement augmenté et a été diversifié (Gomez-Perez, 2002). La majorité des outils existants concernent la création des ontologies, une fois le consensus réalisé (que nous intitulons ontologies post-consensuelles). Au contraire, notre travail se situe dans les premières phases de développement d’une ontologie, lorsque le consensus n’est pas encore atteint. Plus exactement, nous proposons un outil permettant lors de la phase d’acquisition des connaissances des experts du domaine de modéliser les différences de points de vue sur le sens des termes. Ainsi nous construisons un premier prototype d’ontologie appelé ontologie préconsensuelle. Contrairement aux ontologies post consensuelles, les différentes définitions d’un même terme sont conservées.

Dans cet article, nous décrivons notre travail sur la conception d’ontologie préconsensuelle appliquée au domaine de l’urbanisme, réalisé dans le cadre du projet TOWNTOLOGY. Tout d’abord, nous présentons un état de l’art sur les méthodologies de conception d’ontologies. Ensuite, nous détaillons les spécifications d’un système préconsensuel. Dans la troisième section, nous décrivons l’outil Towntology, ses interfaces utilisateurs et ses fonctionnalités. Et en dernier lieu, nous retraçons nos expérimentations sur la construction d’ontologie pré-consensuelle, dans le cadre du projet Towntology, en expliquant l’apport de notre outil.

2. Les méthodes de construction d’ontologies Le processus de construction d’une ontologie est composé de plusieurs phases telles que décrites dans la figure 1.

Figure 1. Le cycle de vie d’une ontologie (Fernandez et al, 1997)

Plusieurs méthodologies ont été proposées pour la construction d’ontologies. Ces méthodologies proposent d’utiliser différents types de supports d’information pour commencer l’ontologie comme des bases terminologiques, de la documentation technique, des ontologies, des comptes rendu d’interviews, des questionnaires. Nous pouvons citer entre autres les méthodes Cyc (Lena and Guha, 1990) et SENSUS (Swartout et al., 1997), l’approche KACTUS (KACTUS, 1996), les méthodologies METHONTOLOGY (Gomez-Perez et al., 1996) et On-To-Knowledge (Staab et al., 2001). Dans le tableau ci-dessous, nous comparons les différentes méthodologies par rapport aux phases du processus de construction de l’ontologie. Le signe "++" indique que la méthodologie décrit comment exécuter chaque tâche de la phase, le

"+" que la méthodologie soutient quelques tâches de la phase, et le "-" que la méthodologie ne prend pas en compte la phase de construction. La dernière ligne de la table indique si la méthodologie à un outil support associé ou pas. Tableau 1. Comparaison des différentes méthodologies de construction d’ontologies

Cyc

Uschold King

& Gruninger Fox

& KACTUS

METHONTOLOGY

SENSUS

On-ToKnowledge

Spécification

-

+

++

+

++

+

++

Acquisition de connaissance

+

+

+

-

++

-

++

Conceptualisation

-

-

++

+

++

-

+

Formalisation

-

-

++

++

++

-

++

Outil Support

Out -ils Cyc

Pas d’outil spécifique

Pas d’outil spécifique

Pas d’outil spécifique

ODE, WebODE,

Pas d’outil spécifique

OntoEdit avec ses plug-ins

OntoEdit, Protégé2000

(OntoSaur us)

Ces méthodologies utilisent différentes approches d’acquisition des connaissances. Par exemple la méthode On-To-Knowledge a étudié l’acquisition des connaissances en spécialisant une ontologie générique (Alexander Maedche et Steffen Staab, 2000a). L’équipe d’Aussenac-Gilles (Aussenac-Gilles et al., 2000a) propose d’extraire des documents techniques une terminologie pour débuter la conceptualisation. Le but de nos travaux est de rendre accessible les différentes étapes de la construction de la conceptualisation du domaine pour les experts. De plus il faut mettre en évidence les conflits terminologiques entre différents experts qui peuvent intervenir lors de la conception. Par exemple, le terme rue ne représente pas le même concept dans le cadre d’un service de distribution de courrier comme La Poste et dans le cadre d’un service de maintenance de la voirie. Notre approche est proche de celle préconisée par l’équipe d’Aussenac-Gilles (Aussenac-Gilles, 2000) sauf que contrairement à eux nous n’avons pas forcément un corpus de documents électroniques. La base terminologique que nous utilisons peut être construite à partir d’interview d’experts, d’analyse manuelle de documents ou d’ontologies. Pour répondre à tous ces besoins nous avons développé notre propre outil de conception et de visualisation d’ontologies pré-consensuelles.

3. Spécifications du système pré-consensuel La conception d'ontologie pré-consensuelle doit tenir compte : - des différentes terminologies employées qui peuvent amener à des ambiguïtés, - des différents points de vues sur les objets du domaine d’étude, qui aboutissent à des définitions différentes d’un même objet. En conséquence, nous devons associer plusieurs définitions aux termes et à partir des définitions qui ne peuvent être considérées comme équivalentes sémantiquement, construire les concepts. Pour illustrer la difficulté d’identifier un concept à partir d’un terme, examinons un exemple très simple : le terme « rue ». Ce terme simple ne semble pas posé de problème car tout un chacun est capable de définir ce qu’est une rue. En réalité la sémantique de ce terme est beaucoup plus complexe. Considérons seulement trois groupes d'acteurs constitués du service d’entretien de la voirie, du service de livraison du courrier et de la compagnie de distribution d’électricité.






Les services d’entretiens nettoient des rues ; en France, ils nettoient seulement les rues publiques tandis que les rues privées doivent être nettoyées par les résidants. Donc le service d’entretien n’est concerné que par les rues qui ont le statut de publique. Les facteurs distribuent des lettres aux résidants vivant dans des rues publiques et privées. Mais si une rue n'a aucun résidant, cette rue n'est pas dans la tournée de distribution de courrier des facteurs. Les employés de la compagnie d’électricité considèrent seulement les rues dans lesquelles leur compagnie fournit l'électricité.

Cet exemple, prouve qu’un mot aussi simple que rue cache plusieurs concepts différents dépendant du point de vue dans lequel on se place. Ainsi dans notre approche un concept est un triplet (terme, point de vue, définitions). Contrairement aux définitions de départ associées aux termes, les définitions associées aux concepts doivent être jugées sémantiquement similaires pour être capable de synthétiser ces définitions en une seule. Ainsi le réseau de termes construits au départ de l’acquisition des connaissances se raffine petit à petit en un réseau de concepts en associant des points de vues pour séparer les définitions incompatibles1.

1

Dans la suite de cet article, nous appellerons concept un élément de la conceptualisation en cours, qui suivant son état pourra être un concept bien défini, c’est à dire un terme, un point de vue si nécessaire et des définitions sémantiquement équivalentes, ou un concept en cours d’identification, c’est à dire un terme avec un ensemble de définitions qui peuvent être incompatibles .

Toutes les techniques d’acquisitions des connaissances citées dans la seconde section ont besoin d’un ingénieur de la connaissance pour pouvoir débuter l’acquisition des connaissances. Une fois, que les connaissances sont identifiées l’ingénieur les transforme en concept pour construire la modélisation du domaine. Dans notre approche nous cherchons à faire intervenir nos experts du domaine le plus longtemps possible dans la phase d’acquisition de la connaissance pour qu’ils participent et comprennent les choix liés à la conceptualisation du domaine. En effet, ce seront au final les experts du domaine qui vont valider et utiliser l’ontologie réalisée. Les méthodes de conception des systèmes d’information ont mis en évidence l’importance des diagrammes graphiques pour faciliter la communication entre les futurs utilisateurs du système et les concepteurs du même système. Ainsi UML (Rumbaugh et al., 1998) propose différents diagrammes (use case, diagramme de classes) afin de modéliser les données ou les opérations du système. En se basant sur ces méthodes de conception de systèmes d’information, nous avons besoin d’un formalisme non informatique basé sur des diagrammes graphiques compréhensibles par des néophytes en gestion de la connaissance. Ainsi pour visualiser de manière graphique le sens des termes, des relations sémantiques entre concepts sont introduites. De plus ces relations permettent de formaliser les liens entre les définitions. D’autres parts, des images ou d’autres types d’illustrations peuvent aussi servir à clarifier le sens des définitions et surtout à faciliter leur mémorisation. Durant le développement de l’ontologie, les incompatibilités et les conflits peuvent persister par exemple si des définitions jugées incompatibles ne sont pas associées à des points de vue différents. Pour faciliter le suivi des modifications et l’évolution des conflits, des informations sur les définitions sont nécessaires comme la source d’où est issue la définition et son auteur, sa date d’insertion dans l’ontologie et le nom de la personne qui a introduit cette définition. À partir de toutes ces considérations, les principales spécifications de notre système sont les suivantes : - Définir des termes - Définir des points de vue - Associer plusieurs définitions à un terme avec ou sans point de vue - Illustrer les définitions par des documents multimédia pour clarifier la définition ou faciliter sa mémorisation. - Visualiser le réseau des concepts. - Définir la source des définitions et leurs auteurs - Définir qui a mis cette définition et à quelle date. - Définir des relations entre concepts - Proposer des fonctionnalités de recherche d’un concept ou d’un terme. - Proposer des fonctionnalités de recherche, de navigation, de filtrage dans un réseau de relations.

4. L’outil Towntology Avant la mise en oeuvre de notre outil nous avons analysé les outils existants qui intègrent les techniques de visualisation des ontologies. Entre autres nous pouvons citer les outils Graph Viz (Gansner et al., 1999), Jambalaya (Storey et al., 2001), WebOnto (Domingue, 1998), et Clustermap (Fluit et al., 2003). Tous ces outils proposent de visualiser des ontologies déjà existantes, et décrites de manière formelle. Dans notre cas, nous ne cherchons pas à rendre plus lisible une ontologie formelle, mais à permettre à des non-informaticiens de valider la conceptualisation (non formelle) de l'ontologie. 4.1 Le langage de Towntology Nous sommes dans le cadre d’une ontologie pré-consensuelle, donc il n’existe pas de définition unique pour un concept et les concepts sont en cours de création à partir des termes du domaine. De plus les définitions sont données en langage naturel ou associées à des images. Ainsi les langages formels comme OWL (OWL), utilisés dans le cas d’ontologie formelle ne sont pas adaptés à nos besoins. Une comparaison des langages existants de représentation des ontologies a été effectuée. Voir (Keita et al.,2004) pour les détails. Pour toutes ces raisons, nous avons préféré définir notre propre grammaire XML pour contenir l’ensemble des informations qui nous intéressaient. Notre spécification XML de l’ontologie est divisée en deux parties, head et body. Comme le montre la figure 2, la partie head contient les informations générales sur l’ontologie : son titre, sa langue, la dernière date de modification.

Figure 2. La partie Head de l’ontologie des transports

La partie body contient les éléments composant l’ontologie, à savoir les types de relation, les points de vue, les concepts et les relations entre concepts. La figure 3 présente un extrait du fichier XML décrivant le concept « Accident de la route ».

Figure 3. Un extrait de la description du concept « Accident de la route »

4.2. Les interfaces TOWNTOLOGY

Towntology visualise des ontologies enregistrées dans des fichiers XML et les représente sous forme de graphe. Le logiciel propose à l’utilisateur un éditeur et un navigateur d’ontologie. Il offre la possibilité d’éditer et de visualiser des définitions multimédia. Enfin l’utilisateur à également la possibilité de consulter des images interactives liées aux différents concepts de l’ontologie.


Navigateur visuel d’ontologie : Townto-Browser

La partie droite du navigateur contient le graphe des relations entre concepts. Il permet à l’utilisateur de naviguer dans l’ontologie. Ce graphe est une partie du graphe global centré sur un concept et son voisinage. La partie gauche est une liste déroulant des concepts présents dans l’ontologie. En sélectionnant un concept, l’utilisateur peut afficher la fenêtre contenant ses définitions.

Figure 4. Townto-Browser




La fenêtre définition :

Elle permet de visualiser le(s) définition(s) textuelles et multimédia du concept sélectionné ainsi que les sources de ces définitions. La partie en haut à gauche contient les informations générales sur l’ontologie. La partie en bas à gauche contient la liste des relations que ce concept entretient avec ces voisins directs.

Figure 5. Fenêtre Définition


La fenêtre de gestion des images interactives (Image-Browser) : Cette fenêtre offre la possibilité à l’utilisateur d’accéder à l’ontologie à travers des images de zones urbaines. L’utilisateur sélectionne une zone de l’image à laquelle

sont associés des concepts de l’ontologie. En sélectionnant un des concepts, l’utilisateur accède au graphe centré sur ce concept dans townto-Browser (cf figure 4).

Figure 6. Image Browser

5. Le projet Towntology Le projet TOWNTOLOGY est issu de la collaboration de deux équipes de recherche de domaines différents : les systèmes d’information et le développement urbain pour atteindre le même objectif qui est la construction d’une ontologie urbaine. Les deux partenaires de ce projet sont : • Le Laboratoire d'InfoRmatique en Image et Systèmes d'information (LIRIS). Dans ce laboratoire, se trouvent des compétences en système d’information et aussi en ingénierie des connaissances. L’équipe du LIRIS regroupe des chercheurs ayant entre autres des compétences dans la représentation des connaissances pour construire un outil d’aide à la conception d’ontologies. • Le laboratoire Environnement Ville et Société (EVS) et plus particulièrement l’Equipe Développement Urbain (EDU) dont le devoir est de fournir au projet les compétences du domaine de l’urbain. Dans ce projet, cette équipe joue le rôle d’expert du domaine dont on cherche à modéliser les connaissances.

Le but du projet est de définir une ontologie utilisée à la fois pour l’enseignement de l’urbanisme et proposer aussi aux experts un cadre de référence, pour l’indexation de leur documentation, l’aide à la recherche d’information ou la formation du personnel.

5.1. Expérimentation Les experts de l’EDU, dans la première phase du projet, avaient pour rôle de construire les bases d’une ontologie urbaine, en rassemblant les termes utilisés dans le domaine de l’aménagement et de l’urbanisme. A partir de ces termes, il a fallu mettre en évidence les concepts et les relations entre ces concepts. La première année, il a été décidé de s’intéresser au domaine de la voirie. Deux étudiants du département Génie Civil et Urbanisme (GCU) de l’INSA de Lyon, ont adopté la méthode de travail basée sur la documentation pour l’identification des concepts de la voirie en se basant sur les travaux de (Aussenac-Gilles N, Bourigault D, 2003). Ainsi ils ont travaillé sur des documents comme : l’ouvrage de Chantal Berdier : Le dictionnaire de la voirie, le Dictionnaire de l’urbanisme et de l’aménagement et le Grand dictionnaire terminologique. La plupart de ces documents n’étaient pas disponibles au format électronique. La deuxième année, l’équipe s’est intéressée au domaine de la mobilité et des transports. Ainsi un autre stagiaire de GCU a utilisé des questionnaires pour identifier les concepts. Dans un souci de représentativité, le public interrogé avec le questionnaire a été le plus large possible : étudiants INSA de GCU de différentes options, doctorants de l’EDU, enseignants-chercheurs de l’EDU, et professionnels de l’urbanisme. Comme résultats, le travail avec les documents a permis de définir plus de 800 concepts dans le domaine de la voirie (exemple : chaussée, trottoir, marquage au sol). Ce qui veut dire que dès la première année nous avions plus de 800 concepts (langue française) dans le projet Towntology. La méthode avec les questionnaires a permis de rassembler environ 50 concepts du domaine de la mobilité et des transports (exemple : Accessibilité, Pollution, Usager). Pour formaliser la sémantique des définitions 12 types de relation entre les concepts ont été déterminés (voir Figure 7.). Ces types de relation sont utilisés pour établir plusieurs centaines de relations entre les concepts. Ci-dessous nous montrons un extrait de notre ontologie sous forme de réseau sémantique. Il contient en même temps des concepts de la voirie et de la mobilité.

Figure 7. Extrait de l’ ontologie de la voirie et des transports

5.2. Difficultés rencontrées par nos experts La première année, les travaux de nos experts ont abouti à la construction d’un hypertexte terminologique contenant pour chaque terme l’ensemble des définitions trouvées dans la documentation. Pour expliciter les liens entre les termes, une série de fichier power point (un par type de relations) représentant les relations entre les termes ont été construits.

La deuxième année l’équipe de GCU à travailler à la construction d’une ontologie en utilisant l’outil towntology. Dans cette section, nous avons identifié les difficultés rencontrées par nos experts la première année et évalué la deuxième année si l’outil permettait de résoudre ces problèmes. Qu’est ce qu’un concept ? Le premier problème de nos experts était de comprendre la notion de concept et les liens entretenus entre les concepts et les termes. Pour eux il manipulait toujours des termes et ne voyait pas la distinction entre un terme et un concept surtout dans le cas d’objet concret. De leur point de vue, une « rue » n’est pas un concept, mais la notion abstraite de « mobilité » est un concept. Concept était dans leur langage synonyme d’abstraction et s’oppose à concret. Cette notion de concept a été masquée par l’emploi de l’outil towntology. En effet le concept apparaît lorsque les points de vues sont associés au terme ou quand les définitions du terme sont jugées similaires. L’ajout du point de vue permet de construire à partir du même terme des concepts distincts sans forcément que l’utilisateur ait conscience du besoin de créer des concepts distincts. Qu’est ce qu’un point de vue ? Certains termes présentaient des difficultés à être définis précisément. Le choix des points de vue à leur associer n'était pas évident à cause de la diversité des acteurs et de la diversité de leurs tâches inhérentes à l’étendu du domaine de l’urbain. L’outil towntology ne permet pas de résoudre ces difficultés. En effet il s’agit plus d’un problème de spécification d’ontologie . Lors de cette phase, il faut identifier précisément les différents types d’acteurs et l’ensemble des tâches qui devront être pris en compte dans la modélisation du domaine. Comment visualiser le réseau de relations ? L’un des problèmes majeurs rencontrés par nos experts se situait au niveau de la navigabilité dans la base terminologique. Les fichiers power point décrivant les relations entre les termes ne permettaient pas de visualiser le voisinage d’un concept, car toutes les connaissances associées à un concept étaient dispersées dans plusieurs fichiers. De plus l’ensemble du réseau des relations n’était pas visible dans sa globalité. Le premier intérêt de l’outil towntology concerne les fonctionnalités de visualisation et de navigation dans le réseau des relations. Le fait de voir le voisinage du concept incluant toutes les relations qu’il entretient avec d’autres concepts facilite sa compréhension et permet de voir si une relation a été oubliée. L’outil offre 3 fonctionnalités de recherche suivant les préférences de l’utilisateur : recherche dans la liste alphabétique des concepts, navigation dans le graphe, accès au graphe par les images.

De plus, l’éditeur offre la possibilité de calculer le nombre de concepts voisins pour évaluer la connexité du réseau et trouver les concepts isolés. Il manque plusieurs autres fonctionnalités dans l’outil comme le fait de filtrer le graphe pour n’afficher que les relations d’un certain type. Il faudrait aussi enrichir le voisinage d’un concept en ajoutant de nouvelles relations calculées à partir des propriétés de transitivités des relations existantes. Par rapport aux autres outils d’édition d’ontologie le fait de ne pas forcer la construction d’une hiérarchie de concepts de manière ascendante a été jugé comme un atout important par nos utilisateurs non informaticiens. Combien de types de relations sont nécessaires ? La recherche de l'équilibre entre le nombre de relations à représenter, et l'intérêt qu'elles présentent, a été un enjeu important. En effet les types de relations trop spécifiques ne sont pas réutilisables par d’autres experts et à l’inverse, si la sémantique de la relation est trop généraliste, l’utilisateur ne voit même pas l’intérêt de la représenter. La possibilité de définir des types de relations dans l’outil towntology et d’expliquer leur signification a donc contribué à étendre ce problème. Par conséquent, une étude devra être mener pour permettre d’aider les experts dans le choix de leur type de relation. Nous savons par exemple que les types de relations comme la spécialisation ou la composition sont des relations nécessaires aux ontologies mais les experts ont peut être besoin de relations propres à leur domaine d’étude. Où trouver le sens d’un terme ? Enfin certains termes sont difficiles à intégrer au réseau de relations, car ce sont des mots nouveaux très peu utilisés et dont la sémantique est en cours de construction : c‘est à dire qu’il n’existe pas de définitions acceptées par un groupe d’utilisateurs. L’outil towntology peut permettre d’aider à expliquer les différents points de vue sur ces terminologies en cours d’évolution en présentant l’évolution du sens de ces termes au cours du temps. Mais ces termes ne seront pas forcément sélectionnés pour la conceptualisation du domaine.

6. Perspectives Il existe des approches de développement d’ontologies qui assistent les experts pour atteindre le consensus dans le cadre du travail collaboratif. Dans ce domaine, nous pouvons citer entre autres les systèmes Ontolingua Server (Farquhar et al., 1996), APECKS (Jenifer Tennison, 1998), CO4 (Euzenat, 1997) , et Protégé-2000 (Natalya et al., 2001). Nos travaux futurs porteront sur l’amélioration de l’outil towntology pour en faire un système de conception coopératif afin d’aider les experts à atteindre un consensus.

De plus notre outil devra être modifier pour accentuer la formalisation de l’ontologie lorsque la conceptualisation a atteint un certain niveau de stabilité.

7. Conclusion Dans cet article nous avons présenté notre outil ( ses spécifications et interfaces) d’aide à la construction d’ontologies pré-consensuelles dans le domaine de l’urbanisme. Nous avons aussi parlé des problèmes rencontrés par nos experts dans la phase d’élaboration de ce type d’ontologie. En effet, la première équipe d’experts a travaillé sans outil alors que la seconde a travaillé avec l’outil pour construire une ontologie du domaine de l’urbanisme. Ainsi nous avons montré l’apport de notre outil dans la conception, la présentation et l’interrogation des ontologies. Enfin l’ontologie pré consensuelle construite par nos experts est à compléter et à approfondir pour être exploitable par des systèmes à base de connaissances. Nous n’avons pas la prétention d’avoir fait un outil parfait et fini, et l’objectif à court terme est d’étendre cet outil pour la construction collaborative d’ontologies afin d’atteindre un consensus.

8. Bibliographie AUSSENAC-GILLES N., BIÉBOW B., SZULMAN N., Revisiting Ontology Design: a method based on corpus analysis. Knowledge engineering and knowledge management: methods, models and tools, Proc. of the 12th International Conference on Knowledge Engineering and Knowledge Management. Juan-Les-Pins (F). Oct 2000. R Dieng and O. Corby (Eds). Lecture Notes in Artificial Intelligence Vol 1937. Berlin: Springer Verlag. pp. 172-188. 2000. Aussenac-Gilles N, Bourigault D. "Construction d'ontologies à partir de textes". Actes de la 10° conférence sur le Traitement Automatique des Langages Naturelles TALN, 2003, Batz-sur-Mer (F), 11 juin 14 juin 2003. Université de Nantes. Bachimont Bruno: "Engagement sémantique et engagement ontologique : conception et réalisation d'ontologies en ingénierie des connaissances"; In "Ingénierie des connaissances, 2000 ? Corcho, O., Gomez-Perez, A. A Roadmap to Ontology Specification Languages. Domingue J. Tadzebao and WebOnto: Discussing, Browsing, and editing ontologies on the web. In Proceedings of the 11th Knowledge Acquisition for Knowledge-Based Systems Workshop, Ban, Canada, 1998. Farquhar A. “The Ontolingua Server: a tool for collaborative ontology construction”, 10th knowledge Acquisition Workshop, Banff, Canada, 1996; Fluit C., Sabou M., F. van Harmelen, “Ontology-based Information Visualization,” Proceedings of Information Visualization ’02, 2002.

Gansner E., North S. An open Graph Visualization System and its Application to Software Engineering, Software-Practice and Experience 1-5. 1999. Gómez-Pérez A., Fernández-López M., Corcho O. (2004) "Ontological Engineering" Springer Verlag Advanced Information and Knowledge Processing, 1st ed. 2004. 2nd printing, 2004, XII, 403 p. 159 illus., Hardcover ISBN: 1-85233-551-3 Gruber, T.R. "A Translation Approach To Portable Ontology Specifications". In Knowledge Acquisition, 1993, Vol. 5, N° 2. Keita A., Laurini R., Roussey C., Zimmerman M. (2004) "Towards an Ontology for Urban Planning: The Towntology Project". In CD-ROM Proceedings of the 24th UDMS Symposium, Chioggia, October 27-29, 2004, pp 12.I.1 Laurini R. (1998) "Groupware for Urban Planning: An Introduction". Journal "Computers, Environment and Urban Systems", Vol. 22,4 July 1998, pp. 317-333. Lena DB, Guha RV (1990). Building Large Knowledge-based Systems: Representation and Inference in the Cyc Project. Addison-Wesley, Boston, Massachusetts. Natalya M.S., Ray Fergerson, “Creating Semantic Web Contents with Protégé-2000”, IEEE Intelligent Systems, vol. 16 (2), 2001; OWL: Ontology Web Language. http://www.w3.org/TR/owl-features/ Staab S, Schnurr HP, Studer R, Sure Y (2001) Knowledge Processes and Ontologies. IEEE Intelligent Systems 16 (1):26-34 Storey M.A., Musen M. Jambalaya: Interactive visualization to enhance ontology authoring and knowledge acquisition in Protégé. In Workshop on Interactive Tools for Knowledge Capture, Victoria, B.C Canada, October 2001; Tunkelang D. “JIGGLE: Java Interactive Graph Layout Algorithm.” GD ’98, LNCS 1547. pp. 413-422. 1998 Uschold, M., Gruninger, M. "Ontologies: Principles, Methods and Applications". In Knowledge Engineering Review, June 1996, Vol. 11, N° 2. XML: The Extensible Markup Language Specification, W3C Recommendation, http://www.w3.org/TR/REC-xml. Zimmermann M, Laurini R, Roussey C, Beaulieu, C., Tardy, Y., Zimmermann, M. "Le projet Towntology, un retour d’expérience pour la construction d’une ontologie urbaine. Revue Internationale de Géomatique, 2004.