L’ontologie OSMonto
20[Codescu et al., 2011] a été créée en 2011 par
l’Univer-sité de Bremen
21et le Centre de Recherche Allemand pour l’Intelligence Articficielle
(DFKI)
22. Elle a pour but d’appuyer un outil de navigation centré sur les activités
proposées par les objets géographiques cartographiés dans OpenStreetMap
23. Avec
cet outil, l’utilisateur qui souhaite aller d’un point A à un point B indique, dans
un premier temps, 1) son point de départ, 2) sa destination et 3) les activités
aux-quelles il souhaite s’adonner (restauration, sport, activités culturelles, etc.). Alors,
le système propose le meilleur itinéraire en fonction des préférences renseignées par
l’utilisateur, des activités disponibles selon la base de données OSM, et de la distance
de ces activités par rapport au trajet à parcourir.
Dans cette ontologie, seuls les tags qui possèdent plus de 100 occurrences dans
la base de données OSM, ainsi que ceux qui sont référencés dans le wiki OSM,
sont intégrés dans l’ontologie. Ce parti pris assure une meilleure qualité des tags
considérés puisqu’ils sontde facto plus consensuels et qu’«il n’y a jamais 100 fois la
même erreur» [Codescu et al., 2011]. Cela permet, par exemple, d’écarter les tags
redondants qui seraient le fruit d’une méconnaissance des bonnes pratiques OSM,
ou encore des tags contenant des erreurs typographiques.
La méthodologie qui sous-tend sa création est semblable à celle de l’ontologie
LGD en cela que les concepts extraits des clés des tags OSM sont considérés comme
18. https://fr.wikipedia.org/wiki/SPARQL
19. http://browser.linkedgeodata.org/
20. http://wiki.openstreetmap.org/wiki/OSMonto
21. http://www.uni-bremen.de/
22. http://www.dfki-bremen.de/
23. http://do-roam.org/
Figure 3.2 – Aperçu de la hiérarchie de tags issue de l’ontologie OSMonto.
super-classes des concepts extraits des valeurs associées. Ainsi, à partir des tags
shop=supermarket et shop=convenience, la classe k_shop est créée, super-classe
des classesv_supermarketetv_convenience. Cette approche a été adoptée chaque
fois que la valeur du tag était une constante OSM plutôt qu’une chaîne de caractères
ou un nombre. Ainsi, les tags OSM classifiés comme attributs de description ou
attributs de données ne sont pas pris en considération dans la méthodologie de
construction de l’ontologie OSMonto.
Afin de prévenir l’ambiguïté dans le cas où elles sont les mêmes, les classes
(owl:class) issues des clés ou bien des valeurs sont respectivement préfixées par
k_ et v_. Ainsi, le tag utilisé pour décrire, par exemple, une gare sur une ligne
ferroviaire au sens large,railway=station, donne la classev_stationtandis que le
tag employé pour spécifier, par exemple, le type de gare dont il s’agit, par exemple
station=subway pour un arrêt de métro, donne la classek_station.
Les dépendances entre tags sont également considérées : certains tags ne sont
compatibles qu’avec d’autres tags bien spécifiques. Par exemple, le tag caractérisant
un type de cuisine cuisine=* (par exemple, cuisine=seafood), n’a de sens qu’au
sein d’une combinaison avec le tagamenity=restaurant. Dans ces cas, la clé du tag
dépendant est convertie en une propriété objet owl:ObjectProperty ayant pour
domaine la valeur du tag dont il est dépendant et sa propre valeur pour rang.
Par conséquent, pour exprimer la cooccurrence des tags amenity=restaurant et
cuisine=*, la propriété objet hasCuisine est créée avec pour domaine la classe
v_restaurant et pour image la classe k_cuisine. De cette manière, et puisque
toutes les valeurs associées à la clé cuisine (french, seafood, pizza) sont des
sous-classes de la classe k_cuisine, elles peuvent être utilisées comme valeur de la
propriété hasCuisine.
Pour finir, l’ontologie OSMonto est utile à plusieurs égards. Tout d’abord, elle
donne un aperçu général des tags caractérisant la nature des objets géographiques
de la base OSM sous la forme d’une hiérarchie à deux niveaux clé-valeur illustrée en
figure 3.2. D’autre part, les auteurs tirent parti du langage OWL pour unifier des
concepts similaires exprimés par différents tags OSM. Ils établissent, par exemple,
une relation d’équivalence owl:equivalentTo entre les classes extraites des tags
fuel:electricity=yes(associé à des stations essence également équipées de bornes
pour voitures électriques) et amenity=charging_station (associé à des bornes de
rechargement de voitures électriques), tous deux associés à des équipements
permet-tant de recharger des voitures électriques. Cette technique permet de faire le lien
entre des classes entre lesquelles aucune similarité ne peut a priori être inférée à
partir de la hiérarchie clé-valeur puisque elles sont issues de tags ne partageant pas
la même clé.
Ces correspondances peuvent être établies de manière automatique grâce à des
matchers d’ontologies. Le matcher Falcon
24a, par exemple, permis de retrouver
80% des relations équivalences entre les classes de OSMonto jugées pertinentes
par les auteurs de [Codescu et al., 2011]. Toutefois, ces outils ont leurs limites :
à cause d’une distance orthographique trop importante, la correspondance entre
les tagsfuel:electricity=yesetamenity=charging_stationn’est pas retournée
par Falcon. Aussi, les auteurs préconisent une méthode semi-automatique dans
la-quelle les matchers assistent les utilisateurs dans leur prise de décision. Par le biais
de cette technique d’alignement, les auteurs proposent également d’établir des
rela-tions d’équivalence entre les classes de OSMonto et d’autres ontologies du LOD, et
notamment des ontologies de haut niveau telle que OpenCyc
25, GUM-Space
26ou
encore Dolce
27. La construction de ponts entre ces différentes représentations de la
connaissance faciliterait l’interopérabilité des tags OSM dans le Web Sémantique.
Dans le document
OF4OSM : un méta-modèle pour structurer la folksonomie d'OpenStreetMap en une nouvelle ontologie
(Page 60-63)