Introduction au Web sémantique

Web sémantique

Introduction

Le début des années 2000 a vu émerger le Web 3.0, un mouvement guidé par le World Wide Web Consortium (W3C) qui a pour but d’étendre le Web d’origine (Web 1.0) afin de l’améliorer. Cette amélioration se situe au niveau du partage, de la manipulation et de l’utilisation des données à travers les frontières des applications, des entreprises et des communautés (W3C, 2013a). Il s’agit en d’autres mots, de passer du Web dit des documents au Web des données, autre nom donné au Web sémantiques (W3C, 2015c). Cette évolution est visible dans la Figure 1 ci-dessous qui montre l’augmentation de la présence de la sématique, « sémanticité » du Web, par rapport au temps, soit depuis 1990 jusqu’à l’horizon 2020.Selon le W3C, les deux principes fondateurs du Web sémantique sont, d’une part, l’utilisation de formats communs qui permettent d’intégrer et de combiner ensemble des données, provenant de sources différentes, et, d’autre part, l’utilisation d’un langage de description des données permettant de les mettre en rapport avec le monde réel. Cette mise en relation a pour but de rendre possible la navigation, à la fois pour les êtres humains et pour les machines, entre des bases de données reliées entre elles par des thématiques communes, c’est-à-dire traitant de sujets communs (W3C, 2013a). L’information, dans ce cadre, se veut donc correctement définie au niveau de sa signification afin de permettre un travail coopératif entre les ordinateurs et les êtres humains, sans place pour l’ambiguïté (Berners-Lee, Hendler, & Lassila, The Semantic Web, 2002).

Contexte

Ce travail est réalisé dans le cadre du dernier module de la formation à temps partiel à la HES-SO Valais / Wallis à Sierre. Chaque étudiant doit rendre un sujet d’étude afin d’obtenir le Bachelor en informatique de gestion. Ce travail a été débuté le 21 février 2017 et a été terminé le 9 août 2017. La réalisation de ce travail a été faite en parallèle des cours de la formation de février à juin, les mois de juillet et août ont été consacrés à la réalisation à plein temps de ce travail. Tous les travaux de Bachelor sont prévus pour une durée de 360 heures.

Livrables

Le rendu, dans le temps imparti, de ce travail de Bachelor comporte plusieurs livrables qui sont :
• Le rapport écrit
• Le code source du prototype développé
• Le poster de présentation du travail

 Introduction au Web sémantique

Ce chapitre a pour but d’expliquer les principaux concepts et technologies liés au Web sémantique qui sont utilisés dans la suite de ce travail.

 Linked Data

Le Web sémantique ne peut pas fonctionner uniquement avec des données dans un format standard, atteignables (accessibles) et gérables avec les outils standards proposés par le W3C. En effet, il est nécessaire qu’elles soient reliées entre elles, afin de ne pas exister chacune de leur côté, de manière complètement indépendante, comme le serait une collection de données dans le sens strict du terme. Cela permet de créer une intégration, à large échelle, de données et d’ensemble de données sur le web, ce qui représente le fondement du Web des données (W3C, 2015a). Pour effectuer ces liaisons, il est nécessaire d’utiliser de bonnes pratiques de publication et de connectivité, afin de les rendre réutilisables même si elles proviennent de sources différentes. D’un point de vue technique, les données, dont le sens doit être défini de manière explicite, doivent être publiées sur le Web en étant atteignables par des machines. De plus, elles doivent être reliées à un autre ensemble de données externe à celui auquel elles appartiennent et offrir une possibilité de connexion à d’autres ensembles de données de sources différentes (Sheth, 2011 Afin de rendre possible cette exploration de données par des êtres humains et par des machines, quatre règles ont été établies et mises en exergue par Tim Berners-Lee, directeur du W3C. La première prévoit que les choses soient nommées par des URI (Uniform Resource Identifiers), courtes chaînes de caractères permettant d’identifier de manière unique des ressources sur le Web (W3C, 2006). La deuxième demande à ce que ces URIs utilisent le protocole d’accès HTTP (Hypertext Transfer Protocol), afin d’offrir la possibilité de rechercher ces noms. La troisième exige que des informations utiles soient fournies lors de la recherche d’une URI et cela grâce à l’utilisation de standards tels que ceux relié au format Resource Description Framework (RDF) ou celui de SPARQL (SPARQL Protocol and RDF Query Language), langage d’interrogation de données au format RDF (ces éléments seront expliqués dans les chapitres suivants). La quatrième et dernière règle requiert l’inclusion de liens à d’autres URIs permettant ainsi la découverte de nouvelles choses en rapport avec celles initialement recherchées. Le respect de ces préceptes permet d’obtenir des données reliées entre elles, le linked data, et d’en arriver au Web des données. De plus, cela rend possible leur réutilisation d’une manière réfléchie et prévue, mais aussi d’une manière inattendue, ce qui représente également la plus-value du Web (Berners-Lee, Linked Data – Design Issues, Le Linked Data et ses quatre principes font que le Web des données est directement lié au Web des documents et s’y superpose en une couche supplémentaire. Ils sont étroitement liés et sont caractérisés par des propriétés similaires, dont notamment le fait d’être générique, le Web des données peut contenir tout type de données, ainsi que la possibilité offerte à tout le monde de publier des données (Sheth, 2011

Linked Open Data

Un exemple de mise en oeuvre du Linked Data est le projet Linked Open Data (LOD), mené par le W3C. Ce projet a pour but d’identifier et de convertir des ensembles de données sous licence ouverte (Open Data), c’est-à-dire facilitant la réutilisabilité libre, dans le format standard RDF, en respectant les quatre principes du Linked Data et, finalement, de les publier ensuite sur le Web (Sheth, 2011 Ce projet vise, entre autres, à standardiser les pratiques de publication de données publiques et librement accessibles par les gouvernements. Pour ce faire, le W3C a publié une échelle de critères cumulatifs qui qualifient la qualité des LOD allant d’une à cinq étoiles.

 RDF

Afin d’être utilisable par les machines, en plus d’être lisible pour les êtres humains, l’information a besoin d’être structurée d’une certaine manière. Le format RDF a été mis au point par le W3C pour répondre à ce besoin dans le cadre du Web sémantique et du Linked Data. Il permet l’échange d’informations entre des applications, sans perte de sens. Sa structure offre la possibilité d’exprimer des informations à propos de ressources (W3C, 2014b). Celles-ci représentent quelque chose dans le monde qui peut être un concept abstrait, un objet physique ou encore un document (W3C, 2014a). Le modèle de données du format RDF permet de faire des déclarations à propos de ressources. Ces déclarations se font toujours selon la même structure, appelée triplet RDF, représentée dans la Figure 2 ci-dessous, qui comprend trois éléments : le sujet, le prédicat et l’objet. Cette manière de représenter les données permet d’exprimer une relation, représentée par le prédicat, entre deux ressources, le sujet et l’objet. Le prédicat désigne la nature de la relation et va toujours dans le même sens, du sujet à l’objet. Un exemple de triplet est illustré dans la Figure 3 ci-après (W3C, 2014b).

 Ontologie

Dans le cadre du Web sémantique, les ontologies sont utilisées afin de définir les concepts et les relations d’un sujet donné. Elles permettent de classifier des termes pouvant être utilisés dans des applications particulières, de caractériser des possibilités de relations ou encore de définir des contraintes d’utilisation. Ceci est fait dans le but de désambiguïser des concepts présents dans différentes collections de données au niveau de leur signification (W3C, 2015b). Prenons l’exemple de deux bases de données au format RDF, dans lesquelles nous retrouvons une fois le triplet « Stephen King est l’auteur de La Ligne verte » et dans l’autre « Victor Hugo est le créateur de Notre-Dame de Paris ». L’ontologie permettrait dans l’élaboration d’une plateforme qui souhaite intégrer ces deux sources de données de définir que les concepts « est l’auteur de » et « est le créateur de » utilisés en prédicat sont identiques. Cette définition sera intégrée dans les données en RDF (W3C, 2015b).

RDF Schema

Afin d’ajouter de la sémantique aux données RDF, le W3C a élaboré une extension de ce format qui fournit du vocabulaire descriptif. Il s’agit des schémas RDF, parfois abrégé RDFS. Ils permettent de décrire des groupes de ressources et les liens entre ces ressources dans le format RDF. Des classes et des propriétés sont utilisées de façon similaire à celle des langages de programmation orientée objet comme Java. Il en diffère cependant dans le sens où il décrit des propriétés par rapport à la classe de ressources à laquelle il s’applique plutôt que de définir les classes par les propriétés que peuvent avoir ses instances (W3C, 2014c).

 OWL

Pour exprimer les ontologies, le W3C a mis au point différents outils dont le langage Web Ontology Language (OWL) qui permet d’exprimer des connaissances riches et complexes à propos de ressources, de groupes de ressources et de liens les connectant. De ce fait, il est possible d’exprimer des concepts dans un langage compris par les machines d’une manière uniformisée et prédictible (W3C, 2012). OWL permet d’ajouter davantage de vocabulaire afin de décrire des classes et des propriétés et cela de manière plus formelle qu’avec RDFS. Les classes permettent de faire des regroupements selon des propriétés communes. Les propriétés qualifient la relation entre deux instances de classes entre elles ou entre une instance de classe et une valeur. Par exemple, les arbres sont une classe et les conifères une sous-classe des arbres et « possède des aiguilles » est une propriété (W3C, 2004). Parmi les autres caractéristiques du langage, il est possible de qualifier des propriétés afin de permettre l’acquisition de connaissances parles machines. Elles peuvent être, entre autres, transitives, symétriques ou encore réflexives (W3C, 2012).

 SPARQL

Le langage permettant notamment d’interroger des graphes de données RDF est le SPARQL Protocol and RDF Query Language (SPARQL) et a été créé par le W3C. Il offre également la possibilité de créer, modifier et de supprimer des données RDF. Une base de données en ligne contenant des données au format RDF pourra être interrogée par une requête SPARQL via le protocole HTTP (Hypertext Transfer Protocol) sur le point d’accès, aussi appelé endpoint, de la base de données, lieu d’écoute des requêtes (W3C, 2013c). Les endpoints peuvent être de deux types, soit générique, c’est-à-dire permettant d’interroger n’importe quel ensemble de données RDF disponible sur le Web, ou spécifiques, permettant d’interroger un ensemble spécifique de données. L’interrogation d’un endpoint se fait en ajoutant une chaîne de caractères représentant la requête SPARQL encodée à la suite de l’URL de base (Cambridge Semantics, 2013). SPARQL a existé, dans une première version dès 2008 et a été mis à jour dans une nouvelle version 1.1 en 2013. Cette dernière permet d’exécuter des requêtes plus élaborées qu’auparavant avec l’ajout notamment des agrégations de valeurs et la possibilité d’exécuter des requêtes emboîtées, tout en pouvant toujours utiliser les filtres et les unions. Il est possible de faire des requêtes de sélection de données, des requêtes de demande dont la réponse est booléenne, des requêtes de construction de nouveaux graphes, ainsi que d’insertion et de suppression de données (W3C, 2013b). Une requête SPARQL est constituée de cinq parties ayant chacune une utilité bien définie. La première sert à déclarer les préfixes servant à abréger les URIs qui seront utilisées dans la suite de la requête. Cela permet de faciliter la lisibilité et la compréhension de la requête et se fait par l’utilisation du mot clé PREFIX. Il faut ensuite, dans la deuxième partie, définir l’ensemble de données qui sera interrogé grâce au mot clé FROM. La troisième partie consiste à préciser les éléments qui seront retournés suite à l’exécution de la requête en utilisant le mot clé SELECT. Il faut ensuite préciser les données que la requête devra ressortir dans l’ensemble de données sélectionné grâce aux conditions définies à la suite du mot clé WHERE. Pour finir, le résultat de la requête peut être arrangé avec des modificateurs qui permettent de réaliser entre autres des tris et des découpages dans les données obtenues (Cambridge Semantics, 2013). Une requête SPARQL vide, visible dans la Figure 6 ci-dessous permet d’en visualiser le squelette. Elle est suivie d’un exemple réel de requête, illustré dans la Figure 7, qui retourne les noms d’oiseau de l’ordre des passereaux disponibles dans les ensembles de données du projet DBpedia.

 État de l’art

Afin de pouvoir envisager le développement du nouveau prototype permettant la recherche des communes dans les archives fédérales suisses, il est nécessaire de faire un état de la composition des données qui seront utilisées, une analyse du prototype existant, ainsi qu’un inventaire des fonctionnalités qu’il propose. De plus, il faudra précéder à une analyse des données RDF à disposition pour la réalisation du nouveau prototype.

 Description des données

Les deux ensembles de données utilisés dans le cadre de ce projet sont les données historisées des communes suisses ainsi que les données des archives fédérales suisses. Les deux sous-chapitres suivants expliquent les éléments constitutifs de ces deux ensembles de données.

 Données historisées des communes suisses

L’Office fédéral de la statistique (OFS) est responsable de la publication du répertoire historisé des communes suisses. Ces données sont soumises à la norme eCH-0071 qui les décrit et en donne les spécifications et divers éléments liés à leur utilisation par voies électroniques. Cela permet notamment aux applications d’entreprises du secteur privé et des administrations d’avoir une base commune pour identifier et désigner les communes suisses (Association eCH, 2014). Selon l’art. 3, let. d, de l’ordonnance du 21 mai 2008 sur les noms géographiques (= ONGéo ; RS 510.625), les communes sont définies comme étant les « entités politiques les plus petites assumant les tâches dévolues à la commune politique par la législation cantonale et définies sans équivoque par un territoire et un nom ». Il ne doit pas exister d’ambiguïté dans les noms officiels des communes en Suisse afin d’éviter toute confusion entre une commune et une autre. En outre, l’OFS attribue à chaque commune un numéro d’identification unique. L’évolution du répertoire officiel des communes dépend des différents processus de mutations qui sont définis selon sept événements (Association eCH, 2014). Par ailleurs, les communes sont englobées dans la plupart des cantons dans une entité intermédiaire située entre les communes et les cantons, appelée district. Cette subdivision n’est, sauf exceptions, pas autonome et existe uniquement pour jouer un rôle administratif, judiciaire ou électoral. Les cantons d’Uri, de Glaris, de Zoug et de Genève, ainsi que les demi-cantons d’Obwald, de Nidwald, de Bâle-Ville et d’Appenzell Rhodes-Extérieures ne possèdent pas de districts. En ce qui concerne le demi-canton d’Appenzell Rhodes-Intérieures, les districts correspondent dans les faits aux communes (Dubler, 2006). Les districts apparaissent toutefois dans le répertoire historisé des communes. Comme expliqué précédemment, une commune est définie notamment par un territoire. Il existe cependant certaines zones qui font exceptions. Il s’agit des surfaces spéciales qui regroupent les territoires qui ne peuvent pas être attribués à une commune, ceux qui se trouvent sous l’autorité de plusieurs communes et aussi les parties cantonales de lac. Ces données sont intégrées dans le répertoire et apparaîtront dans le schéma de données ci-après (Office fédéral de la statistique, 2007). Les données de la liste des communes de la Suisse peuvent être modélisées comme dans la Figure 9 ci-dessous. Une commune dite politique peut faire partie ou non d’un district, mais est obligatoirement rattachée à un canton. Les territoires non attribués à une commune et les parties cantonales de lac possèdent les mêmes caractéristiques. Un district fait toujours partie d’un canton et se compose d’une ou de plusieurs communes. Les cantons sont composés quant à eux d’une ou de plusieurs communes politiques et peuvent comprendre ou non un ou plusieurs districts. Les districts et les cantons peuvent comprendre ou non un ou des territoires non attribués à une commune ou des parties cantonales de lac (Office fédéral de la statistique, 2007).

 Données des archives fédérales suisses

Les Archives fédérales dépendent en Suisse du département fédéral de l’intérieur. Elles permettent, entre autres, de garantir l’accès au public à des documents ayant un lien avec les activités de l’État. L’accès par le public à des fonds d’archives et des données de la Confédération est rendu possible par l’offre de consultation, disponible en documents analogiques, à consulter dans les locaux prévus à cet effet, ou en version numérique (Archives fédérales suisses, 2016 a). Les Archives fédérales suisses possèdent une plateforme en ligne, Swiss Archives, permettant d’effectuer des recherches dans l’ensemble des niveaux d’organisation. Cet outil se base sur une banque de données en ligne et offre la possibilité de commander des dossiers pour consultation. Chaque élément pourra être visualisé sur une page de détails lui étant propre reprenant le détail de ses informations liées et depuis laquelle il pourra être ajouté au panier des commandes (Archives fédérales suisses, 2016 b). Les archives fédérales suisses sont organisées selon une certaine structure hiérarchique. Les documents sont répartis dans un premier temps entre huit divisions. Elles sont désignées par des lettres et correspondent à des périodes et à certains types de documents. Les divisions B, C et D renferment les documents provenant de ce qui peut être désigné comme les autorités centrales de l’État. Ces trois divisions couvrent la période allant de 1798 à 1848, date de la fondation de l’État fédéral. Elles sont toutes les trois fermées, c’est-à-dire qu’elles ne sont plus alimentées de nouveaux documents. La division E contient les documents des autorités fédérales dès 1848 et s’agrandit constamment, étoffée par de nouveaux documents. La division J comprend les archives de personnes physiques ou morales. La division K compte les documents internationaux que sont les actes et les traités depuis 1798. La division M se compose de document ayant une importance jugée secondaire. Finalement, la division P rassemble des copies d’archives provenant de l’étranger remontant jusqu’au Moyen – Âge tardif.

Architecture

L’application actuelle utilise le framework de développement CakePHP dans sa version 2.1.0, écrit, comme son nom l’indique, en langage PHP. Il est gratuit et open source et permet de développer rapidement des applications Web de manière structurée. Il utilise l’architecture Modèle-Vue-Contrôleur et intègre les fonctions de création, de lecture, de mise à jour et de suppression pour les interactions avec la base de données (Cake Software Foundation, 2017). L’application est construite sur une logique de fonctionnement qui veut que l’on sélectionne dans un premier temps une commune et que les ressources des archives correspondantes à cette commune soient affichées, suite à une requête à la base de données relationnelle. La correspondance se fait entre tous les noms que cette commune a pu avoir dans son histoire et les titres des ressources des archives. La correspondance a été faite à l’avance et une liaison existe entre les communes et les archives. Cette correspondance a pris en compte une partie des cas pour lesquels une confusion peut exister entre un nom de commune et un mot d’une des langues nationales.

Fonctionnalités

Lors de l’arrivée sur l’application actuelle, les communes sont affichées dans une liste montrant pour chacune d’entre elles le nom, le numéro postal, le canton, le district et le nombre d’unités de description correspondantes. Les communes sont triées par ordre alphabétique, selon le nom. L’affichage se fait selon l’abécédaire au sommet de la page. Il suffit de sélectionner la lettre désirée pour que s’affichent les communes dont le nom commence par cette lettre. Dans la Figure 12 ci-dessous, le début de la liste pour la lettre a est affiché.

 Conclusion

Le prototype existant possède des fonctionnalités intéressantes, bien que les manières de rechercher une commune soient assez limitées. Du point de vue des données, l’utilisation d’une base de données relationnelles demande des mises à jour régulières à la fois de l’état des communes et à la fois des archives. La correspondance entre les archives et les communes est a priori fixe, le titre d’un document des archives ne changeant pas dans le temps Il serait donc pertinent d’ajouter des éléments aidant à la recherche des communes. De plus, l’utilisation des données RDF aura l’avantage de garantir que les données sont officielles et à jour par rapport aux dernières mutations enregistrées.

Table des matières

Introduction
Contexte
Livrables
1. Introduction au Web sémantique
1.1. Linked Data
1.1.1. Linked Open Data
1.2. RDF
1.3. Ontologie
1.3.1. RDF Schema
1.3.2. OWL
1.4. SPARQL
1.4.1. JSON comme résultat de requête
2. État de l’art
2.1. Description des données
2.1.1. Données historisées des communes suisses
2.1.2. Données des archives fédérales suisses
2.2. Analyse de l’application existante
2.2.1. Base de données
2.2.2. Architecture
2.2.3. Fonctionnalités
2.2.4. Conclusion
2.3. Plateforme LINDAS
2.3.1. Normes eCH
2.4. Analyse des données RDF
2.4.1. Données du répertoire historisé des communes de la Suisse
2.4.2. Données des archives fédérales suisses
2.4.4. Conclusion
2.5. Problématique
3. Technologies Web
3.1. Choix de la technologie de base
3.2. Outils et librairies
3.2.1. Angular Material
3.2.2. Angular Generic Table
4. Architecture de l’application
4.1. Fonctionnalités demandées
4.2. Maquettes
4.2.1. Page d’accueil
Anthony Cheseaux
4.2.2. Liste des communes
4.2.3. Unités de description
4.2.4. Carte
4.2.5. Remarques du mandant
5. Développement
5.1. Communes
5.1.1. Récupération des communes
5.1.2. Affichages des communes
5.1.3. Récupération des cantons et des districts
5.1.4. Recherches parmi les communes
5.1.5. Historique d’une commune
5.2. Archives
5.2.1. Récupération des archives
5.2.2. Affichage des archives
5.2.3. Recherche parmi les archives
5.3. Carte topographique
5.4. Informations à l’utilisateur
5.5. Synthèse
6. Déroulement du projet
6.1. Méthode de travail
6.2. Heures de travail
Conclusion

Télécharger le rapport complet