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

Je veux présenter au public un fragment de ce livre récemment sorti:

Modélisation ontologique des entreprises: méthodes et technologies [Texte]: monographie / [S. V. Gorshkov, S. S. Kralin, O. I. Mushtak et autres; rédacteur en chef S. V. Gorshkov]. - Iekaterinbourg: maison d'édition de l'Université de l'Oural, 2019 .-- 234 p.: Ill., Tab.; 20 cm - Auth. sont indiqués au dos de la mésange. s - Bibliogr. à la fin du chap. - ISBN 978-5-7996-2580-1: 200 exemplaires.

Le calcul de ce fragment sur Habré a trois objectifs:

• Recueillir des questions et des commentaires pour les prendre en compte lors de l'inclusion de ce texte sous une forme révisée dans d'autres publications.
• Pour faire des ajouts peu compatibles avec le format de la monographie imprimée: notes d'actualité (en dessous elles sont sous les spoilers) et hyperliens; ainsi que faire des corrections (ci-dessous, elles ne sont en aucun cas mises en évidence).
• De nombreux adeptes du Web sémantique et des données liées croient encore que leur cercle est si étroit, principalement parce que le grand public n'a toujours pas été bien expliqué au public ce que sont le Web sémantique et les données liées. L'auteur du fragment, bien qu'il appartienne à ce cercle, n'adhère pas à une telle opinion, mais se considère néanmoins obligé de faire une nouvelle tentative.

Contenu du paragraphe

Web sémantique
Données liées
RDF
RDFS
SPARQL
Chouette
Liaison des données d'entreprise
Connexion des données d'entreprise
Littérature

Web sémantique

L'évolution d'Internet peut être représentée comme suit (ou parler de ses segments, formés dans l'ordre suivant):

1. Documents sur Internet . Technologies clés - Gopher, FTP, etc.
   Internet est un réseau mondial de partage de ressources locales.
2. Documents Internet . Les technologies clés sont HTML et HTTP.
   La nature des ressources exposées prend en compte les caractéristiques de leur support de transmission.
3. Données sur Internet . Technologies clés - API REST et SOAP, XHR, etc.
   On peut dire que non seulement les gens deviennent des consommateurs de ressources.
4. Données Internet . Les technologies clés sont les technologies de données liées.
   Cette quatrième phase, prédite par Berners-Lee, créateur des technologies clés du second et directeur du W3C, s'appelle le Web sémantique; Les technologies de données liées sont conçues pour rendre les données Web non seulement lisibles par machine, mais également «lisibles par machine».

Le Web sémantique est plus une vision systémique du futur Internet qu'une tendance spécifique spontanée ou de lobbying, bien qu'il puisse prendre en compte ces dernières. Par exemple, une caractéristique importante de ce qu'on appelle le Web 2.0 est le «contenu généré par l'utilisateur». La recommandation du Web Annotation Ontology du W3C et une initiative telle que Solid sont appelées à en tenir compte.

À partir de ce qui suit, le lecteur verra la correspondance des concepts clés des deuxième et quatrième étapes:

• Les homologues URL sont des URI,
• L'équivalent HTML est RDF,
• Les hyperliens HTML sont similaires aux occurrences d'URI dans les documents RDF.

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 pour atteindre ses objectifs ultimes. Les principes de base des données liées Berners-Lee ont souligné ce qui suit.

Principe 1 Utilisation d'un URI ( Uniform Resource Identifier ) pour nommer les entités.

Les URI sont des identifiants d'entité globaux par opposition aux identifiants d'enregistrement de chaîne locale. Par la suite, ce principe a été mieux exprimé dans le slogan de Google Knowledge Graph «les choses, pas les chaînes ».

Principe 2 Utilisation d'URI dans un schéma HTTP afin de pouvoir les dé-référencer.

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

Principe 3 Utilisation des normes W3C - principalement RDF (S) et SPARQL - en particulier lors du déréférencement d'URI.

Ces «couches» distinctes de la pile technologique de données liées, également connues sous le nom de gâteau de couche Web sémantique , seront décrites ci-dessous.

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

RDF vous permet de vous limiter à une description verbale de la ressource en langage naturel, et le quatrième principe encourage à ne pas le faire. Avec l'observation générale du premier principe, il devient possible, lors de la description d'une ressource, de se référer à d'autres, y compris des «étrangers», c'est pourquoi les données sont appelées liées. En fait, il est presque inévitable d'utiliser des URI nommés dans le dictionnaire RDFS.

RDF

RDF (Resource Description Framework) est un formalisme pour décrire les entités liées.

Des déclarations de la forme «sujet-prédicat-objet», appelées triplets, sont faites sur les entités et leurs relations. Dans le cas le plus simple, le sujet, le prédicat et l'objet sont des URI. Le même URI peut être dans différentes positions dans différents triplets: être un sujet, un prédicat et un objet; ainsi, 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 dits vides , et les objets peuvent également être des littéraux . Les littéraux sont des instances de types primitifs constitués d'une représentation sous forme de chaîne et d'une déclaration de type.

Exemples d'écriture de littéraux (dans la syntaxe Turtle, voir ci-dessous): "5.0"^^xsd:float et "five"^^xsd:string . Les littéraux avec le type rdf:langString peuvent également être fournis avec une balise de langue, dans Turtle, il est écrit comme ceci: "five"@en et ""@ru .

Les nœuds vides sont des ressources «anonymes» sans identificateurs globaux, qui peuvent cependant être revendiqués; une sorte de variable existentielle.

Donc (c'est en fait tout l'intérêt de RDF):

• le 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.

RDF est un modèle abstrait. RDF peut être écrit (sérialisé) dans différentes syntaxes: RDF / XML , Turtle (la plus lisible par l'homme), JSON-LD , HDT (binaire).

Le même RDF peut être sérialisé en RDF / XML de différentes manières, par conséquent, par exemple, le XML résultant est inutile pour valider avec XSD ou essayer de récupérer des données à l'aide de XPath. De même, il est peu probable que JSON-LD satisfasse le désir du développeur Javascript moyen de travailler avec RDF en utilisant la notation Javascript par points et crochets (bien que JSON-LD se déplace dans cette direction, suggérant un mécanisme de cadrage ).

La plupart des syntaxes offrent des moyens de raccourcir les URI longs. Par exemple, la déclaration @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> dans Turtle vous permettra alors d'écrire au lieu de <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> juste rdf:type .

RDFS

RDFS (RDF Schema) est un dictionnaire de modélisation de base qui présente les concepts de propriété et de classe et des propriétés telles que rdf:type , rdfs:subClassOf , rdfs:domain et rdfs:range . À l'aide du dictionnaire RDFS, par exemple, les expressions valides suivantes peuvent être écrites:

 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 restrictions (bien que la spécification officielle laisse la possibilité d'une telle utilisation). Le mot «schéma» ne doit pas être compris dans le même sens que dans l'expression «schéma XML». Par exemple :author rdfs:range foaf:Person signifie que rdf:type toutes les valeurs de la propriété :author est foaf:Person , mais ne signifie pas que cela doit être dit à l'avance.

SPARQL

SPARQL (SPARQL Protocol and RDF Query Language) est un langage de requête pour les données RDF. Dans le cas simple, une requête SPARQL est un ensemble d'échantillons avec lequel les triplets du graphe sont comparés. Des variables peuvent être trouvées dans des échantillons aux positions des sujets, des prédicats et des objets.

La requête renverra de telles valeurs de variables qui, une fois substituées en échantillons, peuvent produire un sous-graphe du graphe RDF interrogé (un sous-ensemble de ses triplets). Les variables du même nom dans différents échantillons de triplets doivent avoir la même valeur.

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

 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 pour décrire la traversée de graphe (cependant, certains référentiels RDF offrent des moyens d'ajuster le plan d'exécution de la requête). Par conséquent, certaines tâches de graphique standard, par exemple, trouver le chemin le plus court, ne peuvent pas être résolues sur SPARQL, y compris en utilisant le mécanisme des chemins de propriété (mais, encore une fois, les référentiels RDF individuels offrent des extensions spéciales pour résoudre ces problèmes).

SPARQL ne partage pas la présomption d'ouverture du monde et suit l'approche de la "négation comme échec", des constructions comme FILTER NOT EXISTS {…} possibles . La distribution des données est prise en compte à l'aide du mécanisme de requête fédérée .

Le point d'accès SPARQL - un magasin RDF capable de gérer les requêtes SPARQL - n'a pas d'homologues directs de la deuxième étape (voir le début de cette section). Elle peut être assimilée à une base de données basée sur le contenu des pages HTML qui ont été générées, mais accessible en externe. Le point d'accès SPARQL est analogue au point d'accès API de la troisième étape, mais avec deux différences principales. 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, une telle API est complètement auto-documentée (ce que HATEOAS a essayé de réaliser).

Il existe des moyens moins fonctionnels d'organiser l'accès aux données RDF, par exemple, les fragments de données liés (LDF) et la plateforme de données liées (LDP).

Chouette

OWL (Web Ontology Language) - formalisme de représentation des connaissances, version syntaxique de la logique descriptive $$$\ mathcal {SROIQ (D)}$ (partout ci-dessous, il est plus correct de dire OWL 2, la première version d'OWL était basée sur $$$\ mathcal {SHOIN (D)}$ )

Les classes correspondent à des concepts de logiques descriptives en OWL, les propriétés correspondent à des rôles, les individus conservent leur ancien nom. Les axiomes sont également appelés axiomes.

Par exemple, dans la soi-disant syntaxe Manchester pour écrire OWL, nous connaissons déjà l' axiome $$$\ mathsf {Parent} \ equiv \ mathsf {Human} \ sqcap \ exist \ mathsf {hasParent} ^ {-} \ mathsf {.Human}$ sera écrit comme ceci:

 Class: Human Class: Parent EquivalentClass: Human and (inverse hasParent) some Human ObjectProperty: hasParent 

Il existe d'autres syntaxes pour écrire OWL, par exemple, la syntaxe fonctionnelle utilisée dans la spécification officielle et OWL / XML . De plus, OWL peut être sérialisé vers la syntaxe RDF abstraite et plus tard vers l'une des syntaxes spécifiques.

OWL par rapport à RDF agit à deux égards. D'une part, il peut être considéré comme une sorte de dictionnaire qui étend RDFS. D'un autre côté, c'est un formalisme plus puissant, pour lequel RDF n'est qu'un format de sérialisation. Toutes les constructions élémentaires OWL ne peuvent pas être écrites à l'aide d'un seul triplet RDF.

Selon le sous-ensemble des constructions OWL autorisés à utiliser, ils parlent des soi-disant profils OWL . Les standardisés et les plus connus sont OWL EL, OWL RL et OWL QL. Le choix du profil affecte la complexité de calcul des tâches typiques. Un ensemble complet de designs OWL assortis $$$\ mathcal {SROIQ (D)}$ , appelé OWL DL. Parfois, ils parlent également de OWL Full, dans lequel les constructions OWL peuvent être utilisées avec la pleine liberté inhérente à RDF, sans limitations sémantiques et informatiques $$$\ mathcal {SROIQ (D)}$ . Par exemple, quelque chose peut être à la fois une classe et une propriété. OWL Full est insoluble.

Les principes clés pour attacher des effets à OWL sont l'acceptation de l'hypothèse du monde ouvert ( OWA ) et le rejet de la présomption d'hypothèse de nom unique ( UNA ). Ci-dessous, nous verrons à quoi ces principes peuvent conduire et nous nous familiariserons avec certaines constructions OWL.

Laissez l'ontologie contenir le fragment suivant (dans la syntaxe de Manchester):

 Class: manyChildren EquivalentTo: Human that hasChild min 3 Individual: John Types: Human Facts: hasChild Alice, hasChild Bob, hasChild Carol 

Doit-on en déduire que John est grand? Le refus de l'UNA forcera le moteur de sortie à répondre à cette question par la négative, car Alice et Bob pourraient bien être la même personne. Pour que ce qui suit se produise, vous devez ajouter l'axiome suivant:

 DifferentIndividuals: Alice, Bob, Carol, John 

Soit maintenant le fragment de l'ontologie a la forme suivante (John est déclaré grand, mais il n'a que deux enfants indiqués):

 Class: manyChildren EquivalentTo: Human that hasChild min 3 Individual: John Types: Human, manyChildren Facts: hasChild Alice, hasChild Bob DifferentIndividuals: Alice, Bob, Carol, John 

Cette ontologie sera-t-elle incohérente (ce qui peut être interprété comme une preuve de données invalides)? L’adoption d’OWA obligera le moteur de sortie à répondre par la négative: «ailleurs» (dans une autre ontologie), on peut très bien dire que Carol est aussi l’enfant de John.

Pour exclure la possibilité de cela, nous ajoutons un nouveau fait sur John:

 Individual: John Facts: hasChild Alice, hasChild Bob, not hasChild Carol 

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

 ObjectProperty: hasChild Domain: Human haracteristics: Irreflexive Class: Human EquivalentTo: { Alice, Bill, Carol, John } 

Maintenant, l'ontologie deviendra controversée, ce que le moteur de sortie ne manquera pas de rapporter. Le dernier des axiomes, dans un sens, nous avons «fermé» le monde, et notons comment la possibilité que John soit un enfant pour lui-même est exclue.

Liaison des données d'entreprise

Un ensemble d'approches et de technologies Linked Data était initialement destiné à la publication de données sur le Web. Leur utilisation dans l'environnement des entreprises se heurte à un certain nombre de difficultés.

Par exemple, dans un environnement d'entreprise fermé, le pouvoir de déduction d'OWL, basé sur l'adoption d'OTA et le rejet de l'UNA, décisions dues à la nature ouverte et distribuée du web, est trop faible. Et ici, les sorties suivantes sont possibles.

• Autonomisation de la sémantique OWL, impliquant l'abandon de OWA et l'adoption de UNA, la mise en œuvre du moteur de sortie correspondant. - De cette façon, va le stockage Stardog RDF.
• L'abandon des capacités déductives de OWL au profit des moteurs de règles. - Stardog prend en charge SWRL ; Jena et GraphDB proposent leurs propres langages de règles.
• Refus des possibilités déductives de OWL, utilisation pour la modélisation de l'un ou l'autre sous-ensemble proche de RDFS. - Voir plus à ce sujet plus tard.

Un autre problème est l'attention plus importante qu'il est possible de consacrer au monde de l'entreprise aux problèmes de qualité des données et au manque d'outils de validation des données sur la pile de données liées. Les sorties sont les suivantes.

• Encore une fois, l'utilisation de constructions OWL avec la sémantique d'un monde fermé et l'unicité des noms en présence d'un moteur de sortie approprié pour la validation.
• À l'aide de SHACL , normalisé après la correction de la liste des couches du gâteau de couche Web sémantique (cependant, il peut également être utilisé comme moteur de règles), ou ShEx .
• La prise de conscience que tout est finalement réalisé par les requêtes SPARQL, la création de notre propre mécanisme simple de validation des données en les utilisant.

Cependant, même un rejet complet des capacités déductives et des outils de validation laisse la pile de données liées inégalée dans les tâches qui sont similaires au paysage ouvert et distribué sur le Web - dans les tâches d'intégration de données.

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 classe MDM (Master Data Management) ou DWH (Data Warehouse). Ces tâches sont disponibles dans n'importe quelle industrie.

En ce qui concerne les applications spécifiques à l'industrie, les technologies de données liées sont actuellement les plus populaires dans les industries suivantes.

• les technologies biomédicales (où leur popularité est apparemment liée à la complexité du sujet);

• la fabrication et l'exploitation de produits complexes (ingénierie à grande échelle, production de pétrole et de gaz; nous parlons le plus souvent de la norme ISO 15926 );

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

• systèmes de questions-réponses qui ont des applications commerciales (IBM Watson, Apple Siri, Google Knowledge Graph);

• publication de données structurées (pour une bonne raison, cela peut déjà être attribué aux données ouvertes liées).

Nous vous recommandons également de vous familiariser avec la liste des utilisateurs de la boutique Stardog RDF sur le site Web de Stardog dans la section Clients.

Quoi qu'il en soit, dans le Gartner Hype Cycle for Emerging Technologies Enterprise Taxonomy and Ontology Management 2016 a été placé au milieu de la descente dans la vallée de la déception avec la perspective d'atteindre le "plateau de productivité" au plus tôt 10 ans plus tard.

Connexion des données d'entreprise

Cependant, déjà dans le «Hype Cycle ...» de 2018, une autre tendance à la hausse est apparue - Knowledge Graphs. Il y a eu une certaine réincarnation: les SGBD graphiques, qui ont attiré l'attention des utilisateurs et la force des développeurs, sous l'influence des demandes des premiers et des habitudes des seconds, ont commencé à acquérir les contours et le positionnement de leurs prédécesseurs-concurrents.

Presque chaque graphe SGBD se proclame désormais une plate-forme appropriée pour construire un «graphe de connaissances» d'entreprise (les «données liées» sont parfois remplacées par des «données connectées»), mais dans quelle mesure ces allégations sont-elles justifiées?

Les bases de données graphiques sont toujours aussi sémantiques, les données dans le SGBD graphique sont toujours le même silo de données. URI , RDF- RDF-. — LPG, .

, . , SQL.

, RDF- LPG. , Blazegraph: RDF*, RDF LPG.

Littérature

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