Semantic Web en Linked Data zijn als de ruimte: er is geen leven. Om daar voor een min of meer lange termijn naartoe te gaan... Ik weet niet wat ze je als kind vertelden als reactie op "Ik wil astronaut worden." Maar je kunt kijken wat er gebeurt terwijl je op aarde bent; amateurastronoom of zelfs professional worden is veel gemakkelijker.
Het artikel zal zich richten op nieuwe, niet ouder dan een paar maanden, trends uit de wereld van RDF-opslag. De metafoor in de eerste alinea is geïnspireerd op een epische promotionele afbeelding onder de snit.
epische foto
I. GraphQL voor RDF-toegang
dat GraphQL beweert de universele taal voor databasetoegang te zijn. En hoe zit het met de mogelijkheid om via GraphQL toegang te krijgen tot RDF?
Out of the box wordt deze mogelijkheid geboden door:
- sterrenhond(, );
- TopQuadrant-producten (, ).
Als de repository een dergelijke mogelijkheid niet biedt, wordt deze onafhankelijk geïmplementeerd door de juiste "resolver" (resolver) te schrijven. Dit gebeurde bijvoorbeeld in het Franse project . Of je kunt al niets schrijven, maar gewoon meenemen .
Vanuit het oogpunt van een orthodoxe aanhanger van het Semantic Web en Linked Data is dit natuurlijk allemaal triest, aangezien het bedoeld lijkt voor integraties die zijn gebouwd rond de volgende datasilo, en niet voor geschikte platforms (natuurlijk RDF-opslag) .
De indrukken van het vergelijken van GraphQL met SPARQL zijn tweeledig.
- Aan de ene kant ziet GraphQL eruit als een verre verwant van SPARQL: het lost de problemen op van herselectie en meerdere queries die typisch zijn voor REST - zonder welke het waarschijnlijk niet mogelijk zou zijn om te overwegen vraag taal, althans voor het web;
- Aan de andere kant verstoort het rigide schema van GraphQL. Dienovereenkomstig lijkt de "introspectiviteit" ervan zeer beperkt te zijn in vergelijking met de volledige reflexiviteit van RDF. En er is geen analoog van eigendomspaden, dus het is niet eens erg duidelijk waarom het "Graph-" is.
II. Adapters voor MongoDB
Een trend die complementair is aan de vorige.
- Nu bij Stardog - in het bijzonder allemaal op dezelfde GraphQL - configureer de weergave van MongoDB-gegevens in virtuele RDF-grafieken;
- Ontotext GraphDB onlangs invoegen in SPARQL-fragmenten op MongoDB Query.
In bredere zin gesproken over adapters naar JSON-bronnen die het mogelijk maken om min of meer "on the fly" de JSON weer te geven die in deze bronnen is opgeslagen als RDF, dan kunnen we de bestaande ook al geruime tijd terugroepen die kan worden aangepast , naar Apache Jena.
Als we de eerste twee trends samenvatten, kunnen we zeggen dat RDF-repository's volledig gereed zijn voor integratie en functioneren in omstandigheden van "meervoudige opslag" (polyglotpersistentie). Het is echter bekend dat deze laatste al lang uit de mode is en deze moet vervangen multi-modellering. En hoe zit het met multi-modellering in de wereld van RDF-opslag?
Kortom, op geen enkele manier. Ik zou graag een apart artikel willen wijden aan het onderwerp van multi-model DBMS, maar voor nu kun je zien dat er nu geen multi-model DBMS "gebaseerd" is op het grafiekmodel (RDF kan als een variatie ervan worden beschouwd). Over enkele kleine multi-modellering - ondersteuning door RDF-opslag van een alternatief LPG-grafiekmodel - zal worden besproken in .
III. OLTP versus OLAP
Echter dezelfde Gartner dat multimodellering in de eerste plaats een conditio sine qua non is еационных DBMS. Dit is begrijpelijk: in een situatie van "meervoudige opslag" doen zich de belangrijkste problemen voor met de transactie.
Maar waar op de OLTP-OLAP-schaal zijn RDF-opslagplaatsen? Ik zou zo antwoorden: noch daar, noch hier. Om aan te geven waarvoor ze bedoeld zijn, is een derde afkorting nodig. Als optie zou ik voorstellen OLP — Online intellectuele verwerking.
Echter nog steeds:
- de integratiemechanismen die in GraphDB met MongoDB zijn geïmplementeerd, zijn niet de minste problemen met schrijfprestaties omzeilen;
- Stardog gaat nog verder en volledig engine, opnieuw met als doel de schrijfprestaties te verbeteren.
En laat me nu een nieuwe speler op de markt introduceren. Van de makers van IBM Netezza en Amazon Redshift - . Een afbeelding uit een advertentie voor een daarop gebaseerd product werd aan het begin van het artikel geplaatst. AnzoGraph positioneert zichzelf als een GOLAP-oplossing. Wat vind je van SPARQL met vensterfuncties? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RotsDB
Hierboven al naar de aankondiging van Stardog 7 Beta, waarin stond dat Stardog RocksDB zou gaan gebruiken als een onderliggend opslagsysteem - sleutel-waardeopslag, Facebook's vork van Google's LevelDB. Waarom is het de moeite waard om over een bepaalde trend te praten?
Ten eerste, te oordelen naar , worden niet alleen RDF-repositories "getransplanteerd" naar RocksDB. Er zijn projecten om RocksDB als opslagmotor te gebruiken in ArangoDB, MongoDB, MySQL en MariaDB, Cassandra.
Ten tweede worden projecten (dat wil zeggen geen producten) van het overeenkomstige onderwerp gemaakt op RocksDB.
eBay gebruikt bijvoorbeeld RocksDB in voor uw "kennisgrafiek". Overigens is het grappig om te lezen: de query-taal begon als een inlands formaat, maar meer recentelijk is het overgegaan om veel meer op SPARQL te lijken. Als grapje: het maakt niet uit hoeveel kennisgrafiek we doen, we krijgen nog steeds RDF.
Een ander voorbeeld - verscheen een paar maanden geleden . Voorafgaand aan de introductie moest de historische informatie van Wikidata toegankelijk zijn via naar de standaard Mediawiki API. Er is nu veel mogelijk in pure SPARQL. "Onder de motorkap" is er ook RocksDB. Trouwens, WDHQS deed het, het lijkt op de persoon die betrokken was bij het importeren van Freebase in de Google Knowledge Graph.
V. LPG-ondersteuning
Laat me u herinneren aan het belangrijkste verschil tussen LPG-grafieken en RDF-grafieken.
In LPG kunnen scalaire eigenschappen worden gekoppeld aan edge-instanties, terwijl ze in RDF alleen kunnen worden gekoppeld aan edge-"types" (maar niet alleen scalaire eigenschappen, maar ook gewone koppelingen). Deze beperking van RDF ten opzichte van LPG een soort modelleringstechniek. De beperkingen van LPG in vergelijking met RDF zijn moeilijker te overwinnen, maar LPG-grafieken lijken meer op afbeeldingen uit het leerboek van Harari dan op RDF-grafieken, dus mensen willen ze.
Het is duidelijk dat de taak van het "ondersteunen van LPG" in twee delen valt:
- het aanbrengen van wijzigingen in het RDF-model die het mogelijk maken om LPG-constructies erin te simuleren;
- het aanbrengen van wijzigingen in de RDF-querytaal die het mogelijk maken om toegang te krijgen tot gegevens in dit gewijzigde model, of de implementatie van de mogelijkheid om dit model te bevragen in populaire LPG-querytalen.
V.1. Gegevensmodel
Er zijn hier verschillende mogelijke benaderingen.
V.1.1. eenpersoons eigendom
De meest letterlijke benadering om RDF en LPG te harmoniseren is waarschijnlijk :
- In plaats van bijvoorbeeld het gezegde
:isMarriedTopredikaten worden gebruikt:isMarriedTo1,:isMarriedTo2en zo verder. д. - Deze predikaten worden dan onderwerpen van nieuwe drielingen:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateetc. - De verbinding van deze instanties van predikaten met een gemeenschappelijk predikaat wordt tot stand gebracht door triolen van de vorm
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Uiteraard de
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, maar overweeg waarom je niet gewoon zou moeten schrijven:isMarriedTo1 rdf:type :isMarriedTo.
De taak van "LPG-ondersteuning" is hier op RDFS-niveau opgelost. Een dergelijk besluit vereist opname in de relevante . Er zijn mogelijk enkele wijzigingen vereist in RDF-repository's die het koppelen van consequenties ondersteunen, maar voor nu kan Singleton Property worden beschouwd als gewoon een andere modelleringstechniek.
V.1.2. Reificatie goed gedaan
Minder naïeve benaderingen komen voort uit het besef dat eigenschapsexemplaren perfect worden geïnstantieerd door triolen. Door over drielingen te kunnen praten, kunnen we ook praten over eigendomsinstanties.
De meest solide van deze benaderingen is ook bekend als RDR, in de ingewanden van Blazegraph. Het is vanaf het begin voor mezelf en AnzoGraph. De degelijkheid van de aanpak wordt bepaald door het feit dat binnen haar kaders overeenkomstige veranderingen in . Het punt is echter uiterst eenvoudig. In RDF Turtle-serialisatie kun je nu zoiets als dit schrijven:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Andere benaderingen
Je kunt je niet druk maken om formele semantiek, maar bedenk gewoon dat de triplets een aantal identifiers hebben, wat natuurlijk URI's zijn, en stel nieuwe triplets samen met deze URI's. Het enige dat overblijft is om toegang te geven tot deze URI's in SPARQL. Dus sterrenhond.
In Allegrograaf op een tussenweg. Het is bekend dat de identifiers van drielingen in Allegrograph , maar wanneer drievoudige attributen zijn geïmplementeerd, steken ze niet uit. Maar zelfs formele semantiek is erg ver weg. Triplet-attributen zijn met name geen URI's en de waarden van deze attributen kunnen ook alleen letterlijke waarden zijn. LPG-aanhangers krijgen precies wat ze wilden. In het speciaal uitgevonden NQX-formaat ziet een voorbeeld dat lijkt op het voorbeeld hierboven voor RDF* er als volgt uit:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Vraag talen
Nadat u LPG op de een of andere manier op modelniveau hebt ondersteund, moet u het mogelijk maken om gegevens in zo'n model op te vragen.
- Blazegraph voor RDF*-query's ondersteunt и . Een SPARQL*-query ziet er als volgt uit:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph ondersteunt ook en gaat steunen , de zoektaal in Neo4j.
- Stardog handhaaft zijn eigen SPARQL en Gremlin. Je kunt de URI van een triplet en "meta-informatie" in SPARQL krijgen door zoiets als dit te gebruiken:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph ondersteunt ook zijn eigen SPARKL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Overigens ondersteunde GraphDB ooit Tinkerpop/Gremlin zonder LPG te ondersteunen, maar dat stopte in versie 8.0 of 8.1.
VI. Licenties aanscherpen
Er zijn geen recente toevoegingen aan de kruising van de sets "triplestore naar keuze" en "open source triplestore". Nieuwe open source RDF-winkels zijn verre van een goede keuze voor dagelijks gebruik, en de broncode voor nieuwe triple-winkels die ik zou willen gebruiken (bijvoorbeeld AnzoGraph) is gesloten. We kunnen eerder praten over kortingen ...
Natuurlijk is eerder open source niet gesloten, maar sommige open source-repository's worden langzamerhand niet meer als de moeite waard beschouwd. Virtuoso, dat een open source-editie heeft, verdrinkt naar mijn mening in bugs. Blazegraph gekocht door AWS en vormde de basis van Amazon Neptune; nu is het niet duidelijk of er nog minstens één release zal komen. Alleen Jenna blijft...
Als open source niet zo belangrijk is, maar je wilt het gewoon proberen, dan is alles ook minder rooskleurig dan voorheen. Bijvoorbeeld:
- Sterrenhond de gratis versie distribueren (de proefperiode van de reguliere versie is echter verdubbeld);
- в , waar u voorheen het gratis basisplan kon kiezen, wordt de registratie van nieuwe gebruikers opgeschort.
Over het algemeen wordt ruimte steeds ontoegankelijker voor een gewone IT-lek, de ontwikkeling ervan wordt het lot van bedrijven.
Bron: www.habr.com