• Aucun résultat trouvé

Les travaux des auteurs de [Auer et al., 2009] au sein du groupe de recherche

pour le Web Sémantique et l’Ingénierie de la Connaissance Agile (Agile Knowledge

Engineering and Semantic Web research group, AKSW)

10

comptent parmi les

pre-mières tentatives de construction d’une ontologie à partir de l’information en base

de données OSM. L’ontologieLinked GeoData (LGD)

11

en est l’aboutissement dont

la première version est publiée en 2009. Dans ce modèle, les tags sont classés en

trois catégories, chacune correspondant à un modèle de conversion vers le langage

de représentation des connaissances Ontology Web Language (OWL)

12

:

Attributs de classification Ce sont des tags qui donnent des informations sur la

nature des éléments spatiaux auxquels ils sont associés (par exemple,

amenity-=school). Ce sont les tags regroupés sous la catégorie "Caractéristique

prin-cipale" sur la page Map Feature du wiki OSM. Dans l’ontologie LGD, la clé

et la valeur sont toutes deux représentées par des classes (owl:Class). La

clé est considérée comme super-classe de la valeur à laquelle elle est associée

dans la paire clé=valeur. La relation de subsomption est décrite au moyen

de la propriétérdfs:subClassOf; ainsi les tagsamenity=schoolet

amenity-=kindergarten vont donner lieu à une hiérarchie à deux niveaux composée

d’un concept (owl:class) Amenitysuper-classe des concepts School et

Kin-dergarten.

Attributs de description Ce sont des tags ayant pour valeur un ensemble de

valeurs prédéfinies (par exemple, internet_access=wired/wlan/terminal).

Ce sont des tags regroupés sous la catégorie "Propriété complémentaire" sur

la page Map Feature du wiki OSM. Ils sont convertis en propriétés objets

(owl:ObjectProperty) dans l’ontologie LGD ;

Attributs de données Ce sont des tags dont la valeur est textuelle ou de type

primitif (par exemple, height=80). Ces tags sont eux aussi rangés sous la

ca-10. http://aksw.org/

11. http://wiki.openstreetmap.org/wiki/LinkedGeoData

tégorie "Propriété complémentaire" sur la pageMap Feature du wiki OSM. Ils

sont convertis en propriétés primitives (owl:DataProperty) dans l’ontologie.

Plus qu’un méta-modèle, l’ontologie LGD est également une vaste base de

don-nées géographiques. En effet, ce ne sont pas uniquement les concepts (la boîte de

terminologie (Terminology Box, TBox), c’est-à-dire les tags OSM) qui sont

repré-sentés : les instances (la boîte d’assertion (Assertion Box, ABox), c’est-à-dire les

objets géographiques) font également partie intégrante de l’ontologie. Ainsi, chaque

élément primitif de la base de données OSM (noeud, ligne, relation) est décrit par

autant de triplets RDF qu’il a de tags associés. Par conséquent, chaque objet est

défini dans letriplestore comme une instance d’un ou plusieurs attribut(s) de

clas-sification et ayant un ou plusieurs attribut(s) de description et de données.

De plus, les auteurs de [Auer et al., 2009] ont développé une heuristique qui tente

d’établir une relation d’équivalence (owl:sameAs) entre chaque instance de

l’onto-logie LGD et l’entité de la base de données DBpedia

13

à laquelle elle correspond.

DBpedia est une base de connaissances qui vise à structurer l’information extraite

depuis l’encyclopédie libre Wikipédia

14

. Les informations qui sont formalisées

ap-paraissent ensuite dans les articles Wikipédia sous la forme d’une infobox

15

dans

la partie droite de l’interface qui synthétise les caractéristiques essentielles du sujet

traité dans l’article. Le but de la structuration proposée par le projet DBpedia est

de permettre une interrogation sophistiquée des données massives regroupées dans

l’encyclopédie Wikipédia.

La mesure de similarité entre un objet de l’ontologie LGD et une entité

prove-nant de DBpedia est calculée sur la base de la comparaison de leur nom, de leur

localisation et de leur type. De cette manière, plus de 50 000 objets de l’ontologie

LGD sont identifiés sur une base de données largement reconnues dans l’écosystème

des Données Ouvertes et Liées. Prise dans son ensemble, l’ontologie LGD contient

500 classes (issues de tags de type attribut de classification), 50 propriétés objets

(issues de tags de type attribut de description) et 15 000 propriétés primitives (issues

de tags de type attribut de données).

Pour illustrer cette méthode de conversion des données OSM au format RDF,

considérons l’exemple donné par l’extrait de code 3.1 représentant l’église

Notre-Dame de Dresde telle qu’elle est retournée par un serveur implémentant l’API OSM

au format XML :

13. http://dbpedia.org/

14. http://wiki.dbpedia.org/about

1 <node i d ="123" l a t = " 5 1 . 0 5 1 " l o n = " 1 3 . 7 4 1 " v e r s i o n ="10" changeset="123" 2 u s e r ="John " u i d ="123" v i s i b l e =" t r u e " timestamp ="2009−03−09T08 : 4 9 : 4 8 Z"> 3 <tag k="name" v=" F r a u e n k i r c h e " /> 4 <tag k=" c r e a t e d_by " v=" P o t l a t c h 0 . 1 0 e " /> 5 <tag k="t o u r i s m " v=" v i e w p o i n t " /> 6 <tag k=" u r l " v="h t t p ://www. f r a u e n k i r c h e−d r e s d e n . de/" /> 7 <tag k="d e n o m i n a t i o n " v=" l u t h e r a n " /> 8 <tag k=" w i k i p e d i a : en " v=" F r a u e n k i r c h e_Dresden " /> 9 <tag k=" r e l i g i o n " v=" c h r i s t i a n " />

10 <tag k="a m e n i t y " v=" p l a c e_o f_w o r s h i p " />

11 <tag k=" w i k i p e d i a : de " v=" F r a u e n k i r c h e_( Dresden ) " /> 12 </node>

Extrait de code 3.1 – Représentation de l’église Notre-Dame de Dresde au format

XML par un serveur implémentant l’API OSM.

L’extrait de code 3.2 ci-dessous est le résultat de la conversion du noeud

corres-pondant à l’identifiant 123, c’est-à-dire à la représentation de l’église Notre-Dame

de Dresde telle que décrite dans la base de données OSM (cf. extrait de code 3.1),

au format RDF dans le triplstore de l’ontologie LGD :

1 lgd−node : 1 2 3 r d f s: comment " G e n e r a t e d by T r i p l i f y V0 . 5 " . 2 lgd−node : 1 2 3 cc: l i c e n s e cc: by−s a/2 . 0 . 3 lgd−node : 1 2 3 lgd−v o c a b u l a r y : a t t r i b u t i o n " T h i s d a t a i s d e r i v e d " . 4 lgd−node :123# i d rdf: t y p e lgd−v o c a b u l a r y : node . 5 lgd−node :123# i d geo−wgs84 : l o n g " 1 3 . 7 4 1 6 " ^ ^xsd: d e c i m a l . 6 lgd−node :123# i d geo−wgs84 : l a t " 5 1 . 0 5 1 9 " ^ ^xsd: d e c i m a l . 7 lgd−node :123# i d lgd−v o c a b u l a r y : c r e a t e d_by lgd: P o t l a t c h +0.10 e . 8 lgd−node :123# i d lgd−v o c a b u l a r y : r e l i g i o n lgd: c h r i s t i a n . 9 lgd−node :123# i d lgd−v o c a b u l a r y : name " F r a u e n k i r c h e " . 10 lgd−node :123# i d lgd−v o c a b u l a r y : t o u r i s m lgd: v i e w p o i n t . 11 lgd−node :123# i d lgd−v o c a b u l a r y : a m e n i t y lgd: p l a c e_o f_w o r s h i p . 12 lgd−node :123# i d lgd−v o c a b u l a r y : w i k i p e d i a %2525 de

13 " h t t p ://de . w i k i p e d i a . o r g/w i k i/F r a u e n k i r c h e_( Dresden ) " . 14 lgd−node :123# i d lgd−v o c a b u l a r y : w i k i p e d i a %2525 en 15 " h t t p ://en . w i k i p e d i a . o r g/w i k i/F r a u e n k i r c h e_Dresden " . 16 lgd−node :123# i d lgd−v o c a b u l a r y : d e n o m i n a t i o n lgd: l u t h e r a n . 17 lgd−node :123# i d lgd−v o c a b u l a r y : u r l " h t t p ://www. f r a u e n k i r c h e−d r e s d e n . de/" . 18 lgd−node :123# i d lgd−v o c a b u l a r y : l o c a t e d N e a r lgd−way :23040893 > . 19 lgd−node :123# i d lgd−v o c a b u l a r y : l o c a t e d N e a r lgd−way :23040894 > .

Extrait de code 3.2 – Triplets représentant l’église Notre-Dame de Dresde dans

l’ontologie LGD.

Pour finir, l’ontologie LGD constitue une base de plus de 1,2 milliards de

tri-plets dans sa dernière version

16

, libre de droit et disponible gratuitement sous

li-cence ODbL

17

. La mise à jour des données est faite tous les ans ou tous les deux

ans. De plus, l’information est directement accessible via un point d’entrée pour le

16. http://blog.aksw.org/linkedgeodata-new-rdf-versions/

langage d’interrogation de données au format RDF SPARQL

18

. Enfin, l’ontologie

LGD dispose d’une interface graphique adhoc pour l’exploration et la modification

de ces données

19

, permettant au profane de bénéficier de l’expressivité formelle de

l’ontologie, notamment grâce à un système de suggestion de tags. En effet, lorsque

l’utilisateur veut associer le tag amenity=schoolà une école maternelle, le système

est capable de repérer que ce tag est lié à l’attribut de classification School,

sous-classe de Amenity, et peut lui proposer des tags similaires, comme d’autres tags

liés à des sous-concepts du concept Amenity, peut-être plus pertinents, tels que

amenity=kindergarten. Cette approche contribue à l’amélioration de la qualité des

méta-données de la base de données OSM.