ProHoster > Log > Internett-nyheter > Hva skjer med RDF-depoter nå?

Hva skjer med RDF-depoter nå?

Det semantiske nettet og koblede data er som verdensrommet: det er ikke noe liv der. Å dra dit for en mer eller mindre lang periode... Jeg vet ikke hva de sa til deg som barn som svar på «Jeg vil bli astronaut». Men du kan observere hva som skjer mens du er på jorden; Det er mye lettere å bli en amatørastronom eller til og med en profesjonell.

Artikkelen vil fokusere på nylige, ikke eldre enn flere måneder, trender fra verden av RDF-lagring. Metaforen i første avsnitt er inspirert av det episke reklamebildet under snittet.


Episk bilde

Hva skjer med RDF-depoter nå?

I. GraphQL for RDF-tilgang

De sierat GraphQL har som mål å bli et universelt databasetilgangsspråk. Hva med muligheten til å få tilgang til RDF ved hjelp av GraphQL?

Ut av boksen er denne muligheten gitt av:

Hvis depotet ikke tilbyr en slik funksjon, kan det implementeres uavhengig ved å skrive en passende "resolver". Dette gjorde de for eksempel i det franske prosjektet Dataturisme. Eller du kan ikke lenger skrive noe, men bare ta HyperGraphQL.

Fra synspunktet til en ortodoks tilhenger av Semantic Web og Linked Data, er alt dette selvfølgelig trist, siden det virker designet for integrasjoner bygget rundt neste datasilo, og ikke egnede plattformer (RDF-butikker, selvfølgelig) .

Inntrykkene fra å sammenligne GraphQL med SPARQL er todelt.

  • På den ene siden ser GraphQL ut som en fjern slektning av SPARQL: den løser problemene med resampling og mangfoldet av spørringer som er typiske for REST - uten hvilke det sannsynligvis ikke ville vært mulig å vurdere spørrespråk, i det minste for nettet;
  • På den annen side er det stive skjemaet til GraphQL skuffende. Følgelig virker dens "introspektivitet" veldig begrenset sammenlignet med RDFs fulle refleksivitet. Og det er ingen analog av eiendomsstier, så det er ikke engang veldig klart hvorfor det er "Graph-".

II. Adaptere for MongoDB

En trend som komplementerer den forrige.

  • I Stardog nå kanskje - spesielt alt på samme GraphQL - konfigurer kartleggingen av MongoDB-data til virtuelle RDF-grafer;
  • Ontotext GraphDB har nylig den lar sett inn fragmenter i SPARQL på MongoDB Query.

Hvis vi snakker bredere om adaptere til JSON-kilder, som lar mer eller mindre "on the fly" representere JSON lagret i disse kildene som RDF, kan vi huske den ganske langvarige SPARQL Generer, som kan justeres, for eksempel, til Apache Jena.

Ved å oppsummere de to første trendene kan vi si at RDF-lagre viser full beredskap for integrering og drift under forhold med "polyglot-utholdenhet". Det er imidlertid kjent at denne sistnevnte lenge har gått av moten, og blir erstattet av kommer multi-modell. Hva med multimodellering i en verden av RDF-lagring?

Kort sagt, ingen måte. Jeg vil gjerne dedikere en egen artikkel til temaet multi-modell DBMS-er, men foreløpig kan det bemerkes at det for øyeblikket ikke er noen multi-modell DBMS-er "basert" på en grafmodell (RDF kan betraktes som en type av det) . Noen små multimodelleringer - RDF-lagringsstøtte for en alternativ LPG-grafmodell - vil bli diskutert i seksjon V.

III. OLTP vs. OLAP

Imidlertid samme Gartner skriverat multimodell er en absolutt betingelse primært for operasjonsstuer DBMS. Dette er forståelig: i en situasjon med "multivariatlagring" oppstår hovedproblemene med transaksjonalitet.

Men hvor er RDF-lagringer plassert på OLTP-OLAP-skalaen? Jeg ville svare på denne måten: verken der eller her. For å indikere hva de er ment for, trengs en tredje forkortelse. Som et alternativ vil jeg foreslå OLIP — Online intellektuell behandling.

Men fortsatt:

  • integrasjonsmekanismene med MongoDB implementert i GraphDB er ikke minst tiltenkt å omgå skriveytelsesproblemer;
  • Stardog går enda lenger og fullstendig omskriver motor, igjen med mål om å forbedre opptaksytelsen.

La meg nå introdusere en ny aktør på markedet. Fra skaperne av IBM Netezza og Amazon Redshift - AnzoGraph™. Et bilde fra en annonse for et produkt basert på det ble lagt ut i begynnelsen av artikkelen. AnzoGraph posisjonerer seg som en GOLAP-løsning. Hvordan liker du SPARQL med vindusfunksjoner? —

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

IV. RocksDB

Allerede høyere det var en link til kunngjøringen av Stardog 7 Beta, som sa at Stardog skulle bruke RocksDB som et underliggende lagringssystem - en nøkkelverdibutikk, en Facebook-gaffel av Googles LevelDB. Hvorfor er det verdt å snakke om en viss trend?

For det første å dømme etter Wikipedia-artikkel, ikke bare RDF-lager blir "transplantert" til RocksDB. Det er prosjekter for å bruke RocksDB som en lagringsmotor i ArangoDB, MongoDB, MySQL og MariaDB, Cassandra.

For det andre opprettes prosjekter (det vil si ikke produkter) om relevante emner på RocksDB.

For eksempel bruker eBay RocksDB i plattform for din "kunnskapsgraf". Det er forresten morsomt å lese: spørringsspråket startet som et hjemmedyrket format, men i senere tid har det gått over til å bli mye mer likt SPARQL. Som i spøken: uansett hvor mye kunnskapsgraf vi lager, ender vi likevel opp med RDF.

Et annet eksempel - et som dukket opp for noen måneder siden Wikidata History Query Service. Før introduksjonen måtte Wikidatas historisk informasjon nås gjennom MWAPI til standard Mediawiki API. Nå er mye mulig med ren SPARQL. "Under panseret" er det også RocksDB. Forresten, WDHQS ble laget, ser det ut til, av personen som importerte Freebase til Google Knowledge Graph.

V. LPG-støtte

La meg minne deg om hovedforskjellen mellom LPG-grafer og RDF-grafer.

I LPG kan skalære egenskaper tilordnes til kantforekomster, mens de i RDF kun kan tildeles kant-"typer" (men ikke bare skalære egenskaper, men også vanlige forbindelser). Denne begrensningen av RDF sammenlignet med LPG overvinne en eller annen modelleringsteknikk. Begrensningene til LPG sammenlignet med RDF er vanskeligere å overkomme, men LPG-grafer er mer som bilder fra en Harari-lærebok enn RDF-grafer, og det er derfor folk vil ha dem.

Åpenbart faller oppgaven med "LPG-støtte" i to deler:

  1. å gjøre endringer i RDF-modellen som gjør det mulig å simulere LPG-strukturer i den;
  2. å gjøre endringer i RDF-spørringsspråket som gjør det mulig å få tilgang til data i denne modifiserte modellen, eller implementere muligheten til å gjøre spørringer til denne modellen på populære LPG-spørringsspråk.

V.1. Datamodell

Det er flere mulige tilnærminger her.

V.1.1. Singleton Eiendom

Den mest bokstavelige tilnærmingen til å harmonisere RDF og LPG er sannsynligvis singleton eiendom:

  • I stedet for for eksempel predikatet :isMarriedTo predikater brukes :isMarriedTo1, :isMarriedTo2 og t. d.
  • Disse predikatene blir deretter gjenstander for nye trillinger: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc.
  • Forbindelsen av disse forekomstene av predikater med et felles predikat er etablert av trillinger av formen :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Selvfølgelig, det rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, men tenk på hvorfor du ikke bare skal skrive :isMarriedTo1 rdf:type :isMarriedTo.

Problemet med "LPG-støtte" er løst her på RDFS-nivå. En slik avgjørelse krever inkludering i passende standard. Noen endringer kan være nødvendige for RDF-butikker som støtter vedleggskonsekvenser, men foreløpig kan Singleton Property betraktes som bare en annen modelleringsteknikk.

V.1.2. Reifikasjon gjort riktig

Mindre naive tilnærminger stammer fra erkjennelsen av at eiendomsforekomster er fullt instansierbare av trillinger. Ved å kunne si noe om trillinger vil vi kunne snakke om eiendomsinstanser.

Den mest robuste av disse tilnærmingene er RDF*, aka RDR, Født i dypet av Blazegraph. Det er helt fra begynnelsen valgt for deg selv og AnzoGraph. Soliditeten til tilnærmingen bestemmes av det faktum at innenfor rammen tilbys tilsvarende endringer i RDF semantikk. Poenget er imidlertid ekstremt enkelt. I Turtle-serialisering av RDF kan du nå skrive noe slikt:

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

V.1.3. Andre tilnærminger

Du kan ikke bry deg med formell semantikk, men ganske enkelt anta at tripletter har visse identifikatorer, som selvfølgelig er URIer, og lage nye tripletter med disse URIene. Alt som gjenstår er å gi tilgang til disse URIene i SPARQL. Så kommer Stardog.

I Allegrograph gikk på en mellom måte. Det er kjent at triplettidentifikatorer i Allegrograph det er, men når de implementerer trippelattributter, stikker de ikke ut. Det er imidlertid fortsatt veldig langt fra formell semantikk. Det er bemerkelsesverdig at triplettattributter ikke er URIer, og verdiene til disse attributtene kan også bare være bokstavelige. LPG-tilhengere får akkurat det de ønsket. I det spesialoppfunne NQX-formatet ser et eksempel som ligner på det ovenfor for RDF* slik ut:

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

V.2. Spørsmål

Etter å ha støttet LPG på en eller annen måte på modellnivå, må du gjøre det mulig å gjøre spørringer på data i en slik modell.

  • Blazegraph for RDF*-spørringer støtter SPARQL* и gremlin. Et SPARQL*-spørring ser slik ut:

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

  • Anzograph støtter også SPARQL* og kommer til å støtte Cypher, et spørrespråk i Neo4j.
  • Stardog støtter sine egne forlengelse SPARQL og en gang til Gremlin. Du kan få triplett-URI og "meta-informasjon" i SPARQL ved å bruke noe som dette:

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

  • Allegrograph støtter også sine egne forlengelse SPARQL:

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

Forresten, GraphDB støttet en gang Tinkerpop/Gremlin uten å støtte LPG, men dette stoppet i versjon 8.0 eller 8.1.

VI. Innstramming av lisenser

Det har ikke vært noen nyere tillegg til skjæringspunktet mellom "triplestore of choice" og "open source triplestore" sett. De nye RDF-butikkene med åpen kildekode er langt fra å være et godt valg for hverdagsbruk, og de nye trippelbutikkene som jeg gjerne vil bruke (som AnzoGraph) er lukket kildekode. Vi kan heller snakke om reduksjoner...

Åpen kildekode har selvfølgelig ikke blitt stengt ned tidligere, men noen åpen kildekode-repositorier blir sakte ikke lenger sett på som verdt å velge. Virtuoso, som har en åpen kildekode-utgave, drukner etter min mening i feil. Blazegraph ble kjøpt av AWS og dannet grunnlaget for Amazon Neptun; nå er det uklart om det blir minst én utgivelse til. Bare Jena gjenstår...

Hvis åpen kildekode ikke er veldig viktig, men du bare vil prøve det, så er alt også mindre rosenrødt enn før. For eksempel:

  • Stardog stopper distribuer gratisversjonen (prøveperioden for den vanlige versjonen har imidlertid doblet seg);
  • в GraphDB Cloud, hvor du tidligere kunne velge en gratis grunnplan, har nye brukerregistreringer blitt suspendert.

Generelt, for den gjennomsnittlige IT-personen, blir plass mer og mer utilgjengelig; utviklingen av det blir bedriftens lodd.

Kilde: www.habr.com

Legg til en kommentar