Il Semantic Web e i Linked Data sono simili allo spazio vicino: non ci sono vite. Per andarci per un periodo di tempo più o meno lungo… beh, non so cosa vi dicessero da bambini quando dicevate «voglio diventare un astronauta». Ma si può osservare ciò che accade anche restando sulla Terra; diventare un astronomo dilettante o addirittura professionista è molto più semplice.
L'articolo parlerà delle tendenze recenti, non più vecchie di pochi mesi, dal mondo dei repository RDF. La metafora nel primo paragrafo è stata ispirata da un'immagine pubblicitaria di dimensioni epiche sotto il tag.
Immagine epica
I. GraphQL per l'accesso a RDF
, che GraphQL aspira a diventare il linguaggio universale per accedere ai database. E come stanno le cose riguardo all'accesso tramite GraphQL a RDF?
«Di default» questa possibilità è fornita da:
- Stardog (, );
- prodotti TopQuadrant (, ).
Se il repository non fornisce questa possibilità, la si implementa autonomamente scrivendo un «risolutore» corrispondente. Così hanno fatto, ad esempio, nel progetto francese . Oppure si può già fare senza scrivere nulla, semplicemente usando .
Dal punto di vista di un ortodosso sostenitore del Semantic Web e dei Linked Data, tutto ciò è, naturalmente, triste, poiché sembra destinato a integrazioni costruite attorno a ulteriori silo di dati, piuttosto che adatte a piattaforme (ovviamente, repository RDF).
Le impressioni dal confronto tra GraphQL e SPARQL rimangono ambivalenti.
- Da un lato, GraphQL appare come un lontano parente di SPARQL: affronta i problemi caratteristici del REST di sovraccarico e molteplicità delle query — senza i quali, probabilmente, non si potrebbe nemmeno considerare un linguaggio di query, almeno per il web;
- Dall'altro lato, la rigidità dello schema di GraphQL è deludente. Di conseguenza, la sua «introspezione» sembra molto limitata rispetto alla completa riflessività di RDF. E non c'è alcun equivalente dei property path, quindi non è nemmeno chiaro perché sia denominato «Graph-».
II. Adattatori per MongoDB
Una tendenza complementare alla precedente.
- In Stardog ora — in particolare, sempre su GraphQL — si può configurare la mappatura dei dati MongoDB in grafi RDF virtuali;
- GraphDB recentemente ha iniziato a inserire frammenti di MongoDB Query in SPARQL.
Se parliamo di più in generale, degli adattatori per fonti JSON, che consentono di presentare più o meno «al volo» il JSON memorizzato in queste fonti come RDF, possiamo ricordare anche il già esistente , che si può implementare, , a Apache Jena.
Riassumendo i primi due trend, si può dire che i repository RDF dimostrano una piena prontezza per integrazioni e funzionamento in condizioni di "storage polimorfico" (polyglot persistence). È noto, però, che quest'ultimo non è più di moda e sta per essere sostituito multimodalità. E come stanno le cose con la multimodalità nel mondo dei repository RDF?
In breve, non bene. La questione dei DBMS multimodali meriterebbe un articolo a parte, ma si può notare che attualmente non esistono DBMS multimodali "basati" sul modello a grafo (una sua variante può essere considerata l'RDF). Di una certa piccola multimodalità — il supporto da parte dei repository RDF di un modello a grafo alternativo come l'LPG — si parlerà nel .
III. OLTP vs. OLAP
Tuttavia, lo stesso Gartner , afferma che la multimodalità è una condizione sine qua non principalmente per DBMS operazionali. È comprensibile: nel contesto dello "storage polimorfico", i principali problemi sorgono con la transazionalità.
Ma dove si collocano i repository RDF sulla scala OLTP—OLAP? Risponderei così: né da una parte né dall'altra. Per descrivere a cosa sono destinati, è necessaria un'altra abbreviazione. Come opzione suggerirei OLIP — Online Intellectual Processing.
Tuttavia, ancora:
- i meccanismi di integrazione realizzati in GraphDB sono progettati, non in ultima analisi, Stardog va ancora oltre e riscrive completamente
- il motore, ancora una volta con l'obiettivo di migliorare le prestazioni in scrittura. AnzoGraph
. L'immagine della pubblicità del prodotto basato su di esso è stata pubblicata all'inizio dell'articolo. AnzoGraph si propone come soluzione GOLAP. Cosa ne pensate di SPARQL con funzioni finestra? — IV. RocksDB
In precedenza è stato fattoun riferimento
all'annuncio di Stardog 7 Beta, dove si affermava che Stardog intende utilizzare come sistema di archiviazione sottostante RocksDB — un repository "chiave-valore", fork di LevelDB di Google. Perché si può già parlare di una certa tendenza? un articolo su Wikipedia,
non solo i repository RDF stanno "migrando" a RocksDB. Ci sono progetti per utilizzare RocksDB come motore di archiviazione in ArangoDB, MongoDB, MySQL e MariaDB, Cassandra. In secondo luogo, su RocksDB si stanno sviluppando progetti (cioè non prodotti) di tema corrispondente.
In secondo luogo, su RocksDB si realizzano progetti (cioè non prodotti) di tema specifico.
Ad esempio, eBay utilizza RocksDB nella per il suo "grafo della conoscenza". A proposito, è divertente leggere: il linguaggio di query è iniziato come un formato sviluppato internamente, ma recentemente sta passando a qualcosa di molto simile a SPARQL.. Come nella barzelletta: non importa quanto facciamo un knowledge graph, viene sempre fuori un RDF.
Un altro esempio è quello apparso qualche mese fa . Prima della sua apparizione, per ottenere informazioni storiche da Wikidata si doveva ricorrere a attraverso l'API standard di Mediawiki. Ora è possibile fare molto con puro SPARQL. "Sotto il cofano", c'è anche RocksDB. A proposito, sembra che WDHQS sia stato fatto da una persona che si è occupata dell'importazione di Freebase nel Google Knowledge Graph.
V. Supporto per LPG
Ricordo la principale differenza tra i grafi LPG e i grafi RDF.
Nei grafi LPG, le istanze degli archi possono avere proprietà scalari, mentre nei grafi RDF possono essere associate solo a "tipi" di archi (anche se non solo proprietà scalari, ma anche relazioni ordinarie). Questa limitazione di RDF rispetto a LPG da varie tecniche di modellazione. La limitazione di LPG rispetto a RDF è più difficile da superare, ma i grafi LPG sono più simili alle immagini del manuale di Harari, perciò le persone li desiderano.
È evidente che il compito di "supporto per LPG" si divide in due parti:
- l'inserimento nel modello RDF di modifiche che permettano di simulare le strutture LPG;
- l'introduzione di modifiche nel linguaggio delle query RDF che consentano di interrogare i dati in questo modello modificato, oppure l'implementazione della possibilità di fare query su questo modello in linguaggi di query popolari per LPG.
V.1. Modello dati
Qui ci sono diversi approcci possibili.
V.1.1. Singleton Property
Il modo più letterale di armonizzare RDF e LPG è probabilmente :
- Invece, ad esempio, del predicato
:isMarriedTovengono utilizzati i predicati:isMarriedTo1,:isMarriedTo2ecc. - Poi questi predicati diventano soggetti di nuovi triplet:
:isMarriedTo1 :since "2013-09-13"^^xsd:datee simili. - Il collegamento di queste istanze di predicati con il predicato comune è stabilito da triplet di tipo
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - È ovvio che
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ma pensate a perché non sarebbe opportuno scrivere semplicemente:isMarriedTo1 rdf:type :isMarriedTo..
Il compito di "supporto per LPG" viene affrontato qui a livello di RDFS. Questa soluzione richiede modifiche nel . Potrebbero essere necessari alcuni cambiamenti ai repository RDF che supportano l'adesione delle conseguenze, mentre la Singleton Property può essere considerata semplicemente come un'altra tecnica di modellazione.
V.1.2. Reificazione Fatta Bene
Approcci meno ingenui derivano dalla consapevolezza che le istanze delle proprietà possono essere istanziate da triplette. Avendo la possibilità di dire qualcosa sulle triple, possiamo anche parlare delle istanze delle proprietà.
Il più solido di questi approcci è , noto anche come RDR, dalle profondità di Blazegraph. Fin dall'inizio da AnzoGraph. La solidità dell'approccio è determinata dal fatto che al suo interno ci sono cambiamenti corrispondenti in La sostanza, però, è estremamente semplice. Nella serializzazione Turtle di RDF, ora si può scrivere in questo modo:
<> :since "2013-09-13"^^xsd:date .V.1.3. Altri Approcci
Non è necessario preoccuparsi della semantica formale, si può semplicemente considerare che le triple hanno alcuni identificatori, che sono ovviamente URI, e comporre nuove triple con questi URI. Resta solo da fornire accesso a questi URI in SPARQL. Così Stardog.
In Allegrograph un percorso intermedio. È noto che gli identificatori delle triple in Allegrograph , ma quando si implementano gli attributi delle triple, non emergono. Tuttavia, siamo ancora molto lontani dalla semantica formale. È interessante notare che gli attributi delle triple non sono URI, e i valori di questi attributi possono essere solo letterali. I sostenitori di LPG ottengono esattamente ciò che desideravano. In un formato NQX appositamente inventato, un esempio analogo a quello sopra per RDF* appare così:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Linguaggi di Richiesta
Dopo aver supportato LPG in un modo o nell'altro a livello di modello, è necessario consentire di effettuare richieste ai dati in tale modello.
- Blazegraph per le richieste a RDF* supporta e Una richiesta in SPARQL* appare così:
SELECT * { <> :since ?since }- AnzoGraph supporta anche e intende supportare , il linguaggio di richiesta in Neo4j.
- Stardog supporta il proprio SPARQL e Gremlin. Per ottenere in SPARQL l'URI della tripletta e la "meta-informazione" è possibile utilizzare una costruzione simile a questa:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Anche Allegrograph supporta il proprio SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }A proposito, GraphDB per un periodo ha supportato Tinkerpop/Gremlin, senza supportare LPG, ma nella versione 8.0 o 8.1 è stato interrotto.
VI. Inasprimento delle licenze
Non ci sono stati recenti aumenti nell'intersezione dei set di dati «triplestore of choice» e «open source triplestore». I nuovi RDF store open source sono ancora lontani dall'essere una buona scelta per l'uso quotidiano, e il codice sorgente dei nuovi RDF store che vorremmo utilizzare (come AnzoGraph) è chiuso. Si può addirittura parlare di riduzioni…
Certo, il codice sorgente aperto non si chiude improvvisamente, ma alcuni repository open source stanno gradualmente smettendo di essere considerati scelte valide. Virtuoso, che ha una versione opensource, a mio avviso, è in difficoltà a causa dei bug. Blazegraph è stato acquistato da AWS ed è alla base di Amazon Neptune; ora non è chiaro se ci sarà un altro rilascio. Rimane solo Jena…
Se il codice sorgente aperto non è così importante e si desidera semplicemente provare, la situazione è meno rosea rispetto a prima. Ad esempio:
- Stardog distribuire la versione gratuita (tuttavia, il periodo di prova standard è raddoppiato);
- in , dove prima era possibile scegliere un piano base gratuito, ha sospeso la registrazione di nuovi utenti.
In generale, per l'utente IT medio, lo spazio diventa sempre più inaccessibile, e la sua esplorazione è riservata alle aziende.
Fonte: habr.com
