🥇Co się teraz dzieje z bazami RDF?

Semantic Web i Linked Data są podobne do bliskiego kosmosu: nie ma tam życia. Aby wyruszyć tam na nieco dłuższy czas... cóż, nie wiem, co mówiono wam w dzieciństwie w odpowiedzi na „chcę zostać astronautą”. Ale można obserwować, co się dzieje, będąc na Ziemi; znacznie łatwiej zostać amatorem astronomii lub nawet profesjonalistą.

W artykule mowa będzie o świeżych, nie starszych niż kilka miesięcy, trendach ze świata RDF-store'ów. Metafora w pierwszym akapicie była inspirowana epickim obrazem promocyjnym pod katem.

Epicki obrazek

I. GraphQL do dostępu do RDF

Mówi się, że GraphQL ma aspiracje stać się uniwersalnym językiem dostępu do baz danych. A jak sprawy wyglądają z możliwością dostępu do RDF za pomocą GraphQL?

Taką możliwość oferują "z pudełka":

Stardog (blog, 文档);
produkty TopQuadrant (webinar, 文档).

Jeśli jednak magazyn nie zapewnia takiej możliwości, można ją samodzielnie zrealizować, pisząc odpowiedni „resolver”. Tak postąpił na przykład francuski projekt DataTourisme. Albo można już nic nie pisać, tylko po prostu wziąć HyperGraphQL.

Z perspektywy ortodoksyjnego zwolennika Semantic Web i Linked Data wszystko to, oczywiście, jest smutne, ponieważ wydaje się przeznaczone do integracji budowanych wokół kolejnych data silo, a nie odpowiednich dla platform (oczywiście RDF-store'ów).

Wrażenia z porównania GraphQL z SPARQL pozostają mieszane.

Z jednej strony, GraphQL wygląda jak daleki krewny SPARQL: rozwiązuje charakterystyczne dla REST problemy nadmiaru i wielości zapytań — bez których, prawdopodobnie, nie można by się liczyć językiem zapytań, chociażby i dla webu;
Z drugiej strony, frustruje sztywna schematyczność GraphQL. Odpowiednio, jego „introspektywność” wydaje się bardzo ograniczona w porównaniu do pełnej refleksyjności RDF. I nie ma żadnego odpowiednika property paths, więc nawet nie bardzo wiadomo, dlaczego nazywa się to „Graph-”.

II. Adaptery do MongoDB

Trend komplementarny do poprzedniego.

w Stardog teraz być może — w szczególności, wszystko na tym samym GraphQL — skonfigurować mapowanie danych MongoDB do wirtualnych grafów RDF;
GraphDB od niedawna przekazywanie wstawia w SPARQL fragmenty zapytań MongoDB.

Jeśli mówić szerzej, o adapterach do źródeł JSON, pozwalających w miarę „na żywo” przedstawiać przechowywany w tych źródłach JSON jako RDF, można przypomnieć sobie także dość długo istniejący SPARQL Generate, który można podłączyć, na przykład, do Apache Jena.

Podsumowując pierwsze dwa trendy, można powiedzieć, że repozytoria RDF wykazują pełną gotowość do integracji i funkcjonowania w warunkach „wielowariantowego przechowywania” (polyglot persistence). Warto jednak zauważyć, że ten ostatni trend jest już raczej na wyginięciu, a jego miejsce zajmuje wielomodelowość. Jak sytuacja wygląda w świecie repozytoriów RDF dotyczących wielomodelowości?

Mówiąc krótko, nie wygląda to zbyt obiecująco. Tematyce wielomodelowych baz danych chciałbym poświęcić osobny artykuł, a na razie można zauważyć, że obecnie nie ma wielomodelowych baz danych „opartych” na modelu grafowym (jego odmianą można uznać RDF). O pewnej ograniczonej wielomodelowości — wsparciu repozytoriów RDF dla alternatywnego modelu grafowego LPG — wspomnę w rozdziale V.

III. OLTP vs. OLAP

Jednak Gartner piszezauważa, że wielomodelowość jest warunkiem sine qua non przede wszystkim dla operacyjnych baz danych. I to ma sens: w sytuacji „wielowariantowego przechowywania” główne problemy dotyczą transakcyjności.

Tylko gdzie na skali OLTP—OLAP plasują się repozytoria RDF? Odpowiedziałbym tak: ani tu, ani tam. Potrzeba jakiejś trzeciej akronimu, aby określić, do czego są przeznaczone. Proponowałbym OLIP — Online Intellectual Processing.

Jednak warto zauważyć, że

mechanizmy integracji z MongoDB zawarte w GraphDB są w dużej mierze przeznaczone do omijania problemów z wydajnością zapisu;
Stardog idzie jeszcze dalej i całkowicie przepisywał silnik, znów z celem zwiększenia wydajności zapisu.

A teraz pozwólcie, że przedstawię nowego gracza na rynku. Od twórców IBM Netezza i Amazon Redshift — AnzoGraph. Grafika z reklamy tego produktu została umieszczona na początku artykułu. AnzoGraph pozycjonuje się jako rozwiązanie GOLAP. Jak podoba się Wam SPARQL z funkcjami okienkowymi? —

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

IV. RocksDB

Już wcześniej był odniesienie do zapowiedzi Stardog 7 Beta, w której mówiono, że Stardog zamierza wykorzystać jako system przechowywania RocksDB — magazyn „klucz-wartość”, fork facebookowy goglewskiej LevelDB. Dlaczego warto mówić o pewnym trendzie?

Po pierwsze, według artykułu w Wikipedii, na RocksDB przenoszą się nie tylko repozytoria RDF. Są projekty wykorzystujące RocksDB jako silnik przechowywania w ArangoDB, MongoDB, MySQL i MariaDB, Cassandra.

Po drugie, na RocksDB powstają projekty (tzn. nie produkty) związane z odpowiednią tematyką.

Na przykład, eBay używa RocksDB w platformie do swojej „grafu wiedzy”. A propos, zabawnie czytać: język zapytań rozpoczął się jako format tworzony wewnętrznie, ale ostatnio przeszedł w kierunku bardziej przypominającego SPARQL. Jak w dowcipie: im więcej robimy knowledge graph, tym bardziej wygląda na RDF.

Inny przykład — pojawił się kilka miesięcy temu Wikidata History Query Service. Przed jego powstaniem historyczne dane Wikidanych można było uzyskać poprzez MWAPI do standardowego API Mediawiki. Teraz wiele rzeczy można zrobić w czystym SPARQL. „Pod maską” również znajduje się RocksDB. Ciekawe, że WDHQS stworzyła osoba, która zajmowała się importem Freebase do Google Knowledge Graph.

V. Wsparcie LPG

Przypomnę główną różnicę między grafami LPG a grafami RDF.

W LPG na instancje krawędzi można nakładać właściwości skalarne, podczas gdy w RDF można je nakładać tylko na „typy” krawędzi (z tym, że nie tylko właściwości skalarne, ale także zwykłe relacje). To ograniczenie RDF w porównaniu z LPG jest przezwyciężane pewnymi technikami modelowania. Ograniczenie LPG w porównaniu z RDF jest trudniejsze do przezwyciężenia, ale grafy LPG bardziej przypominają obrazki z podręcznika Harari, dlatego ludzie ich chcą.

Oczywiście, zadanie „wsparcia LPG” dzieli się na dwie części:

wprowadzenie do modelu RDF zmian, które umożliwiają naśladowanie konstrukcji LPG;
wprowadzenie zmian do języków zapytań RDF, które umożliwiają dostęp do danych w tym zmienionym modelu, — albo wdrożenie możliwości wykonywania zapytań do tego modelu w popularnych językach zapytań LPG.

V.1. Model danych

Tutaj istnieje kilka możliwych podejść.

V.1.1. Singleton Property

Najbardziej dosłownym podejściem do harmonizacji RDF i LPG jest, prawdopodobnie, singleton property:

Zamiast, na przykład, predykatu :isMarriedTo używane są predykaty :isMarriedTo1, :isMarriedTo2 itd.
Następnie te predykaty stają się podmiotami nowych potrójnych zestawów: :isMarriedTo1 :since "2013-09-13"^^xsd:date i tym podobnych.
Związek tych instancji predykatów z ogólnym predykatem ustala się za pomocą potrójnych zestawów rodzaju :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
Jest oczywiste, że rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, ale pomyśl, dlaczego nie warto pisać po prostu :isMarriedTo1 rdf:type :isMarriedTo.

Zadanie „wsparcia LPG” jest tu rozwiązywane na poziomie RDFS. Takie rozwiązanie wymaga wprowadzenia odpowiednich standardNiektóre zmiany mogą być wymagane od magazynów RDF wspierających dołączanie wniosków, a obecnie Singleton Property można traktować po prostu jako jeszcze jedną technikę modelowania.

V.1.2. Reifikacja zrobiona dobrze

Mniej naiwne podejścia wynikają z uświadomienia sobie, że instancje właściwości mogą być instancjonowane przez trójki. Mając możliwość powiedzenia czegoś o trójkach, zyskamy możliwość mówienia także o instancjach właściwości.

Najbardziej solidnym z tych podejść jest RDF*, znane również jako RDR, powstałe w wnętrzach Blazegraph. Już od samego początku wybrano je dla siebie i AnzoGraph. Solidność podejścia określa to, że w jego ramach są oferowane odpowiednie zmiany w RDF Semantics. Istota tego jest jednak niezwykle prosta. W serializacji Turtle RDF można teraz pisać mniej więcej tak:

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

V.1.3. Inne podejścia

Można nie przejmować się formalną semantyką, a po prostu założyć, że trójki mają pewne identyfikatory, będące oczywiście URI, i tworzyć nowe trójki z tymi URI. Wystarczy tylko udostępnić te URI w SPARQL. Tak robi Stardog.

W Allegrograph poszli pośrednią drogą. Wiadomo, że identyfikatory trójek w Allegrograph jest, ale przy realizacji triple attributes nie są one zewnętrzne. Jednak do formalnej semantyki bardzo daleko. Co ciekawe, atrybuty trójek - nie są URI, a wartości tych atrybutów mogą być tylko literatami. Wyznawcy LPG otrzymują dokładnie to, czego pragnęli. W specjalnie wymyślonym formacie NQX przykład, podobny do podanego powyżej dla RDF*, wygląda tak:

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

V.2. Języki zapytań

Wspierając w jakiś sposób LPG na poziomie modelu, należy umożliwić zapytania do danych w tym modelu.

Blazegraph wspiera zapytania do RDF* SPARQL* i Gremlin. Zapytanie w SPARQL* wygląda tak:

 SELECT * { <> :since ?since }

AnzoGraph również wspiera SPARQL* i zamierza wspierać Cypher, język zapytań w Neo4j.
Stardog wspiera własne rozszerzeniu SPARQL i znów Gremlina. Uzyskać w SPARQL URI trójki i "metainformacje" można przy pomocy mniej więcej takiej konstrukcji:

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

Allegrograph również wspiera własne rozszerzeniu SPARQL:

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

Warto zauważyć, że GraphDB pewien czas wspierała Tinkerpop/Gremlina, nie wspierając jednocześnie LPG, ale w wersji 8.0 lub 8.1 to wsparcie zostało przerwane.

VI. Zaostrzenie licencji

Nie było żadnych nowych dodatków na przecięciu zbiorów „triplestore of choice” i „open source triplestore” w ostatnim czasie. Nowe bazy RDF z otwartym kodem źródłowym są dalekie od bycia dobrym wyborem do codziennego użytku, a kod źródłowy nowych baz RDF, które chciałoby się wykorzystać (takiej jak AnzoGraph), jest zamknięty. Można wręcz mówić o spadkach...

Oczywiście, wcześniej otwarty kod źródłowy nie jest zamykany, ale niektóre bazy z otwartym kodem źródłowym stopniowo przestają być postrzegane jako godne wyboru. Virtuoso, posiadające wersję opensource, moim zdaniem tonie w błędach. Blazegraph zostało zakupione przez AWS i stało się bazą Amazon Neptune; teraz nie wiadomo, czy pojawi się jeszcze jakiś nowy wydanie. Zostaje jedynie Jena...

Jeśli jednak otwarty kod źródłowy nie jest szczególnie ważny, a po prostu chce się spróbować, to sytuacja jest również mniej optymistyczna niż wcześniej. Na przykład:

Stardog zatrzymuje dystrybucję wersji darmowej (zresztą, czas próbny standardowej wersji wydłużył się dwukrotnie);
do GraphDB Cloud, gdzie wcześniej można było wybrać darmowy podstawowy plan, wstrzymano rejestrację nowych użytkowników.

Ogólnie rzecz biorąc, dla przeciętnego użytkownika IT przestrzeń kosmiczna staje się coraz mniej dostępna, a jej opanowanie staje się domeną korporacji.

Źródło: habr.com