Semantic Web e Linked Data sono come lo spazio cosmico: lì non c'è vita. Per andarci per un periodo più o meno lungo… non so cosa ti dicevano da bambino in risposta a “Voglio diventare un astronauta”. Ma puoi guardare cosa sta succedendo mentre sei sulla Terra; diventare un astronomo dilettante o anche un professionista è molto più facile.
L'articolo si concentrerà sulle tendenze fresche, non più vecchie di qualche mese, dal mondo dello stoccaggio RDF. La metafora del primo paragrafo è ispirata da un'epica immagine promozionale sotto il taglio.
quadro epico
I. GraphQL per l'accesso RDF
che GraphQL afferma di essere il linguaggio universale di accesso al database. E per quanto riguarda la possibilità di accedere tramite GraphQL a RDF?
Fuori dagli schemi, questa opportunità è fornita da:
- cane stellare(, );
- Prodotti TopQuadrant (, ).
Se il repository non offre tale opportunità, viene implementato in modo indipendente scrivendo l'appropriato "risolutore" (risolutore). Ciò è stato fatto, ad esempio, nel progetto francese . Oppure non puoi già scrivere nulla, ma prendi .
Dal punto di vista di un seguace ortodosso del Semantic Web e dei Linked Data, tutto ciò è, ovviamente, triste, poiché sembra destinato a integrazioni costruite attorno al prossimo silo di dati e piattaforme non adatte (ovviamente, negozi RDF) .
Le impressioni derivanti dal confronto tra GraphQL e SPARQL sono duplici.
- Da un lato, GraphQL sembra un lontano parente di SPARQL: risolve i problemi di riselezione e query multiple tipiche di REST - senza i quali, probabilmente, non sarebbe possibile considerare linguaggio di interrogazione, almeno per il web;
- D'altra parte, lo schema rigido di GraphQL sconvolge. Di conseguenza, la sua "introspettività" sembra essere molto limitata rispetto alla piena riflessività di RDF. E non esiste un analogo dei percorsi di proprietà, quindi non è nemmeno molto chiaro il motivo per cui è "Graph-".
II. Adattatori per MongoDB
Un trend complementare al precedente.
- A Stardog ora - in particolare, tutto sullo stesso GraphQL - configurare la visualizzazione dei dati MongoDB in grafici RDF virtuali;
- Ontotext GraphDB di recente inserire nei frammenti SPARQL su MongoDB Query.
Parlando più in generale, di adattatori a sorgenti JSON che permettono più o meno "al volo" di rappresentare come RDF il JSON memorizzato in queste sorgenti, allora possiamo anche richiamare quello esistente da parecchio tempo che può essere regolato , ad Apache Jena.
Riassumendo le prime due tendenze, possiamo affermare che i repository RDF dimostrano piena disponibilità all'integrazione e al funzionamento in condizioni di “storage multiplo” (persistenza poliglotta). È noto, tuttavia, che quest'ultimo è passato di moda da tempo e per sostituirlo multimodellazione. E per quanto riguarda il multi-modeling nel mondo dell'archiviazione RDF?
Insomma, assolutamente no. Vorrei dedicare un articolo a parte all'argomento del DBMS multi-modello, ma per ora puoi vedere che non ci sono DBMS multi-modello "basati" sul modello a grafo (RDF può essere considerato una sua variazione) ora. Informazioni su alcuni piccoli modelli multipli - il supporto da parte degli archivi RDF di un modello grafico GPL alternativo - saranno discussi in .
III. OLTP vs. OLAP
Tuttavia, lo stesso Gartner che la modellazione multipla è una condizione sine qua non principalmente per sale operatorie DBMS. Questo è comprensibile: in una situazione di "archiviazione multipla", i problemi principali sorgono con la transazionalità.
Ma dove sulla scala OLTP-OLAP sono i repository RDF? Risponderei così: né lì né qui. Per indicare a cosa sono destinati, è necessaria una terza abbreviazione. Come opzione suggerirei OLIP — Elaborazione intellettuale online.
Tuttavia, ancora:
- i meccanismi di integrazione implementati in GraphDB con MongoDB non sono da meno per aggirare i problemi di prestazioni in scrittura;
- Stardog va ancora oltre e completamente engine, sempre con l'obiettivo di migliorare le prestazioni di scrittura.
E ora lascia che ti presenti un nuovo giocatore nel mercato. Dai creatori di IBM Netezza e Amazon Redshift - . All'inizio dell'articolo è stata inserita un'immagine di una pubblicità per un prodotto basato su di esso. AnzoGraph si posiziona come soluzione GOLAP. Ti piace SPARQL con le funzioni della finestra? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Già sopra all'annuncio di Stardog 7 Beta, che affermava che Stardog avrebbe utilizzato RocksDB come sistema di archiviazione sottostante: archiviazione di valori-chiave, fork di Facebook di LevelDB di Google. Perché vale la pena parlare di una certa tendenza?
Innanzitutto, a giudicare da , non solo i repository RDF vengono "trapiantati" in RocksDB. Esistono progetti per utilizzare RocksDB come motore di archiviazione in ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.
In secondo luogo, su RocksDB vengono realizzati progetti (ovvero non prodotti) dell'argomento corrispondente.
Ad esempio, eBay utilizza RocksDB in per il tuo "grafico della conoscenza". A proposito, è divertente leggere: il linguaggio di query è iniziato come un formato sviluppato internamente, ma più recentemente è diventato molto più simile a SPARQL. Come in uno scherzo: non importa quanto grafico della conoscenza facciamo, otteniamo comunque RDF.
Un altro esempio - è apparso pochi mesi fa . Prima della sua introduzione, era necessario accedere alle informazioni storiche di Wikidata tramite all'API Mediawiki standard. Molto è ora possibile in puro SPARQL. "Sotto il cofano" c'è anche RocksDB. A proposito, WDHQS l'ha fatto, sembra la persona coinvolta nell'importazione di Freebase nel Google Knowledge Graph.
V. Supporto GPL
Permettetemi di ricordarvi la differenza principale tra grafici GPL e grafici RDF.
In LPG, le proprietà scalari possono essere associate a istanze edge, mentre in RDF possono essere associate solo a "tipi" edge (ma non solo proprietà scalari, ma anche collegamenti ordinari). Questa limitazione del CDR rispetto al GPL una sorta di tecnica di modellazione. I limiti del GPL rispetto all'RDF sono più difficili da superare, ma i grafici GPL sono più simili alle immagini del libro di testo di Harari che ai grafici RDF, quindi la gente li vuole.
Ovviamente, il compito di "sostenere GPL" si divide in due parti:
- apportare modifiche al modello RDF che consentono di simulare i costrutti LPG in esso;
- apportando modifiche al linguaggio di query RDF che rendono possibile l'accesso ai dati in questo modello modificato, o l'implementazione della capacità di interrogare questo modello nei popolari linguaggi di query LPG.
v.1. Modello di dati
Ci sono diversi possibili approcci qui.
V.1.1. proprietà singleton
L'approccio più letterale all'armonizzazione di RDF e GPL è probabilmente :
- Invece, ad esempio, del predicato
:isMarriedTosi usano i predicati:isMarriedTo1,:isMarriedTo2eccetera - Questi predicati diventano quindi soggetti di nuove terzine:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateeccetera - La connessione di queste istanze di predicati con un predicato comune è stabilita da terzine della forma
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Ovviamente, l'
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ma considera perché non dovresti limitarti a scrivere:isMarriedTo1 rdf:type :isMarriedTo.
Il compito di "supporto GPL" è risolto qui a livello RDFS. Tale decisione richiede l'inclusione nel pertinente . Potrebbero essere necessarie alcune modifiche ai repository RDF che supportano l'associazione delle conseguenze, ma per ora, Singleton Property può essere considerata solo un'altra tecnica di modellazione.
V.1.2. Reificazione fatta bene
Approcci meno ingenui derivano dalla consapevolezza che le istanze di proprietà sono perfettamente istanziate da terzine. Potendo parlare di terzine, possiamo anche parlare di istanze di proprietà.
Il più solido di questi approcci è alias RDR, nelle viscere di Blazegraph. È dall'inizio per me e AnzoGraph. La solidità dell'approccio è determinata dal fatto che all'interno del suo quadro corrispondenti variazioni di . Il punto, tuttavia, è estremamente semplice. Nella serializzazione RDF Turtle, ora puoi scrivere qualcosa del genere:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Altri approcci
Non puoi preoccuparti della semantica formale, ma considera semplicemente che le terzine hanno alcuni identificatori, che, ovviamente, sono URI, e compongono nuove terzine con questi URI. Non resta che dare accesso a questi URI in SPARQL. COSÌ stardog.
In Allegrografo in via intermedia. È noto che gli identificatori di terzine in Allegrograph , ma quando vengono implementati attributi tripli, non sporgono. Tuttavia, anche la semantica formale è molto lontana. In particolare, gli attributi triplet non sono URI e anche i valori di questi attributi possono essere solo letterali. Gli aderenti al GPL ottengono esattamente ciò che volevano. Nel formato NQX appositamente inventato, un esempio simile a quello sopra per RDF* si presenta così:
:bob :marriedTo :alice {"since" : "2013-09-13"}v.2. Lingue di interrogazione
Avendo supportato LPG in un modo o nell'altro a livello di modello, è necessario rendere possibile l'interrogazione dei dati in tale modello.
- Blazegraph per le query RDF* supporta и . Una query SPARQL* ha il seguente aspetto:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph supporta anche e sta andando a sostenere , il linguaggio di query in Neo4j.
- Stardog mantiene il suo SPARQL e Gremlin. Puoi ottenere l'URI di una tripletta e "meta-informazioni" in SPARQL usando qualcosa del genere:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph supporta anche il proprio SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Per inciso, GraphDB ha supportato Tinkerpop/Gremlin una volta senza supportare LPG, ma si è fermato nella versione 8.0 o 8.1.
VI. Licenze stringenti
Non ci sono state aggiunte recenti all'intersezione dei set "triplestore of choice" e "triplestore open source". I nuovi negozi RDF open source sono ben lungi dall'essere una buona scelta per l'uso quotidiano e il codice sorgente per i nuovi negozi tripli che vorrei utilizzare (ad esempio, AnzoGraph) è chiuso. Piuttosto, possiamo parlare di riduzioni ...
Naturalmente, in precedenza l'open source non è chiuso, ma alcuni repository open source gradualmente non sono più considerati degni di scelta. Virtuoso, che ha un'edizione open source, secondo me, sta annegando nei bug. Blazegraph acquistato da AWS e ha costituito la base di Amazon Neptune; ora non è chiaro se ci sarà almeno un'altra release. Resta solo Jenna...
Se l'open source non è molto importante, ma vuoi solo provare, allora tutto è anche meno roseo di prima. Per esempio:
- Stardog distribuire la versione gratuita (ma il periodo di prova di quella normale è raddoppiato);
- в , dove in precedenza si poteva scegliere il piano base gratuito, la registrazione di nuovi utenti è sospesa.
In generale, lo spazio sta diventando sempre più inaccessibile per un normale laico IT, il suo sviluppo sta diventando il destino delle aziende.
Fonte: habr.com