Le Monde Sémantique
Extension commerciale .com
Tout devrait être rendu aussi simple que possible, mais pas plus simple.
Albert Einstein
1.1. Introduction
Toute modélisation en RDF se fait en spécifiant des triplets qui décrivent la logique de la modélisation d'un graphe de connaissance.
Les triplets prennent la forme comme suit: <Sujet> <Prédicat> <Objet>. Par conséquent, vos données et votre «schéma» utilisent donc le même mécanisme de persistance à base triple.
Pour des raisons historiques, l'univers RDF est communément classé en deux types de triplets. Ceux qui se rangent dans la boîte T (pour Terminologique) et ceux qui se rangent dans la boîte A (pour Assertionnelle).
Les ontologies, les classes et les règles sont stockées dans la boîte T (Terminologique/schéma). Par exemple, un article est défini comme ceci: <Vélo> <est_de_type> <produit>.
Les instances de classes sont stockées dans la boîte A (Assertionnelle). C'est-à-dire toutes vos données traditionnelles, comme par exemple le <produit123> <est_de_couleur> <rouge>.
La combinaison de la boîte T avec la boîte A est ce que nous appellons ordinairement un graphe de connaissance. Les deux boîtes sont nécessaires pour avoir un graphe de connaissance utilisable, sinon cela ne se distinguerait pas des données stockées sous la forme de tables relationnelles. De plus, c'est la logique maintenue par la boîte T qui permet l'inférence / le raisonnement (par exemple, mon vélo est rouge) - c'est là que réside toute la magie de RDF. Plus précisément, votre application n'a pas besoin de gérer ou d'étendre un modèle particulier - mieux; le modèle peut (et doit) se gérer lui-même. Cela rend votre application beaucoup moins fragile et s'aligne parfaitement avec le modèle MVC (Modèle-vue-contrôleur) bien connu pour créer une architecture logicielle et les applications web.
Ci-dessous, la meilleure pratique à suivre pour modéliser correctement un graphe de connaissance RDF:
La base de connaissance est composée de 4 étages différents:
URI globalement unique |
Nombre de Triplets | Vocabulaire | Changement | Propriétaire |
Boîte T | 100 (centaines) | L'ontologie d'entreprise "BASE DE CONNAISSANCE" en OWL |
Rarement | Ontologiste |
Boîte T + la catégorie |
1000 (milliers) | Extensions de l'ontologie | Souvent | Taxonomiste |
Boîte A | Inférieur à 1 million | Spécifique au domaine | ça dépend | Toute l'équipe et l'administration |
Boîte A | Supérieur à 1 million | Spécifique au domaine | Au quotidien | Les créateurs de contenus et les "manipulateurs" de données |
1.2. Spécificité du domaine
Alors que la boîte T et la boîte A sont des distinctions historiques utiles, il existe une zone (en vert) entre les deux boîtes qui est spécifique à chaque domaine (taxonomie). En ayant bien à son esprit cet étage, il devient aisé maintenant de spécifier les différents sous-domaines aux URI de chacun des triplets pour la boîte T, la boîte A et la taxonomie. Cela réduira au minimum les livrables d'un groupe d'interférer avec les livrables d'un autre groupe. Les exemples de ces URI de base pourraient ressembler à ceci:
https://data.exemple.com/ (pour la boîte A)
https://taxonomies.exemple.com/ (Taxonomie spécifique au domaine)
https://ontologies.lemondesémantique.fr/base/ (pour la boîte T)
Bien sûr, vous pouvez utiliser n'importe quel autre modèle d'URI (globalement unique) que vous jugez approprié.
(Attention: les URI ne devraient pas changer une fois que vous entrez en production)
Du point de vue des dépendances, la boîte A dépend du fait que tout le reste soit en place avant toute discussion sur les données, donc la transformation des données en RDF devrait idéalement être la dernière chose à faire. De même, la taxonomie a une dépendance évidente vis-à-vis de la boîte T. En tant que tel, vous devez toujours partir de l'ontologie, au niveau supérieur.
L'étape suivante consistera à implémenter toutes les règles d'inférence et de savoir si elles seront matérialisées ou non. Ces décisions devront impliquer toute l'équipe car elles affectent la fonctionnalité, la convivialité, l'évolutivité et les performances. En général, on n'implémente pas toutes les inférences possibles simplement parce que cela générerait probablement une quantité exponentielle de données. Le choix de l'inférence à implémenter doit être basé uniquement sur le traitement des cas d'utilisation documentés pour vos utilisateurs finaux et pas plus.
Enfin, une fois les règles d'inférence terminées de la boîte T et de la taxonomie, vous pouvez commencer à ajouter vos données à la boîte A.
Du point de vue de la gouvernance, la gestion de la boîte T est du domaine de l'ontologiste. Alors que la gestion de la taxonomie est du domaine du taxonomiste.
La gestion de la boîte A est le domaine des créateurs de contenu qui utilisent généralement des outils tels que les mappeurs R2RML pour convertir les données relationnelles ETL en RDF. Étant donné que l'inférence nécessite des ressources de base de données (à la fois le stockage et le processeur), tout le monde, y compris l'administrateur de base de données, doit être impliqué dans le choix de la quantité d'inférence que votre application devra implémenter et de la matérialisation de ces inférences.
Finalement, les instances des données sont elles le domaine des "manipulateurs" de données. En règle générale, ils utiliseront des outils tels que R2RML pour extraire, transformer et charger des données relationnelles en RDF. Inutile de dire qu'ils mapperont les données sur votre ontologie superieure et les taxonomies existantes, sans lesquelles ils devraient inventer une cartographie arbitraire (alias une «ontologie putative») - quelque chose que vous devrez certainement abandonner ou refactoriser de manière significative. D'autres outils tels que RML (un sur-ensemble de R2RML) permettent aux manipulateurs de données de convertir des données ETL à partir de sources non-relationnelles telles que les big data, les feuilles de calcul, JSON, etc.
Vous comprenez maintenant pourquoi utiliser une ontologie de niveau supérieur dans l'objectif d'implémenter des micro-modèles utiles, réutilisables et cohérents et dont les développeurs ont tellement besoin dans toutes leurs applications est un enjeu stratégique pour les entreprises.
1.3. Une ontologie de niveau supérieur
Note: les instances d'une même classe (OWL) vont dans le même seau.
Se faisant distinguons les différents types de seaux et les manières de les modéliser avec l'ontologie d'entreprise "BASE" de niveau supérieur:
Le seau le plus courant représente quelque chose, comme par exemple: une personne ou un bâtiment. Les sortes de choses qui entrent dans ces seaux sont des individus du type; Albert Einstein, ou l'immeuble de bureaux dans lequel vous travaillez. Nous représentons ce genre de seau par owl:Class et nous utilisons rdf:type pour mettre les choses dans ce seau.
Un autre type de seau est représenté par un groupe de choses, comme un jury ou une équipe de football dont les membres sont fonctionnellement connectés d'une manière ou d'une autre. Ces choses liées vont dans un seau composé des membres du jury, ou des 11 joueurs d'une même équipe etc.
Remarque:
Nous avons une classe spéciale dans l'ontologie d'entreprise "BASE" appelée base:Collection, pour ce type de seau. Un seau spécifique de ce type sera alors lui-même une instance d'une sous-classe de base:Collection. Ci-dessous, taxo:_jury_de_thèse est une instance de la classe taxo:Jury, une sous-classe de base:Collection. Nous utilisons base:membreDe pour mettre cette collection de choses dans le seau commun. Aussi convainquez-vous que ces seaux ne représentent pas une sorte de chose. Un jury est une sorte de chose, un jury en particulier ne l'est pas. Nous utiliserions rdf:type pour connecter le jury taxo:_jury_de_thèse à la classe OWL taxo:Jury, et utiliserons base:membreDe pour connecter les jurés spécifiques à taxo:_jury_de_thèse.
Le troisième type de seau est une balise (tag) qui représente un sujet et est utilisée pour catégoriser des éléments individuels dans le but d'indexer un corps de contenu. Par exemple, les balises «Comédie» et «SciFi» peuvent être utilisées pour indexer des films. Tout élément de contenu qui se rapporte à l'une des deux balises d'une manière ou d'une autre doit être catégorisé à l'aide de la balise qui le représente. Concrètement, nous représentons cela d'une manière structurellement identique à la façon dont nous représentons les seaux qui sont des collections d'éléments fonctionnellement connectés. Néanmoins, les différences sont les suivantes: 1) le seau est une instance d'une sous-classe de base:Catégorie, plutôt que de base:Collection et 2) nous mettons les choses dans le seau en utilisant base:catégoriséPar plutôt que base:membreDe. Les balises «comédie» et «SciFi» sont essentiellement deux seaux respectifs contenant chacun tous les éléments qui ont été indexés ou classés à l'aide de ces premières.
# open-source: 1_3_2_A.ttl
@prefix ex: <https://data.exemple.com/> .
@prefix taxo: <https://taxonomies.exemple.com/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Personne> rdf:type owl:Class .
ex:EmmanuelMacron rdf:type base:Personne .
ex:PeterSloterdijk rdf:type base:Personne .
ex:LivierGuidat rdf:type base:Personne .
# open-source: 1_3_2_B.ttl
@prefix ex: <https://data.exemple.com/> .
@prefix taxo: <https://taxonomies.exemple.com/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Collection> rdf:type owl:Class .
taxo:Jury rdfs:subClassOf base:Collection .
taxo:_jury_de_these rdf:type taxo:Jury .
ex:ZinédineZidane rdf:type base:Personne ;
base:MembreDe taxo:_jury_de_thèse .
ex:JeanClam rdf:type base:Personne ;
base:MembreDe taxo:_jury_de_thèse .
ex:LéaCoutin rdf:type base:Personne ;
base:MembreDe taxo:_jury_de_thèse .
# open-source: 1_3_2_C.ttl
@prefix ex: <https://data.exemple.com/> .
@prefix taxo: <https://taxonomies.exemple.com/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/Catégorie> rdf:type owl:Class .
<https://ontologies.lemondesémantique.fr/base/Tag> rdfs:subClassOf base:Catégorie .
taxo:Comédie rdf:type base:Tag ;
base:a_pour_Tag "Une comédie".
taxo:SciFi rdf:type base:Tag ;
base:a_pour_Tag "Une science-fiction".
ex:lestroisfrères rdf:type ex:film .
ex:lesbronzésfontduski rdf:type ex:film .
ex:lempirecontreattaque rdf:type ex:film .
ex:lestroisfrères base:catégorisePar taxo:Comédie .
ex:lesbronzésfontduski base:catégorisePar taxo:Comédie .
ex:lempirecontreattaque base:catégorisePar taxo:SciFi .
Les micro-modèles précédents qui utilisent l'ontologie "base" supérieure nous servent aussi à modéliser une taxonomie (science de la classification).
Une taxonomie informelle est une structure de contenu hiérarchique dans lequel aucune hiérarchie de classes cohérentes n'est appliquée. En effet, aucune exigence formelle n'y est observée selon laquelle un nœud doit être limité à une seule catégorie parente. Le comportement déterminant de la taxonomie informelle (à l'inverse d'une taxonomie formelle) est de permettre aux nœuds d'appartenir à plusieurs catégories parentes selon les besoins. Se faisant les taxonomies informelles sont omniprésentes dans toute entreprise.
Pour mettre en production une ontologie d'entreprise comme base de connaissance au sein de votre propre organisation il est alors judicieux de modéliser cette taxonomie informelle comme suit:
# open-source: 1_3_3_A.ttl
@prefix ex: <https://data.exemple.com/> .
@prefix taxo: <https://taxonomies.exemple.com/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://taxonomies.exemple.com/TaxonomieInformelle> rdf:type owl:Class .
taxo:MonArbre rdf:type taxo:TaxonomieInformelle .
ex:Objet1 base:catégorisePar taxo:Niveau_1-1-1 .
ex:Objet2 base:catégorisePar taxo:Niveau_1-1-2 .
ex:Objet3 base:catégorisePar taxo:Niveau_1-2-1 .
ex:Objet4 base:catégorisePar taxo:Niveau_1-2-2 .
ex:Objet4 base:catégorisePar taxo:Niveau_1-1-0 .
ex:Objet5 base:catégorisePar taxo:Niveau_1-2-2 .
taxo:Niveau_1-1-0 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-1-1 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-1-2 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-2-0 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-2-1 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-2-2 base:allouéPar ex:_organisation_ou_personne .
taxo:Niveau_1-1-0 base:a_sousCatégorie taxo:Niveau_1-1-1 .
taxo:Niveau_1-1-0 base:a_sousCatégorie taxo:Niveau_1-1-2 .
taxo:Niveau_1-2-0 base:a_sousCatégorie taxo:Niveau_1-1-2 .
taxo:Niveau_1-2-0 base:a_sousCatégorie taxo:Niveau_1-2-1 .
taxo:Niveau_1-2-0 base:a_sousCatégorie taxo:Niveau_1-2-2 .
taxo:MonArbre base:a_pourMembre taxo:Niveau_1-1-0 .
taxo:MonArbre base:a_pourMembre taxo:Niveau_1-2-0 .
taxo:Niveau_1-1-0 rdf:type base:Catégorie .
taxo:Niveau_1-2-0 rdf:type base:Catégorie .
taxo:Niveau_1-1-1 rdf:type base:Catégorie .
taxo:Niveau_1-1-2 rdf:type base:Catégorie .
taxo:Niveau_1-2-1 rdf:type base:Catégorie .
taxo:Niveau_1-2-2 rdf:type base:Catégorie .
# Inférence:
# taxo:Niveau_1-1-1 base:a_superCatégorie taxo:Niveau_1-1-0 .
# taxo:Niveau_1-1-2 base:a_superCatégorie taxo:Niveau_1-1-0 .
# taxo:Niveau_1-1-2 base:a_superCatégorie taxo:Niveau_1-2-0 .
# taxo:Niveau_1-2-1 base:a_superCatégorie taxo:Niveau_1-2-0 .
# taxo:Niveau_1-2-2 base:a_superCatégorie taxo:Niveau_1-2-0 .
# taxo:Niveau_1-1-0 base:membreDe taxo:MonArbre .
# taxo:Niveau_1-2-0 base:membreDe taxo:MonArbre .
Ci-dessus: le micro-modèle d'une taxonomie informelle.
Notez qu'un nœud d'élément (Objet4) est catégorisé par deux catégories parentes différentes. De plus, une catégorie parentale (Niveau_1-1-2) est également catégorisée comme ayant plusieurs parents de catégorie.
# open-source: 1_3_3_B.ttl
@prefix ex: <https://data.exemple.com/> .
@prefix taxo: <https://taxonomies.exemple.com/> .
@prefix base: <https://ontologies.lemondesémantique.fr/base/> .
<https://ontologies.lemondesémantique.fr/base/VocabulaireHiérarchisé> rdfs:subClassOf base:Collection .
<https://ontologies.lemondesémantique.fr/base/Taxonomie> rdfs:subClassOf base:VocabulaireHiérarchisé .
taxo:Profession rdf:type base:Taxonomie .
ex:Alex rdf:type base:Personne .
ex:Léa rdf:type base:Personne .
ex:Marie rdf:type base:Personne .
ex:Diane rdf:type base:Personne .
taxo:Médecin rdf:type base:Catégorie .
taxo:Cardiologiste rdf:type base:Catégorie .
taxo:Orthopédiste rdf:type base:Catégorie .
ex:Alex base:catégoriséPar taxo:Cardiologiste .
ex:Léa base:catégoriséPar taxo:Médecin .
ex:Marie base:catégoriséPar taxo:Orthopédiste .
ex:Diane base:catégoriséPar taxo:Orthopédiste .
taxo:Profession base:a_pourMembre taxo:Médecin .
taxo:Profession base:a_pourMembre taxo:Cardiologiste .
taxo:Profession base:a_pourMembre taxo:Orthopédiste .
taxo:Médecin base:a_sousCatégorie taxo:Cardiologiste .
taxo:Médecin base:a_sousCatégorie taxo:Orthopédiste .
# Inférence:
# taxo:Cardiologiste base:a_superCatégorie taxo:Médecin .
# taxo:Orthopédiste base:a_superCatégorie taxo:Médecin .
# taxo:Médecin base:membreDe taxo:Profession .
# taxo:Cardiologiste base:membreDe taxo:Profession .
# taxo:Orthopédiste base:membreDe taxo:Profession .
# taxo:_organisation_ou_personne base:gouverne taxo:Profession .
Le Monde Sémantique
améliore la Vie des Entreprises.
Copyright © 2018-2024