# ATLANTIS: Une ontologie pour représenter les Instructions nautiques

Helen Mair Rawsthorne, Nathalie Abadie, Eric Kergosien, Cécile Duchêne, Éric Saux

► To cite this version:

Helen Mair Rawsthorne, Nathalie Abadie, Eric Kergosien, Cécile Duchêne, Éric Saux. ATLANTIS: Une ontologie pour représenter les Instructions nautiques. Conférence Nationale d'Intelligence Artificielle, Zied Bouraoui; Valérie Camps; Éric Gaussier; Maxime Guériau; Christelle Launois; Nicolas Prcovic; Céline Rouveirol; Fatiha Saïs; François Schwarzentruber; Anaëlle Wilczynski, Jun 2022, Saint-Étienne, France. pp.155-162. [hal-04419907](https://hal.science/hal-04419907v1)

HAL Id: hal-04419907

https://hal.science/hal-04419907v1

Submitted on 26 Jan 2024

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 Attribution 4.0 International License
# ATLANTIS : Une ontologie pour représenter les
*Instructions nautiques*

H. M. Rawsthorne¹, N. Abadie¹, E. Kergosien², C. Duchêne³, E. Saux⁴

¹ LASTIG, Univ Gustave Eiffel, IGN-ENSG, F-94165 Saint-Mandé, France

² GERiICO, Université de Lille, F-59000 Villeneuve d'Ascq, France

³ LASTIG, Univ Gustave Eiffel, IGN-ENSG, F-77420 Champs-sur-Marne, France

⁴ IRENav, École navale, Lanvéoc-Poulmic, CC 600, F-29240 Brest Cedex 9, France

helen/rawsthorne@ign.fr

## Résumé

Les Instructions nautiques sont une série d'ouvrages produits et publiés par le Service hydrographique et océanographique de la Marine (Shom) qui donnent aux navigateurs les informations nécessaires pour naviguer près des côtes et accéder aux ports. Dans cet article, nous présentons l'ontologie ATLANTIS (coAsTaL mAritime NavigaTion InstructionS) que nous avons développée pour modéliser les connaissances contenues dans ces ouvrages, ainsi qu'un retour d'expérience et des adaptations que nous avons apportées à la Simplified Agile Methodology for Ontology Development (SAMOD), la méthodologie de développement d'ontologies que nous avons employée.

## Mots-clés

Environnement maritime côtier, Instructions nautiques, navigation maritime côtière, ontologie.

## Abstract

The Instructions nautiques are a series of books produced and published by the French Naval Hydrographic and Oceanographic Service, the Shom. They contain information on navigating in coastal waters and accessing ports. In this article we present the ATLANTIS (coAsTaL mAritime NavigaTion InstructionS) ontology that we have developed to model the knowledge contained in these books. We also give feedback on the Simplified Agile Methodology for Ontology Development (SAMOD), which we used to create our ontology, and present the modifications that we made to it.

## Keywords

Coastal maritime environment, Instructions nautiques, coastal maritime navigation, ontology.

## 1 Introduction

Les Instructions nautiques sont une série d'ouvrages produits et publiés par le Service hydrographique et océanographique de la Marine (Shom). Elles décrivent l'environnement maritime côtier depuis le point de vue d'un navire et donnent les informations nécessaires pour naviguer près de la côte et accéder aux ports. Les Instructions nautiques

sont utilisées par les navigateurs (civils ou militaires, professionnels ou plaisanciers) en complément des cartes marines papier ou électroniques pour planifier leur itinéraire de navigation. Elles apportent des informations qui, pour des raisons de lisibilité, ne sont pas affichées sur une carte marine, et contribuent donc à la sécurité de la navigation maritime. Aujourd'hui, les connaissances contenues dans les Instructions nautiques existent uniquement sous forme de texte en langage naturel. Ceci impose au Shom un processus exigeant d'actualisation et de vérification manuelle du contenu des ouvrages. Pour les utilisateurs, la forme des Instructions nautiques implique une lecture attentive pour trouver les informations recherchées. Sous cette forme, les connaissances sont difficilement réutilisables. Les travaux de thèse de [15] ont porté sur la formalisation des connaissances contenues dans les Instructions nautiques du Shom via la création d'un langage contrôlé. Le but du langage proposé est de « servir de pivot entre la rédaction du texte par l'opérateur dédié, la production de l'ouvrage imprimé ou en ligne, et l'interaction avec des bases de connaissances et des outils d'aide à la navigation ». Or, la base de connaissances couvrant le contenu des Instructions nautiques sur laquelle le langage est censé s'appuyer n'existe pas à ce jour. Nous visons donc à structurer et à géoréférencer le contenu des Instructions nautiques et le stocker dans une base de connaissances. À terme, cette base de connaissances pourra servir à alimenter une plateforme permettant aux utilisateurs des Instructions nautiques d'interroger le contenu des ouvrages. Ils pourront, au lieu de lire le texte intégral, accéder aux informations souhaitées en réalisant des recherches par facettes et notamment par zone géographique. Une première étape vers la création de cette base de connaissances consiste à se doter d'une ontologie.

Dans cet article nous présentons ATLANTIS, l'ontologie que nous avons développée pour la base de connaissances, ainsi que la méthodologie que nous avons suivie. Nous avons adopté la Simplified Agile Methodology for Ontology Development (SAMOD) [12, 13], à laquelle nous avons apporté des modifications afin de l'adapter à notre projet. Les deux contributions de cet article sont (1) ATLANTIS, l'on-
tologie du domaine des *Instructions nautiques* et (2) le tour d'expériences et les adaptations de la méthodologie SAMOD. Dans la section 2, nous recensons les travaux connexes à nos recherches. Un premier état de l'art porte sur les ontologies et thésaurus existants sur le domaine maritime. Le second porte sur les méthodologies de développement d'ontologies et le choix que nous avons fait. La section 3 présente SAMOD, la méthodologie de développement d'ontologie sur laquelle nous nous sommes appuyés, et la manière dont nous l'avons mise en œuvre pour créer et tester ATLANTIS. Enfin, dans la section 4 nous présentons nos adaptations concernant SAMOD avant de conclure dans la section 5. Cet article est une version raccourcie de [14], qui présente plus en détail les *Instructions nautiques* et qui contient un état de l'art plus conséquent.

# 2 État de l'art

## 2.1 Ontologies et thésaurus maritimes

D'autres travaux ont porté sur la création d'ontologies et de thésaurus du domaine maritime. En particulier, [9] a proposé une ontologie pour l'information spatiale dans le domaine de la navigation maritime. Elle est fondée sur plusieurs sources officielles de connaissances maritimes, notamment les *United States Coast Pilot*. Cette série d'ouvrages, publiée par la *National Oceanic and Atmospheric Administration (NOAA)*, constitue l'équivalent des *Instructions nautiques* aux États-Unis. Ce travail pourrait constituer une base importante pour notre cas d'application. Cependant, à notre connaissance, cette ontologie n'est pas publiée sur le Web et nous n'en avons pas retrouvé de trace en dehors des publications qui la décrivent.

L'ensemble d'ontologies *Semantic Web for Earth and Environmental Terminology* (SWEET) a été développé par le *Jet Propulsion Laboratory* au *California Institute of Technology* sous contrat avec la NASA. Il porte sur les sciences de la Terre et contient donc des éléments qui nous intéressent, tels que les phénomènes météorologiques et océanographiques. L'Agence européenne pour l'environnement (AEE) a développé le *General Multilingual Environmental Thesaurus* (GEMET), une source commune de terminologie utilisée dans le cadre de l'agenda environnemental. Il contient de nombreux termes désignant des types d'entités spatiales, dont des entités du domaine côtier telles que *anse* et *port*. Le Thésaurus Eau, qui a été créé par les six Agences de l'Eau, l'Onema (Office national de l'eau et des milieux aquatiques), la Direction de l'Eau et de la Biodiversité du Ministère de l'Écologie et du Développement Durable ainsi que l'Office International de l'Eau, contient certains termes désignant des types d'entités géographiques du domaine de l'eau telles que *voie navigable* et *zone de mouillage*. Le NERC *Vocabulary Server* (NVS) est géré par le *British Oceanographic Data Centre* et le *National OceanoGRAPHY Centre* (NOC), et est financé par le *Natural Environment Research Council* (NERC) au Royaume-Uni. Il est destiné aux sciences marines et contient notamment des thésaurus portant sur l'océanographie. Les thésaurus suivants nous intéressent particulièrement : l'Oregon Coastal

*Atlas Coastal Erosion Thesaurus*, le MIDA *Coastal Erosion Thesaurus* et le *Marisaurus Thesaurus*. Ils contiennent des types d'entités géographiques du domaine maritime telles que *balise* et *épave*. Le NVS héberge également deux théésaurus qui contiennent des termes désignant des types de navires tels que *navire de pêche* et *navire militaire*. Ce sont le *World Meteorological Organisation voluntary observing ship category* et le *SeaVoX Platform Categories*.

En l'absence d'ontologies existantes qui modélisent les consignes de navigation et l'ensemble des entités et phénomènes de l'environnement maritime côtier, nous en avons développé une et l'avons liée, autant que possible, aux théésaurus existants. Ce travail est décrit dans la section 3.

## 2.2 Méthodologies de développement d'ontologies

Nous cherchons à créer une ontologie de domaine pour présenter les connaissances contenues dans les *Instructions nautiques* et que des utilisateurs seraient susceptibles de rechercher. Nous avons donc besoin d'une méthodologie de création d'ontologie de domaine extensible, liée à d'autres vocabulaires, qui prenne en compte les besoins des utilisateurs, et qui n'impose pas une structure de données trop complexe à peupler de façon automatique à partir du texte des *Instructions nautiques*. Ces deux derniers critères impliquent de tester le peuplement de l'ontologie et l'interrogation des données au cours de sa construction pour s'assurer de sa bonne adéquation.

Nous avons étudié et comparé 10 méthodologies de développement d'ontologies. Toutes commencent avec une phase d'acquisition de connaissances, de rédaction de documents de spécification ou de questions de compétence. L'étape d'intégration de concepts provenant d'autres ontologies ou ressources existantes permet de différencier les méthodologies car elle n'est pas effectuée au même moment : elle est prévue au début du processus de développement d'ontologies dans *Ontology Development 101* [10] tandis qu'elle est réservée à la dernière étape dans SAMOD. NeOn [22], SAMOD et MOMo [16] proposent des consignes pour créer des ontologies modulaires. Certaines méthodologies, notamment OTK [21], NeOn et SAMOD, explicitent une méthode pour évaluer l'ontologie produite lors de l'étape finale. METHONTOLOGY [2] recommande un guide d'évaluation publié dans une autre ressource et HCOME [7] souligne le besoin d'effectuer une évaluation sans proposer de stratégie. *Ontology Development 101*, DOGMA [6], DOGMA-MESS [1] et MOMo n'intègrent aucune évaluation de l'ontologie produite, les rendant moins adaptées à nos besoins. DOGMA-MESS, DILIGENT [23] et HCOME sont orientées vers une application inter-organisationelle ou multi-acteur car elles permettent ou exigent le développement de l'ontologie en parallèle par les différents acteurs impliqués. Cette façon de travailler n'est pas adaptée à notre contexte, c'est pourquoi nous les avons écartées. SAMOD et MOMo proposent un développement modulaire de l'ontologie qui est construite petit à petit, soit en ajoutant, à chaque itération, la modélisation d'une partie supplémentaire du domaine, soit en
modélisant toutes les parties du domaine d'abord, puis en les fusionnant. NeOn se distingue des autres méthodologies présentées car elle fournit de nombreuses approches pour élaborer une ontologie ou un réseau ontologique. Elle demande aux ontologues de réaliser préalablement une analyse approfondie du projet afin de pouvoir choisir la bonne combinaison des processus et activités proposés.

Finalement, la méthodologie que nous avons choisie est SAMOD, essentiellement pour trois raisons. Premièrement, elle permet de créer un premier squelette qui répond à l'essentiel des besoins puis de l'améliorer et de l'étendre de façon itérative. Deuxièmement, l'approche de développement modulaire est adaptée à un grand domaine comme celui des *Instructions nautiques*. Troisièmement, elle intègre des phases de tests. Une des phases, fondée sur la transformation de questions informelles de compétence en requêtes SPARQL, permet de tester aussi bien le modèle que la création des données destinées à le peupler.

# 3 Mise en œuvre de SAMOD

SAMOD exige l'implication de deux types de personnes : des experts du domaine et des ontologues. Les experts doivent pouvoir décrire d'une manière détaillée le domaine en question. Les ontologues doivent être capables de construire une ontologie en utilisant un langage formel à partir des descriptions informelles fournies par les experts.

## 3.1 Sources de connaissances

En premier lieu, SAMOD conseille aux ontologues de récolter les informations à propos du domaine choisi avec l'aide des experts. Nous avons utilisé deux sources principales de connaissances sur le domaine de la navigation et de l'environnement maritime côtier : les documents de référence et les interactions avec les experts du domaine.

### 3.1.1 Les documents de référence du domaine

Du Shom, en plus de la série d'*Instructions nautiques* nous avons utilisé l'ouvrage *Signalisation maritime* [17], l'ouvrage *Symboles, abréviations et termes utilisés sur les cartes marines papier* [19] et un document décrivant la base de données *Balisage maritime* [18]. De l'Organisation hydrographique internationale (OHI), nous avons consulté l'*S-32 IHO Hydrographic Dictionary* [3] ainsi que le catalogue en ligne des objets décrits dans la norme S-57 [5]. Enfin, de l'Association Internationale de Signalisation Maritime (AISM) nous avons utilisé le manuel des aides à la navigation maritime, le *Navguide* [4].

### 3.1.2 Les connaissances d'experts du domaine

Nous avons identifié deux types d'experts du domaine des *Instructions nautiques* : les rédacteurs de ces ouvrages d'un côté, et les utilisateurs des ouvrages de l'autre, aussi appelés utilisateurs finaux. Ces deux groupes d'experts interagissent d'une manière différente avec les *Instructions nautiques* et ont donc leurs propres besoins les concernant. Les utilisateurs ont des habitudes de consultation efficace des *Instructions nautiques*, en parallèle des cartes marines et d'autres sources d'informations, pour planifier un itinéraire de navigation. Les rédacteurs, eux, maîtrisent toute

la chaîne éditoriale des *Instructions nautiques*. Nous avons ainsi organisé une série d'entretiens avec les utilisateurs et deux réunions avec les rédacteurs. Ces interactions sont détaillées dans la section 4.1.

## 3.2 Production de documentation

SAMOD conseille ensuite de choisir une sous-partie du domaine à modéliser. Le sous-modèle correspondant est appelé un *modelet*. Les ontologues et les experts du domaine travaillent ensemble afin de rédiger un argumentaire à propos de la sous-partie du domaine. Un argumentaire donne une description en langage naturel du problème à traiter par le modelet ainsi qu'un ou plusieurs exemples illustratifs. L'argumentaire doit être rédigé en utilisant le vocabulaire employé dans le domaine. À partir de l'argumentaire, les ontologues et les experts rédigent une liste de questions informelles de compétence. Ces questions, rédigées en langage naturel, représentent les besoins exprimés dans l'argumentaire et auxquels l'ontologie doit permettre de répondre. Pour chaque question, il faut également préciser le type de réponse attendue et fournir quelques exemples. Le dernier document à produire est un glossaire des termes utilisés dans cette sous-partie du domaine.

Nous avons préparé quatre modelets correspondants aux sous-domaines identifiés dans les *Instructions nautiques* : (1) les navires, (2) les consignes de navigation et les règlements, (3) les entités pérennes de l'environnement maritime côtier et les relations spatiales, et (4) les temporalités et les phénomènes météorologiques et océanographiques. Par la suite, nous allons prendre comme exemple le modelet (3). L'extrait des *Instructions nautiques* de la figure 5 illustre la manière dont les entités pérennes de l'environnement maritime côtier et leurs relations spatiales sont décrites. La figure 1 montre un extrait de l'argumentaire que nous avons rédigé pour ce modelet, à l'aide des documents de référence décrits dans la section 3.1.1 et après avoir analysé et syn-

**Nom** : Entités pérennes de l'environnement maritime côtier et relations spatiales

**Description** : Les *Instructions nautiques* contiennent des références à des entités pérennes de l'environnement maritime côtier et à des relations spatiales entre elles. Une entité pérenne de l'environnement maritime côtier peut être une entité géographique ou une aide virtuelle à la navigation. Elles sont citées dans les *Instructions nautiques* dans les descriptions de paysages, dans les consignes de navigation, dans les règlements et dans les descriptions de phénomènes météorologiques et océanographiques. Elles peuvent être utilisées pendant une navigation pour se situer localement [...]

**Exemple 1** : « Le *canal de l'île de Batz* est un chenal profond de 0,4 à 10 m qui sépare l'île de Batz de la côte et donne accès aux ports d'échouage de **Porz Kernok** (île de Batz) et de Roscoff. » [20, p. 398]

**Exemple 2** : « La *pointe de Bloscon* porte la *chapelle de Sainte-Barbe* (48° 43,53' N — 3° 58,28' W), de couleur blanche. Plus à l'Ouest, on voit le clocher de Roscoff (48° 43,59' N — 3° 59,16' W) et, juste au Sud, les installations portuaires de Roscoff-Bloscon. » [20, p. 399]

<caption>FIGURE 1 – Extrait de l’argumentaire du modelet.</caption>
thétisé l'utilisation et l'importance de ces concepts et de ces propriétés dans les textes des *Instructions nautiques*. Il contient le nom du modelet, une description expliquant la thématique dans le cadre des *Instructions nautiques* et son importance, ainsi que des extraits du texte qui montrent la manière dont la thématique s'y manifeste.

Nos questions informelles de compétence correspondent aux types d'informations recherchées par les utilisateurs des *Instructions nautiques*, d'après les résultats des entretiens mentionnés dans la section 3.1.2. La figure 2 en montre trois exemples pour le modelet « Entités pérennes de l'environnement maritime côtier et relations spatiales ».

**Question 1 : Comment est le phare de l'île de Batz ?**

**Type de réponse** : Une liste des caractéristiques physiques du phare de l'île de Batz et de ses relations spatiales.

**Exemple de réponse** : Le phare de l'île de Batz est de couleur grise, haut de 43 mètres, équipé d'une balise d'émission AIS, entouré d'un groupe de maisons.

**Question 2 : Où se situe le clocher de Roscoff ?**

**Type de réponse** : Les coordonnées géographiques du clocher de Roscoff et une liste de ses relations spatiales.

**Exemple de réponse** : Le clocher de Roscoff est situé à 48° 43,59' N — 3° 59,16' W, à l'ouest de la chapelle de Sainte-Barbe et au nord des installations portuaires de Roscoff-Bloscon.

**Question 3 : Quels amers sont visibles sur l'île de Batz ?**

**Type de réponse** : Une liste des amers sur l'île de Batz.

**Exemple de réponse** : L'île de Batz porte le phare de l'île de Batz, la chapelle de Notre-Dame de Bon Secours, le clocher de l'île de Batz, un sémaphore et la tour du sémaphore.

<caption>FIGURE 2 – Trois exemples de questions informelles de compétence du modelet.</caption>

Nous avons ensuite rédigé le glossaire (cf. figure 3) dans lequel nous expliquons les termes du domaine, comme par exemple « Alignement » et « Marque latérale », grâce aux définitions données dans les documents de référence. Nous donnons également nos propres définitions pour les concepts que nous avons créés dans le cadre du modelet, tels que « Lieu de stationnement ».

À partir de l'argumentaire, des questions informelles de compétence et du glossaire, SAMOD indique que les onto- logues commencent ensuite à travailler sans les experts du domaine afin de créer le modelet dans un langage formel.

## 3.3 Structure et formalisation d'un modelet

Un extrait du graphe du modelet « Entités pérennes de l'environnement maritime côtier et relations spatiales » est présenté dans la figure 4. Ce modelet contient trois classes principales. La première, `gsp:Feature`, est une classe issue de l'ontologie GeoSPARQL. GeoSPARQL est un standard de représentation et d'interrogation d'en- tités géographiques. Ce standard nous permet de défi- nir la géométrie des entités et d'accéder à leurs des- criptions (en WKT ou GML) par des propriétés. Nous avons identifié deux types distincts d'entités pérennes de l'environnement maritime côtier : des entités physiques,

**Alignement** : « Ligne droite définie par deux ou plusieurs amers clairement indiqués sur une carte, le long de laquelle un navire peut faire route en toute sécurité, pour entrer dans une passe, parer un danger, etc. » [3]. Un alignement est une aide virtuelle à la navigation.

**Lieu de stationnement** : Un lieu de stationnement est un point ou une zone géographique où un navire peut stationner tem- porairement ou d'une manière permanente soit en mouillant (jeter l'ancre du navire), soit en amarrant (attacher le navire à un amarrage), soit en échouant (laisser le navire toucher le fond à marée basse). Un lieu de stationnement peut être défini par la position d'un corps-mort, [...].

**Marque latérale** : « Les marques latérales, dont l'emploi est associé à un « sens conventionnel de balisage », sont généra- lement utilisées pour des chenaux bien définis. Ces marques indiquent les côtés bâbord et tribord de la route à suivre. [...] Les marques latérales diffèrent suivant qu'elles sont em- ployées dans l'une ou l'autre des régions de balisage A et B. » [17]. Dans la région A, une marque de bâbord est de couleur rouge et une marque de tribord est de couleur verte. Dans la région B, les couleurs sont inversées.

<caption>FIGURE 3 – Extrait du glossaire du modelet.</caption>

visibles, et des entités virtuelles, telles que des aligne- ments, des dispositifs de séparation du trafic et des sec- teurs de feux. La classe `gsp:Feature` est donc divi- sée en deux sous-classes : `nav:EntiteGeographique` et `nav:AideVirtuelleALaNavigation`. Les deux autres classes principales, `nav:DirectionCardinale` et `nav:DirectionLaterale`, sont dédiées à contenir les instances permettant de décrire les caractéristiques d'en- tités telles que les marques latérales (cf. figure 3) et les directions de phénomènes météorologiques et océanogra- phiques tels qu'un vent ou un courant.

Nous avons décidé de créer un thésaurus SKOS pour les entités géographiques physiques : `nav:TypeDEntiteGeographique`. Ce choix a été fait parce que le formalisme d'un thésaurus SKOS est plus simple que le formalisme descriptif rigoureux des ontolo- gies définies avec OWL, et ne nécessite pas une description formelle de la sémantique [11]. Cela signifie qu'il sera plus facile d'enrichir un thésaurus par de nouveaux concepts SKOS que de créer automatiquement de nouvelles classes lors du peuplement de la base de connaissances. De plus, les éléments décrivant les types d'entités géographiques ne nécessitent pas l'ajout d'axiomes en plus de leurs relations hiérarchiques. Dans ce thésaurus nous avons créé trois sous- thésaurus : `nav:TypeDAmer`, `nav:TypeDeDanger` et `nav:TypeDeLieuDeStationnement`. Ils servent à rassembler les groupes d'entités géographiques physiques que nous pourrions vouloir isoler dans une requête.

Grâce aux entretiens avec des utilisateurs des *Instructions nautiques*, nous avons appris qu'ils cherchent en priorité quatre éléments principaux. Les informations sur les com- munications à réaliser sont recherchées pour savoir qui contacter, à quel moment et comment (numéro de téléphone ou canal VHF). Les photographies, surtout d'amers, sont fortement recherchées afin d'avoir une meilleure représen- tation de ce qu'il faut s'attendre à voir à l'horizon et de
<figure><img src="image_2.png" /><figcaption>FIGURE 4 – Un extrait du graphe du modelet.</figcaption></figure>

ce à quoi ressemble le paysage côtier en réalité. Les informations sur les ports, surtout sur les approches et les entrées, sont très recherchées ainsi que les informations administratives, celles sur le pilotage ou encore celles plus spécifiques à chaque port. Enfin, également très recherchés sont les amers, les alignements (cf. figure 3) et les feux. En cherchant des informations à propos, par exemple, d'un amer, les utilisateurs cherchent plutôt l'ensemble des caractéristiques le décrivant. Avant de consulter les Instructions nautiques, ils ne savent pas a priori quelles informations seront disponibles. Nous répondons à ce besoin spécifique en créant une hiérarchie dans les propriétés d'objets afin de pouvoir récupérer par inférence toutes les caractéristiques d'une instance de la classe gsp:Feature. Le propriété d'objets nav:aPourCaracteristique a donc plusieurs sous-propriétés telles que nav:aPourForme et nav:estDeCouleur.

Pendant les réunions avec les rédacteurs des Instructions nautiques, nous avons pris conscience qu'il est vital, pour des raisons de sécurité, de conserver les indications d'importances relatives mentionnées dans le texte. La phrase « Vue du Nord, l'Île de Batz montre la tour du sémaphore (48° 44,78' N — 4° 00,69' W) et surtout le phare (48° 44,72' N — 4° 01,61' W), tour grise haute de 43 m, entourée de maisons. » [20, p. 398] illustre ce problème. La hiérarchie indiquée par le mot « surtout » permet d'aider un navigateur dans des conditions de mauvaise visibilité en lui conseillant de privilégier, comme amer, le phare plutôt que la tour du sémaphore. Afin de résoudre ce problème, et d'autres problèmes similaires possibles liés à des nuances subtiles mais importantes dans le texte, nous avons décidé d'associer à chaque instance la phrase initiale qui la mentionne dans le texte. La propriété de données nav:aPourTexteAssocie a donc comme domaine gsp:Feature et comme range xsd:string.

Nous avons également créé des axiomes permettant

de classer automatiquement certaines entités selon leurs propriétés et d'inférer de nouvelles connaissances. Nous allons prendre comme exemple la classe nav:MarqueLateraleTribordRegionA qui est destinée à stocker les instances de marques latérales tribord (cf. figure 4). Dans les Instructions nautiques, les marques peuvent être aussi bien désignées (1) uniquement par leur nature physique (balise, bouée, espar, tourelle) et leur type (cardinal, eaux saines, danger isolé, latéral, spécial) que (2) en utilisant le terme « marque » avec une nature physique et un type. À titre d'exemple, l'extrait « Cette route laisse dans l'Ouest la balise latérale tribord » [20, p. 320] correspond au cas (1) et l'extrait « la tourelle « Grand Pot de Beurre » (48° 37,22' N — 4° 36,47' W), marque latérale bâbord du Grand Chenal » [20, p. 413] correspond au cas (2).

Dans notre ontologie, nous avons donc déclaré la classe nav:MarqueLateraleTribordRegionA comme :

```
nav: MarqueLateraleTribordRegionA owl:
    equivalentClass [ owl:intersectionOf ( [
        a owl:Class ;
        owl:unionOf ( nav:Balise
            nav:Bouee
            nav:Marque
            nav: Tourelle ) ]
    [ a owl:Restriction ;
    owl:onProperty nav:aPourTypeLateral ;
    owl:hasValue tdi:Tribord ]
    [ a owl:Restriction ;
    owl:onProperty nav:estDeCouleur ;
    owl:hasValue tco:Vert ] ) ]
    a owl:Class ] .
```

De cette manière, toute entité classée comme une instance de la classe nav:MarqueLateraleTribordRegionA sera inférée, par exemple, comme étant de couleur verte (cf. figure 3). Inversement, toute entité classée comme nav:Bouee, par exemple, ayant une propriété nav:aPourTypeLateral pointant vers l'instance tdi:Tribord et une autre propriété nav:estDeCouleur pointant vers l'instance tco:Vert, sera inférée comme faisant partie de la classe nav:MarqueLateraleTribordRegionA.

Puis, nous avons aligné manuellement notre ontologie avec les ressources maritimes cités dans la section 2.1 qui ont été publiés sur le Web, ainsi que des ontologies plus génériques telles que la Spatial Relations Ontology de l'Ordnance Survey au Royaume-Uni et l'Extent module de l'ontologie de haut-niveau PROTON, créée pour la gestion de connaissances et les applications du Web sémantique.

## 3.4 Tests et résultats

La dernière étape de SAMOD consiste à tester les modelets produits, d'abord avec un test de modèle, puis avec un test de données et finalement avec des tests de requêtes. Le modelet doit être ajusté jusqu'à ce que tous les tests soient concluants.

Un test de modèle implique la vérification de la cohérence
globale d'un modèle. Nous avons effectué des tests de modèle sur chaque modelet et sur l'ontologie fusionnée en utilisant le raisonneur HermiT 1.4.3.456 intégré à Protégé.

Un test de données consiste à vérifier la validité du modèle après son peuplement à l'aide de triplets d'instances. Les amers de l'île de Batz, ainsi que les principaux dagers qui entourent l'île, sont décrits sur la figure 5. Nous avons modélisé en triplets RDF et RDF-star une partie de cet extrait pour instancier l'ontologie (cf. figure 6, où l'entité ent:4004 correspond au phare de l'île de Batz). RDF-star est une extension de RDF qui permet de créer des triplets dont le sujet ou l'objet est lui-même un triplet. Le fait qu'il ait été possible de modéliser des textes grâce à notre ontologie assure la validation du test de données.

Un test de requête consiste à transformer une question informelle de compétence en requête SPARQL, l'exécuter et, si le test est probant, obtenir les réponses attendues. Considérons la question 3 présentée sur la figure 2 : « Quels amers sont sur l'île de Batz ? ». La requête SPARQL ci-dessous identifie l'entité spatiale « Île de Batz » et puis sélectionne les entités spatiales étant des amers ayant une relation spatiale geof:sfContains avec l'île :

<caption>01 5.4.2. De Roscoff à l'anse de Kernic</caption>

<caption>01 5.4.2.1. Île de Batz et canal de l'île de Batz</caption>

<caption>07 Vue du Nord, île de Batz montre la tour du sémaphore (48° 44,78' N – 4° 00,69' W) et surtout le phare (48° 44,72' N – 4° 01,61' W), tour grise haute de 43 m, entourée de maisons. L'île est débordée de tous côtés par des dangers. Les plus au large sont :</caption>

– à l'Est, la **Basse Astan**, couverte de 0,8 m d'eau, marquée par la bouée « Astan » (48° 44,91' N – 3° 57,66' W), cardinale Est lumineuse ;

– au Nord, la **Grande Basse** (48° 45,92' N – 4° 01,64' W), couverte de 0,5 m d'eau ;

– à l'Ouest, **Men Aodi** (48° 44,64' N – 4° 03,39' W), roche non balisée découvrant de 0,1 m.

13

<figure><img src="image_3.png" /><figcaption>5.4.2.1.A. – Phare de l'île de Batz, au SW (2012).</figcaption></figure>

FIGURE 5 – Un extrait des Instructions nautiques [20, p. 398].

<figure><img src="image_4.png" /><figcaption>FIGURE 6 – Un graphe de quelques triplets représentant l'entité correspondant au phare de l'île de Batz.</figcaption></figure>

SELECT DISTINCT ?typeDAmer ?labelAmer WHERE {

?entite nav:aPourNature teg:lle.

?entite rdfs:label ?label.

FILTER (regex(str(?label), "Batz"))

?entite geom:hasGeometry ?GeomIdB.

?GeomIdB gsp:asWKT ?WKTIdB.

?amer nav:aPourNature ?typeDAmer.

?typeDAmer a nav:TypeDAmer.

?amer geom:hasGeometry ?GeomAmer.

?GeomAmer gsp:asWKT ?WKT Amer.

OPTIONAL (?amer rdfs:label ?labelAmer).

FILTER (geof:sfContains(?WKTIdB, ? WKT Amer)).

Le tableau 1 présente les résultats de cette requête qui a identifié dans la base de connaissances cinq amers sur l'île de Batz. Quatre d'entre eux sont cités dans l'extrait des Instructions nautiques de la figure 5; l'autre est cité sur une autre page. Grâce à l'ontologie puis à cette requête, nous avons pu rassembler ces informations qui étaient dispersées dans le texte. Pour chaque amer, la requête a récupéré son type et, si disponible, son nom. Ceci correspond à un test de requête réussi.

<table><caption>TABLE 1 – Résultats de la requête SPARQL.</caption><thead><tr><td>typeDAmer</td><td>labelAmer</td></tr></thead><tbody><tr><td>teg:Phare</td><td>"phare de l'île de Batz"@fr</td></tr><tr><td>teg:Chapelle</td><td>"chapelle Notre-Dame de Bon Secours"@fr</td></tr><tr><td>teg:Clocher</td><td>"clocher de l'île de Batz"@fr</td></tr><tr><td>teg:Semaphore</td><td></td></tr><tr><td>teg:Tour</td><td>"tour du sémaphore"@fr</td></tr></tbody></table>

Le processus itératif de documentation, modélisation, évaluation et amélioration des quatre modelets et de l'ontologie fusionnée est retracé sur ce dépôt GitHub. Il contient également un fichier qui contient la liste des prefixes utilisés. L'ontologie est composée de 110 classes, 90 propriétés d'objets, 90 propriétés de données et 2190 axiomes au total.

# 4 Adaptations de SAMOD

## 4.1 La relation entre les ontologues et les experts du domaine

SAMOD conseille aux ontologues et aux experts du domaine de recueillir des informations et de rédiger ensemble l'argumentaire, la liste de questions informelles de compétence et le glossaire. N'ayant pas la possibilité de collaborer constamment avec des experts du domaine, nous avons travaillé de manière autonome en les consultant ponctuellement pour compléter nos connaissances et valider nos travaux. Pour ce faire, nous nous sommes d'abord familiarisés avec le contenu des Instructions nautiques ainsi qu'avec les documents de référence détaillés dans la section 3.1.1. Pour guider utilement la modélisation de l'ontologie, la liste des questions informelles de compétences doit refléter les besoins des utilisateurs. Nous avons donc réalisé une série d'entretiens semi-directifs auprès de personnes, ayant des
niveaux d'expertise différents, qui utilisent les *Instructions nautiques* dans le cadre de leur travail ou de leurs études, dans le domaine militaire ou civil. Au total, nous avons réalisé 10 entretiens allant de 30 à 60 minutes, en petits groupes ou individuellement, avec cinq élèves en deuxième année du cycle ingénieur à l'École navale, quatre instructeurs militaires de l'École navale et trois instructeurs civils de l'École nationale supérieure maritime (ENSM). Au début de chaque entretien, nous avons présenté le cadre du projet et le but de ces entretiens, de manière à être compréhensibles pour des personnes non familières avec le Web sémantique. Nous avons précisé l'objectif de notre projet, à savoir : extraire, organiser et stocker numériquement les informations contenues dans les *Instructions nautiques*, de manière à pouvoir les utiliser différemment, en dehors de leur format habituel, en les liant à des informations provenant d'autres sources. Ensuite, nous avons indiqué que les entretiens servaient à analyser les besoins des utilisateurs des *Instructions nautiques* afin de pouvoir orienter notre travail vers des solutions adéquates. Ces entretiens ont été réalisés pendant la phase de préparation de la documentation. Ils nous ont non seulement permis de compléter nos connaissances sur le domaine des *Instructions nautiques* et leur utilisation, mais également de vérifier et de faire valider par des experts la documentation produite.

Pour recueillir l'avis des rédacteurs nous avons réalisé deux entrevues avec les membres de l'équipe de rédaction des *Instructions nautiques*. Pendant ces entrevues, nous avons présenté l'approche globale de notre projet et plus précisément l'ontologie que nous avons développée. Ensuite, nous avons eu l'opportunité de discuter et de poser des questions, pour améliorer les modelets produits.

## 4.2 Le développement en parallèle des modelets

SAMOD conseille de développer un seul modelet à la fois. Les nombres de classes, d'attributs, de relations et d'individus doivent chacun être limités à $7 \pm 2$. Ceci correspond à la Loi de Miller, qui indique le nombre d'éléments qu'un humain peut garder dans sa mémoire à court terme. Contrairement à ces recommandations, nous avons travaillé sur le développement de tous les modelets en parallèle. Cela nous a permis d'avoir une vue complète du domaine à tout moment et ainsi de travailler sur la modélisation de chacune de ses parties de manière non pas indépendante mais plutôt complémentaire. Cette façon de travailler nous a conduits à estimer la Loi de Miller trop contraignante, car elle aurait demandé une division trop fine du domaine des *Instructions nautiques*. Pendant la modélisation, il y a eu un va-et-vient constant inter- et intra-modelets. Il a été nécessaire d'avoir des éléments en commun entre certains modelets, comme par exemple la classe `nav:EntiteGeographique`. De cette manière, il a été plus facile de créer des liens entre des éléments de différents modelets lors de leur fusion. Après avoir défini chaque modelet, nous les avons fusionnés afin de créer l'ontologie complète. Nous les avons intégrés au fur et à mesure, en réalisant à chaque fois un test de modèle, un test de données et des tests de requêtes.

## 4.3 La production des jeux de données

Pour réaliser les tests de données, SAMOD demande aux ontologues de créer pour chaque modelet un jeu de données relatif aux exemples introduits dans la documentation. Il est conseillé de réaliser cette tâche après avoir produit le modelet et après avoir fait le test de modèle. Cependant, nous avons décidé de commencer à construire un jeu de données pour chaque modelet directement après la phase de récolte d'informations et avant de produire la documentation. Pour construire les jeux de données, nous avons strukturé quelques extraits de texte des *Instructions nautiques* en construisant à la main des triplets en RDF et RDF-star. Le fait d'identifier les instances et leurs relations dès le début nous a conduits à mieux connaître le domaine et nous a aidés à mieux structurer notre modèle ontologique. Plus précisément, ceci nous a aidés à (1) identifier les sous-domaines à représenter par un modelet, (2) rédiger l'argumentaire et les questions informelles de compétence, (3) identifier les classes et propriétés nécessaires dans chaque modelet et (4) structurer le modèle global d'une manière qui permet de répondre aux usages auxquels on la destine, notamment répondre aux questions des navigateurs qui préparent leur sortie en mer. Nous avons ensuite élargi les jeux de données tout au long du développement des modelets.

# 5 Conclusions et perspectives

Nous avons produit l'ontologie ATLANTIS qui modélise le contenu des *Instructions nautiques* du Shom. Ce modèle permet de décrire les entités pérennes de l'environnement maritime côtier, les phénomènes météorologiques et océanographiques qui peuvent se produire dans cet environnement, les consignes de navigation côtière, les règlements en vigueur dans le domaine maritime côtier, les relations spatiales, les temporalités et enfin les navires.

Pour créer l'ontologie nous nous sommes fondés sur SAMOD, une méthodologie agile et itérative pour le développement d'ontologies de domaine. Nous lui avons apporté quelques modifications afin de l'adapter à notre contexte. Cela nous a permis de travailler directement à partir de données réelles sur un domaine très large sans devoir le découvrir trop finement. De plus, nous avons pu travailler de manière autonome et orienter les interactions avec les experts du domaine vers le raffinement du modèle tout en tenant compte des besoins des utilisateurs finaux de la base.

La base produite offre de nouvelles possibilités concernant à la fois l'accès aux connaissances contenues dans les *Instructions nautiques* et leur fiabilité. À terme, elle pourra alimenter une plateforme permettant aux utilisateurs des *Instructions nautiques* de chercher directement les informations précises souhaitées, par catégorie ou par zone géographique, au lieu de lire le texte intégral.

En perspectives à court terme, sur la base du peuplement de l'ontologie avec des triplets RDF et RDF-star extraits manuellement des *Instructions nautiques*, nous prévoyons d'automatiser l'extraction des connaissances géoréférencées du texte, puis de peupler la base de connaissances. Nous comptons nous appuyer sur la méthode d'extraction
automatique initiée par [8], fondée sur une combinaison
d'une approche lexicale et d'une approche à base de pa-
trons linguistiques. Une fois le modèle ontologique instan-
cié, il sera possible de réaliser une évaluation rigoureuse de
l'ontologie produite pour ce cas d'usage.

Remerciements

Ce travail est co-financé par le Shom et l'IGN et réalisé
au LASTIG, une unité de recherche de l'Université Gus-
tave Eiffel. Nous remercions les utilisateurs des *Instruc-
tions nautiques* qui ont accepté de s'entretenir avec nous
ainsi que les rédacteurs des *Instructions nautiques* au Shom.

Références

[1] A. de Moor, P. De Leenheer, and R. Meersman. DOGMA-MESS: A Meaning Evolution Support System for Interorganizational Ontology Engineering. In *Proceedings of the 14th International Conference on Conceptual Structures*, volume 4068 of *Lecture Notes in Computer Science*, pages 189–202, Aalborg, Denmark, 2006. Springer.

[2] M. Ferndández, A. Gómez-Pérez, and N. Juristo. Met-
thontology: From Ontological Art Towards Ontologi-
cal Engineering. Technical Report SS-97-06, Labora-
torio de Inteligencia Artificial, Facultad de Informá-
tica, Universidad Politécnica de Madrid, Spain, 1997.

[3] Hydrographic Dictionary Working Group (HDWG). S-32 IHO Hydrographic Dictionary, 2019.

[4] International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA). Navguide. Marine Aids to Navigation Manual, 2018.

[5] International Hydrographic Organization. S-57 IHO Object Catalogue.

[6] M. Jarrar and R. Meersman. Ontology Engineering - The DOGMA Approach. In *Advances in Web Semantics I*, volume 4891 of *Lecture Notes in Computer Science*. Springer, Berlin and Heidelberg, 2008.

[7] K. Kotis and G. A. Vouros. Human-centered ontology engineering: The HCOME methodology. *Knowledge and Information Systems*, 10:109–131, 2006.

[8] L. Lamotte, N. Abadie, E. Saux, and E. Kergosien. Extraction de connaissances pour la description de l'environnement maritime côtier à partir de textes d'aide à la navigation. In *Revue des Nouvelles Technologies de l'Information*, volume Extraction et Gestion des Connaissances, RNTI-E-36, pages 341–348, Bruxelles, Belgium, 2020. Éditions RNTI.

[9] R. Malyankar. Maritime Information Markup and Use in Passage Planning. In *Proceedings of the National Conference on Digital Government*, pages 25–32, Marina del Rey, California, USA, 2001.

[10] N. F. Noy and D. L. McGuiness. Ontology Develop-
ment 101: A Guide to Creating Your First Ontology.

Technical Report Stanford Knowledge Systems Labo-
ratory Technical Report KSL-01-05 and Stanford Me-
dical Informatics Technical Report SMI- 2001-0880,
Stanford University, Stanford, California, USA, 2001.

[11] J.-A. Pastor-Sánchez, F. J. Martínez Mendez, and J. V. Rodríguez-Muñoz. Advantages of thesaurus representation using the Simple Knowledge Organization System (SKOS) compared with proposed alternatives. *Information Research*, 14(4), 2009.

[12] S. Peroni. SAMOD: an agile methodology for the de-
velopment of ontologies. 2016.

[13] S. Peroni. A Simplified Agile Methodology for Ontology Development. In *OWL: Experiences and Directions – Reasoner Evaluation*, Bologna, Italy, 2016.

[14] H. M. Rawsthorne, N. Abadie, E. Kergosien, and E. Saux. ATLANTIS : Une ontologie pour représenter les Instructions nautiques. In *Journées Francophones d'Ingénierie des Connaissances (IC) Plate-Forme Intelligence Artificielle (PFIA 2022)*, Saint-Étienne, France, 2022. In the press.

[15] J. Sauvage-Vincent. *Un langage contrôlé pour les instructions nautiques du Service Hydographique et Océanographique de la Marine*. PhD thesis, Université Bretagne Loire, 2017.

[16] C. Shimizu, K. Hammar, and P. Hitzler. Modular Ontology Modeling. *Semantic Web*, pages 1–31, 2022.

[17] Shom. *Signalisation maritime*. Ouvrages généraux. 3e edition, 2016.

[18] Shom. Balisage maritime. Descriptif de contenu du produit externe, 2019.

[19] Shom. Symboles, abréviations et termes utilisés sur les cartes marines papier. 7e edition, 2019.

[20] Shom. *Instructions nautiques*. C22 : France (côtes Nord et Ouest). Du cap de La Hague à la pointe de Penmarc'h. 2021. Version à jour au 20 octobre 2021.

[21] Y. Sure. A Tool-Supported Methodology for Ontology-Based Knowledge Management. In H. Stuckenschmidt, E. Stubkjær, and C. Schlieder, editors, *The Ontology and Modelling of Real Estate Transactions*, International Land Management Series, pages 115–126. Routledge, London, 2003.

[22] M. C. Suárez-Figueroa, A. Gómez-Pérez, and M. Fernández-López. The NeOn Methodology for Ontology Engineering. In M. C. Suárez-Figueroa, A. Gómez-Pérez, E. Motta, and A. Gangemi, editors, *Ontology Engineering in a Networked World*, pages 9–34. Springer, Berlin, Heidelberg, 2012.

[23] D. Vrandečić, S. Pinto, C. Tempich, and Y. Sure. The DILIGENT knowledge processes. *Journal of Knowledge Management*, 9(5):85–96, 2005.