ProHoster > Blog > podávání > Co se nyní děje s repozitáři RDF?

Co se nyní děje s repozitáři RDF?

Sémantický web a propojená data jsou jako vesmír: není tam žádný život. Jet tam na více či méně dlouhou dobu... no, nevím, co vám jako dítěti řekli na otázku „Chci se stát astronautem“. Ale můžete pozorovat, co se děje na Zemi; Je mnohem jednodušší stát se amatérským astronomem nebo dokonce profesionálem.

Článek se zaměří na nedávné, ne starší než několik měsíců, trendy ze světa úložiště RDF. Metafora v prvním odstavci byla inspirována epickým reklamním obrázkem pod řezem.


Epický obrázek

Co se nyní děje s repozitáři RDF?

I. GraphQL pro přístup RDF

Říkajíže GraphQL si klade za cíl stát se univerzálním jazykem pro přístup k databázi. A co možnost přístupu k RDF pomocí GraphQL?

Po vybalení tuto příležitost poskytuje:

Pokud úložiště takovou možnost neposkytuje, lze ji implementovat nezávisle napsáním vhodného „řešiče“. To se jim povedlo například ve francouzském projektu DataTourisme. Nebo už nemůžete nic psát, ale jen brát HyperGraphQL.

Z pohledu ortodoxního přívržence sémantického webu a propojených dat je to vše samozřejmě smutné, protože se zdá být navrženo pro integrace postavené kolem dalšího datového sila a nevhodných platforem (samozřejmě úložiště RDF) .

Dojmy ze srovnání GraphQL se SPARQL jsou dvojí.

  • Na jednu stranu vypadá GraphQL jako vzdálený příbuzný SPARQL: řeší problémy s převzorkováním a multiplicitou dotazů, které jsou pro REST typické - bez kterých by pravděpodobně nebylo možné uvažovat dotazovací jazyk, alespoň pro web;
  • Na druhou stranu rigidní schéma GraphQL je zklamáním. V souladu s tím se jeho „introspektivita“ zdá velmi omezená ve srovnání s plnou reflexivitou RDF. A neexistuje žádná analogie cest vlastností, takže není ani úplně jasné, proč je to „Graf-“.

II. Adaptéry pro MongoDB

Trend doplňující ten předchozí.

  • nyní ve Stardogu možná - zejména vše na stejném GraphQL - nakonfigurujte mapování dat MongoDB do virtuálních grafů RDF;
  • GraphDB nedávno umožňuje vložte fragmenty do SPARQL na MongoDB Query.

Hovoříme-li šířeji o adaptérech ke zdrojům JSON, které umožňují víceméně „za běhu“ reprezentovat JSON uložený v těchto zdrojích jako RDF, lze připomenout poměrně dlouholetý Generovat SPARQL, které lze upravit, například, do Apache Jena.

Shrneme-li první dva trendy, můžeme říci, že RDF úložiště prokazují plnou připravenost k integraci a provozu v podmínkách „polyglot persistence“. Je však známo, že tento druhý již dávno není v módě a je nahrazován příchod vícemodelový. A co multi-modeling ve světě úložiště RDF?

Zkrátka v žádném případě. Tématu multimodelových DBMS bych rád věnoval samostatný článek, ale prozatím lze poznamenat, že v současnosti neexistují multimodelové DBMS „založené“ na grafovém modelu (za jeho typ lze považovat RDF) . Některé malé multi-modelování - podpora úložiště RDF pro alternativní model grafu LPG - bude diskutováno v oddíl V.

III. OLTP vs. OLAP

Nicméně to samé Gartner píšeže multimodel je podmínkou sine qua non primárně pro operační sály DBMS. To je pochopitelné: v situaci „multivariančního úložiště“ vznikají hlavní problémy s transakčností.

Ale kde jsou RDF úložiště umístěna na stupnici OLTP-OLAP? Odpověděl bych takto: ani tam, ani tady. Pro označení toho, k čemu jsou určeny, je potřeba nějaká třetí zkratka. Jako možnost bych doporučil OLIP — Intelektuální zpracování online.

Nicméně stále:

  • integrační mechanismy s MongoDB implementované v GraphDB jsou v neposlední řadě zamýšlený obejít problémy s výkonem zápisu;
  • Stardog jde ještě dál a úplně přepisuje engine, opět s cílem zlepšit výkon záznamu.

Nyní mi dovolte představit nového hráče na trhu. od tvůrců IBM Netezza a Amazon Redshift - AnzoGraph. Na začátku článku byl zveřejněn obrázek z reklamy na produkt na jejím základě. AnzoGraph se staví jako řešení GOLAP. Jak se vám líbí SPARQL s funkcemi oken? —

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

IV. RocksDB

Již vyšší byl tam odkaz k oznámení Stardog 7 Beta, který řekl, že Stardog bude používat RocksDB jako základní úložný systém – obchod s klíčovou hodnotou, Facebook fork Google LevelDB. Proč stojí za to mluvit o určitém trendu?

Za prvé, soudě podle Článek na Wikipedii, nejen RDF úložiště jsou „transplantována“ do RocksDB. Existují projekty pro použití RocksDB jako úložiště v ArangoDB, MongoDB, MySQL a MariaDB, Cassandra.

Za druhé, na RocksDB vznikají projekty (tedy ne produkty) na relevantní témata.

Například eBay používá RocksDB in platforma pro váš „graf znalostí“. Mimochodem, je vtipné číst: dotazovací jazyk začínal jako domácí formát, ale v poslední době se mění tak, aby byl mnohem více podobný SPARQL. Jako ve vtipu: bez ohledu na to, jak velký znalostní graf uděláme, stejně skončíme s RDF.

Další příklad – ten, který se objevil před pár měsíci Dotazovací služba historie wikidat. Před jeho zavedením bylo nutné získat přístup k historickým informacím Wikidata MWAPI na standardní Mediawiki API. S čistým SPARQL je nyní možné hodně. „Pod kapotou“ je také RocksDB. Mimochodem, WDHQS vytvořil, zdá se, člověk, který importoval Freebase do Google Knowledge Graph.

V. Podpora LPG

Dovolte mi připomenout hlavní rozdíl mezi grafy LPG a grafy RDF.

V LPG lze skalární vlastnosti přiřadit instancím hran, zatímco v RDF je lze přiřadit pouze „typům“ hran (ale nejen skalární vlastnosti, ale i běžné spoje). Toto omezení RDF ve srovnání s LPG překonat jedna nebo druhá modelovací technika. Omezení LPG oproti RDF je obtížnější překonat, ale LPG grafy jsou spíše obrázky z učebnice Harari než RDF grafy, proto je lidé chtějí.

Úkol „podpory LPG“ samozřejmě spadá do dvou částí:

  1. provádění změn v modelu RDF, které v něm umožňují simulovat struktury LPG;
  2. provádění změn v dotazovacím jazyce RDF, které umožňují přístup k datům v tomto upraveném modelu, nebo implementace schopnosti pokládat dotazy do tohoto modelu v oblíbených dotazovacích jazycích LPG.

V.1. Datový model

Zde je několik možných přístupů.

V.1.1. Singleton Property

Nejdoslovnější přístup k harmonizaci RDF a LPG je pravděpodobně singleton majetku:

  • Místo např. predikátu :isMarriedTo používají se predikáty :isMarriedTo1, :isMarriedTo2 atd.
  • Tyto predikáty se pak stanou předmětem nových trojic: :isMarriedTo1 :since "2013-09-13"^^xsd:date atd.
  • Spojení těchto instancí predikátů se společným predikátem je založeno na trojicích tvaru :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Je zřejmé, že rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ale zamyslete se nad tím, proč byste neměli jen psát :isMarriedTo1 rdf:type :isMarriedTo.

Problém „podpory LPG“ je zde řešen na úrovni RDFS. Takové rozhodnutí vyžaduje zařazení do příslušného standardní. Některé změny mohou být vyžadovány pro obchody RDF, které podporují připojení důsledků, ale prozatím lze Singleton Property považovat pouze za další modelovací techniku.

V.1.2. Reifikace provedena správně

Méně naivní přístupy pramení z uvědomění, že instance vlastností jsou plně instanciovatelné pomocí trojic. Tím, že budeme moci říci něco o trojicích, budeme moci mluvit o majetkových instancích.

Nejrobustnější z těchto přístupů je RDF*, neboli RDR, narozený v hlubinách Blazegraphu. Je to od samého začátku zvolený pro sebe a AnzoGraph. Solidnost přístupu je dána tím, že v jeho rámci nabídl odpovídající změny v Sémantika RDF. Pointa je však velmi jednoduchá. V želví serializaci RDF nyní můžete napsat něco takového:

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

V.1.3. Jiné přístupy

Nemůžete se obtěžovat formální sémantikou, ale jednoduše předpokládat, že triplety mají určité identifikátory, kterými jsou samozřejmě URI, a vytvářet nové triplety s těmito URI. Zbývá pouze poskytnout přístup k těmto URI ve SPARQL. Tak dorazí Hvězdný pes.

V Allegrograph pojďme mezilehlým způsobem. Je známo, že tripletové identifikátory v Allegrograph je, ale při implementaci trojitých atributů nevyčnívají. K formální sémantice má však stále velmi daleko. Je pozoruhodné, že atributy tripletů nejsou URI a hodnoty těchto atributů mohou být také pouze literály. Příznivci LPG dostanou přesně to, co chtěli. Ve speciálně vynalezeném formátu NQX vypadá příklad podobný výše uvedenému pro RDF* takto:

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

V.2. Dotazovací jazyky

Po podpoře LPG tak či onak na úrovni modelu musíte umožnit dotazy na data v takovém modelu.

  • Blazegraph pro dotazy RDF* podporuje SPARQL* и Skřítek. Dotaz SPARQL* vypadá takto:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

  • Anzograf také podporuje SPARQL* a chystá se podpořit Nicka, dotazovací jazyk v Neo4j.
  • Stardog podporuje své vlastní prodloužení SPARQL a znovu Skřítek. Triplet URI a „metainformace“ ve SPARQL můžete získat pomocí něčeho takového:

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

  • Allegrograph také podporuje svůj vlastní prodloužení SPARQL:

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

Mimochodem, GraphDB svého času podporoval Tinkerpop/Gremlin bez podpory LPG, ale to se zastavilo ve verzi 8.0 nebo 8.1.

VI. Zpřísnění licencí

K průsečíku sad „triplestore of choice“ a „open source triplestore“ nebyly v poslední době přidány žádné nové doplňky. Nové obchody s otevřeným zdrojovým kódem RDF mají daleko k tomu, aby byly dobrou volbou pro každodenní použití, a nové obchody RDF, které bych chtěl používat (jako AnzoGraph), jsou uzavřené zdroje. Spíše se dá mluvit i o úbytcích...

Samozřejmě, že open source nebyl v minulosti ukončen, ale některá open source úložiště už pomalu nevidí, že by stálo za to vybírat. Virtuoso, který má opensource edici, se podle mě topí v bugech. Blazegraph byl koupen AWS a vytvořil základ Amazon Neptun; nyní není jasné, zda bude ještě alespoň jedno vydání. Zůstala jen Jena...

Pokud není open source příliš důležitý, ale chcete si to jen vyzkoušet, pak je také vše méně růžové než dříve. Například:

  • Hvězdný pes končí distribuovat bezplatnou verzi (zkušební doba běžné verze se však zdvojnásobila);
  • в Cloud GraphDB, kde jste si dříve mohli vybrat základní tarif zdarma, pozastavila registrace nových uživatelů.

Obecně se pro běžného IT člověka stává prostor stále nedostupnější, jeho rozvoj se stává údělem korporací.

Zdroj: www.habr.com

Přidat komentář