Cosa sta succedendo ora con i repository RDF?

Il Semantic Web e i Linked Data sono simili allo spazio vicino: non c'è vita lì. Per intraprendere un viaggio di durata decente… beh, non so cosa ti abbiano detto da bambino in risposta a "voglio diventare un astronauta". Ma è possibile osservare ciò che accade anche rimanendo sulla Terra; diventare un astronomo amatoriale o persino professionale è molto più facile.

L'articolo parlerà delle tendenze fresche, recenti e non più vecchie di pochi mesi, nel mondo degli archivi 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

Si dice, che GraphQL aspira a diventare un linguaggio universale per l'accesso ai database. Ma qual è la situazione riguardo alla possibilità di accesso a RDF utilizzando GraphQL?

Questa possibilità è fornita "out of the box":

• Stardog (blog, documentazione);
• prodotti TopQuadrant (un webinar, documentazione).

Se un archivio non offre tale possibilità, è possibile implementarla autonomamente, scrivendo un "risolutore" (resolver) corrispondente. È quanto hanno fatto, ad esempio, nel progetto francese DataTourisme. Oggi è possibile non scrivere nulla e semplicemente utilizzare HyperGraphQL.

. Dal punto di vista di un ortodosso sostenitore del Semantic Web e dei Linked Data, tutto ciò è chiaramente triste, poiché sembra destinato a integrazioni costruite attorno a ulteriori data silo, piuttosto che a piattaforme (naturalmente, archivi RDF) adeguate.

Le impressioni sul confronto tra GraphQL e SPARQL rimangono contrastanti.

• Da un lato, GraphQL appare un parente lontano di SPARQL: affronta i problemi tipici del REST, come la sotto-selezione e la molteplicità delle richieste — senza i quali, probabilmente, non si potrebbe nemmeno considerare un linguaggio di query, anche solo per il web;
• D'altra parte, la rigidità dello schema di GraphQL è deludente. Pertanto, la sua "introspezione" sembra molto limitata rispetto alla piena riflessività di RDF. Inoltre, non esiste alcun analogo dei property paths, quindi non è nemmeno chiaro perché si chiami "Graph-".

II. Adattatori per MongoDB

Una tendenza complementare alla precedente.

• In Stardog ora è possibile — in particolare, tutto su GraphQL — è possibile configurare la visualizzazione dei dati MongoDB in grafi RDF virtuali;
• GraphDB di recente permette consente di inserire frammenti di query MongoDB in SPARQL.

Parlando in termini più ampi, riguardo agli adattatori alle fonti JSON, che permettono di rappresentare più o meno "al volo" il JSON contenuto in queste fonti come RDF, si può ricordare anche il già esistente SPARQL Generate, che può essere adattato ad esempio, ad Apache Jena.

Riassumendo le prime due tendenze, si può dire che gli archivi RDF dimostrano piena disponibilità per integrazioni e funzionamento in condizioni di "storage polivalente" (polyglot persistence). È noto, tuttavia, che quest'ultimo non è più di moda, e al suo posto sta arrivando la multimodalità. Ma qual è la situazione con la multimodalità nel mondo degli archivi RDF?

In breve, non c'è nulla. Meriterebbe un articolo a parte dedicato ai DBMS multimodali, ma per ora si può notare che al momento non esistono DBMS multimodali "basati" sul modello a grafo (una varietà di esso può essere considerato RDF). Si parlerà di una certa piccola multimodalità — supporto per i modelli grafici alternativi LPG da parte degli archivi RDF — nella sezione V.

III. OLTP vs. OLAP

Tuttavia, lo stesso Gartner scrive, afferma che la multimodalità è una condizione sine qua non prima di tutto per DBMS operativi. E questo è comprensibile: nella situazione dello "storage polivalente" sorgono le principali problematiche legate alla transazionalità.

Ma dove si collocano gli archivi RDF sulla scala OLTP-OLAP? Risponderei così: né qui, né lì. Per identificare ciò per cui sono destinati, serve un'altra abbreviazione. Come opzione, proporrei OLIP — Online Intellectual Processing.

Tuttavia,

• meccanismi di integrazione realizzati in GraphDB con MongoDB sono progettati non in ultimo per superare i problemi di prestazioni di scrittura; Stardog va ancora oltre e riscrive completamente
• il motore, ancora una volta con l'obiettivo di aumentare le prestazioni di scrittura. E ora permettetemi di presentarvi un nuovo attore sul mercato. Dalla creatrice di IBM Netezza e Amazon Redshift — motore, ancora una volta con l'obiettivo di migliorare le prestazioni di scrittura.

E ora permettetemi di presentarvi un nuovo attore sul mercato, dai creatori di IBM Netezza e Amazon Redshift — AnzoGraph. L'immagine nella pubblicità del prodotto basata su di esso è stata pubblicata all'inizio dell'articolo. AnzoGraph si posiziona come una soluzione GOLAP. Che ne pensate di SPARQL con funzioni di finestra? —

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

IV. RocksDB

Già in precedenza è stato fatto riferimento all'annuncio di Stardog 7 Beta, dove si affermava che Stardog intende utilizzare come sistema di archiviazione sottostante RocksDB — un archivio "chiave-valore", il fork di Facebook di LevelDB di Google. Perché già ora si deve parlare di una certa tendenza?

In primo luogo, a giudicare da un articolo su Wikipedia, gli archivi RDF non sono gli unici a "trasferirsi" su RocksDB. Ci sono progetti che utilizzano RocksDB come motore di archiviazione in ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.

In secondo luogo, su RocksDB stanno nascendo progetti (cioè non prodotti) di corrispondente tematica.

Ad esempio, eBay utilizza RocksDB nella piattaforma per il suo «grafo della conoscenza». A proposito, è divertente leggere: il linguaggio di query è iniziato come un formato sviluppato internamente, ma più recentemente è stato in fase di transizione per assomigliare molto di più a SPARQL. Come in una barzelletta: per quanto facciamo un knowledge graph, alla fine risulta sempre un RDF.

Un altro esempio è il recente Wikidata History Query Service. Prima della sua introduzione, per ottenere informazioni storiche da Wikidata era necessario ricorrere a MWAPI attraverso il standard Mediawiki API. Ora molto è possibile con puro SPARQL. «Sotto il cofano» c'è di nuovo RocksDB. A proposito, sembra che WDHQS sia stato creato da qualcuno che si è occupato dell'importazione di Freebase nel Google Knowledge Graph.

V. Supporto LPG

Ricordo la principale differenza tra i grafi LPG e i grafi RDF.

Negli LPG, le istanze degli archi possono avere proprietà scalari, mentre negli RDF possono essere assegnate solo ai «tipi» degli archi (ma non solo proprietà scalari, ma anche relazioni comuni). Questo limite degli RDF rispetto agli LPG è superato con varie tecniche di modellazione. Tuttavia, la limitazione degli LPG rispetto agli RDF è più complessa da superare, ma i grafi LPG somigliano di più a immagini del manuale di Harari, quindi le persone li preferiscono.

Evidentemente, il compito di «supportare LPG» si suddivide in due parti:

1. l'inserimento nella model RDF di modifiche che permettano di imitare le strutture LPG;
2. e modifiche al linguaggio di query RDF che consentano l'accesso ai dati in questo modello modificato, o la realizzazione della possibilità di fare query in linguaggi di query popolari per LPG.

V.1. Modello di dati

Ci sono diversi approcci possibili.

V.1.1. Singleton Property

L'approccio più letterale per armonizzare RDF e LPG è probabilmente singleton property:

• Invece, ad esempio, del predicato :isMarriedTo si usano i predicati :isMarriedTo1, :isMarriedTo2 ecc.
• Poi questi predicati diventano soggetti di nuovi triplet: :isMarriedTo1 :since "2013-09-13"^^xsd:date e così via.
• La connessione di questi istanti predicati con il predicato comune viene stabilita tramite triplet di tipo :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
• È ovvio che rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ma pensate a perché non dovremmo semplicemente scrivere :isMarriedTo1 rdf:type :isMarriedTo.

Il compito di «supportare LPG» qui viene risolto a livello di RDFS. Questa soluzione richiede modifiche ai corrispondenti standard. Potrebbero essere necessarie alcune modifiche dai repository RDF che supportano l'assemblaggio delle conseguenze, ma al momento Singleton Property può essere visto semplicemente come un'altra tecnica di modellazione.

V.1.2. Reification Done Right

Approcci meno naif derivano dalla consapevolezza che le istanze delle proprietà possono essere instantiate da triplet. Avere la possibilità di dire qualcosa sui triplet ci permette di dire qualcosa anche sulle istanze delle proprietà.

Il più solido di questi approcci è RDF*, anche noto come RDR, nato nel contesto di Blazegraph. Sin dall'inizio è stato scelto da AnzoGraph. La solidità dell'approccio è definita dal fatto che nel suo ambito sono offerti le modifiche corrispondenti a RDF Semantics. Tuttavia, la sostanza è estremamente semplice. Nella serializzazione Turtle di RDF, ora è possibile scrivere all'incirca così:

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

V.1.3. Altri approcci

Non è necessario preoccuparsi della semantica formale, ma si può semplicemente pensare che i triplet abbiano alcuni identificatori, che sono naturalmente URI, e comporre nuovi triplet con queste URI. Rimane solo da dare accesso a queste URI in SPARQL. Così da fonti interne e osservatori. Non ci sono dichiarazioni ufficiali al riguardo al momento. Stardog.

In Allegrograph hanno adottato una via intermedia. È noto che gli identificatori dei triplet in Allegrograph ci siano, ma nella realizzazione degli attributi triplet non sono esposti. Tuttavia, non si tratta nemmeno di semantica formale. È interessante notare che gli attributi dei triplet non sono URI, e anche i valori di tali attributi possono essere solo letterali. Gli aderenti a LPG ottengono esattamente ciò che desiderano. In un formato appositamente inventato NQX, un esempio che assomiglia a quello sopra per RDF* appare così:

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

V.2. Linguaggi di query

Avendo supportato LPG in qualche modo a livello di modello, bisogna dare la possibilità di fare query ai dati in tale modello.

• Blazegraph, per le query su RDF*, supporta SPARQL* e Gremlin. Una query su SPARQL* appare così:

 SELECT * { <> :since ?since }

• Anzograph supporta anche SPARQL* e prevede di supportare Cypher, il linguaggio di query di Neo4j.
• Stardog supporta il proprio estensione SPARQL e di nuovo Gremlin. È possibile ottenere in SPARQL l'URI di un triplet e le «meta-informazioni» con un costrutto simile a questo:

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

• Anche Allegrograph supporta il proprio estensione SPARQL:

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

A proposito, GraphDB ha supportato per un certo tempo Tinkerpop/Gremlin, senza però supportare LPG, ma nella versione 8.0 o 8.1 questo è stato interrotto.

VI. Inasprimento delle licenze

Non ci sono stati recenti sviluppi tra le intersezioni di "triplestore of choice" e "open source triplestore". I nuovi repository RDF open source non sono ancora considerati una buona opzione per l'uso quotidiano, e il codice sorgente dei nuovi repository RDF che si vorrebbero esplorare (come AnzoGraph) è chiuso. Più che altro, si può parlare di diminuzioni...

Naturalmente, un codice sorgente aperto non viene mai chiuso, ma alcuni repository open source stanno gradualmente smettendo di essere considerati scelte valide. Virtuoso, che ha una versione open source, a mio avviso, è pieno di 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 invece il codice sorgente open non è molto importante e si vuol solo provare, la situazione non è affatto rosea come prima. Ad esempio:

• Stardog sospende distribuirà una versione gratuita (in realtà, il periodo di prova standard è raddoppiato);
• in GraphDB Cloud, dove in precedenza era possibile scegliere un piano base gratuito, la registrazione di nuovi utenti è stata sospesa.

In generale, per l'IT medio, lo spazio diventa sempre più inaccessibile, la sua esplorazione è riservata alle corporazioni.

Fonte: habr.com