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

Hvad sker der med RDF-depoter nu?

Semantisk web og linkede data er som det ydre rum: der er intet liv der. At tage dertil i mere eller mindre lang sigt... Jeg ved ikke, hvad de fortalte dig som barn som svar på "Jeg vil blive astronaut." Men du kan se, hvad der sker, mens du er på Jorden; at blive amatørastronom eller endda professionel er meget nemmere.

Artiklen vil fokusere på friske, ikke ældre end et par måneder, trends fra RDF-opbevaringsverdenen. Metaforen i første afsnit er inspireret af et episk reklamebillede under snittet.


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.

  • Hos Stardog nu måske - især alle på den samme GraphQL - konfigurer visningen af ​​MongoDB-data til virtuelle RDF-grafer;
  • Ontotext GraphDB 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.

Og 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 nylige tilføjelser til skæringspunktet mellem "triplestore of choice" og "open source triplestore" sæt. Nye open source RDF-butikker er langt fra et godt valg til hverdagsbrug, og kildekoden til nye triple-butikker, som jeg gerne vil bruge (f.eks. AnzoGraph), er lukket. I stedet kan vi tale om reduktioner ...

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 du tidligere kunne vælge den gratis grundplan, er ny brugerregistrering suspenderet.

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