Semantiese web en gekoppelde data is soos die buitenste ruimte: daar is geen lewe daar nie. Om daarheen te gaan vir 'n min of meer lang termyn ... Ek weet nie wat hulle vir jou as kind gesê het in reaksie op "Ek wil 'n ruimtevaarder word nie." Maar jy kan kyk wat gebeur terwyl jy op Aarde is; om 'n amateur-sterrekundige of selfs 'n professionele persoon te word, is baie makliker.
Die artikel sal fokus op vars, nie ouer as 'n paar maande nie, neigings uit die wêreld van RDF-berging. Die metafoor in die eerste paragraaf is geïnspireer deur 'n epiese promosiebeeld onder die snit.
epiese prentjie
I. GraphQL vir RDF Toegang
dat GraphQL beweer dat dit die universele databasistoegangstaal is. En wat van die vermoë om toegang te verkry met behulp van GraphQL na RDF?
Uit die boks word hierdie geleentheid gebied deur:
- sterrehond(, );
- TopQuadrant produkte (, ).
As die bewaarplek nie so 'n geleentheid bied nie, word dit onafhanklik geïmplementeer deur die toepaslike "resolver" (resolver) te skryf. Dit is byvoorbeeld in die Franse projek gedoen . Of jy kan reeds niks skryf nie, maar vat net .
Uit die oogpunt van 'n ortodokse aanhanger van die Semantiese Web en Gekoppelde Data, is dit alles natuurlik hartseer, aangesien dit lyk of dit bedoel is vir integrasies wat rondom die volgende datasilo gebou is, en nie geskikte platforms nie (natuurlik RDF-winkels) .
Die indrukke van die vergelyking van GraphQL met SPARQL is tweeledig.
- Aan die een kant lyk GraphQL soos 'n verre familielid van SPARQL: dit los die probleme van herseleksie en veelvuldige navrae op wat kenmerkend van REST is - waarsonder dit waarskynlik nie moontlik sou wees om te oorweeg nie navraagtaal, ten minste vir die web;
- Aan die ander kant ontstel die rigiede skema van GraphQL. Gevolglik blyk die "introspektiwiteit" daarvan baie beperk te wees in vergelyking met die volle refleksiwiteit van RDF. En daar is geen analoog van eiendomspaaie nie, so dit is nie eens baie duidelik hoekom dit "Grafiek-" is nie.
II. Adapters vir MongoDB
'n Tendens aanvullend tot die vorige een.
- Nou by Stardog - veral, almal op dieselfde GraphQL - konfigureer die vertoning van MongoDB-data in virtuele RDF-grafieke;
- Ontotext GraphDB onlangs voeg in SPARQL-fragmente op MongoDB Query.
As ons meer in die breë praat, oor adapters na JSON-bronne wat min of meer "on the fly" toelaat om die JSON wat in hierdie bronne gestoor is as RDF voor te stel, dan kan ons ook die bestaande een vir 'n geruime tyd onthou wat aangepas kan word , na Apache Jena.
Om die eerste twee tendense op te som, kan ons sê dat RDF-bewaarplekke volle gereedheid vir integrasie en funksionering in toestande van "veelvuldige berging" (poliglot-volharding) toon. Dit is egter bekend dat laasgenoemde lankal uit die mode is, en om dit te vervang multi-modellering. En wat van multi-modellering in die wêreld van RDF-berging?
Kortom, geen manier nie. Ek wil graag 'n aparte artikel aan die onderwerp van multi-model DBBS wy, maar vir nou kan jy sien dat daar nie 'n multi-model DBBS "gebaseer" op die grafiek model (RDF kan beskou word as 'n variasie daarvan) nou. Sommige klein multi-modellering - ondersteuning deur RDF-bergings van 'n alternatiewe VPG-grafiekmodel - sal in bespreek word .
III. OLTP vs. OLAP
Dieselfde Gartner dat multi-modellering 'n sine qua non voorwaarde hoofsaaklik vir operasiekamers DBMS. Dit is verstaanbaar: in 'n situasie van "veelvuldige berging" ontstaan die hoofprobleme met transaksionaliteit.
Maar waar op die OLTP-OLAP-skaal is RDF-bewaarplekke? Ek sou so antwoord: nie daar of hier nie. Om aan te dui waarvoor hulle bedoel is, is 'n derde afkorting nodig. As 'n opsie sou ek voorstel OLIP — Aanlyn intellektuele verwerking.
Tog, steeds:
- die integrasiemeganismes wat in GraphDB met MongoDB geïmplementeer is, is nie die minste nie om werkverrigtingkwessies te skryf;
- Stardog gaan selfs verder en heeltemal enjin, weer met die doel om skryfprestasie te verbeter.
En laat ek nou 'n nuwe speler in die mark voorstel. Van die skeppers van IBM Netezza en Amazon Redshift - . 'n Prent van 'n advertensie vir 'n produk wat daarop gebaseer is, is aan die begin van die artikel geplaas. AnzoGraph posisioneer homself as 'n GOLAP-oplossing. Hoe hou jy van SPARQL met vensterfunksies? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocksDB
Bo reeds na die aankondiging van Stardog 7 Beta, wat gesê het dat Stardog RocksDB gaan gebruik as 'n onderliggende bergingstelsel - sleutelwaardeberging, Facebook se vurk van Google se LevelDB. Hoekom is dit die moeite werd om oor 'n sekere tendens te praat?
Eerstens, te oordeel aan , nie net RDF-bewaarplekke word na RocksDB oorgeplant nie. Daar is projekte om RocksDB as 'n bergingsenjin te gebruik in ArangoDB, MongoDB, MySQL en MariaDB, Cassandra.
Tweedens word projekte (dit is nie produkte nie) van die ooreenstemmende vak op RocksDB gemaak.
Byvoorbeeld, eBay gebruik RocksDB in vir jou "kennisgrafiek". Terloops, dit is snaaks om te lees: die navraagtaal het begin as 'n tuisgemaakte formaat, maar meer onlangs het dit oorgeskakel om baie meer soos SPARQL te wees. Soos in 'n grap: maak nie saak hoeveel kennisgrafiek ons doen nie, ons kry steeds RDF.
Nog 'n voorbeeld - verskyn 'n paar maande gelede . Voor die bekendstelling daarvan moes toegang tot Wikidata se historiese inligting verkry word na die standaard Mediawiki API. Baie is nou moontlik in suiwer SPARQL. "Onder die kap" is daar ook RocksDB. Terloops, WDHQS het dit gedoen, dit lyk soos die persoon wat betrokke was by die invoer van Freebase in die Google Knowledge Graph.
V. LPG ondersteuning
Laat ek jou die belangrikste verskil tussen LPG-grafieke en RDF-grafieke herinner.
In LPG kan skalêre eienskappe aan randgevalle geheg word, terwyl dit in RDF slegs aan rand "tipes" geheg kan word (maar nie net skalêre eienskappe nie, maar ook gewone skakels). Hierdie beperking van RDF in vergelyking met LPG een of ander modelleertegniek. Die beperkings van LPG in vergelyking met RDF is moeiliker om te oorkom, maar LPG-grafieke is meer soos prente uit Harari se handboek as RDF-grafieke, so mense wil dit hê.
Uiteraard val die taak van "ondersteuning van LPG" in twee dele:
- veranderings aan die RDF-model aan te bring wat dit moontlik maak om VPG-konstrukte daarin te simuleer;
- veranderings aan die RDF-navraagtaal te maak wat dit moontlik maak om toegang tot data in hierdie gewysigde model te maak, of die implementering van die vermoë om hierdie model in gewilde LPG-navraagtale te bevraagteken.
V.1. Data Model
Daar is verskeie moontlike benaderings hier.
V.1.1. enkelton eiendom
Die mees letterlike benadering tot harmonisering van RDF en LPG is waarskynlik :
- In plaas van byvoorbeeld die predikaat
:isMarriedTopredikate gebruik word:isMarriedTo1,:isMarriedTo2en so aan. - Hierdie predikate word dan onderwerpe van nuwe drieling:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateens. - Die verband van hierdie gevalle van predikate met 'n algemene predikaat word vasgestel deur drieling van die vorm
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Dit is duidelik dat
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, maar oorweeg hoekom jy nie net moet skryf nie:isMarriedTo1 rdf:type :isMarriedTo.
Die taak van "LPG-ondersteuning" word hier op die RDFS-vlak opgelos. So 'n besluit vereis insluiting by die betrokke . Sommige veranderinge kan vereis word van RDF-bewaarplekke wat die aanhegting van gevolge ondersteun, maar vir eers kan Singleton Property as net nog 'n modelleringstegniek beskou word.
V.1.2. Reifikasie Reg gedoen
Minder naïewe benaderings spruit uit die besef dat eiendomsgevalle perfek deur drieling geïnstansieer word. Deur oor drieling te kan praat, kan ons ook oor eiendomsgevalle praat.
Die mees soliede van hierdie benaderings is aka RDR, in die ingewande van Blazegraph. Dis van die begin af vir myself en AnzoGraph. Die soliditeit van die benadering word bepaal deur die feit dat binne sy raamwerk ooreenstemmende veranderinge in . Die punt is egter uiters eenvoudig. In RDF Skilpad serialisering, kan jy nou iets soos hierdie skryf:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Ander benaderings
U kan u nie met formele semantiek steur nie, maar dink bloot daaraan dat die drieling 'n paar identifiseerders het, wat natuurlik URI's is, en nuwe drielinge met hierdie URI's saamstel. Al wat oorbly, is om toegang tot hierdie URI's in SPARQL te gee. Dus sterrehond.
In Allegrograaf op 'n intermediêre manier. Dit is bekend dat die identifiseerders van drieling in Allegrograph , maar wanneer driedubbele eienskappe geïmplementeer word, steek hulle nie uit nie. Selfs formele semantiek is egter baie ver weg. Veral drieling-kenmerke is nie URI's nie, en die waardes van hierdie eienskappe kan ook net letterlik wees. LPG-aanhangers kry presies wat hulle wou hê. In die spesiaal uitgevindte NQX-formaat lyk 'n voorbeeld soortgelyk aan die een hierbo vir RDF* soos volg:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Navraag tale
Nadat u LPG op een of ander manier op modelvlak ondersteun het, moet u dit moontlik maak om data in so 'n model te bevraagteken.
- Blazegraph vir RDF*-navrae ondersteun и . 'n SPARQL*-navraag lyk soos volg:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograaf ondersteun ook en gaan ondersteun , die navraagtaal in Neo4j.
- Stardog handhaaf sy eie SPARQL en Gremlin. Jy kan die URI van 'n drieling en "meta-inligting" in SPARQL kry deur iets soos hierdie te gebruik:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph ondersteun ook sy eie SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Terloops, GraphDB het Tinkerpop/Gremlin op een slag ondersteun sonder om LPG te ondersteun, maar dit het in weergawe 8.0 of 8.1 gestop.
VI. Verskerping van lisensies
Daar was geen onlangse toevoegings tot die kruising van die "triplestore of choice" en "open source triplestore"-stelle nie. Nuwe oopbron RDF-winkels is nog lank nie 'n goeie keuse vir alledaagse gebruik nie, en die bronkode vir nuwe driedubbele winkels wat ek graag wil gebruik (byvoorbeeld AnzoGraph) is gesluit. Ons kan eerder praat oor vermindering ...
Natuurlik is voorheen oopbron nie gesluit nie, maar sommige oopbronbewaarplekke word geleidelik nie meer as 'n keusewaardig beskou nie. Virtuoso, wat 'n oopbron-uitgawe het, is myns insiens besig om in goggas te verdrink. Blazegraph gekoop deur AWS en het die basis van Amazon Neptune gevorm; nou is dit nie duidelik of daar ten minste nog een vrystelling sal wees nie. Net Jenna bly oor...
As oopbron nie baie belangrik is nie, maar jy wil net probeer, dan is alles ook minder rooskleurig as voorheen. Byvoorbeeld:
- sterrehond versprei die gratis weergawe (die proeftydperk van die gewone een het egter verdubbel);
- в , waar jy voorheen die gratis basiese plan kon kies, word nuwe gebruikerregistrasie opgeskort.
In die algemeen word ruimte meer en meer ontoeganklik vir 'n gewone IT-leek, die ontwikkeling daarvan word die lot van korporasies.
Bron: will.com