Le Web sémantique et les données liées sont comme l'espace : il n'y a pas de vie là-bas. Y aller plus ou moins longtemps… Je ne sais pas ce qu'on vous disait enfant en réponse à « Je veux devenir astronaute ». Mais vous pouvez regarder 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 quelques mois à peine, du monde du stockage RDF. La métaphore du premier paragraphe est inspirée d'une image promotionnelle épique sous la coupe.
image épique
I. GraphQL pour l'accès RDF
que GraphQL prétend être le langage universel d'accès aux bases de données. Et qu'en est-il de la possibilité d'accéder à l'aide de GraphQL à RDF ?
Hors de la boîte, cette opportunité est fournie par :
- stardog (, );
- Produits TopQuadrant (, ).
Si le référentiel ne fournit pas une telle opportunité, il est implémenté indépendamment en écrivant le "résolveur" approprié (résolveur). Cela a été fait, par exemple, dans le projet français . Ou vous pouvez déjà ne rien écrire, mais juste prendre .
Du point de vue d'un adepte orthodoxe du Web sémantique et des données liées, tout cela est, bien sûr, triste, puisque cela semble destiné à des intégrations construites autour du prochain silo de données, et non à des plates-formes adaptées (bien sûr, RDF stores) .
Les impressions de la comparaison de GraphQL avec SPARQL sont doubles.
- D'une part, GraphQL ressemble à un lointain parent de SPARQL : il résout les problèmes de resélection et de requêtes multiples qui sont caractéristiques de REST - sans lesquels, probablement, il ne serait pas possible d'envisager langage de requête, du moins pour le web ;
- En revanche, le schéma rigide de GraphQL dérange. En conséquence, son "introspectivité" semble être très limitée par rapport à la pleine réflexivité de RDF. Et il n'y a pas d'analogue des chemins de propriété, donc on ne sait même pas très bien pourquoi c'est "Graph-".
II. Adaptateurs pour MongoDB
Une tendance complémentaire à la précédente.
- Chez Stardog maintenant - en particulier, le tout sur le même GraphQL - configurer l'affichage des données MongoDB dans des graphes RDF virtuels ;
- Ontotext GraphDB récemment insérer dans les fragments SPARQL sur la requête MongoDB.
En parlant plus largement, des adaptateurs aux sources JSON qui permettent plus ou moins "à la volée" de représenter le JSON stocké dans ces sources en tant que RDF, alors on peut aussi rappeler l'existant pendant un bon bout de temps qui peut être ajusté , à Apache Iéna.
En résumant les deux premières tendances, nous pouvons dire que les référentiels RDF démontrent une parfaite préparation à l'intégration et fonctionnent dans des conditions de « stockage multiple » (persistance polyglotte). On sait cependant que ce dernier est passé de mode depuis longtemps, et pour le remplacer multi-modélisation. Et qu'en est-il de la multi-modélisation dans le monde du stockage RDF ?
Bref, pas question. Je voudrais consacrer un article séparé au sujet du SGBD multi-modèle, mais pour l'instant vous pouvez voir qu'il n'y a pas de SGBD multi-modèle "basé" sur le modèle de graphe (RDF peut être considéré comme une variante de celui-ci) maintenant. Quelques petites multi-modélisations - prise en charge par les stockages RDF d'un modèle de graphe LPG alternatif - seront discutées dans .
III. OLTP contre OLAP
Cependant, le même Gartner que la multi-modélisation est une condition sine qua non principalement pour salles d'opération SGBD. Cela se comprend : dans une situation de « stockage multiple », les principaux problèmes se posent avec la transactionnalité.
Mais où se situent les référentiels RDF sur l'échelle OLTP-OLAP ? Je répondrais ainsi : ni là ni ici. Pour indiquer à quoi ils sont destinés, une troisième abréviation est nécessaire. En option, je suggérerais OLIP — Traitement intellectuel en ligne.
Cependant, toujours:
- les mécanismes d'intégration mis en place dans GraphDB avec MongoDB ne sont pas des moindres pour contourner les problèmes de performances d'écriture ;
- Stardog va encore plus loin et complètement moteur, encore une fois dans le but d'améliorer les performances d'écriture.
Et maintenant, permettez-moi de vous présenter un nouvel acteur sur le marché. Par les créateurs d'IBM Netezza et d'Amazon Redshift - . Une image d'une publicité pour un produit basé 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. RochesDB
Ci-dessus déjà à l'annonce de Stardog 7 Beta, qui annonçait que Stardog allait utiliser RocksDB comme système de stockage sous-jacent - le stockage clé-valeur, le fork de Facebook de LevelDB de Google. Pourquoi vaut-il la peine de parler d'une certaine tendance?
Tout d'abord, à en juger par , non seulement les référentiels RDF sont "transplantés" dans RocksDB. Il existe des projets pour utiliser RocksDB comme moteur de stockage dans ArangoDB, MongoDB, MySQL et MariaDB, Cassandra.
Deuxièmement, les projets (c'est-à-dire pas les produits) du sujet correspondant sont réalisés sur RocksDB.
Par exemple, eBay utilise RocksDB dans pour votre « graphe de connaissances ». Au passage, c'est marrant à lire : le langage de requête a commencé comme un format maison, mais plus récemment, il a évolué pour ressembler beaucoup plus à SPARQL. Comme dans une blague : peu importe la quantité de graphes de connaissances que nous faisons, nous obtenons toujours RDF.
Un autre exemple - apparu il y a quelques mois . Avant son introduction, les informations historiques de Wikidata devaient être accessibles via à l'API standard de Mediawiki. Beaucoup est maintenant possible en SPARQL pur. "Sous le capot" il y a aussi RocksDB. Au fait, WDHQS l'a fait, il semble que la personne impliquée dans l'importation de Freebase dans le Google Knowledge Graph.
V. Prise en charge du GPL
Permettez-moi de vous rappeler la principale différence entre les graphiques LPG et les graphiques RDF.
Dans LPG, les propriétés scalaires peuvent être attachées à des instances d'arête, alors qu'en RDF elles ne peuvent être attachées qu'à des "types" d'arête (mais pas seulement des propriétés scalaires, mais aussi des liens ordinaires). Cette limitation du RDF par rapport au GPL une sorte de technique de modélisation. Les limitations de LPG par rapport à RDF sont plus difficiles à surmonter, mais les graphiques LPG ressemblent plus à des images du manuel de Harari qu'à des graphiques RDF, donc les gens les veulent.
Évidemment, la tâche de « soutenir le GPL » se divise en deux parties :
- apporter des modifications au modèle RDF qui permettent d'y simuler des constructions LPG ;
- apporter des modifications au langage de requête RDF qui permettent d'accéder aux données dans ce modèle modifié, ou la mise en œuvre de la possibilité d'interroger ce modèle dans les langages de requête LPG populaires.
V.1. Modèle de données
Il existe ici plusieurs approches possibles.
V.1.1. propriété unique
L'approche la plus littérale pour harmoniser RDF et LPG est probablement :
- Au lieu, par exemple, du prédicat
:isMarriedToles prédicats sont utilisés:isMarriedTo1,:isMarriedTo2etc - Ces prédicats deviennent alors sujets de nouveaux triplets :
:isMarriedTo1 :since "2013-09-13"^^xsd:dateetc - La connexion de ces instances de prédicats avec un prédicat commun est établie par des triplets de la forme
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - De toute évidence, l'
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mais demandez-vous pourquoi vous ne devriez pas simplement écrire:isMarriedTo1 rdf:type :isMarriedTo.
La tâche de "support GPL" est résolue ici au niveau RDFS. Une telle décision nécessite l'inclusion dans le . Certaines modifications peuvent être requises des référentiels RDF qui prennent en charge les conséquences attachées, mais pour l'instant, Singleton Property peut être considéré comme une simple 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é sont parfaitement instanciées par des triplets. En pouvant parler de triplets, on peut aussi parler d'instances de propriété.
La plus solide de ces approches est alias RDR, dans les entrailles de Blazegraph. C'est depuis le début pour moi et AnzoGraph. La solidité de l'approche est déterminée par le fait que dans son cadre changements correspondants dans . Le point, cependant, est extrêmement simple. Dans la sérialisation RDF Turtle, vous pouvez maintenant écrire quelque chose comme ceci :
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Autres approches
Vous ne pouvez pas vous soucier de la sémantique formelle, mais considérez simplement que les triplets ont des identifiants, qui, bien sûr, sont des URI, et composez de nouveaux triplets avec ces URI. Il ne reste plus qu'à donner accès à ces URI dans SPARQL. Donc stardog.
Dans l'allégrographe de manière intermédiaire. On sait que les identifiants des triplets dans l'allégrographe , mais lorsque les attributs triples sont implémentés, ils ne ressortent pas. Cependant, même la sémantique formelle est très éloignée. Notamment, les attributs de triplet 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. Langages de requête
Ayant pris en charge LPG d'une manière ou d'une autre au niveau du modèle, vous devez rendre possible l'interrogation des données dans un tel modèle.
- Blazegraph pour les requêtes RDF* prend en charge и . Une requête SPARQL* ressemble à ceci :
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph prend également en charge et va soutenir , le langage de requête de Neo4j.
- Stardog maintient le sien SPARQL et Diablotin. Vous pouvez obtenir l'URI d'un triplet et des "méta-informations" dans SPARQL en utilisant quelque chose comme ceci :
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph prend également en charge ses propres SPARQL :
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Incidemment, GraphDB a pris en charge Tinkerpop/Gremlin à un moment donné sans prendre en charge LPG, mais cela s'est arrêté dans la version 8.0 ou 8.1.
VI. Resserrer les licences
Il n'y a eu aucun ajout récent à l'intersection des ensembles "triplestore de choix" et "triplestore open source". Les nouveaux magasins RDF open source sont loin d'être un bon choix pour un usage quotidien, et le code source des nouveaux magasins triples que j'aimerais utiliser (par exemple, AnzoGraph) est fermé. On peut plutôt parler de réductions...
Bien sûr, auparavant l'open source n'est pas fermé, 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 acheté par AWS et formé la base d'Amazon Neptune ; maintenant, il n'est pas clair s'il y aura au moins une autre version. Seule Jenna reste...
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:
- Chien vedette distribuer la version gratuite (cependant, la période d'essai de la version standard a doublé) ;
- в , où vous pouviez auparavant choisir le plan de base gratuit, l'enregistrement de nouveaux utilisateurs est suspendu.
De manière générale, l'espace devient de plus en plus inaccessible pour un informaticien ordinaire, son développement devient le lot des grandes entreprises.
Source: habr.com