Semantični splet in povezani podatki sta podobna bližnjemu vesolju: tam ni življenja. Da bi se odpravili tja za daljše obdobje… no, ne vem, kaj so vam rekli v otroštvu v odgovoru na vprašanje "želimo postati astronavt". A opazovati dogajanje je mogoče tudi od tod; postati ljubiteljski astronom ali celo profesionalec je veliko lažje.
V članku bo govora o svežih, ne starejših od nekaj mesecev, trendih iz sveta RDF-shranjevanja. Metafora v prvem odstavku je bila navdihnjena z epsko velikansko oglasno sliko pod točko.
Epska slika
I. GraphQL za dostop do RDF
, da želi GraphQL postati univerzalni jezik dostopa do podatkovnih baz. Kako pa je s sposobnostjo dostopa z uporabo GraphQL do RDF?
"Iz škatle" to možnost zagotavljajo:
- Stardog (, );
- izdelek TopQuadrant (, ).
Če pa shramba ne ponuja te možnosti, jo lahko implementirajo sami s pisanjem ustreznega "odločitelja" (resolverja). Tako so ravnali, na primer, v francoskem projektu . Ali pa je mogoče nič ne pisati, temveč preprosto vzeti .
Z vidika ortodoksnega privrženca semantičnega spleta in povezanih podatkov je to seveda žalostno, saj se zdi, da je namenjeno integracijam, ki temeljijo na teh podatkovnih silo, namesto da bi bilo primerno za platforme (seveda, RDF-shranjevanja).
Impresije iz primerjave GraphQL s SPARQL ostajajo mešane.
- Po eni strani se GraphQL zdi daljni sorodnik SPARQL: reši težave, značilne za REST, kot so ponovna izbira in množičnost poizvedb — brez česar verjetno ne bi mogli biti jezik poizvedb, čeprav bi bil le za splet;
- Po drugi strani pa žalosti strogost sheme GraphQL. Posledično se zdi njegova "introspekcija" zelo omejena v primerjavi s popolno refleksivnostjo RDF. In ni nobenega analoga lastnostnih poti, tako da niti ni povsem jasno, zakaj se imenuje "Graph-".
II. Adapterji za MongoDB
Trend, ki dopolnjuje prejšnjega.
- v Stardog zdaj — zlasti vse na istem GraphQL — nastaviti prikazovanje podatkov MongoDB v virtualne RDF-grafi;
- GraphDB je nedavno dovolil vstavljanje fragmentov MongoDB poizvedb v SPARQL.
Če govorimo širše, o adapterjih za JSON-vir, ki omogočajo bolj ali manj "v živo" prikazovanje shranjenega JSON v teh virih kot RDF, se lahko spomnimo tudi na že dolgo obstoječ , which can be adapted, , to Apache Jena.
To summarize the first two trends, it can be said that RDF repositories demonstrate complete readiness for integrations and functioning in conditions of "polyglot persistence." However, it is known that this last concept has long been out of fashion, and it is being replaced by In short, not at all. The topic of multimodel DBMS deserves a separate article, but for now, it can be noted that there are currently no multimodel DBMS "based" on the graph model (one variety of which can be considered RDF). Some minor multimodelity — support for alternative graph models by RDF repositories — will be discussed in
section V .
However, Gartner itself
states operational DBMS. This is understandable: in a "polyglot persistence" situation, the main problems arise with transactionality. But where do RDF repositories fall on the OLTP—OLAP scale? I would answer: neither here nor there. To denote what they are intended for, some kind of third abbreviation is needed. As an option, I would suggest
OLIP — Online Intellectual Processing. However, nonetheless:
the integration mechanisms implemented in GraphDB are not least
- intended Stardog goes even further and completely
- rewrites And now allow me to introduce a new player in the market, from the creators of IBM Netezza and Amazon Redshift —
AnzoGraph SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocksDBAbove, there was already
a reference Firstly, judging from
the article on Wikipedia , na RocksDB "presadijo" ne samo RDF-shranilniki. Obstajajo projekti za uporabo RocksDB kot shrambe v ArangoDB, MongoDB, MySQL in MariaDB, Cassandra.
Po drugi strani se na RocksDB izvajajo projekti (tj. ne proizvodi) ustrezne tematike.
Na primer, eBay uporablja RocksDB v za svoj 'graf znanja'. Mimogrede, zabavno je brati: jezik poizvedovanja se je začel kot domači format, vendar se je v zadnjem času preusmeril, da bi bil bolj podoben SPARQL. Kot v anekdotah: kolikorkoli knowledge graph delali, vedno znova nastane RDF.
Drug primer je nedavno nastali . Pred njegovim nastankom je bilo treba za zgodovinske podatke iz Wikidata posegati preko do standardnega Mediawiki API. Zdaj je veliko mogoče na čistem SPARQL. Mimogrede, WDHQS je naredil nekdo, ki se je ukvarjal s prenosom Freebase v Google Knowledge Graph.
V. Podpora LPG
Ponovim osnovno razliko med LPG-grafi in RDF-grafi.
Pri LPG lahko na primere robov pripnemo skalarne lastnosti, medtem ko jih v RDF lahko pripnemo le na 'tipa' robov (pa tudi ne le skalarne lastnosti, temveč tudi običajne povezave). Ta omejitev RDF v primerjavi z LPG s temi ali drugimi tehnikami modeliranja. Omejitev LPG v primerjavi z RDF pa je težje premagati, vendar so LPG-grafi bolj podobni slikam iz učbenika Hararija, zato jih ljudje želijo.
Očitno se naloga 'podpore LPG' razdeli na dva dela:
- vnos sprememb v model RDF, ki omogočajo simuliacijo LPG-konstrukcij;
- vnos sprememb v jezik poizvedovanja za RDF, ki omogoča dostop do podatkov v tem spremenjenem modelu — ali pa realizacija možnostih poizvedovanja v tem modelu v priljubljenih jezikih poizvedovanja za LPG.
V.1. Model podatkov
Tu je več možnih pristopov.
V.1.1. Singleton Property
Najbolj dobeseden pristop k usklajevanju RDF in LPG je verjetno :
- Namesto, na primer, predikata
:isMarriedTose uporabljajo predikati:isMarriedTo1,:isMarriedTo2itd. - Nato ti predikati postanejo subjekti novih tripletov:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateitd. - Povezava teh primerov predikatov s skupnim predikatom se vzpostavi s tripleti tipa
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Očitno je, da
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, toda pomislite, zakaj ni smiselno preprosto zapisati:isMarriedTo1 rdf:type :isMarriedTo.
Naloga 'podpore LPG' se tukaj rešuje na ravni RDFS. Takšno rešitev je treba uvesti v ustrezni . Nekatere spremembe so lahko potrebne od RDF-repozitorijev, ki podpirajo dodajanje posledic, zaenkrat pa lahko Singleton Property obravnavamo preprosto kot še eno tehniko modeliranja.
V.1.2. Pravilna reifikacija
Manj naivni pristopi izhajajo iz zavedanja, da se primeri lastnosti povsem instancirajo s trojkami. Če bomo imeli možnost govoriti o trojkah, bomo lahko govorili tudi o primerih lastnosti.
Najbolj trden od teh pristopov je , znan tudi kot RDR, v okviru Blazegraph. Od samega začetka za AnzoGraph. Trdnost pristopa se določa s tem, da se v njegovem okviru ustrezne spremembe v . Vendar je bistvo izjemno preprosto. V Turtle-serializaciji RDF lahko zdaj pišemo približno takole:
<> :since "2013-09-13"^^xsd:date .V.1.3. Drugi pristopi
Lahko se ne obremenjujemo s formalno semantiko, ampak preprosto smatrajmo, da imajo trojke nekakšne identifikatorje, ki so seveda URI, in sestavimo nove trojke s temi URI. Ostati mora le še omogočiti dostop do teh URI v SPARQL. Tako Stardog.
V Allegrograph za vmesno pot. Znano je, da identifikatorji trojk v Allegrograph , vendar pri implementaciji triple attributes navzven niso vidni. Vendar je do formalne semantike še daleč. Zanimivo je, da atributi trojk niso URI, in vrednosti teh atributov so lahko tudi samo literali. Pristopi LPG dobijo točno tisto, kar so želeli. V posebej izumljenem formatu NQX, primer, podoben zgoraj za RDF*, pa izgleda tako:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Jeziki poizvedb
Po tem, ko je na ravni modela podpreti LPG, je potrebno omogočiti poizvedovanja nad podatki v takem modelu.
- Blazegraph za poizvedbe o RDF* podpira in Poizvedba SPARQL* izgleda tako:
SELECT * { <> :since ?since }- AnzoGraph prav tako podpira in se namerava podpirati , jezik poizvedb v Neo4j.
- Stardog podpira svoje SPARQL in Gremlin. V SPARQL je mogoče pridobiti URI trojke in 'meta informacije' s pomočjo približno takšne konstrukcije:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph prav tako podpira svoje SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Mimogrede, GraphDB je neko vreme podržavao Tinkerpop/Gremlin, dok nije podržavao LPG, ali je to prekinuto u verziji 8.0 ili 8.1.
VI. Oštrenje licenci
Poslednjih godina nije bilo novih preklapanja između 'triplestore of choice' i 'open source triplestore'. Nova RDF skladišta s otvorenim izvorom su daleko od toga da budu dobar izbor za svakodnevnu upotrebu, a izvorni kod novih RDF skladišta koje bismo želeli da koristimo (kao AnzoGraph) je zatvoren. Možda se može govoriti čak i o smanjenju...
Naravno, otvoreni izvor se ne zatvara, ali neka skladišta s otvorenim izvorom postepeno prestaju da budu smatrana dostojnim izborom. Virtuoso, koji ima opensource verziju, po mom mišljenju, tonulira u greškama. Blazegraph je kupljen od strane AWS i postao je osnova za Amazon Neptune; sada nije jasno da li će biti još jedne verzije. Ostaje samo Jena...
Ako otvoreni izvor nije od velikog značaja, a samo želite da probate, situacija je takođe manje bezbrižna nego ranije. Na primer:
- Stardog distribuciju besplatne verzije (inače, probni period se udvostručio);
- u , gde je ranije bilo moguće izabrati besplatni osnovni plan, obustavljena je registracija novih korisnika.
U suštini, za običnog IT korisnika svemir postaje sve manje dostupan, a njegovo ovladavanje postaje privilegija korporacija.
Izvor: habr.com
