Le Web Sémantique

Le Web Sémantique

Le langage RDF

RDF est le langage standard du Web Sémantique permettant de représenter des métadonnées comme par exemple le titre, l’auteur ou la date de modification d’une page Web, les droits d’auteur, les informations de licence d’un document Web, les critères de disponibilité ou les paramètres de confidentialité d’une ressource partagée. Il utilise des idées bien établies issues de différentes communautés de représentation de données et de Etat de l’art Le Web Sémantiqueconnaissances, avec des approches liées aux graphes conceptuels (J. F. Sowa 1984), aux représentations de connaissances basées sur la logique (J. E. Sowa & Shapiro 2006) et aux bases de données relationnelles (Gray 1984). RDF est basé sur XML qui fournit une structure syntaxique pour représenter des documents et d’autres informations mais qui ne fournit pas d’informations sur la sémantique des données. RDF possède un modèle de graphe simple et une sémantique formelle (P. Hayes 2004) avec une notion d’implication définie rigoureusement, fournissant une base pour des déductions sur les données RDF (Klyne & Carroll 2004). Cela rend possible le traitement automatique d’une ressource Web à l’aide d’agents logiciels, faisant ainsi passer le Web de support d’informations lisibles par les humains à un réseau de processus coopératifs. Le standard RDF permet également aux développeurs d’applications de profiter de la présence de parseurs RDF génériques. La possibilité d’échanger de l’information entre différentes applications implique qu’une information créée spécifiquement pour une application peut être utilisée dans toute autre application s’appuyant sur du RDF, ce qui favorise le partage d’information.

L’identifiant unique

RDF est basé sur l’idée de pouvoir tout identifier en utilisant une URI. L’utilisation d’URIs permet de relier des fragments d’informations dispersés sur le Web. Dans le langage RDF, une URI peut être utilisée pour renvoyer à toute chose identifiable, y compris celles qui ne peuvent pas être récupérées directement sur le net, comme par exemple une personne, une plante ou un gène. Les URIs sont utilisées pour identifier précisément une ressource, qu’il s’agisse d’une classe ou d’une propriété. Dans l’exemple ci-dessous, la première ligne permet d’identifier précisément la classe « Person » issue du vocabulaire FOAF. La deuxième ligne de cet exemple définie la propriété « type », issue de RDF. Chacune de ces ressources est une URI de référence, composée d’une URI identifiant le contexte, puis d’un nom, présenté ici en gras, définissant le terme utilisé pour le contexte choisi.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

IntroductionEtat de l’art
1. L’intégration de données
1.1. Introduction
1.2. Les systèmes d’intégration de données
1.2.1. Etat de l’art des approches
1.2.2. L’entrepôt de données
1.2.2.1. Les avantages
1.2.2.2. Les inconvénients
1.2.3. La médiation
1.2.3.1. Les adaptateurs
1.2.3.2. Les avantages
1.2.3.3. Les inconvénients
1.2.3.4. Les solutions existantes dans le domaine bioinformatique
1.3. Conclusion
2. Le Web Sémantique
2.1. Introduction
2.2. L’architecture du Web Sémantique
2.3. Le langage RDF
2.3.1. L’identifiant unique
2.3.2. Le triplet RDF
2.3.3. Le graphe RDF
2.3.4. La sérialisation
2.3.5. L’annuaire RDF
2.4. Le langage de requête SPARQL
2.5. Le Web des Données (Linked Data)
2.6. Les ontologies
2.6.1. Les logiques de description
2.6.2. Les langages d’ontologie
2.6.2.1. Le langage OWL
2.6.2.2. Le langage OBO
2.6.3. Les logiciels d’édition d’ontologies
2.6.4. Les annuaires d’ontologies
2.7. La biologie et le Web Sémantique
2.7.1. Le Web des Données
2.7.2. Les systèmes d’intégration du Web Sémantique
2.8. Conclusion
3. Les Services Web
3.1. Introduction
3.2. Le principe général des Services Web
3.2.1. Les principales technologies de Service Web
3.2.2. Les intérêts d’utilisation des Services Web dans la bioinformatique
3.2.3. Le principe d’utilisation des Services Web
3.3. Les limites des Services Web classiques
3.4. Les Services Web Sémantiques
3.5. Les Services Web Sémantiques en Biologie
3.6. Conclusion
4. Les correspondances entre bases de données et ontologies
4.1. Introduction
4.2. Qu’est ce qu’un mapping entre bases de données et ontologies
4.3. Les bases de données et les bases de connaissances
4.4. Des motivations variées
4.5. Les types d’approches existantes
4.6. Détails de projets existants en informatique
4.7. La réécriture de requêtes SPARQL en requêtes SQL
4.8. Conclusion
Contexte et objectifs
5. Contexte et objectifs
5.1. Le Contexte scientifique 5.1.1. Le Projet GCP
5.1.1.1. La plateforme GCP Pantheon
5.1.2. BioMoby
5.1.2.1. Les Services Web Sémantiques
5.1.2.2. BioMoby DashBoard
5.1.2.3. L’enregistrement des types de données
5.1.2.4. La création d’un Service Web
5.1.3. Les avantages de GCP Pantheon
5.1.4. Les limites de la plateforme GCP Pantheon
5.2. Les objectifs de la thèse 5.2.1. Objectif général
5.2.2. L’approche basée sur BioMoby
5.2.3. L’approche basée sur les standards du Web Sémantique
Contributions
6. Intégration automatique de bioontologies de domaine dans BioMoby
6.1. Introduction
6.2. L’approche générale
6.3. L’intégration automatique de bioontologies de domaine dans BioMoby
6.4. La méthodologie mise en place
6.4.1. Le détail des besoins
6.4.2. Détermination du Framework de développement
6.4.3. La conception de BioMoby Converter
6.5. L’implémentation du plugin
6.5.1. Le parcours d’une ontologie OWL
6.5.2. Definition des règles de transformation d’une ontologie OWL vers une
ontologie BioMoby
6.5.3. Les inconvénients de la transformation
6.5.3.1. Les relations d’héritage
6.5.3.2. La perte de l’espace de nom
6.5.3.3. Les paramètres d’un type de données BioMoby
6.5.3.4. Le stockage des correspondances
6.5.3.5. Le tri des classes de l’ontologie de types de données BioMoby
6.6. Les résultats
6.6.1. Le plugin BioMoby Converter
6.6.2. Evaluation des performances d’enregistrement
6.6.3. Evaluation des autres performances
6.7. Discussion
6.7.1. Les limites de BioMoby
6.7.2. Remise en cause du choix de BioMoby
6.8. Perspectives
6.9. Conclusion
7. Développement d’une plateforme d’intégration de données
Introduction
7.2. Architecture de la plateforme
7.3. Description des étapes de création de Services Web Sémantiques

7.4. Création et annotation de la vue RDF
7.4.1. L’appliation D2RQ en détail
7.4.1.1. Quel fichier de mapping choisir : vue RDF ou dump RDF
7.4.1.2. La vue RDF de D2RQ
7.4.1.3. Le Serveur D2R
7.4.2. Annotation sémantique de la vue RDF
7.4.3. Enrichissement sémantique de la vue RDF
7.4.4. Stockage des vues RDF
7.5. Création automatique de Services Web sémantiques
7.5.1. Annotation sémantique du fichier de description
7.5.2. Enregistrement dans un annuaire de Services Web
7.6. Résultats
7.6.1. Utilisation de l’interface de l’application Web BioSemantic
7.6.1.1. Création d’une vue RDF
7.6.1.2. Chargement de la vue RDF dans l’annuaire
7.6.1.3. Création de Services Web Sémantiques
7.6.2. Cas d’utilisation pour le fonctionnement de BioSemantic
7.6.2.1. Ajout de plusieurs modules TropGene
7.6.2.2. Ajout de nouvelles sources de données
7.7. Perspectives
7.8. Conclusion
8. Création automatique de requête SPARQL
8.1. Introduction
8.2. Recherche de plus court chemin dans un graphe RDF
8.2.1. Contexte
8.2.1.1. Utilisation du plus court chemin
8.2.1.2. Problème de combinatoire
8.2.1.3. Les différents algorithmes existants
8.2.1.4. L’algorithme de Dijkstra
8.2.1.5. Les limites de l’algorithme de Dijkstra
8.2.2. Prise en compte de la spécificité du modèle relationnel dans le parcours de graphe RDF
8.2.2.1. La combinaison de chemins
8.2.2.2. Prise en compte de pondérations dans la sélection de chemins
8.2.3. Prise en compte des spécificités du modèle relationnel dans l’algorithme
8.2.3.1. Le type de relations et le type de nœuds
8.2.3.2. Implémentation des spécificités du modèle relationnel dans l’algorithme
8.3. Création de requêtes SPARQL
8.3.1. Sélection des concepts d’entrée et de sortie de la requête SPARQL
8.3.2. Détails du fonctionnement de l’algorithme
8.3.2.1. Création automatique des triplets de la requête SPARQL
8.3.3. Traitement du cas particulier des relations d’héritage dans le graphe RDF
8.4. Création de la requête SPARQL résultant de l’algorithme
8.5. Résultats
8.5.1. Pertinence des requêtes traitées par l’algorithme
8.5.1.1. Intérêts de notre approche
8.5.1.2. Comparaison avec les requêtes créées manuellement
8.5.2. Benchmark sur les temps de création et d’exécution des requêtes
8.5.2.1. Estimation du temps de création de la requête
8.5.2.2. Estimation du temps d’exécution de la requête
8.5.2.3. Estimation du temps d’exécution du Service Web
8.6. Perspectives
8.7. Conclusion
9. Synthèse et discussion
9.1. Synthèse
9.1.1. Utilisation de BioMoby à travers BioMoby Converter
9.1.2. Vers une plateforme de création automatisée de Services Web Sémantiques
9.1.3. Création automatisée de requêtes SPARQL
9.2. Discussion
9.2.1. BioMoby Converter
9.2.2. BioSemantic
9.2.2.1. Comparaison avec d’autres approches de création de SWS
9.2.2.2. Les étapes manuelles à améliorer
9.2.2.3. Améliorer l’expressivité des requêtes
9.2.2.4. Faciliter l’accès aux requêtes
9.2.2.5. Optimiser la transformation SQL-SPARQL
Conclusion
Bibliographie
Annexes