🥇Ce se întâmplă acum cu depozitele RDF?

Web-ul Semantic și Linked Data sunt asemănătoare cu spațiul cosmic apropiat: acolo nu există viață. Pentru a ajunge acolo pentru o perioadă mai lungă de timp... ei bine, nu știu ce v-au spus în copilărie când ați spus „vreau să fiu astronaut”. Dar se poate observa ceea ce se întâmplă și de pe Pământ; să devii astronom amator sau chiar profesionist este mult mai simplu.

Articolul se va concentra pe tendințele recente din lumea depozitelor RDF, care nu au mai mult de câteva luni. Metafora din primul paragraf a fost inspirată de o imagine publicitară de dimensiuni epice.

Imagine epică

I. GraphQL pentru acces la RDF

Se spune, pentru că GraphQL pretinde că va deveni un limbaj universal pentru accesul la baze de date. Dar cum stau lucrurile cu posibilitatea de acces folosind GraphQL la RDF?

Această posibilitate este oferită „din cutie” de:

Stardog (blog, documentația);
produsele TopQuadrant (un webinar, documentația).

Dacă depozitul nu oferă această posibilitate, aceasta poate fi implementată manual, scriind un „rezolvitor” corespunzător. Așa au procedat, de exemplu, în proiectul francez DataTourisme. Sau poate că acum nu mai trebuie să scrii nimic și pur și simplu să iei HyperGraphQL.

Din perspectiva unui susținător ortodox al Web-ului Semantic și Linked Data, toate acestea sunt, desigur, triste, deoarece par să fie destinate integrărilor construite în jurul unor noi silozuri de date, nu platformelor potrivite (desigur, depozitelor RDF).

Impresiile despre compararea GraphQL cu SPARQL sunt contradictorii.

Pe de o parte, GraphQL arată ca un „rude îndepărtată” a SPARQL: rezolvă problemele tipice ale REST legate de suprasarcină și de multiplicitatea cererilor – fără de care, probabil, nu ar putea fi considerat un limbaj de interogare, chiar și pentru web;
Pe de altă parte, mă întristează rigiditatea schema GraphQL. În consecință, „introspecția” sa pare foarte limitată comparativ cu reflexivitatea completă a RDF. Și nu există niciun echivalent al căilor proprietății, așa că nici nu este foarte clar de ce este denumit „Graph-”.

II. Adaptori pentru MongoDB

O tendință complementară celei anterioare.

în Stardog acum se poate — în principal, tot pe același GraphQL — pentru a configura afișarea datelor MongoDB în grafuri RDF virtuale;
GraphDB, de ceva vreme, permite înserând în SPARQL fragmente în interogarea MongoDB.

Dacă vorbim mai larg despre adaptoare pentru sursele JSON, care permit reprezentarea mai mult sau mai puțin „din mers” a JSON-ului stocat în aceste surse ca RDF, ne putem aminti și de SPARQL Generate, care poate fi instalat, de exemplu, la Apache Jena.

Rezumând primele două tendințe, se poate spune că depozitele RDF demonstrează o disponibilitate totală pentru integrare și pentru funcționarea în condițiile „stocării variate” (polyglot persistence). Totuși, este cunoscut faptul că această ultimă tendință nu mai este la modă, iar în locul ei urmează multimodalitatea. Cum stau lucrurile cu multimodalitatea în lumea depozitelor RDF?

Pe scurt, nu prea bine. Subiectul sistemelor de gestionare a bazelor de date multimodale ar merita un articol separat, deocamdată se poate observa că nu există sisteme de gestionare a bazelor de date multimodale „bazate” pe modelul grafic (o variantă a acestuia poate fi considerată RDF). Se va discuta despre o oarecare mică multimodalitate - suportul de către depozitele RDF al unui model grafic alternativ LPG - în secțiunea V.

III. OLTP vs. OLAP

Totuși, același Gartner scrie, că multimodalitatea este o condiție sine qua non în primul rând pentru baze de date operaționale. Și este de înțeles: în situația „stocării variate”, principalele probleme apar cu tranzacționalitatea.

Dar unde se află depozitele RDF pe scala OLTP—OLAP? Aș răspunde astfel: nici în stânga, nici în dreapta. Pentru a desemna ceea ce sunt destinate, este nevoie de un alt acronim. Ca variantă, aș propune OLIP — Procesare Intelectuală Online.

Cu toate acestea:

mecanismele de integrare implementate în GraphDB nu sunt în ultimul rând destinate oferirii de soluții pentru problemele de performanță a scrierii;
Stardog merge și mai departe și rescrie complet motorul, tot cu scopul de a îmbunătăți performanța scrierii. Acum permiteți-mi să prezint un nou jucător pe piață. de la creatorii IBM Netezza și Amazon Redshift —

AnzoGraph . Imaginea din reclama produsului bazat pe acesta a fost publicată la începutul articolului. AnzoGraph se poziționează ca o soluție GOLAP. Ce ziceți de SPARQL cu funcții fereastră? —SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }

IV. RocksDB

Mai sus a fost

o referință la anunțul Stardog 7 Beta, care menționa că Stardog intenționează să utilizeze ca sistem de stocare de bază RocksDB - un depozit „cheie-valoare”, un fork al Google LevelDB creat de Facebook. De ce merită deja să vorbim despre o oarecare tendință? În primul rând, conform

articolului de pe Wikipedia , pe RocksDB „trec” nu doar depozitele RDF. Există proiecte care folosesc RocksDB ca motor de stocare în ArangoDB, MongoDB, MySQL și MariaDB, Cassandra.În al doilea rând, pe RocksDB sunt realizate proiecte (adică nu produse) de tematica corespunzătoare.

În al doilea rând, pe RocksDB se dezvoltă proiecte (adică nu produse) de tematică corespunzătoare.

De exemplu, eBay folosește RocksDB în platforma pentru „graful său de cunoștințe”. Apropo, este amuzant să citești: limbajul de interogare a început ca un format creat intern, dar mai recent a început să semene mult mai mult cu SPARQL. Ca în gluma aceea: câți grafuri de cunoștințe facem, tot RDF iese.

Un alt exemplu - apărut cu câteva luni în urmă Wikidata History Query Service. Înainte de asta, pentru informații istorice despre Wikidata trebuia să apelăm la MWAPI prin API-ul standard Mediawiki. Acum, multe sunt posibile în SPARQL pur. „Sub capotă” este tot RocksDB. Apropo, WDHQS a fost realizat de cineva care s-a ocupat cu importul Freebase în Google Knowledge Graph.

V. Suport pentru LPG

Amintesc principalul diferent dintre grafurile LPG și cele RDF.

În LPG, instanțele arcelor pot avea proprietăți scalare atașate, în timp ce în RDF acestea pot fi atașate doar la „tipurile” de arce (dar nu doar proprietăți scalare, ci și relații obișnuite). Această limitare a RDF în comparație cu LPG este depășită prin diferite tehnici de modelare. Totuși, limitarea LPG în comparație cu RDF este mai greu de depășit, dar grafurile LPG sunt mai asemănătoare cu imaginile din manualul lui Harari, de aceea oamenii le doresc.

Evident, sarcina „sprijinirii LPG” se împarte în două părți:

introducerea în modelul RDF a modificărilor care permit imitarea structurilor LPG;
introducerea în limbajul de interogare RDF a modificărilor care permit accesul la date în acest model modificat, sau realizarea posibilității de a face interogări în acest model în limbaje populare de interogare la LPG.

V.1. Model de date

Aici există câteva abordări posibile.

V.1.1. Proprietatea Singleton

Cea mai literală abordare de armonizare a RDF și LPG este probabil, proprietatea singleton:

În loc de, de exemplu, predicatul :isMarriedTo se folosesc predicatele :isMarriedTo1, :isMarriedTo2 etc.
Apoi, aceste predicate devin subiecți ai noilor triplete: :isMarriedTo1 :since "2013-09-13"^^xsd:date și altele.
Legătura acestor instanțe de predicate cu predicatul comun este stabilită prin triplete de tipul :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
Este evident că rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, dar gândiți-vă de ce nu ar trebui să scrieți pur și simplu :isMarriedTo1 rdf:type :isMarriedTo.

Sarcina „sprijinirii LPG” este rezolvată aici la nivelul RDFS. Această soluție necesită introducerea în cadrul standard. Este posibil să fie necesare modificări de la depozitele RDF care suportă atașarea efectelor, iar până atunci, Singleton Property poate fi perceput pur și simplu ca o altă tehnică de modelare.

V.1.2. Reificarea corectă

Abordările mai puțin naive derivă din conștientizarea că instanțele proprietăților pot fi cu adevărat instantiate prin triplete. Având capacitatea de a spune ceva despre triplete, vom obține și capacitatea de a vorbi despre instanțele proprietăților.

Cea mai solidă dintre aceste abordări este RDF*, cunoscut și ca RDR, născut în cadrul Blazegraph. Acesta a fost ales de la bun început pentru sine și AnzoGraph. Soliditatea abordării este definită de faptul că în cadrul său oferite modificările corespunzătoare în Semantica RDF. Esența, totuși, este extrem de simplă. În serializarea Turtle a RDF, acum se va putea scrie aproximativ așa:

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

V.1.3. Alte abordări

Poți să nu te complici cu semantica formală și pur și simplu să consideri că tripletele au niște identificatori, care sunt, desigur, URI, și să compui noi triplete cu aceste URI. Rămâne doar să acorzi acces la aceste URI în SPARQL. Așa din surse interne și observatori. O declarație oficială pe această temă nu a fost încă făcută. Stardog.

În Allegrograph au realizat pe un drum intermediar. Este cunoscut că identificatorii tripletelor în Allegrograph are, dar la implementarea atributelor triple în exterior nu sunt expuși. Totuși, este departe de semantica formală. Notabil este că atributelor tripletelor nu sunt URI, iar valorile acestor atribute pot fi și ele doar literaluri. Adepții LPG obțin exact ceea ce au dorit. Într-un format special inventat NQX, un exemplu similar cu cel de mai sus pentru RDF* arată astfel:

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

V.2. Limbaje de interogare

Susținând LPG într-un fel sau altul la nivelul modelului, trebuie să oferim posibilitatea de a interoga datele într-un astfel de model.

Blazegraph pentru interogările RDF* suportă SPARQL* și Gremlin. O interogare SPARQL* arată astfel:

 SELECT * { <> :since ?since }

AnzoGraph de asemenea suportă SPARQL* și intenționează să susțină Cypher, limbajul de interogare în Neo4j.
Stardog suportă propriul său extensie SPARQL și iarăși Gremlin. Obținerea în SPARQL a URI-ului tripletului și a „metainformației” se poate face cu o construcție de genul următor:

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

Allegrograph de asemenea suportă propriul său extensie SPARQL:

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

Apropo, GraphDB a susținut o vreme Tinkerpop/Gremlin, fără a susține LPG, dar în versiunea 8.0 sau 8.1 acest lucru a încetat.

VI. Întărirea licențelor

Nu au avut loc în ultima vreme adăugări în intersecția „triplestore of choice” și „open source triplestore”. Noile depozite RDF cu sursă deschisă sunt departe de a fi o alegere bună pentru utilizarea zilnică, iar codul sursă al noilor depozite RDF pe care ne-am dorit să le folosim (precum AnzoGraph) este închis. Mai degrabă, se poate vorbi chiar despre scăderi...

Desigur, un cod sursă deschis nu devine închis, dar unele depozite cu sursă deschisă încet încetează să fie considerate alegeri demne. Virtuoso, care are o ediție opensource, în opinia mea, se scufundă în buguri. Blazegraph a fost achiziționat de AWS și a stat la baza Amazon Neptune; acum nu este clar dacă va mai exista vreo versiune. Rămâne doar Jena...

Dacă sursa deschisă nu este foarte importantă și vrei doar să încerci, atunci lucrurile sunt la fel de sumbre ca înainte. De exemplu:

Stardog tremează distribuie o versiune gratuită (în orice caz, perioada de probă standard a crescut de două ori);
în GraphDB Cloud, unde înainte se putea alege un plan de bază gratuit, a fost suspendată înregistrarea utilizatorilor noi.

În general, pentru IT-iștii obișnuiți, cosmosul devine tot mai inaccesibil, iar explorarea lui devine apanajul corporațiilor.

Sursa: habr.com