Que se passe-t-il actuellement avec les référentiels RDF?

Le Web sémantique et les données liées sont similaires à l'espace proche: la vie n'est pas là. Pour y aller pour une période plus ou moins longue ... eh bien, je ne sais pas ce qu'ils vous ont dit dans l'enfance en réponse à "Je veux devenir astronaute". Mais vous pouvez observer ce qui se passe et ce qui se passe sur Terre; Devenir astronome amateur ou même professionnel est beaucoup plus facile.


L'article se concentrera sur les nouvelles tendances, datant de moins de quelques mois, du monde des référentiels RDF. La métaphore du premier paragraphe a été inspirée par cette image publicitaire de taille épique.


Table des matières


GraphQL pour accéder à RDF
II. Adaptateurs à MongoDB
III. OLTP vs. OLAP
IV. RocksDB
Prise en charge du GPL
V.1. Modèles de données
V.1.1. Biens immobiliers Singleton
V.1.2. Réification bien faite
V.1.3. D'autres approches
V.2. Langues de requête
VI. Licences plus strictes


GraphQL pour accéder à RDF


Ils disent que GraphQL prétend être un langage universel pour accéder aux bases de données. Qu'en est-il de la possibilité d'utiliser GraphQL pour accéder à RDF?


Hors de la boîte, cette opportunité est fournie par:



Si le référentiel ne fournit pas une telle opportunité, il est implémenté indépendamment en écrivant le résolveur correspondant. Cela a été fait, par exemple, dans le projet français DataTourisme . Ou vous ne pouvez déjà rien écrire, mais prenez simplement HyperGraphQL .


Du point de vue du disciple orthodoxe du Web sémantique et des données liées, tout cela, bien sûr, est triste, car il semble destiné aux intégrations qui sont construites autour de silos de données réguliers, et ne conviennent pas à cette plate-forme (bien sûr, le stockage RDF).


Les impressions de la comparaison de GraphQL avec SPARQL sont doubles.


  • D'une part, GraphQL ressemble à un parent éloigné de SPARQL: il a résolu les problèmes spécifiques à REST de récupération et de multiplicité des requêtes - sans lesquels, probablement, il serait impossible d'être considéré comme un langage de requête, même pour le Web, et d'avoir «-QL» dans le nom;
  • D'un autre côté, les circuits rigides de GraphQL bouleversent. En conséquence, son "introspectivité" semble très limitée par rapport à la pleine réflexivité du RDF. Et il n'y a pas d'analogue aux chemins de propriété, donc ce n'est pas très clair pourquoi c'est "Graph-".

II. Adaptateurs à MongoDB


Une tendance complémentaire à la précédente.


  • Dans Stardog, il est maintenant possible - en particulier, tout sur le même GraphQL - de configurer le mappage des données MongoDB en graphiques RDF virtuels;
  • Ontotext GraphDB vous permet récemment d' insérer des fragments dans SPARQL sur MongoDB Query.

De manière plus générale, sur les adaptateurs aux sources JSON qui permettent plus ou moins "à la volée" de représenter JSON comme RDF, il convient de rappeler la génération SPARQL assez longue, qui peut être attachée, par exemple , à Apache Jena.


En résumant les deux premières tendances, on peut dire que les stockages RDF démontrent leur pleine disponibilité pour les intégrations et leur fonctionnement dans les conditions de «stockage multivarié» (persistance polyglotte). On sait cependant que ce dernier est depuis longtemps démodé, et le multimodèle vient le remplacer. Et qu'en est-il du multimodélisation dans le monde du stockage RDF?


Bref, pas du tout. Je voudrais consacrer un article séparé au sujet du SGBD multimodèle. En attendant, vous pouvez voir qu'il n'y a pas de SGBD multimodèle dans lequel le modèle principal serait un modèle graphique (une variété de celui-ci peut être considéré comme RDF). Quelques petits multimodélisations - prise en charge du référentiel RDF pour un autre modèle de graphe LPG - seront discutés dans la section V.


III. OLTP vs. OLAP


Cependant, le même Gartner écrit que le multimodélisation est une condition sine qua non principalement pour les SGBD opérationnels . C'est compréhensible: dans une situation de «stockage multivarié», les principaux problèmes se posent avec la transactionnalité.


Mais où sont les référentiels RDF à l'échelle OLTP - OLAP? Je répondrais de cette façon: ni là ni ici. Pour indiquer à quoi ils sont destinés, une troisième abréviation est nécessaire. Alternativement, je suggérerais OLIP - traitement intellectuel en ligne.


Cependant, toujours:


  • Les mécanismes d'intégration de GraphDB mis en œuvre avec MongoDB ne sont pas moins conçus pour contourner les problèmes de performances d'écriture;
  • Stardog va encore plus loin et réécrit complètement le moteur, toujours dans le but d'améliorer les performances d'enregistrement.

Permettez-moi maintenant de présenter un nouveau joueur sur le marché. Des créateurs d'IBM Netezza et d'Amazon Redshift - AnzoGraph . L'image de la publicité du produit basée sur celle-ci a été placée au début de l'article. AnzoGraph se positionne comme une solution GOLAP. Comment aimez-vous SPARQL avec les fonctions de fenêtre? -


SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … } 

IV. RocksDB


Ci-dessus, il y avait déjà un lien vers l'annonce de Stardog 7 Beta, qui a déclaré que Stardog allait utiliser RocksDB comme système de stockage sous-jacent - stockage de valeur-clé, Facebook fork de LevelDB de Google. Pourquoi vaut-il la peine de parler d'une certaine tendance?


Tout d'abord, à en juger par l'article de Wikipedia , non seulement les référentiels RDF sont transférés vers RocksDB. Il existe des projets sur l'utilisation de RocksDB comme moteur de stockage dans ArangoDB, MongoDB, MySQL et MariaDB, Cassandra.


Deuxièmement, des projets (c'est-à-dire pas des produits) du sujet correspondant sont en cours de réalisation à RocksDB.


Par exemple, eBay utilise RocksDB dans la plate - forme pour son «graphique de connaissances». Au fait, c'est amusant à lire: le langage de requête a commencé comme un format maison, mais plus récemment, il a été en transition pour ressembler beaucoup plus à SPARQL . Comme dans la blague: peu importe la quantité de graphe de connaissances que nous faisons, nous obtenons toujours RDF.


Un autre exemple est le Wikidata History Query Service , qui est apparu il y a quelques mois. Avant son apparition, Wikidata devait accéder à l'API Mediawiki standard via MWAPI . Maintenant, beaucoup de choses sont possibles sur SPARQL pur. "Sous le capot", il y a aussi RocksDB. Soit dit en passant, WDHQS a fait, semble-t-il, la personne qui a importé Freebase dans le Google Knowledge Graph.


Prise en charge du GPL


Permettez-moi de vous rappeler la principale différence entre les graphiques LPG et les graphiques RDF .


En LPG, les propriétés scalaires peuvent être accrochées aux instances de bord, tandis qu'en RDF, elles ne peuvent être accrochées qu'aux "types" d'arêtes (mais pas seulement les propriétés scalaires, mais aussi les relations régulières). Cette limitation du RDF par rapport au LPG est surmontée par diverses techniques de modélisation. Les limites du LPG par rapport au RDF sont plus difficiles à surmonter, mais les graphiques LPG sont plus grands que les graphiques RDF, similaires aux images du manuel Harari, donc les gens les veulent.


De toute évidence, la tâche de soutenir le GPL se divise en deux parties:


  1. introduire des modifications dans le modèle RDF qui permettent de simuler des constructions LPG en son sein;
  2. apporter des modifications au langage de requête RDF qui permet d'accéder aux données dans ce modèle modifié, ou la mise en œuvre de la possibilité d'effectuer des requêtes sur ce modèle dans les langages de requête LPG populaires.

V.1. Modèles de données


Il existe plusieurs approches possibles.


V.1.1. Biens immobiliers Singleton


L'approche la plus littérale pour harmoniser RDF et LPG est probablement la propriété singleton :


  • À la place, par exemple :isMarriedTo , des prédicats sont utilisés :isMarriedTo1 , etc.
  • Ces prédicats deviennent alors des sujets de nouveaux triplets :: :isMarriedTo1 :since "2013-09-13"^^xsd:date , etc.
  • La relation de ces instances de prédicats avec un prédicat commun est établie par des triplets de la forme :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo .
  • Évidemment, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type , mais réfléchissez à la raison pour laquelle vous ne devriez pas écrire simplement :isMarriedTo1 rdf:type :isMarriedTo .

La tâche de prise en charge du GPL est résolue ici au niveau RDFS. Une telle solution nécessite d'être incluse dans la norme pertinente. Certaines modifications peuvent être requises des référentiels RDF qui prennent en charge les effets d'attachement, mais pour l'instant, la propriété Singleton peut être considérée simplement comme une autre technique de modélisation.


V.1.2. Réification bien faite


Des approches moins naïves découlent de la prise de conscience que les instances de propriétés sont instanciées par des triplets. Ayant la possibilité de dire quelque chose sur les triplets, nous avons la possibilité de parler d'instances de propriétés.


La plus solide de ces approches est RDF * , alias RDR, dans les entrailles du Blazegraph. Dès le début, AnzoGraph l'a choisi pour lui-même. La solidité de l'approche est déterminée par le fait que dans son cadre des changements correspondants sont proposés dans RDF Semantics . Le point, cependant, est extrêmement simple. Dans la sérialisation Turtle, RDF peut maintenant être écrit quelque chose comme ceci:


 <<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date . 

V.1.3. D'autres approches


Vous ne pouvez pas vous soucier de la sémantique formelle, mais supposez simplement que les triplets ont certains identificateurs, qui sont, bien sûr, des URI, et composent de nouveaux triplets avec ces URI. Il ne reste plus qu'à donner accès à ces URI dans SPARQL. C'est ce que fait Stardog.


Allegrograph a fait un chemin intermédiaire. Il est connu que les identificateurs de triplet existent dans Allegrograph, mais lors de la mise en œuvre des attributs triples, ils ne ressortent pas. Cependant, la sémantique formelle est très éloignée. Il est à noter que les attributs des triplets ne sont pas des URI, et les valeurs de ces attributs ne peuvent également être que des littéraux. Les adhérents au GPL obtiennent exactement ce qu'ils voulaient. Dans le format NQX spécialement inventé, un exemple similaire à celui ci-dessus pour RDF * ressemble à ceci:


 :bob :marriedTo :alice {"since" : "2013-09-13"} 

V.2. Langues de requête


Ayant pris en charge le GPL d'une manière ou d'une autre au niveau du modèle, vous devez donner la possibilité de faire des demandes de données dans un tel modèle.


  • Blazegraph pour les requêtes RDF * prend en charge SPARQL * et Gremlin . La requête pour SPARQL * ressemble à ceci:

  SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since } 

  • Anzograph prend également en charge SPARQL * et va prendre en charge Cypher , un langage de requête dans Neo4j.
  • Stardog prend en charge sa propre extension SPARQL et à nouveau Gremlin. Vous pouvez obtenir un triplet et des «méta-informations» dans l'URI SPARQL en utilisant quelque chose comme ceci:

 SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since } 

  • Allegrograph prend également en charge sa propre extension SPARQL:

  SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) } 

Soit dit en passant, GraphDB a pris en charge Tinkerpop / Gremlin, tout en ne prenant pas en charge le GPL, mais dans la version 8.0 ou 8.1, cela s'est arrêté.


VI. Licences plus strictes


Aucun ajout à l'intersection des ensembles «triplestore of choice» et «open source triplestore» n'est survenu récemment. Les nouveaux référentiels RDF open source sont loin d'être un bon choix pour un usage quotidien, et le code source des nouveaux triplesteurs que nous aimerions utiliser (le même AnzoGraph) est fermé. On peut plutôt parler de baisses ...


Bien sûr, le code source précédemment ouvert ne ferme pas, mais certains référentiels open source ne sont progressivement plus considérés comme dignes de choix. Virtuoso, qui a une édition open source, à mon avis, se noie dans les bugs. Blazegraph a été acheté par AWS et a constitué la base d'Amazon Neptune; maintenant, il n'est pas clair s'il y aura au moins une autre version. Il ne reste que Jena ...


Si l'open source n'est pas très important, mais que vous voulez juste essayer, alors tout est aussi moins rose qu'avant. Par exemple:


  • Stardog arrête de distribuer la version gratuite (cependant, elle a doublé la période d'essai de la version régulière);
  • dans GraphDB Cloud , où vous pouviez auparavant choisir un forfait de base gratuit, l'enregistrement des nouveaux utilisateurs est suspendu.

En général, pour le profane informatique moyen, l'espace devient de plus en plus inaccessible, son développement devient le lot des entreprises.

Source: https://habr.com/ru/post/fr451206/


All Articles