ProHoster > Blog > administration > Hvad sker der med RDF-depoter nu?

Hvad sker der med RDF-depoter nu?

Det semantiske web og linkede data er som det nære rum: der er intet liv der. At være der i en mere eller mindre lang periode ... ja, jeg ved ikke, hvad man som barn fik at vide som svar på "Jeg vil være astronaut." Men man kan observere, hvad der sker, mens man er på Jorden; det er meget lettere at blive amatør eller endda professionel astronom.

Artiklen vil diskutere nye, ikke ældre end et par måneder, trends fra RDF-lagringens verden. Metaforen i første afsnit var inspireret af et reklamebillede i episk størrelse under udskæringen.


episk billede

Hvad sker der med RDF-depoter nu?

I. GraphQL til RDF-adgang

De sigerat GraphQL hævder at være det universelle databaseadgangssprog. Og hvad med muligheden for at få adgang ved hjælp af GraphQL til RDF?

Ud af boksen leveres denne mulighed af:

Hvis depotet ikke giver en sådan mulighed, implementeres det uafhængigt ved at skrive den passende "resolver" (resolver). Det blev for eksempel gjort i det franske projekt Dataturisme. Eller du kan allerede ikke skrive noget, men bare tage HyperGraphQL.

Fra synspunktet af en ortodoks tilhænger af Semantic Web og Linked Data, er alt dette selvfølgelig trist, da det ser ud til at være beregnet til integrationer bygget omkring den næste datasilo, og ikke egnede platforme (naturligvis RDF-butikker) .

Indtrykkene fra at sammenligne GraphQL med SPARQL er dobbelte.

  • På den ene side ligner GraphQL en fjern slægtning til SPARQL: den løser problemerne med genvalg og flere forespørgsler, der er typiske for REST - uden hvilke det sandsynligvis ikke ville være muligt at overveje forespørgselssprog, i det mindste for nettet;
  • På den anden side forstyrrer det stive skema af GraphQL. Følgelig synes dens "introspektivitet" at være meget begrænset sammenlignet med RDF's fulde refleksivitet. Og der er ingen analog af ejendomsstier, så det er ikke engang meget klart, hvorfor det er "Graph-".

II. Adaptere til MongoDB

En trend, der supplerer den forrige.

  • i Stardog nu måske - især alle på den samme GraphQL - konfigurer visningen af ​​MongoDB-data til virtuelle RDF-grafer;
  • GraphDB har for nylig Det gør det muligt indsæt i SPARQL-fragmenter på MongoDB Query.

Hvis vi taler mere bredt, om adaptere til JSON-kilder, der tillader mere eller mindre "on the fly" at repræsentere JSON'en, der er lagret i disse kilder som RDF, så kan vi også huske den eksisterende i et stykke tid SPARQL Generersom kan justeres for eksempel, til Apache Jena.

Sammenfattende de to første tendenser kan vi sige, at RDF-depoter viser fuld klarhed til integration og funktion under forhold med "multiple storage" (polyglot persistens). Det er dog kendt, at sidstnævnte længe har været ude af mode, og at erstatte det kommer multi-modellering. Og hvad med multi-modellering i en verden af ​​RDF-opbevaring?

Kort sagt, ingen måde. Jeg vil gerne afsætte en separat artikel til emnet multi-model DBMS, men for nu kan du se, at der ikke er nogen multi-model DBMS "baseret" på grafmodellen (RDF kan betragtes som en variation af det) nu. Nogle små multimodelleringer - understøttet af RDF-lager af en alternativ LPG-grafmodel - vil blive diskuteret i Afsnit V.

III. OLTP vs. OLAP

Dog samme Gartner skriverat multimodellering er en ufravigelig betingelse primært for operationsstuer DBMS. Dette er forståeligt: ​​I en situation med "multiple storage" opstår hovedproblemerne med transaktionalitet.

Men hvor på OLTP-OLAP-skalaen er RDF-depoter? Jeg ville svare sådan her: hverken der eller her. For at angive, hvad de er beregnet til, er der brug for en tredje forkortelse. Som en mulighed vil jeg foreslå OLIP — Online intellektuel bearbejdning.

Dog stadig:

  • integrationsmekanismerne implementeret i GraphDB med MongoDB er ikke de mindste tilsigtet at omgå skriveydelsesproblemer;
  • Stardog går endnu længere og fuldstændigt omskriver motor, igen med det mål at forbedre skriveydelsen.

Lad mig nu introducere en ny spiller på markedet. Fra skaberne af IBM Netezza og Amazon Redshift — AnzoGraph. Et billede fra en annonce for et produkt baseret på det blev placeret i begyndelsen af ​​artiklen. AnzoGraph positionerer sig som en GOLAP-løsning. Hvordan kan du lide SPARQL med vinduesfunktioner? —

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

IV. RocksDB

Allerede ovenover der var et link til annonceringen af ​​Stardog 7 Beta, som sagde, at Stardog ville bruge RocksDB som et underliggende lagringssystem - nøgleværdi-lagring, Facebooks fork af Googles LevelDB. Hvorfor er det værd at tale om en bestemt tendens?

Først at dømme efter Wikipedia artikel, ikke kun RDF-depoter "transplanteres" til RocksDB. Der er projekter for at bruge RocksDB som en lagringsmotor i ArangoDB, MongoDB, MySQL og MariaDB, Cassandra.

For det andet laves projekter (det vil sige ikke produkter) af det tilsvarende emne på RocksDB.

For eksempel bruger eBay RocksDB i platform for din "vidensgraf". Det er i øvrigt sjovt at læse: forespørgselssproget startede som et hjemmedyrket format, men på det seneste er det gået over til at være meget mere som SPARQL. Som i en joke: uanset hvor meget viden graf vi laver, får vi stadig RDF.

Et andet eksempel - dukkede op for et par måneder siden Wikidata History Query Service. Inden introduktionen skulle Wikidatas historiske oplysninger tilgås via MWAPI til standard Mediawiki API. Meget er nu muligt i ren SPARQL. "Under motorhjelmen" er der også RocksDB. Forresten, WDHQS gjorde det, det ligner den person, der er involveret i at importere Freebase til Google Knowledge Graph.

V. LPG-støtte

Lad mig minde dig om den største forskel mellem LPG-grafer og RDF-grafer.

I LPG kan skalære egenskaber knyttes til kantforekomster, mens de i RDF kun kan knyttes til kant-"typer" (men ikke kun skalaregenskaber, men også almindelige links). Denne begrænsning af RDF sammenlignet med LPG overvinde en form for modelleringsteknik. Begrænsningerne ved LPG sammenlignet med RDF er sværere at overvinde, men LPG-grafer ligner mere billeder fra Hararis lærebog end RDF-grafer, så folk vil have dem.

Det er klart, at opgaven med at "støtte LPG" falder i to dele:

  1. foretage ændringer i RDF-modellen, der gør det muligt at simulere LPG-konstruktioner i den;
  2. at foretage ændringer i RDF-forespørgselssproget, der gør det muligt at få adgang til data i denne modificerede model, eller implementering af muligheden for at forespørge denne model i populære LPG-forespørgselssprog.

V.1. Data model

Der er flere mulige tilgange her.

V.1.1. singleton ejendom

Den mest bogstavelige tilgang til harmonisering af RDF og LPG er sandsynligvis singleton ejendom:

  • I stedet for for eksempel prædikatet :isMarriedTo prædikater bruges :isMarriedTo1, :isMarriedTo2 og t. d.
  • Disse prædikater bliver derefter emner for nye trillinger: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc.
  • Forbindelsen mellem disse forekomster af prædikater med et fælles prædikat er etableret ved hjælp af tripletter af formen :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Det er klart, at rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, men overvej hvorfor du ikke bare skal skrive :isMarriedTo1 rdf:type :isMarriedTo.

Opgaven med "LPG support" løses her på RDFS niveau. En sådan afgørelse kræver inddragelse i det relevante standard. Nogle ændringer kan være nødvendige fra RDF-depoter, der understøtter vedhæftede konsekvenser, men indtil videre kan Singleton Property opfattes som blot en anden modelleringsteknik.

V.1.2. Reifikation udført rigtigt

Mindre naive tilgange stammer fra erkendelsen af, at ejendomsforekomster er perfekt instansieret af trillinger. Ved at kunne tale om trillinger kan vi også tale om ejendomsinstanser.

Den mest solide af disse tilgange er RDF*aka RDR, Født i Blazegraphs tarme. Det er fra starten valgt for mig selv og AnzoGraph. Soliditeten af ​​tilgangen bestemmes af, at inden for dens rammer tilbydes tilsvarende ændringer i RDF semantik. Pointen er dog ekstremt enkel. I RDF Turtle serialisering kan du nu skrive noget som dette:

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

V.1.3. Andre tilgange

Du kan ikke bøvle med formel semantik, men blot overveje, at tripletterne har nogle identifikatorer, som selvfølgelig er URI'er, og komponer nye tripletter med disse URI'er. Tilbage er kun at give adgang til disse URI'er i SPARQL. Så ankommer stjernehund.

I Allegrograf gik på en mellem måde. Det er kendt, at identifikatorerne for tripletter i Allegrograph Der er, men når tredobbelte attributter implementeres, stikker de ikke ud. Men selv formel semantik er meget langt væk. Navnlig er triplet-attributter ikke URI'er, og værdierne af disse attributter kan også kun være bogstavelige. LPG-tilhængere får præcis, hvad de ønskede. I det specielt opfundne NQX-format ser et eksempel svarende til det ovenfor for RDF* således ud:

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

V.2. Forespørgselssprog

Efter at have understøttet LPG på den ene eller anden måde på modelniveau, skal du gøre det muligt at forespørge data i en sådan model.

  • Blazegraph for RDF*-forespørgsler understøtter SPARQL* и Gremlin. En SPARQL*-forespørgsel ser sådan ud:

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

  • Anzograph understøtter også SPARQL* og vil støtte Cypher, forespørgselssproget i Neo4j.
  • Stardog opretholder sin egen udvidelse SPARQL og en gang til Gremlin. Du kan få URI'en for en triplet og "metainformation" i SPARQL ved at bruge noget som dette:

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

  • Allegrograph understøtter også sin egen udvidelse SPARQL:

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

GraphDB understøttede i øvrigt Tinkerpop/Gremlin på én gang uden at understøtte LPG, men det stoppede i version 8.0 eller 8.1.

VI. Stramning af licenser

Der har ikke været nogen tilføjelser til krydsfeltet mellem "triplestore of choice" og "open source triplestore"-sættene på det seneste. Nye open source RDF-lagre er langt fra et godt valg til daglig brug, og kildekoden til nye RDF-lagre, som vi gerne vil bruge (den samme AnzoGraph), er lukket. Vi kan snarere endda tale om subtraktioner...

Selvfølgelig er tidligere open source ikke lukket, men nogle open source-depoter anses efterhånden ikke længere for at være værdige til at vælge. Virtuoso, som har en open source-udgave, er efter min mening ved at drukne i fejl. Blazegraph købt af AWS og dannede grundlaget for Amazon Neptun; nu er det ikke klart, om der kommer mindst én udgivelse mere. Kun Jenna er tilbage...

Hvis open source ikke er særlig vigtig, men du bare vil prøve, så er alt også mindre rosenrødt end før. For eksempel:

  • Stjernehund stopper distribuer den gratis version (prøveperioden for den almindelige er dog fordoblet);
  • в GraphDB Cloud, hvor man tidligere kunne vælge en gratis basisplan, har suspenderet nye brugerregistreringer.

Generelt bliver plads mere og mere utilgængelig for en almindelig it-lægmand, dets udvikling bliver virksomhedernes lod.

Kilde: www.habr.com

Tilføj en kommentar