Semantic Web och Linked Data liknar den nÀrliggande rymden: det finns inget liv dÀr. För att resa dit under en lÀngre tid⊠tja, jag vet inte vad de sa till dig som barn nÀr du sa "jag vill bli astronaut". Men du kan observera vad som hÀnder Àven frÄn jorden; det Àr mycket lÀttare att bli amatörastronom eller till och med professionell.
I denna artikel kommer vi att diskutera fÀrska trender frÄn vÀrlden av RDF-lager, som inte Àr Àldre Àn nÄgra mÄnader. Metaforen i den första paragrafen inspirerades av en episk reklambild som finns lÀngre ner.
Episk bild
I. GraphQL för Ätkomst till RDF
, som hÀvdar att GraphQL ska bli ett universellt sprÄk för Ätkomst till databaser. Hur stÄr det dÄ till med möjligheten att fÄ Ätkomst till RDF med hjÀlp av GraphQL?
"FrÄn start" erbjuder följande möjligheter:
- Stardog (, );
- produkter frÄn TopQuadrant (, ).
Om lagret inte erbjuder en sÄdan möjlighet, implementerar man den sjÀlv genom att skriva en motsvarande "resolver". Det gjorde de exempelvis i det franska projektet . Eller sÄ kan man nu inget skriva, utan helt enkelt anvÀnda .
Ur en ortodox Semantic Web och Linked Data-anhÀngares perspektiv Àr allt detta förstÄs sorgligt, eftersom det verkar vara avsett för integrationer som byggs runt nya data silo, snarare Àn plattformar (naturligtvis RDF-lager).
Intrycken frÄn jÀmförelsen mellan GraphQL och SPARQL Àr blandade.
- Ă ena sidan ser GraphQL ut som en avlĂ€gsen slĂ€kting till SPARQL: det löser typiska REST-problem som överbeskĂ€rning och multipla förfrĂ„gningar â utan vilket man nog inte kunde anse sig vara ett frĂ„gesprĂ„k, Ă€ven om det bara Ă€r för webben;
- à andra sidan Àr den strikta schematiskheten hos GraphQL nedslÄende. DÀrmed verkar dess "introspektivitet" vara mycket begrÀnsad jÀmfört med den fulla reflexiviteten hos RDF. Och det finns ingen motsvarighet till property paths, sÄ det Àr knappast klart varför det kallas "Graph-".
II. Adaptrar till MongoDB
Trend som kompletterar den föregÄende.
- i Stardog nu â sĂ€rskilt, allt pĂ„ samma GraphQL â att konfigurera databearbetning av MongoDB till virtuella RDF-grafer;
- GraphDB har nyligen kunna infoga fragment av MongoDB Query i SPARQL.
Om vi pratar bredare om adaptrar till JSON-kÀllor, som gör det mer eller mindre möjligt att "on-the-fly" representera JSON som lagras i dessa kÀllor som RDF, sÄ kan vi ocksÄ nÀmna den ganska lÀnge existerande , som kan anpassas, , till Apache Jena.
Sammanfattningsvis av de första tvÄ trenderna kan man sÀga att RDF-lagringssystem visar en fullstÀndig beredskap för integrationer och funktionalitet under förhÄllanden med "polyglot persistence". Det Àr dock vÀlkÀnt att detta i stort sett har fallit ur modet, och istÀllet multimodellering. Men hur stÄr det till med multimodellering i vÀrlden av RDF-lagringssystem?
Kort sagt, sĂ„ stĂ„r det inte sĂ„ bra till. Ămnet multimodell-db:er förtjĂ€nar en egen artikel, men man kan bemĂ€rka att det för nĂ€rvarande inte finns nĂ„gra multimodell-db:er som «baseras» pĂ„ grafmodellen (en variant av den skulle kunna vara RDF). Om en viss liten multimodellering â stöd för RDF-lagringssystemens alternativa grafmodell LPG â kommer det att berĂ€ttas i .
III. OLTP vs. OLAP
För övrigt anser samma Gartner , att multimodellering Àr en betingelse sine qua non, frÀmst för operativa db:er. Det Àr förstÄeligt: i situationen med "polyglot persistence" uppstÄr de största problemen med transaktionalitet.
Men var pĂ„ skalan OLTPâOLAP befinner sig RDF-lagringssystem? Jag skulle sĂ€ga sĂ„ hĂ€r: varken dĂ€r eller hĂ€r. För att beteckna vad de Ă€r avsedda för behövs en tredje akronym. Som alternativ skulle jag föreslĂ„ OLIP â Online Intellectual Processing.
Men ÀndÄ:
- de mekanismer för integration med MongoDB som implementerats i GraphDB Àr inte minst för att kringgÄ problem med skrivprestanda;
- Stardog gÄr Ànnu lÀngre och helt motorn, Äterigen med syftet att öka skrivprestanda.
Och nu fĂ„r jag lov att presentera en ny aktör pĂ„ marknaden, frĂ„n skaparna av IBM Netezza och Amazon Redshift â . Bilden frĂ„n produktannonseringen baserad pĂ„ den publicerades i början av artikeln. AnzoGraph positionerar sig som en GOLAP-lösning. Vad sĂ€gs om SPARQL med fönsterfunktioner? â
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { ⊠}IV. RocksDB
Ovan nĂ€mndes redan till meddelandet om Stardog 7 Beta, dĂ€r det nĂ€mndes att Stardog planerar att anvĂ€nda RocksDB som lagringssystem â ett "nyckel-vĂ€rde"-lager, en Facebook-fork av Googles LevelDB. Varför prata om en trend?
För det första, enligt , sÄ "planterar" inte bara RDF-lagringssystem pÄ RocksDB. Det finns projekt som anvÀnder RocksDB som lagringsmotor i ArangoDB, MongoDB, MySQL och MariaDB, Cassandra.
För det andra görs projekt (dvs. inte produkter) inom denna tematik pÄ RocksDB.
Till exempel anvÀnder eBay RocksDB i för sin "kunskapsgraf". För övrigt Àr det roligt att lÀsa: frÄgesprÄket började som ett internt format, men pÄ senare tid har det övergÄtt till att likna SPARQL mycket mer.. Som i ett skÀmt: hur mÄnga kunskapsgrafer vi Àn gör blir det ÀndÄ RDF.
Ett annat exempel Àr det som dök upp för nÄgra mÄnader sedan. . Innan dess var man tvungen att anvÀnda till standard Mediawiki API för att fÄ historiska uppgifter frÄn Wikidata. Nu Àr mycket möjligt med ren SPARQL. "Under huven" dÀr ocksÄ RocksDB. Förresten, det verkar som att det var en person som arbetat med importen av Freebase till Google Knowledge Graph som gjorde WDHQS.
V. Stöd för LPG
Jag vill pÄminna om den grundlÀggande skillnaden mellan LPG-grafer och RDF-grafer.
I LPG kan instanser av kanter tilldelas skalÀra egenskaper, medan i RDF kan de endast tilldelas "typer" av kanter (men inte bara skalÀra egenskaper, utan Àven vanliga relationer). Denna begrÀnsning i RDF jÀmfört med LPG genom olika modelleringsmetoder. à andra sidan Àr LPG:s begrÀnsningar i förhÄllande till RDF svÄrare att överbrygga, men LPG-grafer liknar mer bilderna frÄn Hararis lÀrobok, vilket gör att folk vill ha dem.
Uppenbarligen delas uppgiften "att stödja LPG" upp i tvÄ delar:
- att införa Àndringar i RDF-modellen som möjliggör att hÀrma LPG-strukturer;
- att införa Àndringar i frÄgesprÄket för RDF som gör det möjligt att frÄga data i denna Àndrade modell, eller att implementera möjligheten att göra frÄgor pÄ denna modell med vanliga LPG-frÄgesprÄk.
V.1. Datamodell
HÀr finns det flera möjliga tillvÀgagÄngssÀtt.
V.1.1. Singleton Property
Den mest bokstavliga metoden för harmonisering av RDF och LPG Àr nog :
- IstÀllet för till exempel predikatet
:isMarriedToanvÀnds predikaten:isMarriedTo1,:isMarriedTo2.och sÄ vidare. - DÀrefter blir dessa predikat subjekt för nya tripletter:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateoch sÄ vidare. - Relationen av dessa instanser av predikaten till det gemensamma predikatet etableras genom tripletter av typen
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.. - Det Àr uppenbart att
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type,men tÀnk pÄ varför man inte bör skriva helt enkelt:isMarriedTo1 rdf:type :isMarriedTo..
Uppgiften "att stödja LPG" löses hÀr pÄ RDFS-nivÄ. Denna lösning krÀver införande av motsvarande . Vissa Àndringar kan krÀvas av RDF-lager som stödjer anslutning av slutsatser, och tills vidare kan Singleton Property uppfattas som en ytterligare modelleringsmetod.
V.1.2. Reifiering PĂ„ RĂ€tt SĂ€tt
Mindre naiva tillvÀgagÄngssÀtt kommer frÄn insikten att instanser av egenskaper helt kan instansieras av tripletter. Genom att kunna sÀga nÄgot om tripletter kan vi ocksÄ tala om instanser av egenskaper.
Det mest solid av dessa tillvÀgagÄngssÀtt Àr , Àven kallad RDR, i djupet av Blazegraph. Den valdes frÄn början AnzoGraph. Soliditeten i tillvÀgagÄngssÀttet definieras av att de relevanta förÀndringarna i RDF Semantics <> :since "2013-09-13"^^xsd:date .
V.1.3. Ăvriga TillvĂ€gagĂ„ngssĂ€ttMan kan skippa den formella semantiken och helt enkelt betrakta att tripletter har vissa identifierare som naturligtvis Ă€r URI:er, och skapa nya tripletter med dessa URI:er. Det Ă„terstĂ„r bara att ge tillgĂ„ng till dessa URI:er i SPARQL. SĂ„
Stardog. I Allegrograph
genom en mellanvÀg. Det Àr kÀnt att identifierarna för tripletterna i Allegrograph , men nÀr det gÀller implementationen av triple attributes framtrÀder de inte utÄt. Men det Àr fortfarande lÄngt ifrÄn formell semantik. Notabelt Àr att attributen för tripletter inte Àr URI:er, och vÀrdena av dessa attribut kan ocksÄ bara vara litteraler. AnhÀngare av LPG fÄr precis vad de ville. I det speciellt uppfunna formatet NQX ser ett exempel ut, liknande det som nÀmnts tidigare för RDF*, sÄ hÀr: :bob :marriedTo :alice {"since" : "2013-09-13"}
V.2. FrÄgesprÄkGenom att pÄ ett eller annat sÀtt stödja LPG pÄ modellnivÄ behöver vi möjliggöra att göra frÄgor om data i en sÄdan modell.
Blazegraph stödjer
- SPARQL* och SELECT * { <> :since ?since }
Anzograph stöder ocksÄ- och planerar att stödja Cypher Stardog stödjer sin egen
- SPARQL och Ă„terigen SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }
Allegrograph stöder ocksÄ sin egen- SPARQL: SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
Förresten, GraphDB stödde en gÄng Tinkerpop/Gremlin utan att stödja LPG, men i version 8.0 eller 8.1 slutade det.VI. FörstÀrkning av Licenser
VI. SkÀrpning av licenser
Det har nyligen inte skett nĂ„gra tillĂ€gg i skĂ€rningspunkten mellan "triplestore of choice" och "open source triplestore". Nya RDF-lager med öppen kĂ€llkod Ă€r lĂ„ngt ifrĂ„n att bli ett bra val för dagligt bruk, och kĂ€llkoden för nya RDF-lager som man skulle vilja anvĂ€nda (till exempel AnzoGraph) Ă€r stĂ€ngd. Man kan snarare till och med tala om neddragningarâŠ
SjĂ€lvklart stĂ€ngs inte öppen kĂ€llkod, men vissa förr öppna kĂ€llkods-lager börjar gradvis upphöra att ses som vĂ€rdiga alternativ. Virtuoso, som har en opensource-version, sjunker enligt min Ă„sikt i buggar. Blazegraph har köpts av AWS och ligger till grund för Amazon Neptune; nu Ă€r det oklart om det ens kommer att ske fler releaser. Endast Jena Ă„terstĂ„râŠ
Om öppen kÀllkod inte Àr sÄ viktigt, och man bara vill prova, sÄ ser allt ocksÄ mindre lovande ut Àn tidigare. Till exempel:
- Stardog distribuera en gratisversion (för övrigt har den vanliga testperioden fördubblats);
- pÄ , dÀr man tidigare kunde vÀlja en gratis grundplan, har registreringen av nya anvÀndare pausats.
Sammanfattningsvis blir rymden alltmer otillgÀnglig för den genomsnittliga IT-anvÀndaren, och att behÀrska den blir företagens domÀn.
KĂ€lla: habr.com
