L E TRADUCTEUR AROM-ONTO/OWL 2 DL

5.5.1 Traduction OWL 2 DL→AROM-ONTO . . . . 146

5.5.2 Traduction AROM-ONTO→OWL 2 DL . . . . 146

5.6 SYNTHÈSE . . . . 149

Résumé

Ce chapitre présente ONTOAST, un système de représentation et de raisonnement spatial et temporel quantitatif et qualitatif, construit comme extension du système AROM-ONTO. ON-TOAST peut être utilisé dans le contexte du Web Sémantique Géospatial pour exploiter les annotations spatiales et temporelles décrites en OWL DL ou OWL 2 DL en utilisant les types temporels proposés par les deux langages et/ou les concepts spatiaux et temporels définis par les ontologiesGeoRSS-Simple,OWL-TimeetQualitativeSpatialRelations.

152 6.2. De AROM-ONTO vers ONTOAST

6.1 Introduction

Dans ce chapitre, nous proposons la construction, au dessus du système AROM-ONTO, d’un module de représentation et de raisonnement spatial et temporel, appelé ONTOAST, capable de décrire et d’exploiter des informations spatiales et temporelles à la fois quantitatives et qualita-tives. ONTOAST est donc une extension spatio-temporelle du système AROM-ONTO défini dans le chapitre5. L’un des avantages principaux de ONTOAST, par rapport à la problématique iden-tifiée dans le chapitre3, vient de son ouverture vers le Web Sémantique Géospatial garantie par AROM-ONTO (voir section6.2). Ainsi, le raisonneur que nous proposons ici peut être utilisé pour exploiter les informations spatiales et temporelles quantitatives et qualitatives définies dans des ontologies OWL DL ou OWL 2DL, suite à leur traduction préalable dans ONTOAST.

À partir du moment où les connaissances ontologiques sont importées dans ONTOAST, toute la palette de raisonnements dont il dispose peut être utilisée pour compléter l’ontologie avec les connaissances implicites. Ensuite, par le biais de l’exportation des résultats de calculs dans OWL, ces derniers peuvent être exploités dans le cadre général du Web Sémantique.

Nous proposons également la définition d’un ensemble de relations qualitatives géospatiales pour ONTOAST, afin d’accroître sa flexibilité et son expressivité, ainsi que pour permettre des raisonnements lorsqu’on ne dispose pas de données spatiales et temporelles précises (voir sec-tions6.4et6.5). Des associations géospatiales complexes pourront désormais être définies à l’aide d’équations exprimées dans le Langage de Modélisation Algébrique d’AROM, étendu ici par des opérateurs de topologie, d’orientation et de proximité des objets (voir section6.3). Bénéficiant de la compatibilité entre AROM-ONTO et OWL 2 DL, ONTOAST permet donc de décrire des on-tologies géospatiales pour le Web Sémantique Géospatial, ainsi que de formuler et de traiter des requêtes qualitatives sur ces ontologies, en exploitant les mécanismes de raisonnement d’AROM.

La construction du Web Sémantique Géospatial est soutenue par la mise à disposition, à travers l’utilisation du système ONTOAST, d’un ensemble de raisonnements spatiaux et temporels qui peuvent exploiter les connaissances décrites en OWL DL/OWL 2 DL, notamment :

– la déduction de relations spatiales/temporelles qualitatives à partir de données quantitatives connues ; Ce type d’inférence est basé sur les définitions des relations spatiales et tem-porelles qualitatives (voir sections 2.3.2,2.4.2) et utilise des calculs mathématiques pour traduire les données numériques en relations qualitatives ;

– la déduction de relations spatiales/temporelles qualitatives à partir d’autres relations spa-tiales/temporelles explicitement stockées dans la base ontologique ou déduites (voir sec-tions6.4.4et6.5.4). Ces raisonnements sont construits sur les propriétés des relations spa-tiales/temporelles, telles que la transitivité, la symétrie, etc., ainsi que sur les tableaux de composition spécifiques à chaque type de relation qualitative (voir chapitre2) ;

– les raisonnements algébriques à base d’équations.

6.2 De AROM-ONTO vers ONTOAST

Le système ONTOAST est construit comme extension spatiale et temporelle du système AROM-ONTO. Si AROM-ONTO garantit la compatibilité générale entre AROM et les langages

d’onto-logies OWL DL et OWL 2 DL, ONTOAST propose l’extension des traducteurs OWL↔

AROM-ONTO pour prendre en compte de façon adaptée les descriptions spatiales et temporelles réalisées par rapport aux ontologiesGeoRSS-Simple et OWL Time. Celle-ci est mise en œuvre à travers la

définition d’un ensemble de règles de traduction qui prennent en compte la spécificité des infor-mations spatiales et temporelles que ONTOAST propose.

Ainsi, les raisonnements spatiaux et temporels que nous définissons dans ce chapitre, peuvent être utilisés pour exploiter les descriptions spatiales et temporelles définies dans des ontologies OWL DL et OWL 2 DL, moyennant une traduction vers et depuis ONTOAST. Un aperçu de cette chaîne de traitements est présenté dans la figure6.1.

AROM AROM-ONTO ONTOAST OWL 2

Semantic Web

FIG. 6.1: Modifications apportées par ONTOAST à l’architecture initiale de AROM.

ONTOAST apporte plusieurs modifications au système AROM-ONTO, qui sont localisées au niveau des modules d’Implémentation du Modèle Objet AROM de Types, et d’Interprétation Algébrique (voir figure5.3, page116). Au niveau duModule de Types, et du Module d’Interpré-tation Algébrique, nous avons complété l’extension AROM-ST (décrite dans la section6.3.1) par un ensemble d’opérateurs spatiaux et temporels qui facilitent la transformation des données quan-titatives dans des relations qualitatives. Nous proposons également un modèle spatial et temporel prédéfini qui est présenté dans la section6.4.

6.3 Modèle spatial et temporel quantitatif de ONTOAST

Le module de types d’AROM définit l’ensemble des types de données et d’opérations sur ces types qui peuvent être utilisés dans une base de connaissances. De la même manière que le système de types Metéo [48], le module de types d’AROM considère deux niveaux de représentation des types :

– le C−type (classe de types) qui représente l’ensemble, fini ou non, des valeurs partageant une même structure, tel que l’ensemble des réels ou l’ensemble des chaînes de caractères. Chaque C−type définit des opérations qui lui sont applicables ;

– lesδ−types qui représentent des sous-ensembles de C−types. Chaqueδ−type est associé à un C−type qui représente son type principal. Les informations relatives aux données et les opérations se trouvent donc dans le C−type. En revanche, lesδ−types contiennent des informations relatives à la restriction du domaine défini par le C−type. Pour un même C−type il peut donc exister plusieurs, voir une infinité, deδ−types.

154 6.3. Modèle spatial et temporel quantitatif de ONTOAST

En exploitant l’extensibilité du Module de Types du système AROM, Moisuc a proposé dans sa thèse [174] l’extension AROM-ST qui intègre le modèle spatial vectoriel proposé par l’OGC (décrit dans la section 2.3.1.1). Selon cette norme, l’ensemble des types spatiaux nécessaires et suffisants pour représenter tout objet spatial, est composé des types géométriques simples :

point, polyline etpolygon (voir figure6.2). Les typesline etlinearRing sont définis en appliquant des contraintes sur le type polyline. Comme illustré dans la figure6.2, à partir des types simples sont définis les types géométriques complexes (composés) :multiPoint(nuage de points),multiLineetmultiArea.

CType

Basic Constructed

Ordered Structure

Discrete Continous

Boolean Integer String

Record Multivalued Set List LinearRing Float Line Curve Surface Point 2 GeometryCollection MultiSurface MultiCurve MultiArea Polygon 3..* 0..* _MultiLine PolyLine 2..* 1..* 1..* 1..* MultiPoint 0..* 0..* 0..* 0..* 0..* 0..*

FIG. 6.2: Méta-modèle définissant l’ensemble de types géométriques proposé par AROM-ST.

Les types temporels simples en AROM-ST sont le typeinstant et le typeinterval (voir figure 6.3). Les types composés, constituant des collections d’instants ou d’intervalles, sont les typesmultiInstantetmultiInterval.

À cet ensemble de types défini par [174], nous avons ajouté le typeduration, afin de permettre la modélisation des durées. Le typedurationde AROM-ST est construit comme une adaptation du type homonyme défini par la librairiejavax.xml.datatype.Duration.

Afin de formuler des requêtes, d’exprimer des contraintes, ou bien de décrire des inférences sur des variables de types spatio-temporels, le LMA d’AROM a été également étendu [174], en introduisant trois catégories d’opérateurs spatiaux et temporaux :

a) lesopérateurs topologiques qui sont des prédicats logiques binaires testant la position rela-tive (spatiale ou temporelle) de deux objets. Les opérateurs topologiques spatiaux introduits sont ceux définis par le consortium OpenGIS :contains,within,intersects,disjoint,

overlaps,crossesetequals. Pour compléter la totalité des positions spatiales possibles, l’opérateurinAdjacenta été ajouté [85]. Ces opérateurs sont définis pour des polygones (à l’exception decrosses, défini pour un objet de typelinequi peut traverser une région

sur-facique) mais peuvent s’appliquer à des paramètres moins complexes. En ce qui concerne la topologie temporelle, l’ensemble d’opérateurs définis par AROM-ST est l’image fidèle des relations proposées par Allen [14] :before,after,starts,started-by,finishes,

finishedby,during,contains,equals,meets,met-by,overlaps,overlapped-by;

b) lesopérateurs ensemblistes qui traitent l’espace et le temps, respectivement comme un en-semble de points et d’instants temporels. Ces opérateurs ont la même forme pour la di-mension spatiale et pour la didi-mension temporelle :union,intersection,differenceet

symmetricalDifference;

c) lesopérateurs de mesure qui donnent une description quantitative de l’espace et du temps. Pour la dimension spatiale, les opérateurs définis sont dimension, pour mesurer la sur-face ou l’étendu d’une région, etdistance, pour mesurer l’écartement ou l’éloignement entre deux régions, leurs correspondants pour la dimension temporelle étant durationet

timeLength.

CType

Basic Constructed

Ordered Structure

Discrete Continous

Boolean Integer String

Record Multivalued Set List Float ^{MultiInterval} Interval 1..* 1..* MultiInstant Instant 2 0..* 1..* 0..* 0..* Duration

FIG. 6.3: Méta-modèle définissant l’ensemble des types temporels proposés par AROM-ST.

Nous avons complété cet ensemble d’opérateurs, en ajoutant :

– l’opérateur de direction,direction, qui teste l’orientation relative d’un objet spatial A par rapport à un objet spatial B. Les objets A et B peuvent être représentés par des polygones ou par des structures moins complexes (lignes ou points). L’opérateurdirectionrenvoie une relation de direction de typecarreau unique (définie dans la section2.3.2.4), parmiNorth,

West,South,EastetNeutral, si la géométrie de l’objet A est incluse dans un seul carreau de direction construit à partir du rectangle englobant minimal de l’objet de référence B. Dans le cas contraire, on obtient une relation de direction de typecarreaux multiples, telle queNorth:West:NeutralouSouth:East,etc.

– lesopérateurs de distanceveryClose,close,faretveryFarsont définis par rapport à des échelles.

156 6.3. Modèle spatial et temporel quantitatif de ONTOAST

6.3.2 Ontologie de types spatiaux utilisée par ONTOAST

Afin de traduire les données spatiales décrites à l’aide de types spatiaux définis par AROM-ST (voir section6.3.1) vers OWL/OWL 2, nous utilisonsGeoRSS-Simple (présentée dans la section

3.3.1) comme ontologie de référence. Dans les sous-sections qui suivent, nous définissons les correspondances entre les types de données de AROM-ST et les concepts spatiaux et les attributs introduits par GeoRSS-Simple.

6.3.2.1 AROM-ST→GeoRSS-Simple

Les types spatiaux introduits par AROM-ST sont utilisés dans la définition de l’intension d’une classe ou d’une association ONTOAST. Ils n’ont pas de correspondants directs dans le langage OWL. Néanmoins, comme présenté dans la section 3.3.1, afin de décrire en OWL des données spatiales quantitatives, on peut utiliser des concepts et/ou attributs dont la sémantique est établie dans une ontologie considérée de référence.

Type AROM-ST Concept GeoRSS-Simple AttributGeoRSS-Simple

point − point line − line polygon − polygon polyLine gml:LineString − linearRing gml:LinearRing − multiPoint − gml:posList

plusieurs attributslineet

multiLine −

qml:featuretypetag=“MultiLine” plusieurs attributspolygonet

multiArea −

qml:featuretypetag=“MultiArea”

TAB. 6.1: Correspondances entre les types AROM-ST et lesconcepts/attributsGeoRSS-Simple.

Afin de garantir un minimum de perte d’information lors de la traduction d’une base de connaissances ONTOAST en une ontologie OWL 2 DL (ou OWL DL), nous définissons dans cette section les correspondances qui existent entre les types spatiaux proposés par AROM-ST et les structures proposées par l’ontologie GeoRSS-Simple que nous prenons comme référence. Le tableau 6.1montre les différentes façons de traduire les données spatiales quantitatives pour le Web Sémantique. Par exemple, les valeurs de typepoint,line etpolygon sont traduites en utilisant les attributs de typexsd:string,point,line, et respectivementpolygon, définies dans l’ontologieGeoRSS-Simple.

La figure6.4présente l’exemple simple de la traduction de la classeCityde ONTOAST vers OWL 2 DL (ou OWL DL). Cette classe ayant une variable dont le type estpolygon, est traduite en OWL comme sous-classe degml:_Feature. Elle hérite ainsi de la propriétépolygon, qui ne doit pas être explicitement redéfinie, mais peut être directement utilisée pour décrire les instances de

City. L’exemple de la figure6.4continue avec la traduction de la description attachée à la ville de

Cannes. Il faut notamment observer la traduction de la variablegeomet de sa valeur. Cette dernière n’a pas un attribut homonyme, mais correspond à l’attributpolygon. L’attribut utilisé pour traduire la valeur de la variablegeomest choisi en fonction du type de la variable. Par exemple, si le type

de geométait point, sa valeur en OWL 2/OWL aurait été décrite à l’aide de l’attribut GeoRSS Simplepoint.

Dans ce travail, nous avons choisi de limiter à un le nombre de variables de type spatial qui peuvent être attachées à une classe/association. Néanmoins, cette limitation est assez restrictive et il serait intéressant d’étudier les possibilités de traduction de plusieurs variables spatiales qui modélisent, par exemple, la géométrie d’un objet selon plusieurs niveaux de détails.

<owl:Class rdf:ID="City"> <rdfs:subClassOf rdf:resource="&gml;_Feature"/> </owl:Class> <City rdf:about="# "> <name rdf:datatype="&xsd;string">Cannes</name> <georss:polygon rdf:datatype="&xsd;string"> </georss:polygon> </City> <owl:DatatypeProperty rdf:ID="name"> <rdfs:domain rdf:resource="#City"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="population"> <rdfs:domain rdf:resource="#City"/> <rdfs:range rdf:resource="&xsd;integer"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="surface"> <rdfs:domain rdf:resource="#City"/> <rdfs:range rdf:resource="&xsd;float"/> </owl:DatatypeProperty> City1440695831 43.552925 7.009449, 43.552521 7.00799, 43.551806 7.006831 43.550344 7.006316 ... 43.552925 7.009449, <population rdf:datatype="&xsd;integer">70400</population> <surface rdf:datatype="&xsd;float">1962.0</surface> class : City variables : variable : geom type : polygon variable : population type : integer variable: name type: string variable: surface type: float instance: City1440695831 is-a: City name = "Cannes" geom = #43.552925 7.009449, 43.552521 7.00799, 43.551806 7.006831, 43.550344 7.006316, ... 43.552925 7.009449,# population = 70400 surface = 1962.0 ONTOAST OWL

FIG. 6.4: Exemple de traduction de données spatiales de ONTOAST vers OWL-DL.

Les valeurs de type polyLine et linearRing sont traduites en des instances de concepts

gml:LineString, respectivementgml:LinearRing, reliées aux objets qu’elles décrivent à en uti-lisant des instances de la propriété-lienwhere. Un ensemble de points (multiPoint) est traduit à l’aide d’une propriétégml:posList. Une valeur de typemultiLinedevient, lors de la traduction en OWL-DL, un ensemble de propriétésline. Pour signaler le fait que les valeurs des propriétés

lineattachées à un objet doivent être considérées comme un ensemble et non pas de façon indi-viduelle, nous attribuons la valeur “multiLine” à la propriétégml:featuretypetag. Les valeurs de typemultiAreasont modélisées de façon analogue.

6.3.2.2 GeoRSS-Simple→AROM-ST

En faisant le chemin inverse, si on souhaite accéder à l’ensemble des raisonnements spatiaux et temporels proposés par ONTOAST (que nous décrivons dans les sections6.4et6.5) pour réa-liser des inférences sur une ontologie OWL DL/OWL 2 DL, les données spatiales quantitatives que celle-ci décrit doivent être transformées en des valeurs concrètes attachées aux types spatiaux proposés par AROM-ST (voir section6.3.1). Dans ce travail, nous considérons exclusivement les descriptions réalisées par rapport à l’ontologie GeoRSS-Simple. Néanmoins, il serait intéressant d’étudier des descriptions créées à l’aide d’autres ontologies proposant des concepts spatiaux et

158 6.3. Modèle spatial et temporel quantitatif de ONTOAST

dont les définitions sont alignées avec l’ontologie GeoRSS-Simple. Ce type d’approche pose un certain nombre de problèmes surtout concernant l’hétérogénéité des structures utilisées pour dé-crire les types spatiaux. Si un appariement du type :

<owl:Class rdf:about="&gml;Point">

<owl:equivalentClass rdf:resource="#exPoint"/> </owl:Class>

garantit le fait que les extensions des deux classes (Point etexPoint) sont équivalentes, il ne spécifie pas les règles de transformation des données d’un format vers l’autre.

owl:Thing

SpatialObject

gml:_Geometry ^geoRSS:where gml:_Feature SpatialObject

FIG. 6.5: La position qu’un concept spatial (SpatialObject) peut avoir par rapport aux classes gml :

_Feature et gml :_Geometry définies par l’ontologie GeoRSS-Simple.

Comme le montre la figure6.5, pour définir un concept spatial (SpatialObject) en OWL 2/OWL à l’aide de l’ontologie GeoRSS-Simple, on a plusieurs alternatives :

– on peut lui attacher exclusivement une description thématique et profiter des attributs qu’il hérite deowl:Thing−gml:upperCorner,gml:lowerCorner,gml:posetgml:posList

(voir la définition de l’ontologie GeoRSS-Simple dans la section 3.3.1)− pour situer ses instances dans l’espace ;

– on peut le définir comme sous-classe degml:_Featureet décrire les caractéristiques spa-tiales de ses instances en utilisant les attributs définis pourgml:_Feature;

– on peut le définir comme sous-classe degml:_Featureet utiliser la relationwherepour lui associer une instance de la classegml:_Geometry.

Pour les trois alternatives énumérées auparavant, le résultat de la traduction en ONTOAST est le même, à ceci près que le type de la variablegeomchange en fonction du type de géométrie atta-ché aux instances de la classeSpatialObject. Il faut préciser qu’en OWL rien n’empêche l’uti-lisateur de définir pour les instances d’une même classe des géométries hétérogènes. Par exemple, une instance x de SpatialObject peut être décrite par un attributpolygon alors qu’une autre instance y de la même classe peut être décrite par une propriété-lienwhereavec une instance de la classegml:Point. Dans ce cas, la traduction en ONTOAST de la classeSpatialObject doit contenir deux variables spatiales : l’une de type polygonet l’autre de type point. Néanmoins, pour des raisons de clarté de la présentation, dans cette thèse, nous faisons la supposition que ce genre de situation ne peut pas arriver.

Supposons qu’on veut traduire vers OWL une classe spatiale A^′qui a été traduite en ONTOAST au préalable à partir d’une classe OWL A. Pour garantir le fait que le résultat de la traduction, A^′′, est identique à la définition initiale A, on garde une trace de l’origine de la variable spatialegeom. En d’autre mots, en ONTOAST, à chaque variable spatiale obtenue suite à une traduction depuis

OWL, correspond l’un des tags : "where", "feature", "thing", définis à l’aide de la facette de do-cumentation. L’exemple de la figure6.6illustre la définition d’un tel tag. Ces tags sont utilisées lors de la traduction vers OWL d’une classe ONTOAST disposant d’une variable spatiale. Concrè-tement, si la classe A^′ dispose d’une variablegeomde type polygon, dont le tag est "where", les caractéristiques spatiales de ses instances sont traduites en OWL comme des instances de la classe

gml:_Geometryreliés par des propriétéswhereaux instances de A^′. Si la variable geom n’a pas de tag, alors elle est traduite selon les règles définies dans le tableau6.1.

<owl:DatatypeProperty rdf:about="qsr#name"> <rdfs:domain rdf:resource="qsr#City"/> <rdfs:range rdf:resource="&xsd;string"/> </owl:DatatypeProperty> <City rdf:about="#city1"> <name>Cannes</name> <georss:where rdf:resource="# "/>