Le Web sémantique et les données liées sont semblables à l'espace proche : il n'y a pas de vie là-bas. Pour y aller pour une période relativement longue... eh bien, je ne sais pas ce qu'on vous a dit dans votre enfance en réponse à « je veux devenir astronaute ». Mais vous pouvez observer ce qui se passe depuis la Terre ; devenir astronome amateur ou même professionnel est beaucoup plus simple.
Cet article traitera des tendances récentes, datant de quelques mois tout au plus, provenant du monde des entrepôts RDF. La métaphore du premier paragraphe était inspirée par une image publicitaire d'une taille épique sous le saut.
Image épique
I. GraphQL pour accéder à RDF
, GraphQL prétend devenir un langage universel d'accès aux bases de données. Et qu'en est-il de la possibilité d'accéder à RDF en utilisant GraphQL ?
Cette possibilité est fournie « prête à l'emploi » par :
- Stardog (, );
- les produits de TopQuadrant (, ).
Si un entrepôt ne fournit pas cette possibilité, il faut la réaliser soi-même en écrivant un « résolveur » correspondant. C'est ce qu'ont fait, par exemple, dans le projet français . Ou l'on peut simplement utiliser .
D'un point de vue d'un adepte orthodoxe du Web sémantique et des données liées, tout cela est bien sûr triste, car cela semble destiné à des intégrations construites autour des nouveaux silos de données, plutôt que d'être adapté à ces plateformes (bien sûr, les entrepôts RDF).
Les impressions de la comparaison entre GraphQL et SPARQL sont partagées.
- D'une part, GraphQL ressemble à un parent éloigné de SPARQL : il résout les problèmes typiques de suréchantillonnage et de multiplicité des requêtes propres aux REST - sans quoi, on ne pourrait probablement pas être considéré comme un langage de requêtes, même si c'est pour le web ;
- D'autre part, la rigidité du schéma de GraphQL est décevante. Par conséquent, son « introspectibilité » semble très limitée comparée à la pleine réflexivité de RDF. Et il n'y a pas d'analogues des chemins de propriété, donc il est même difficile de comprendre pourquoi il est « Graph- ».
II. Adaptateurs MongoDB
Une tendance complémentaire à la précédente.
- Dans Stardog maintenant - en particulier, tout sur ce même GraphQL - pour configurer la représentation des données MongoDB en graphes RDF virtuels ;
- GraphDB a récemment commencé à insérer des fragments MongoDB dans SPARQL.
Pour parler plus largement, des adaptateurs pour les sources JSON, permettant de représenter plus ou moins « à la volée » le JSON stocké dans ces sources comme RDF, on peut également mentionner le déjà ancien , qui peut être adapté, , à Apache Jena.
En résumé des deux premières tendances, on peut dire que les bases de données RDF démontrent une pleine capacité d'intégration et de fonctionnement dans des conditions de « stockage polyglotte » (polyglot persistence). Il est cependant connu que cette dernière n'est plus à la mode depuis longtemps, et qu'elle est remplacée par multimodalité. Comment se passe la multimodalité dans le monde des bases de données RDF ?
En bref, ça ne se passe pas. Le sujet des bases de données multimodelles mérite un article séparé; pour l'instant, on peut noter qu'il n'existe pas de bases de données multimodèles « basées » sur le modèle graphique (une variété de celui-ci peut être considérée comme RDF). Une certaine petite multimodalité — le support par les bases de données RDF d'un modèle graphique alternatif LPG — sera abordée dans le .
III. OLTP vs. OLAP
Cependant, Gartner lui-même , que la multimodalité est une condition sine qua non, principalement pour les bases de données opérationnelles. C'est compréhensible : dans une situation de « stockage polyglotte », les principaux problèmes surgissent avec la transactionnalité.
Alors, où se trouvent les bases de données RDF sur l'échelle OLTP—OLAP ? Je répondrais ainsi : ni là, ni ici. Pour désigner ce à quoi elles sont destinées, il faut un troisième acronyme. Comme option, je proposerais OLIP — Online Intellectual Processing.
Cependant, néanmoins :
- les mécanismes d'intégration réalisés dans GraphDB ne sont pas uniquement à contourner les problèmes de performance d'écriture ;
- Stardog va encore plus loin et réécrit complètement Et maintenant, permettez-moi de présenter un nouvel acteur sur le marché, des créateurs d'IBM Netezza et d'Amazon Redshift —
AnzoGraph SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocksDBCi-dessus, il y avait déjà
un lien Tout d'abord, selon
un article sur Wikipedia, Deuxièmement, des projets en rapport avec ce thème sont réalisés sur RocksDB (c'est-à-dire, ce ne sont pas des produits).
Deuxièmement, des projets (c'est-à-dire non des produits) de la thématique correspondante sont réalisés sur RocksDB.
Par exemple, eBay utilise RocksDB dans pour son « graphe de connaissances ». D'ailleurs, c'est amusant de lire : le langage de requête a commencé comme un format développé en interne, mais dernièrement, il a évolué pour ressembler beaucoup plus à SPARQL. Comme dans la blague : peu importe combien de graphes de connaissances nous faisons, cela revient toujours à RDF.
Un autre exemple — le Service de requête sur l'historique de Wikidata MWAPI V. Support des LPG
Je rappelle la principale différence entre les graphes LPG et les graphes RDF.
Dans les LPG, des propriétés scalaires peuvent être attachées aux instances des arêtes, tandis que dans les RDF, elles ne peuvent être attachées qu'aux « types » d'arêtes (mais pas seulement des propriétés scalaires, aussi des relations ordinaires). Cette limitation des RDF par rapport aux LPG
est surmontée Il est clair que la tâche « de support des LPG » se divise en deux parties :
l'incorporation dans le modèle RDF de modifications permettant d'imiter les constructions LPG ;
- l'incorporation dans le langage de requêtes RDF de modifications permettant d'interroger les données dans ce modèle modifié, — ou la mise en œuvre de la possibilité de formuler des requêtes sur ce modèle dans des langages de requête LPG populaires.
- V.1. Modèle de données
Il existe plusieurs approches possibles.
V.1.1. Propriété Singleton
L'approche la plus littérale pour harmoniser RDF et LPG est probablement
propriété singleton :
- :isMarriedTo
on utilise les prédicats:isMarriedTo1:isMarriedTo2,Ensuite, ces prédicats deviennent les sujets de nouveaux triplets :etc. - :isMarriedTo1 :since "2013-09-13"^^xsd:date
La relation de ces instances de prédicats avec le prédicat commun est établie par des triplets de typeetc. - :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type. - Il est évident que
, mais réfléchissez, pourquoi ne pas simplement écrire:isMarriedTo1 rdf:type :isMarriedToLa tâche « de support des LPG » est résolue ici au niveau de RDFS. Cette solution nécessite d'incorporer les modifications nécessaires..
La tâche de «support de LPG» est résolue ici au niveau de RDFS. Cette solution nécessite des modifications dans le . Des modifications peuvent être nécessaires de la part des dépôts RDF prenant en charge l'attachement des conséquences, mais pour l'instant, la propriété Singleton peut être considérée simplement comme une autre technique de modélisation.
V.1.2. La Réification Bien Fait
Des approches moins naïves proviennent de la prise de conscience que des instances de propriétés peuvent être entièrement instanciées par des triplets. En ayant la possibilité de dire quelque chose sur les triplets, nous pourrons aussi parler des instances de propriétés.
L'approche la plus solide parmi celles-ci est , également connu sous le nom de RDR, dans le ventre de Blazegraph. Il a été dès le début par lui et AnzoGraph. La solidité de l'approche est définie par le fait que dans son cadre les changements appropriés dans . La substance, cependant, est extrêmement simple. Dans la sérialisation Turtle RDF, on peut maintenant écrire à peu près ceci :
<> :since "2013-09-13"^^xsd:date .V.1.3. Autres Approches
On peut ne pas se soucier de la sémantique formelle, mais simplement considérer que les triplets ont certains identifiants qui sont, bien sûr, des URI, et composer de nouveaux triplets avec ces URI. Il ne reste plus qu'à donner accès à ces URI dans SPARQL. Ainsi Stardog.
Dans Allegrograph par un chemin intermédiaire. Il est connu que les identifiants des triplets dans Allegrograph , mais lors de la mise en œuvre des attributs de triplet, ils ne sont pas exposés. Cependant, la sémantique formelle est encore très loin. Il est remarquable que les attributs des triplets ne sont pas des URI, et que les valeurs de ces attributs peuvent également être seulement des littéraux. Les adeptes de LPG obtiennent exactement ce qu'ils voulaient. Dans un format spécialement inventé NQX, un exemple, similaire à celui donné ci-dessus pour RDF*, ressemble à ceci :
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Langages de Requête
En soutenant d'une manière ou d'une autre LPG au niveau du modèle, il faut permettre de faire des requêtes sur les données dans ce modèle.
- Blazegraph pour les requêtes sur RDF* supporte et Une requête SPARQL* ressemble à ceci :
SELECT * { <> :since ?since }- AnzoGraph supporte également et prévoit de supporter , le langage de requête de Neo4j.
- Stardog supporte son propre SPARQL et Gremlin. Pour obtenir dans SPARQL l'URI du triplet et les « métadonnées », on peut utiliser une construction semblable à celle-ci :
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph supporte également son propre SPARQL :
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Au fait, GraphDB a un temps supporté Tinkerpop/Gremlin, sans supporter cependant LPG, mais cela a cessé à partir de la version 8.0 ou 8.1.
VI. Renforcement des Licences
Il n'y a eu récemment aucune avancée notable à l'intersection des ensembles « triplestore de choix » et « triplestore open source ». Les nouveaux dépôts RDF open source sont encore loin d'être une bonne option pour une utilisation quotidienne, et le code source des nouvelles bases de données RDF que l'on aimerait utiliser (comme AnzoGraph) est fermé. On peut même parler de reculs...
Bien sûr, le code source ouvert ne devient pas fermé, mais certains dépôts open source ne sont progressivement plus considérés comme des choix dignes. Virtuoso, qui a une édition open source, est, à mon avis, en proie à de nombreux bugs. Blazegraph a été acheté par AWS et a servi de base à Amazon Neptune ; il n'est désormais pas clair s'il y aura un autre lancement. Il reste juste Jena...
Cependant, si le code source ouvert n'est pas très important et que l'on souhaite simplement essayer, la situation n'est pas aussi réjouissante qu'auparavant. Par exemple :
- Stardog propose une version gratuite (bien que la période d'essai standard ait doublé) ;
- dans , où l'inscription de nouveaux utilisateurs pour le plan de base gratuit a été suspendue.
En général, pour l'IT moyen, l'espace devient de plus en plus inaccessible, et sa maîtrise est devenue l'apanage des entreprises.
Source : habr.com
