De Semantic Web en Linked Data zijn vergelijkbaar met de nabijgelegen ruimte: daar is geen leven. Om er voor een meer of minder lange tijd naartoe te gaan... nou, ik weet niet wat ze je als kind zeiden toen je zei: 'ik wil astronaut worden'. Maar je kunt de gebeurtenissen volgen vanuit de aarde; een amateur- of zelfs professionele astronoom worden is veel eenvoudiger.
In dit artikel zullen de recente trends uit de wereld van RDF-opslagplekken besproken worden, die niet ouder zijn dan enkele maanden. De metafoor in de eerste alinea werd geïnspireerd door een epische reclameafbeelding onderaan.
Epische afbeelding
I. GraphQL voor toegang tot RDF
, dat GraphQL pretendeert de universele taal voor database toegang te worden. Hoe zit het echter met de mogelijkheid om toegang te krijgen tot RDF met GraphQL?
Deze mogelijkheid wordt "uit de doos" aangeboden door:
- Stardog (, );
- producten van TopQuadrant (, ).
Als de opslagplaats deze mogelijkheid niet biedt, kan je deze zelf implementeren door een passende "resolver" te schrijven. Zo hebben ze het bijvoorbeeld gedaan in het Franse project . Of je kunt nu gewoon gebruik maken van .
Vanuit het perspectief van een orthodoxe aanhanger van Semantic Web en Linked Data is dit natuurlijk treurig, omdat het lijkt te zijn bedoeld voor integraties die zijn opgebouwd rond nieuwe data silo's, en niet voor platformen (uiteraard RDF-opslagplaatsen).
De indrukken van de vergelijking tussen GraphQL en SPARQL blijven dubbelzinnig.
- Aan de ene kant lijkt GraphQL een verre verwant van SPARQL: het lost typische problemen van REST op zoals overselectie en meervoudige verzoeken — zonder dat, zou je waarschijnlijk niet kunnen worden beschouwd als een querytaal, zelfs niet voor het web;
- Aan de andere kant is het teleurstellend dat GraphQL zo rigide is in zijn schema. Daardoor lijkt de "introspectiviteit" ervan zeer beperkt in vergelijking met de volledige reflectiviteit van RDF. Er is ook geen equivalent voor property paths, waardoor het zelfs niet duidelijk is waarom het "Graph-" heet.
II. Adapters voor MongoDB
Een trend die complementair is aan de vorige.
- in Stardog nu — vooral allemaal op hetzelfde GraphQL — het instellen van datamapping van MongoDB in virtuele RDF-grafen;
- GraphDB staat sinds kort om fragmenten van MongoDB Query in SPARQL in te voegen.
Als we het breder hebben over adapters voor JSON-bronnen, die meer of minder "on-the-fly" de opgeslagen JSON in deze bronnen als RDF kunnen presenteren, kunnen we herinneren aan de al langere tijd bestaande , dat kan worden aangepast, , aan Apache Jena.
Samenvattend de eerste twee trends, kan worden gezegd dat RDF-opslagplaatsen volledig klaar zijn voor integraties en functioneren in omstandigheden van "polyglot persistence". Het is echter bekend dat deze laatste al lang niet meer in de mode is, en wordt vervangen door Als ik het kort samenvat, dan eigenlijk niet. Het onderwerp van multimodale databases verdient een apart artikel, voor nu kan worden opgemerkt dat er momenteel geen multimodale databases zijn "gebaseerd" op het grafmodel (een variant daarvan kan worden beschouwd als RDF). Er zal worden gesproken over een bepaalde kleine multimodelheid - de ondersteuning van RDF-opslagplaatsen voor een alternatieve grafmodel LPG - in
hoofdstuk V .
Toch schrijft hetzelfde Gartner
dat multimodelheid een sine qua non is in de eerste plaats voor databases. Dat is ook begrijpelijk: in een situatie van "polyglot persistence" ontstaan de belangrijkste problemen met transactiecapaciteit. Waar staan RDF-opslagplaatsen op de OLTP-OLAP schaal? Ik zou antwoorden: nergens. Voor het aanduiden van wat ze bedoeld zijn, is er een derde afkorting nodig. Als optie zou ik voorstellen OLIP
— Online Intellectuele Verwerking. Echter, de in GraphDB geimplementeerde integratiemechanismen met MongoDB zijn niet in de laatste plaats bedoeld
om problemen met schrijfprestaties te omzeilen;
- Stardog gaat zelfs verder en herschrijft volledig En nu, staat u mij toe om een nieuwe speler op de markt voor te stellen, van de makers van IBM Netezza en Amazon Redshift -
- AnzoGraph SELECT ?maand (COUNT(?gebeurtenis) OVER (PARTITION BY ?maand) AS ?gebeurtenissen) WHERE { … }
IV. RocksDB een verwijzing
naar de aankondiging van Stardog 7 Beta, waarin werd vermeld dat Stardog van plan is om RocksDB te gebruiken als onderliggende opslagoplossing - een "key-value" opslag, de Facebook-fork van Google’s LevelDB. Waarom zou men al moeten spreken van een bepaalde trend?Ten eerste, volgens
een artikel op Wikipedia over de aankondiging van Stardog 7 Beta, waarin werd vermeld dat Stardog RocksDB zal gebruiken als de onderliggende opslag — een ‘key-value’ opslag, een Facebook-fork van Google's LevelDB. Waarom is het al tijd om te spreken van een bepaalde trend?
Ten eerste, op basis van , wordt RocksDB niet alleen gebruikt door RDF-opslag. Er zijn projecten die RocksDB als opslagengine gebruiken in ArangoDB, MongoDB, MySQL en MariaDB, Cassandra.
Ten eerste worden er op RocksDB projecten (d.w.z. geen producten) van de desbetreffende thematiek gemaakt.
Bijvoorbeeld, eBay gebruikt RocksDB in voor zijn 'kennisgrafiek'. Trouwens, het is leuk om te lezen: de querytaal begon als een in-house formaat, maar recentelijk is het veel meer als SPARQL aan het worden.. Zoals in de grap: hoeveel knowledge graphs we ook maken, het blijft allemaal RDF.
Een ander voorbeeld is de onlangs gelanceerde . Voor zijn komst moest men voor historische gegevens van Wikidata terugvallen op via de standaard Mediawiki API. Nu is er veel mogelijk met pure SPARQL. 'Onder de motorkap' draait ook RocksDB. Overigens lijkt het erop dat WDHQS is ontwikkeld door iemand die zich bezig hield met de import van Freebase naar de Google Knowledge Graph.
V. Ondersteuning van LPG
Ik herinner me het belangrijkste verschil tussen LPG-graphen en RDF-graphen.
In LPG kunnen schalare eigenschappen aan exemplaren van randen worden toegevoegd, terwijl in RDF deze alleen aan 'typen' randen kunnen worden gekoppeld (daarentegen kunnen niet alleen schalare eigenschappen, maar ook gewone verbindingen worden gekoppeld). Deze beperking van RDF in vergelijking met LPG door verschillende modelingtechnieken. De beperking van LPG in vergelijking met RDF is moeilijker te overwinnen, maar LPG-graphen lijken meer op afbeeldingen uit het boek van Harari, daarom willen mensen ze.
Het is duidelijk dat de taak van 'ondersteuning van LPG' in twee delen valt:
- het aanbrengen van wijzigingen in het RDF-model die het mogelijk maken om LPG-constructies na te bootsen;
- het aanbrengen van wijzigingen in de querytaal van RDF die het mogelijk maken om gegevens in dit gewijzigde model op te vragen, of de mogelijkheid te implementeren om queries in populaire LPG-querytalen te doen.
V.1. Datastructuur
Hier zijn verschillende mogelijke benaderingen.
V.1.1. Singleton Property
De meest letterlijke aanpak om RDF en LPG te harmoniseren is waarschijnlijk :
- In plaats van bijvoorbeeld het predicaat
:isMarriedToworden de predikaten gebruikt::isMarriedTo1,:isMarriedTo2enz. - Vervolgens worden deze predikaten subjecten van nieuwe triplets:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateenz. - De verbinding tussen deze exemplaren van predikaten en het algemene predicaat wordt vastgesteld door triplets van het soort
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Het is duidelijk dat
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, maar denk na over waarom je niet gewoon moet schrijven:isMarriedTo1 rdf:type :isMarriedTo.
De taak van 'ondersteuning van LPG' wordt hier op het niveau van RDFS opgelost. Een dergelijke oplossing vereist wijzigingen in de desbetreffende Sommige wijzigingen kunnen vereist zijn van RDF-opslagplaatsen die de aansluiting van gevolgtrekkingen ondersteunen, en voorlopig kan Singleton Property eenvoudig worden gezien als weer een andere modelleertechniek.
V.1.2. Reificatie Goed Gedaan
Minder naïeve benaderingen voortkomen uit de erkenning dat eigenschapsinstanties volledig zijn geïnstantieerd door triplets. Door iets te kunnen zeggen over triplets, kunnen we ook iets zeggen over eigenschapsinstanties.
De meest robuuste van deze benaderingen is , ook wel RDR genoemd, in de schoot van Blazegraph. Vanaf het begin gekozen voor zichzelf en AnzoGraph. De robuustheid van de benadering wordt bepaald door het feit dat binnen het kader in . De essentie is echter zeer eenvoudig. In de Turtle-serialisatie van RDF kan nu ongeveer zo worden geschreven:
<> :since "2013-09-13"^^xsd:date .V.1.3. Overige benaderingen
Je kunt de formele semantiek negeren en gewoon aannemen dat triplets bepaalde identificatoren hebben, die natuurlijk URI's zijn, en nieuwe triplets samenstellen met deze URI's. Je hoeft alleen toegang te geven tot deze URI's in SPARQL. Zo Stardog.
In Allegrograph de tussenweg ingeslagen. Het is bekend dat triplet-identificatoren in Allegrograph , maar bij de implementatie van triple attributen komen ze niet naar buiten. Echter, de formele semantiek is nog ver weg. Opmerkelijk is dat triplet-attributen geen URI zijn, en de waarden van deze attributen kunnen ook slechts literalen zijn. Voorstanders van LPG krijgen precies wat ze wilden. In een speciaal uitgevonden formaat NQX lijkt een voorbeeld, vergelijkbaar met het bovenstaande voor RDF*, zo:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Taal voor aanvragen
Nadat LPG op de een of andere manier op modelniveau is ondersteund, moet er de mogelijkheid zijn om aanvragen voor gegevens in zo'n model te doen.
- Blazegraph ondersteunt voor aanvragen aan RDF* en . Een aanvraag op SPARQL* ziet er als volgt uit:
SELECT * { <> :since ?since }- Anzograph ondersteunt ook en is van plan om , de querytaal in Neo4j.
- Stardog ondersteunt zijn eigen SPARQL en Gremlin. Je kunt in SPARQL de URI van het triplet en "meta-informatie" verkrijgen met behulp van ongeveer de volgende constructie:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph ondersteunt ook zijn eigen SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Overigens heeft GraphDB een tijdlang Tinkerpop/Gremlin ondersteund, zonder LPG te ondersteunen, maar dit is in versie 8.0 of 8.1 gestopt.
VI. Verstrenging van licenties
Er zijn de laatste tijd geen toevoegingen geweest in de overlap tussen 'triplestore of choice' en 'open source triplestore'. Nieuwe RDF-opslagplaatsen met open source blijven ver verwijderd van een goede keuze voor dagelijks gebruik, en de broncode van nieuwe RDF-opslagplaatsen die men zou willen gebruiken (zoals AnzoGraph) is gesloten. Het lijkt eerder alsof er iets van afneemt…
Natuurlijk wordt open source niet gewoon gesloten, maar sommige opslagplaatsen met open source worden geleidelijk minder serieus overwogen als waardige keuze. Virtuoso, dat een opensource-editie heeft, lijkt naar mijn mening vol bugs te zitten. Blazegraph is gekocht door AWS en ligt ten grondslag aan Amazon Neptune; het is nu onduidelijk of er nog een andere release zal komen. Alleen Jena blijft over…
Als open source echter niet heel belangrijk is en je gewoon een proef wilt doen, dan ziet het er ook minder rooskleurig uit dan vroeger. Bijvoorbeeld:
- Stardog de verspreiding van de gratis versie gestopt (de proefperiode is echter wel verdubbeld);
- in , waar je eerder een gratis basisplan kon kiezen, is de registratie van nieuwe gebruikers stopgezet.
Al met al wordt de ruimte steeds minder toegankelijk voor de gewone IT-gebruiker, en het beheersen ervan is steeds meer het domein van bedrijven.
Bron: habr.com
