🥇Mi történik most az RDF-tárolókkal?

A Szemantikus Web és a Linked Data olyanok, mint a közeli világűr: élet nincs ott. Ahhoz, hogy oda utazzunk egy viszonylag hosszabb időre... nos, nem tudom, mit mondtak nektek gyerekként a "szeretnék űrhajós lenni" kérdésére. De megfigyelni a történéseket a Földről is lehet; amatőr vagy akár profi csillagász válni sokkal egyszerűbb.

A cikk a friss, néhány hónapnál nem régebbi RDF-tárak világából származó trendekről fog szólni. Az első bekezdés metaforája egy epikus méretű reklámképből merített ihletet, amely a folytatásban található.

Epikus kép

I. GraphQL az RDF-hez való hozzáféréshez

Azt mondják, hogy a GraphQL azt állítja, hogy az adatbázisokhoz való univerzális hozzáférés nyelve lesz. De hogyan áll a helyzet a GraphQL RDF-hez való hozzáférésével?

Ezt „dobozból” nyújtja:

Stardog (blogra, dokumentáció);
a TopQuadrant termékei (webináriumot, dokumentáció).

Ha a tároló ilyen lehetőséget nem kínál, azt magunk valósítjuk meg, írva a megfelelő „felismerőt” (resolver). Például így jártak el a francia DataTourismeprojektnél. Vagy már nem is szükséges semmit írni, hanem egyszerűen el lehet venni a HyperGraphQL.

Szempontjából a Szemantikus Web és a Linked Data ortodox híve számára mindez természetesen szomorú, mivel úgy tűnik, hogy integrációkra van szánva, amelyek köré a következő adat szigetek épülnek, nem pedig olyan platformokhoz (nyilvánvalóan RDF tárolókhoz) alkalmasak.

A GraphQL és a SPARQL összehasonlításából származó benyomások vegyesek.

Egyrészt a GraphQL távoli rokonának tűnik a SPARQL-lal: benne megoldották a REST által hordozott problémákat, mint az újraválasztás és a több kérés, anélkül, hogy valaha is számítani lehetne rá, mint lekérdezési nyelv, még ha webes célokra is;
Másrészt a GraphQL szigorú sémáztatása csalódást okoz. Ennek megfelelően az „introspektív” jellege nagyon korlátozottnak tűnik a RDF teljes reflektálhatóságához képest. Nincs analógia a property paths-al, így még az sem egyértelmű, miért hívják ezt „Graph-”-nak.

II. Adapterek MongoDB-hez

Trend, ami kiegészíti az előzőt.

a Stardog most lehetséges — köztük mindazonáltal GraphQL-on — a MongoDB adatok RDF grafikonokba való virtuális leképezésévé képes;
A GraphDB nemrégiben MMM-DD-YYYY frissítéseket integrál a MongoDB lekérdezések SPARQL-ba történő beszúrásával.

Ha tágabban beszélünk, a JSON forráshoz kapcsolódó adapterek révén, amelyek lehetővé teszik a tárolt JSON RDF-kként való bemutatását viszonylag „futás közben”, emlékezhetünk a viszonylag régen létező SPARQL Generate, amit rá lehet illeszteni, például, az Apache Jena-ról.

Összefoglalva az első két trendet, elmondható, hogy az RDF tárolók teljes mértékben készen állnak az integrációkra, és a „többféle tárolás” (polyglot persistence) körülményei között működésre. Az azonban már régóta köztudott, hogy ez az utóbbi nem divatos, és a helyébe a multimodelliség lép. Mi a helyzet a multimodelliséggel az RDF tárolók világában?

Röviden, sehogy. A multimodell adatbázisok témáját érdemes lenne külön cikknek szentelni, de egyelőre megfigyelhetjük, hogy a grafikus modellre (amelynek egyik változata az RDF) alapozott multimodell adatbázisok jelenleg nem léteznek. Az RDF tárolók által támogatott alternatív grafikus modell, az LPG vonatkozásában egy kis multimodelliségről fogunk beszélni a V. fejezetben..

III. OLTP vs. OLAP

Ettől függetlenül a Gartner Ki vezeti be az IPv6-ot, és mi lassítja annak fejlődését?, hogy a multimodelliség alapvető feltétel a műveleti adatbázisok számára. Ez érthető: a „többféle tárolás” helyzetében a legfontosabb problémák a tranzakciós kérdésekkel kapcsolatosak.

De hol helyezkednek el az RDF tárolók az OLTP–OLAP skálán? A válaszom így hangzik: se ott, se itt. Ahhoz, hogy megnevezzük, mire valók, szükség van egy harmadik rövidítésre. Egy alternatívaként javasolnám az OLIP-ot, azaz Online Intellectual Processing-et.

Azonban mégis:

a GraphDB-ben megvalósított MongoDB-vel való integrációs mechanizmusokat nem utolsósorban kifejezetten arra hozták létre, hogy megkerüljék a rekordok írásának teljesítménybeli problémáit;
a Stardog még tovább megy, és teljesen újraírja a motort, ismét a rekordok írásának teljesítményének növelése céljából.

Most pedig engedje meg, hogy bemutassam a piacon egy új szereplőt, az IBM Netezza és az Amazon Redshift alkotóitól — AnzoGraph-ot.A termék alapjául szolgáló reklámkép a cikk elején került megjelenítésre. Az AnzoGraph GOLAP megoldásként pozicionálja magát. Mi a véleménye a SPARQL ablakfunkciókkal kapcsolatban? —

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

IV. RocksDB

Már említettük a hivatkozást a Stardog 7 Beta bejelentésére, ahol arról volt szó, hogy a Stardog RocksDB-t kívánja használni alsóbb szintű tárolókedésként — egy „kulcs-érték” tárolót, amely a Facebook forkja a Google LevelDB-nek. Miért érdemes már mostanra valamilyen trendről beszélni?

Először is, a Wikipedia cikkénekszemszögéből nézve a RocksDB-re nemcsak RDF tárolók „ültetnek át” projektjeiket. Vannak projektek, amelyek a RocksDB-t a tárolási motorként használják az ArangoDB, MongoDB, MySQL és MariaDB, Cassandra vonatkozásában.

Másodszor, RocksDB-re olyan projekteket (azaz nem termékeket) fejlesztenek, amelyek ezen a szakterületen relevánsak.

Például az eBay a RocksDB-t használja platformján tudásgrafikonja számára. Egyébként érdekes olvasni: a lekérdezési nyelv eredetileg egy házi készítésű formátum volt, de mostanában sokkal inkább hasonlít a SPARQL-ra. Ahogy a vicc tartja: bármit is készítünk a tudásgrafikonból, az mindig RDF lesz.

Egy másik példa a néhány hónappal ezelőtt megjelent Wikidata History Query Service. Azelőtt a Wikidata történeti adataihoz a MWAPI-n keresztül kellett hozzáférni a standard Mediawiki API-n. Most már sok minden elérhető tiszta SPARQL-leal. „A motorháztető alatt” is RocksDB található. Érdekesség, hogy a WDHQS-t úgy tűnik, egy olyan ember készítette, aki a Freebase-t importálta a Google Knowledge Graph-ba.

V. LPG támogatás

Emlékeztetnék a LPG grafikonok és az RDF grafikonok közötti fő különbségre.

A LPG-ben a szegmensekhez skálázható tulajdonságok csatlakoztathatók, míg RDF esetében csak a „típusokhoz” csatlakozhatnak (bár nemcsak skálázható tulajdonságok, hanem hagyományos kapcsolatok is). Ez az RDF korlátozottsága a LPG-hez képest leküzdhető különböző modellezési technikákkal. A LPG korlátozottságát az RDF-hez képest nehezebb leküzdeni, de a LPG grafikonok jobban hasonlítanak Harari tankönyvének képeire, ezért az emberek ezt szeretnék.

Nyilvánvaló, hogy a „LPG támogatás” feladata két részre oszlik:

a modell RDF-ben végrehajtott változtatások, amelyek lehetővé teszik a LPG struktúráinak megjelenítését;
a RDF lekérdező nyelvében végrehajtott változtatások, amelyek lehetővé teszik az adatok elérhetőségét ebben a módosított modellben, vagy a LPG népszerű lekérdező nyelvein történő lekérdezések lehetőségének megvalósítása.

V.1. Adatmodell

Itt több lehetséges megközelítés létezik.

V.1.1. Singleton Property

Talán a legszemélyesebb megközelítés RDF és LPG harmonizálására a singleton property:

Használjon például predikátum helyett :isMarriedTo predikátumokkal, mint például :isMarriedTo1, :isMarriedTo2 stb.
Ezután ezek a predikátumok új tripletek alanyai lesznek: :isMarriedTo1 :since "2013-09-13"^^xsd:date és így tovább.
Ezeknek a predikátum objektumai a közös predikátummal a következő típusú tripletek segítségével kapcsolódnak: :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
Nyilvánvaló, hogy rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, de gondolkodjon el rajta, hogy miért nem érdemes egyszerűen írni. :isMarriedTo1 rdf:type :isMarriedTo.

A „LPG támogatás” feladata itt az RDFS szintjén van. Ez a megoldás változtatásokat követel meg a megfelelő szabvány. Néhány változtatásra szükség lehet az RDF tárolóknál, amelyek támogatják a következtetés csatlakoztatását, de addig a Singleton Property-t egyszerűen úgy lehet kezelni, mint egy újabb modellezési technikát.

V.1.2. A reifikáció helyesen

A kevésbé naiv megközelítések abból a felismerésből fakadnak, hogy a tulajdonságpéldányok teljes mértékben tripletekből példányosíthatók. Ha képesek vagyunk valamit mondani a tripletekről, akkor képesek leszünk a tulajdonságpéldányokról is beszélni.

Ezek közül a megközelítések közül a legszilárdabb — RDF*, más néven RDR, amely a Blazegraph méhéből született. Ezt már a kezdetektől választotta maga és az AnzoGraph. A megközelítés szilárdsága abban rejlik, hogy ennek keretein belül kínálják a megfelelő változtatásokat végrehajtják az RDF szemantikában.A lényege azonban rendkívül egyszerű. Az RDF Turtle-sorozatban ezentúl körülbelül így lehet írni:

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

V.1.3. Egyéb megközelítések

Nincs szükség a formális szemantika túlbonyolítására, egyszerűen úgy lehet tekinteni, hogy a tripleteknek vannak bizonyos azonosítóik, amelyek természetesen URI-k, és új tripleteket lehet alkotni ezekkel az URI-kkal. Csak hozzáférést kell biztosítani ezekhez az URI-khez SPARQL-ban. Így belső forrásoktól Stardog.

Az Allegrograph válaszkompromisszumot kötöttek köztes úton. Ismert, hogy a tripletek azonosítói az Allegrograph-ban tartalmaz, de a triple attributes külső megvalósításakor nem látszanak. Azonban a formális szemantikától is nagyon messze vannak. Figyelemre méltó, hogy a triplet attribútumok nem URI-k, és ezeknek az attribútumoknak az értékei is csak literálok lehetnek. Az LPG támogatói pontosan azt kapják, amit akartak. Egy különösen kitalált NQX formátumban a fenti RDF*-alapú példához hasonló példa így néz ki:

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

V.2. Lekérdezési nyelvek

Annak érdekében, hogy a model szintjén bármilyen módon támogassuk az LPG-t, lehetőséget kell biztosítani az adatok lekérdezésére egy ilyen modellben.

A Blazegraph az RDF* lekérdezésekhez támogatja a SPARQL*-t. és GremlinA SPARQL* lekérdezés így néz ki:

 SELECT * { <> :since ?since }

Az AnzoGraph is támogatja SPARQL*-t. és támogatni akarja a Cypher-t, a lekérdezési nyelvet a Neo4j-ban.
A Stardog saját kiterjesztés SPARQL-ját támogatja, és még mindig a Gremlin-t. A SPARQL-ban a triplet URI és a "meta-információ" lekérdezéséhez körülbelül a következő struktúrával lehet hozzájutni:

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

Az Allegrograph is támogatja saját kiterjesztés SPARQL-ját:

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

Egyébként a GraphDB egy időben a Tinkerpop/Gremlin-t támogatta, anélkül, hogy támogatta volna az LPG-t, de a 8.0 vagy 8.1 verzióban ez megszűnt.

VI. A licenszek szigorítása

A közelmúltban nem történt semmiféle növekedés a "triplestore of choice" és az "open source triplestore" metszéspontjában. Az új, nyílt forráskódú RDF-tárolók messze vannak attól, hogy jó választásnak számítsanak a mindennapi használatra, és az új RDF-tárolók forráskódja, amelyeket szeretnénk használni (például AnzoGraph), zárva van. Inkább csökkentésekről lehet beszélni...

Természetesen a korábban nyílt forráskód nem válik lezárttá, de néhány nyílt forráskódú tároló fokozatosan már nem számít kelendő választásnak. A Virtuoso, amelynek van nyílt forrású kiadása, véleményem szerint bugoktól hemzseg. A Blazegraph-ot megvette az AWS, és az Amazon Neptune alapját képezi; most már nem világos, hogy lesz-e még egy kiadás. Csak a Jena marad...

Ha a nyílt forráskód nem túl fontos, és egyszerűen csak ki szeretnénk próbálni, akkor a helyzet is kevésbé derűs, mint korábban. Például:

Stardog leállítja ingyenes verziót kínál (bár a szokásos próbaidőszak kétszeresére nőtt);
be. GraphDB Cloud, ahol korábban választhattunk egy ingyenes alapcsomagot, új felhasználók regisztrációja felfüggesztve.

Összességében a hétköznapi IT-felhasználó számára a világűr egyre elérhetetlenebbé válik, felfedezése a cégek privilégiumává válik.

Forrás: habr.com