Web sémantique et données liées. Corrections et ajouts

Je souhaite présenter au public un extrait de ce livre récemment publié :

Modélisation ontologique des entreprises : méthodes et technologies [Texte] : monographie / [S. V. Gorchkova, S. S. Kràlin, O. I. Mushtak et al. ; rédacteur en chef S. V. Gorchkova]. — Ekaterinbourg : Éd. de l'Université de l'Oural, 2019. — 234 p. : ill., tabl. ; 20 cm. — Les auteurs sont mentionnés au verso de la page de titre. — Bibliographie à la fin des chapitres. — ISBN 978-5-7996-2580-1 : 200 ex.

Le but de la publication de cet extrait sur Habr est quadruple :

• Il est peu probable que quelqu'un puisse tenir ce livre entre ses mains s'il n'est pas client du respecté SergeIndex; il n'est absolument pas en vente.
• Le texte a été corrigé (les modifications ne sont pas mises en évidence ci-dessous) et des ajouts ont été faits, qui ne sont pas très compatibles avec le format de la monographie imprimée : des remarques d'actualité (sous spoilers) et des hyperliens.
• Il est souhaitable de recueillir des questions et des commentaires, afin de les prendre en compte lors de l'inclusion de ce texte dans une version retravaillée d'autres publications.
• De nombreux adeptes du Web sémantique et des Données liées estiment encore que leur cercle est si étroit principalement parce qu'il n'a pas été clairement expliqué au grand public à quel point il est agréable d'être un adepte du Web sémantique et des Données liées. L'auteur de l'extrait, bien qu'appartenant à ce cercle, ne partage pas cet avis, mais estime néanmoins avoir l'obligation de faire une nouvelle tentative.

Alors,

Web sémantique

L'évolution d'Internet peut être décrite de la manière suivante (ou en parlant de ses segments, qui se sont formés dans l'ordre indiqué ci-dessous) :

1. Documents sur Internet. Les technologies clés sont Gopher, FTP, etc.
   Internet est un réseau global pour l'échange de ressources locales.
2. Documents Internet. Les technologies clés sont HTML et HTTP.
   La nature des ressources exposées tient compte des particularités de l'environnement de transmission.
3. Données sur Internet. Les technologies clés sont REST et SOAP API, XHR, etc.
   L'ère des applications Internet, où les consommateurs de ressources ne sont plus seulement des humains.
4. Données Internet. Les technologies clés sont les technologies de Données liées.
   Cette quatrième étape, prédite par Berners-Lee, créateur des technologies clés de la seconde étape et directeur du W3C, est appelée Web sémantique ; les technologies de Données liées visent à rendre les données sur le web non seulement lisibles par les machines, mais aussi 'compréhensibles par les machines'.

Il deviendra clair pour le lecteur la correspondance entre les concepts clés des deuxième et quatrième étapes :

• Les analogues des URL sont les URI,
• l'analogue de HTML est RDF,
• Les hyperliens HTML sont similaires aux occurrences d'URI dans les documents RDF.

Le Web sémantique est plutôt une vision systémique de l'avenir d'Internet, qu'une tendance spécifique ou lobbyiste, bien qu'il puisse également prendre en compte ces dernières. Par exemple, une caractéristique importante de ce qu'on appelle le Web 2.0 est le « contenu créé par les utilisateurs ». Ce concept doit être pris en compte, notamment par la recommandation W3C «Web Annotation Ontology» et une telle initiative comme Solid.

Le Web sémantique est-il mort ?

Si l'on renonce à des attentes irréalistes,la situation du web sémantique est à peu près la même que celle du communisme à l'époque du socialisme développé (et chacun doit décider lui-même si la fidélité aux préceptes d'Ilitch est respectée). Les moteurs de recherche forcent assez efficacement les sites web à utiliser RDFa et JSON-LD et utilisent eux-mêmes des technologies apparentées aux technologies décrites ci-après (Google Knowledge Graph, Bing Knowledge Graph).

De manière générale, l'auteur ne peut pas affirmer ce qui empêche une plus grande diffusion, mais peut s'exprimer sur la base de son expérience personnelle. Les tâches qui pourraient être résolues « hors de la boîte » dans le contexte de l'émergence du SW existent, bien que pas très répandues. En conséquence, ceux qui sont confrontés à ces tâches n'ont pas de moyens de coercition concernant ceux qui peuvent fournir des solutions, leur propre fourniture de solutions contredisant leurs modèles économiques. Donc, nous continuons à analyser le HTML et à combiner diverses API, chacune plus médiocre que l'autre.

Cependant, les technologies des données liées ont été adoptées au-delà du web de masse ; c'est à ces applications que le livre est en fait dédié. Actuellement, la communauté des données liées s'attend à ce que ces technologies connaissent une diffusion encore plus grande grâce à la fixation (ou proclamation, selon la perspective) par Gartner de tendances telles que Knowledge Graphs et Data Fabric. On peut espérer que ce ne sont pas les réalisations « à bicyclette » de ces concepts qui réussiront, mais celles qui concernent les standards W3C évoqués par la suite.

Données liées

Berners-Lee a défini les données liées comme un web sémantique « bien fait » : un ensemble d'approches et de technologies permettant d'atteindre ses objectifs finaux. Les principes de base des données liées que Berners-Lee a mis en avant sont les suivants.

Principe 1. Utilisation des URI pour nommer les entités.

Les URI sont des identifiants globaux d'entités par opposition aux identifiants de chaîne locaux des enregistrements. Par la suite, la meilleure expression de ce principe a été trouvée dans le slogan du Google Knowledge Graph «choses, pas chaînes».

Principe 2. Utilisation des URI dans le schéma HTTP, afin qu'ils puissent être déséréférencés.

En s'adressant à une URI, il doit être possible d'obtenir le signifié qui se cache derrière ce signifiant (ici, l'analogie avec le nom de l'opérateur «*» en C); plus précisément, obtenir une certaine représentation de ce signifié - selon la valeur de l'en-tête HTTP Accept:. Peut-être qu'avec l'avènement de l'AR/VR il sera possible d'obtenir la ressource elle-même, mais pour l'instant, ce sera probablement un document RDF, qui est le résultat de l'exécution d'une requête SPARQL DESCRIBE.

Principe 3. Utilisation des standards W3C - en particulier, RDF(S) et SPARQL - notamment lors du déséréférencement des URI.

Ces différentes « couches » de la pile technologique des données liées, également connue sous le nom de Semantic Web Layer Cake, seront décrites plus loin.

Principe 4. Utilisation de références à d'autres URI lors de la description d'entités.

RDF permet de se limiter à une description verbale de la ressource dans un langage naturel, et le quatrième principe appelle à ne pas le faire. Avec le respect universel du premier principe, il devient possible, lors de la description d'une ressource, de faire référence à d'autres, y compris à celles de tiers, d'où le nom de données liées. En réalité, l'utilisation d'URI, nommés dans le vocabulaire RDFS, est presque inévitable.

RDF

RDF (Resource Description Framework) - un formalisme de description d'entités interconnectées.

Des assertions concernant les entités et leurs relations sont formulées sous la forme «sujet-prédicat-objet», appelées triplets. Dans le cas le plus simple, le sujet, le prédicat et l'objet sont tous des URI. La même URI peut se trouver à différentes positions dans différents triplets : être à la fois un sujet, un prédicat et un objet; de cette manière, les triplets forment une sorte de graphe, appelé graphe RDF.

Les sujets et les objets peuvent être non seulement des URI, mais aussi des nœuds vides, et les objets peuvent également être des littéraux. Les littéraux sont des instances de types primitifs, composées d'une représentation sous forme de chaîne et d'une indication de type.

Exemples d'enregistrement de littéraux (en syntaxe Turtle, qui sera décrite ci-dessous) : "5.0"^^xsd:float et "cinq"^^xsd:string. Les littéraux de type rdf:langString peuvent également être dotés d'une balise linguistique, en Turtle cela s'écrit ainsi : "cinq"@fr et "cinq"@fr.

Les nœuds vides sont des ressources « anonymes » sans identifiants globaux, sur lesquels des affirmations peuvent cependant être formulées ; une sorte de variables existentielle.

Ainsi (c'est là que réside toute la nature du RDF) :

• un sujet — est un URI ou un nœud vide,
• un prédicat — est un URI,
• un objet — est un URI, un nœud vide ou un littéral.

Pourquoi les prédicats ne peuvent-ils pas être des nœuds vides ?

Une raison probable est le désir de comprendre informellement et de traduire en langage de logique des prédicats de premier ordre le triplet s p o comme quelque chose de semblable à , où — un prédicat, et — des constantes. Des traces de cette compréhension apparaissent dans le document «LBase : Semantics for Languages of the Semantic Web», qui a le statut de note de groupe de travail W3C. Avec cette compréhension, le triplet s p [], où [] — un nœud vide, serait traduit comme , où — une variable, mais comment alors traduire s [] o? Имеющий статус рекомендации W3C документ «RDF 1.1 Semanticspropose une autre façon de traduction, mais la possibilité que les prédicats soient des nœuds vides n'est pas considérée.

Cependant, Manu Sporny a autorisé.

RDF est un modèle abstrait. Le RDF peut être enregistré (sérialisé) dans divers syntaxes : RDF/XML, Turtle (le plus lisible), JSON-LD, HDT (binaire).

Le même RDF peut être sérialisé en RDF/XML de différentes manières, donc, par exemple, le XML résultant ne peut pas être validé de manière significative à l'aide de XSD ou en essayant d'extraire des données à l'aide de XPath. De même, JSON-LD ne satisfera probablement pas le désir d'un développeur Javascript ordinaire de travailler avec RDF en utilisant la notation Javascript avec des points et crochets carrés (bien que JSON-LD avance dans cette direction en proposant un mécanisme de framing.).

La plupart des syntaxes propose des moyens de raccourcir de longs URI. Par exemple, la déclaration @prefix rdf: dans Turtle permettra d'écrire ensuite plutôt que <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> tout simplement rdf:type.

RDFS

RDFS (RDF Schema) — un dictionnaire de base de modélisation, introduit les notions de propriété et de classe et des propriétés telles que rdf:type, rdfs:subClassOf, rdfs:domain et rdfs:range. Avec le dictionnaire RDFS, les expressions suivantes peuvent être enregistrées :

rdf:type         rdf:type         rdf:Property .
rdf:Property     rdf:type         rdfs:Class .
rdfs:Class       rdfs:subClassOf  rdfs:Resource .
rdfs:subClassOf  rdfs:domain      rdfs:Class .
rdfs:domain      rdfs:domain      rdf:Property .
rdfs:domain      rdfs:range       rdfs:Class .
rdfs:label       rdfs:range       rdfs:Literal .

RDFS est un dictionnaire de description et de modélisation, mais ce n'est pas un langage de contraintes (bien que la spécification officielle laisse à désirer. la possibilité d'une telle utilisation). Le terme « Schéma » ne doit pas être compris dans le même sens que dans l'expression « XML Schema ». Par exemple, :author rdfs:range foaf:Person signifie que rdf:type toutes les valeurs de la propriété :author — foaf:Person, mais cela ne signifie pas qu'il faille en parler à l'avance.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) — un langage de requêtes pour les données RDF. Dans un cas simple, une requête SPARQL consiste en un ensemble de motifs avec lesquels les triplets du graphe interrogé sont mis en correspondance. Dans les motifs, les positions des sujets, des prédicats et des objets peuvent contenir des variables.

La requête retournera les valeurs des variables pour lesquelles, lorsqu'elles sont substituées dans les motifs, un sous-graphe du graphe RDF interrogé (un sous-ensemble de ses triplets) peut être obtenu. Les variables nommées dans différents motifs de triplets doivent avoir les mêmes valeurs.

Par exemple, avec l'ensemble de sept axiomes RDFS ci-dessus, la requête suivante retournera rdfs:domain et rdfs:range comme valeurs ?s et ?p respectivement :

SELECT * WHERE {
 ?s ?p rdfs:Class .
 ?p ?p rdf:Property .
}

Il convient de noter que SPARQL est déclaratif et n'est pas un langage de description de parcours de graphe (bien que certains entrepôts RDF proposent des moyens pour modifier le plan d'exécution de la requête). Par conséquent, certaines tâches graphiques standard, comme la recherche du chemin le plus court, ne peuvent pas être résolues avec SPARQL, même en utilisant le mécanisme property paths (mais encore une fois, certains entrepôts RDF proposent des extensions spécifiques pour résoudre ces problèmes).

SPARQL ne partage pas la présomption d'ouverture du monde et suit l'approche « negation as failure », dans laquelle il est possible d'utiliser des constructions telles que FILTER NOT EXISTS {…}. La distribution des données est prise en compte grâce au mécanisme des requêtes fédérées.

Le point d'accès SPARQL — un entrepôt RDF capable de traiter des requêtes SPARQL — n'a pas d'analogue direct de la deuxième étape (voir le début de ce paragraphe). Il peut être comparé à une base de données, dont le contenu génère des pages HTML, mais qui est accessible de l'extérieur. Le point d'accès SPARQL est plutôt l'analogue d'un point d'accès API de la troisième étape, mais avec deux différences majeures. Premièrement, il est possible de combiner plusieurs requêtes « atomiques » en une seule (ce qui est considéré comme une caractéristique clé de GraphQL), et deuxièmement, cette API est entièrement auto-documentée (ce que HATEOAS a tenté d'atteindre).

Remarque polémique

RDF est un moyen de publier des données sur le web, c'est pourquoi les entrepôts RDF devraient être considérés comme des bases de données documentaires. Cependant, puisque RDF est un graphe et non un arbre, ils sont également devenus des bases de données graphiques. Il est surprenant qu'ils aient pu exister. Qui aurait pu penser qu'il y aurait des experts capables de réaliser des nœuds vides. Chez Codd, ça n'a pas fonctionné. Ça n'a pas abouti..

Il existe également des moyens moins fonctionnels d'organiser l'accès aux données RDF, par exemple, Linked Data Fragments (LDF) et Linked Data Platform (LDP).

OWL

OWL (Web Ontology Language) est un formalisme de représentation des connaissances, une variante syntaxique de la logique descriptive (partout ci-dessous, il est plus correct de parler de OWL 2, la première version de OWL était basée sur ).

Les concepts de la logique descriptive dans OWL correspondent aux classes, les rôles sont des propriétés, et les individus gardent leur nom d'origine. Les axiomes sont également appelés axiomes.

Par exemple, dans la soi-disant syntaxe manchoisienne pour enregistrer OWL, l'axiome déjà connu sera écrit comme suit : Classe : Humain Classe : Parent ClasseÉquivalente : Humain et (inverse aParent) quelques Humains PropriétéObjet : aParent

Il existe d'autres syntaxes pour écrire OWL, par exemple,

la syntaxe fonctionnelle , utilisée dans la spécification officielle, etOWL/XML. De plus, OWL peut être sérialisédans la syntaxe abstraite RDF et par la suite dans n'importe laquelle des syntaxes spécifiques. OWL en relation avec RDF se présente sous un double aspect. D'une part, il peut être considéré comme une sorte de dictionnaire élargissant le RDFS. D'autre part, c'est un formalisme plus puissant, pour lequel RDF n'est qu'un format de sérialisation. Toutes les constructions élémentaires d'OWL ne peuvent pas être notées par un seul triplet RDF.

Selon le sous-ensemble de constructions OWL autorisé, on parle de soi-disant

profils OWL. Les plus connus et standardisés sont OWL EL, OWL RL et OWL QL. Le choix du profil influence la complexité computationnelle des tâches typiques. L'ensemble complet de constructions OWL, correspondant à, est appelé OWL DL. On parle parfois également d'OWL Full, dans lequel les constructions OWL peuvent être utilisées avec toute la liberté inhérente à RDF, sans limites sémantiques et computationnelles. Par exemple, quelque chose peut être à la fois une classe et une propriété. OWL Full est indécidable. Les principes clés de déduction en OWL sont l'adoption de l'hypothèse du monde ouvert (open world assumption,

OWA ) et le rejet de l'hypothèse d'unicité des noms (unique name assumption,UNA .). Nous allons voir ci-dessous à quelles conclusions ces principes peuvent mener et découvrir certaines constructions OWL.

Supposons que l'ontologie contienne le fragment suivant (en syntaxe manchester) :

Classe : manyChildren
   Équivalent à : Humain ayant enfant min 3
Individu : John
   Types : Humain
   Faits : aEnfant Alice, aEnfant Bob, aEnfant Carol

Sera-t-il permis de conclure que John a des enfants ? Le refus de l'UNA amènera le moteur d'inférence à répondre négativement à cette question, car Alice et Bob peuvent très bien être la même personne. Pour qu'une conclusion soit valable, il faudra ajouter un tel axiome :

DifférentsIndividus : Alice, Bob, Carol, John

Supposons maintenant que le fragment de l'ontologie soit le suivant (John est déclaré avoir des enfants, mais il n'a que deux enfants) :

Classe : manyChildren
   Équivalent à : Humain ayant enfant min 3
Individu : John
   Types : Humain, manyChildren
   Faits : aEnfant Alice, aEnfant Bob
DifférentsIndividus : Alice, Bob, Carol, John

Cette ontologie sera-t-elle incohérente (ce qui pourrait être interprété comme un indice de non-validité des données) ? L'acceptation de l'OWA amènera le moteur d'inférence à répondre négativement : « quelque part » (dans une autre ontologie), il peut très bien être dit que Carol est également un enfant de John.

Pour exclure cette possibilité, ajoutons un nouveau fait concernant John :

Individu : John
   Faits : aEnfant Alice, aEnfant Bob, pas aEnfant Carol

Pour exclure l'apparition d'autres enfants, disons que toutes les valeurs de la propriété « avoir un enfant » sont des personnes, dont nous avons au total quatre :

PropriétéObjet : aEnfant
   Domaine : Humain
   Caractéristiques : Irreflexif
Classe : Humain
Équivalent à : { Alice, Bill, Carol, John }

Maintenant, l'ontologie deviendra incohérente, ce dont le moteur d'inférence ne manquera pas de faire état. Par la dernière des axiomes, nous avons en quelque sorte « fermé » le monde, et notez comment il a été exclu que John soit son propre enfant.

Liaison des Données d'Entreprise

L'ensemble des approches et technologies Linked Data était initialement destiné à la publication des données sur le web. Leur utilisation dans un environnement interne d'entreprise rencontre plusieurs difficultés.

Par exemple, dans un environnement d'entreprise fermé, la puissance déductive de l'OWL, fondée sur l'acceptation de l'OWA et le rejet de l'UNA – des décisions dictées par la nature ouverte et distribuée du web – s'avère trop faible. Et plusieurs solutions sont possibles ici.

• Doter l'OWL d'une sémantique, nécessitant le rejet de l'OWA et l'acceptation de l'UNA, la mise en œuvre d'un moteur d'inférence approprié. – Par cette voie nous nous engageons RDF-store Stardog.
• Abandonner les capacités de déduction d'OWL au profit de moteurs de règles. — Stardog prend en charge SWRL; Jena et GraphDB proposent leurs propres langages de règles.
• Abandonner les capacités de déduction d'OWL, utilisant pour modéliser un sous-ensemble proche de RDFS. — Voir à ce sujet plus loin.

Un autre problème est l'attention plus significative que dans le monde des entreprises on peut porter aux problèmes de qualité des données, ainsi que l'absence dans la pile des données liées d'outils de validation des données. Les solutions sont les suivantes.

• Encore une fois, utiliser pour la validation des constructions OWL avec une sémantique de monde fermé et d'unicité des noms en présence d'un moteur d'inférence approprié.
• Utilisation SHACL, standardisé après que la liste des couches du Semantic Web Layer Cake a été établie (bien qu'il puisse également être utilisé comme moteur de règles), ou ShEx.
• Prendre conscience que tout se fait finalement par des requêtes SPARQL, créer son propre mécanisme de validation des données simple en les utilisant.

Cependant, même un abandon complet des capacités de déduction et des outils de validation laisse la pile des données liées inégalée dans des tâches liées à l'intégration des données, semblables à celles du web ouvert et décentralisé.

Qu'en est-il d'un système d'information d'entreprise courant?

C'est possible, mais il convient, bien sûr, de comprendre quels problèmes spécifiques les technologies correspondantes doivent résoudre. Je décrirai ici la réaction typique des participants au développement pour montrer à quoi ressemble cette pile technologique du point de vue de l'informatique conventionnelle. Cela rappelle un peu la fable de l'éléphant :

• Analyste commercial: RDF est quelque chose comme un modèle logique stocké directement.
• Analyste système: RDF, c'est comme EAV, seulement avec plein d'index et un langage de requête pratique.
• Développeur: eh bien, c'est tout dans l'esprit des concepts de rich model et low code, j'ai lu récemment à ce sujet.
• Chef de projet: eh bien, c'est collapsing the stack!

La pratique montre que la pile est le plus souvent utilisée dans des tâches liées à la distribution et à l'hétérogénéité des données, par exemple lors de la construction de systèmes de type MDM (Master Data Management) ou DWH (Data Warehouse). De telles tâches existent dans n'importe quel secteur.

En ce qui concerne les applications spécifiques à un secteur, les technologies des données liées sont actuellement les plus populaires dans les secteurs suivants.

• technologies biomédicales (où leur popularité semble liée à la complexité du domaine) ;

d'actualité

Récemment, à « Point de Ferveur » s'est tenue une conférence organisée par l'association « Base nationale des connaissances médicales » «L'unification des ontologies. De la théorie à l'application pratique».

• fabrication et exploitation de produits complexes (grande ingénierie, extraction de pétrole et de gaz ; il s'agit le plus souvent de la norme ISO 15926);

d'actualité

Ici, c'est également la complexité du domaine qui est en cause, par exemple, en phase amont, lorsqu'on parle de l'industrie pétrolière et gazière, il est nécessaire de disposer de certaines fonctions de CAO.

En 2008, une conférence inaugurale représentative a été organisée par Chevron conférence.

ISO 15926 s'est finalement révélé trop lourd pour l'industrie pétrolière et gazière (et a probablement trouvé un plus grand usage dans l'ingénierie). Seule Statoil (Equinor) a vraiment investi dans ce standard, en Norvège, une véritable écosystème. D'autres tentent de faire quelque chose de leur côté. Par exemple, selon les rumeurs, le ministère russe de l'Énergie envisage de créer un « modèle ontologique conceptuel pour le secteur énergétique », similaire, semble-t-il, à celui créé pour l'énergie électrique.

• organisations financières (même le XBRL peut être considéré comme un hybride entre le SDMX et l'ontologie RDF Data Cube) ;

d'actualité

LinkedIn a activement spammé l'auteur avec des offres d'emploi de presque tous les géants de l'industrie financière avec lesquels il est familier grâce à la série « Suits » : Goldman Sachs, JPMorgan Chase et / ou Morgan Stanley, Wells Fargo, SWIFT / Visa / Mastercard, Bank of America, Citigroup, la Réserve fédérale, Deutsche Bank... Probablement, tout le monde cherchait quelqu'un à envoyer à la Knowledge Graph Conference. Beaucoup ont réussi à se trouver un poste : les organisations financières ont occupé toute la matinée du premier jour.

Sur HeadHunter, il n'y avait quelque chose d'intéressant que chez Sberbank, il s'agissait d'un « entrepôt EAV avec un modèle de données similaire à RDF ».

Probablement, la différence dans le degré d'affection pour les technologies concernées entre les institutions financières russes et occidentales est due à la nature transnationale de l'activité de ces dernières. Il semble que l'intégration à travers les frontières exige des solutions organisationnelles et techniques qualitativement différentes.

• systèmes de questions-réponses ayant une application commerciale (IBM Watson, Apple Siri, Google Knowledge Graph);

d'actualité

À propos, le créateur de Siri, Thomas Gruber, est l'auteur de cette fameuse définition de l'ontologie (au sens informatique) comme "spécification de conceptualisation". À mon avis, le réarrangement des mots dans cette définition n'en change pas le sens, ce qui pourrait indiquer qu'il n'y en a peut-être pas.

• publication de données structurées (ce qui peut être largement considéré comme faisant partie des Linked Open Data).

d'actualité

Les grands amateurs de Linked Data sont les GLAM : Galeries, Bibliothèques, Archives et Musées. Il suffit de dire que pour remplacer le MARC21, la Bibliothèque du Congrès promeut BIBFRAME, qui fournit une base pour l'avenir de la description bibliographique et, bien sûr, est basé sur le RDF.

Souvent, comme exemple de projet réussi dans le domaine des Linked Open Data, on cite Wikidata - une sorte de version lisible par machine de Wikipédia, dont le contenu, contrairement à DBPedia, n'est pas généré par importation à partir des infobox des articles, mais est créé plus ou moins manuellement (et devient par la suite une source d'information pour les mêmes infobox).

Nous recommandons également de consulter des les utilisateurs du dépôt RDF Stardog sur le site de Stardog dans la section «Clients».

Quoi qu'il en soit, dans le rapport de Gartner «Hype Cycle for Emerging Technologies» de 2016 «Enterprise Taxonomy and Ontology Management» est placé au milieu de la descente dans la vallée du désespoir, avec une perspective d'atteindre le «plateau de la productivité» au plus tôt dans 10 ans.

Connecting Enterprise Data

Prévisions, prévisions, prévisions...

Par intérêt historique, j'ai résumé dans le tableau ci-dessous les prévisions de Gartner au fil des ans pour les technologies qui nous intéressent.

Cependant, déjà dans «Hype Cycle…» de 2018 un autre trend émergent est apparu - les Graphes de Connaissances. Une sorte de réincarnation a eu lieu : les SGBD graphes, sur lesquels l'attention des utilisateurs et les efforts des développeurs se sont concentrés, ont commencé à prendre les contours et le positionnement de leurs prédécesseurs concurrents sous l'influence des demandes des premiers et des habitudes des derniers.

Pratiquement chaque SGBD graphe se déclare désormais comme une plateforme adaptée à la construction d'un "graphe de connaissances" d'entreprise (le "linked data" est parfois remplacé par "connected data"), mais dans quelle mesure de telles revendications sont-elles justifiées?

Les bases de données graphiques restent non sémantiques, les données dans une SGBD graphique demeurent les mêmes silos de données. Les identifiants en chaîne plutôt que les URI rendent l'intégration de deux SGBD graphiques similaire à l'intégration de nouveaux silos, tandis que l'intégration de deux entrepôts RDF se résume souvent simplement à la fusion de deux graphes RDF. Un autre aspect de la non-sémantique est la non-réflexivité du modèle LPG, rendant difficile la gestion des métadonnées en utilisant la même plateforme.

Enfin, les SGBD graphiques ne possèdent pas de moteurs d'inférence et de moteurs de règles. Les résultats produits par ces moteurs peuvent être reproduits par la complexité des requêtes, mais c'est également possible même en SQL.

Cependant, les principaux entrepôts RDF n'ont pas de difficultés à prendre en charge le modèle LPG. L'approche la plus solide est considérée comme celle proposée autrefois dans Blazegraph : le modèle RDF*, qui combine RDF et LPG.

En savoir plus

Pour en savoir plus sur la prise en charge du modèle LPG par les entrepôts RDF, vous pouvez lire l'article précédent sur Habr : « Que se passe-t-il actuellement avec les entrepôts RDF ». Concernant les Graphes de Connaissance et le Data Fabric, j'espère qu'un jour un article séparé sera écrit. La dernière section, comme on peut facilement le comprendre, a été écrite à la hâte; néanmoins, même après six mois, ces concepts ne sont pas beaucoup plus clairs.

Littérature

1. Halpin, H., Monnin, A. (éds.) (2014). Philosophical Engineering: Toward a Philosophy of the Web
2. Allemang, D., Hendler, J. (2011) Semantic Web for the Working Ontologist (2e éd.)
3. Staab, S., Studer, R. (éds.) (2009) Handbook on Ontologies (2e éd.)
4. Wood, D. (éd.). (2011) Linking Enterprise Data
5. Keet, M. (2018) An Introduction to Ontology Engineering

Source : habr.com