ProHoster > Blog > Administración > Que está a pasar agora cos repositorios RDF?

Que está a pasar agora cos repositorios RDF?

A web semántica e os datos enlazados son coma o espazo exterior: alí non hai vida. Ir alí durante calquera período de tempo... ben, non sei que che dicían de neno cando dicías: "Quero ser astronauta". Pero podes observar o que está a suceder desde a Terra; converterse en astrónomo afeccionado ou mesmo profesional é moito máis doado.

Este artigo tratará as tendencias recentes no mundo do almacenamento RDF, que non teñen máis duns meses de antigüidade. A metáfora do primeiro parágrafo inspirouse na imaxe promocional de tamaño épico que hai debaixo do corte.


Imaxe épica

Que está a pasar agora cos repositorios RDF?

I. GraphQL para acceso RDF

Eles dinque GraphQL pretende converterse nunha linguaxe de acceso universal a bases de datos. Que pasa coa posibilidade de acceder a RDF usando GraphQL?

Fóra da caixa esta oportunidade é ofrecida por:

Se o repositorio non ofrece tal oportunidade, pódese implementar de forma independente escribindo un "resolvedor" adecuado. Isto é o que fixeron, por exemplo, no proxecto francés Turismo de datos. Ou xa non podes escribir nada, senón tomar HyperGraphQL.

Desde o punto de vista dun ortodoxo adepto da Web Semántica e dos Datos Enlazados, todo isto, por suposto, é triste, xa que parece pensado para integracións construídas arredor do próximo silo de datos, e plataformas non axeitadas (tendas RDF, claro). .

As impresións ao comparar GraphQL con SPARQL son dúas.

  • Por unha banda, GraphQL parece un parente afastado de SPARQL: resolve os problemas de remuestreo e multiplicidade de consultas típicos de REST -sen os cales, probablemente, non sería posible considerar. linguaxe de consulta, polo menos para a web;
  • Por outra banda, o esquema ríxido de GraphQL é decepcionante. En consecuencia, a súa "introspectividade" parece moi limitada en comparación coa reflexividade total de RDF. E non hai un análogo de camiños de propiedade, polo que nin sequera está moi claro por que é "Gráfico-".

II. Adaptadores para MongoDB

Unha tendencia complementaria á anterior.

  • en Stardog agora quizais - en particular, todos no mesmo GraphQL - configure a asignación de datos de MongoDB en gráficos RDF virtuais;
  • GraphDB recentemente permite inserir fragmentos en SPARQL en MongoDB Query.

Se falamos dun xeito máis amplo dos adaptadores a fontes JSON, que permiten representar máis ou menos "sobre a marcha" o JSON almacenado nestas fontes como RDF, podemos lembrar os de bastante longa data. Xerar SPARQL, que se pode axustar, por exemplo, a Apache Jena.

Resumindo as dúas primeiras tendencias, podemos dicir que os almacenamentos RDF demostran unha total disposición para a integración e o funcionamento en condicións de "persistencia políglota". Sábese, con todo, que este último pasou de moda hai tempo, e está sendo substituído por está chegando multimodelo. E o multimodelado no mundo do almacenamento RDF?

En resumo, de ningún xeito. Gustaríame dedicar un artigo aparte ao tema dos DBMS multimodelo, pero polo momento pódese sinalar que actualmente non hai DBMS multimodelo "baseados" nun modelo gráfico (RDF pódese considerar un tipo del). . Algúns pequenos modelos múltiples (soporte de almacenamento RDF para un modelo gráfico de GLP alternativo) serán discutidos en sección V.

III. OLTP vs. OLAP

Con todo, o mesmo Gartner escribeese multimodelo é unha condición sine qua non principalmente para quirófanos DBMS. Isto é comprensible: nunha situación de "almacenamento multivariante", os principais problemas xorden coa transaccionalidade.

Pero onde están os almacenamentos RDF situados na escala OLTP-OLAP? Eu contestaría deste xeito: nin alí nin aquí. Para indicar para que están destinados, é necesaria algunha terceira abreviatura. Como opción suxeriría OLIP — Procesamento intelectual en liña.

Con todo, aínda:

  • os mecanismos de integración con MongoDB implementados en GraphDB non son menos importantes destinado para solucionar problemas de rendemento da escritura;
  • Stardog vai aínda máis lonxe e completamente reescrituras motor, de novo co obxectivo de mellorar o rendemento da gravación.

Agora, permítanme presentarlles un novo actor no mercado. Dos creadores de IBM Netezza e Amazon Redshift, AnzoGraph. Ao comezo do artigo publicouse unha imaxe dun anuncio dun produto baseado nel. AnzoGraph sitúase como unha solución GOLAP. Como che gusta SPARQL coas funcións da fiestra? —

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

IV. RocksDB

Xa máis alto había unha ligazón ao anuncio de Stardog 7 Beta, que dicía que Stardog ía usar RocksDB como un sistema de almacenamento subxacente: unha tenda de valores clave, un fork de Facebook de LevelDB de Google. Por que paga a pena falar dunha determinada tendencia?

En primeiro lugar, a xulgar por Artigo da Wikipedia, non só os almacenamentos RDF son "transplantados" a RocksDB. Hai proxectos para usar RocksDB como motor de almacenamento en ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.

En segundo lugar, os proxectos (é dicir, non produtos) sobre temas relevantes créanse en RocksDB.

Por exemplo, eBay usa RocksDB en plataforma para o teu "gráfico de coñecemento". Por certo, é divertido ler: a linguaxe de consulta comezou como un formato casero, pero máis recentemente pasou a ser moito máis parecido a SPARQL. Como na broma: por moito gráfico de coñecemento que fagamos, aínda acabamos con RDF.

Outro exemplo - un que apareceu hai uns meses Servizo de consulta de historial de Wikidata. Antes da súa introdución, había que acceder á información histórica de Wikidata MWAPI á API estándar de Mediawiki. Agora é posible moito con SPARQL puro. "Debaixo do capó" tamén hai RocksDB. Por certo, WDHQS foi feito, ao parecer, pola persoa que importou Freebase no Google Knowledge Graph.

V. Soporte de GLP

Permíteme lembrarche a principal diferenza entre os gráficos GLP e os gráficos RDF.

En LPG, as propiedades escalares pódense asignar a instancias de borde, mentres que en RDF só se poden asignar a "tipos" de bordo (pero non só propiedades escalares, senón tamén conexións ordinarias). Esta limitación de RDF en comparación co GLP superar unha ou outra técnica de modelado. As limitacións do GLP en comparación co RDF son máis difíciles de superar, pero os gráficos de GLP parécense máis a imaxes dun libro de texto de Harari que os gráficos RDF, polo que a xente quere.

Obviamente, a tarefa de "soporte de GLP" divídese en dúas partes:

  1. realizar modificacións no modelo RDF que permitan simular estruturas de GLP nel;
  2. realizar cambios na linguaxe de consulta RDF que permitan acceder aos datos neste modelo modificado, ou implementar a posibilidade de realizar consultas a este modelo en linguaxes de consulta LPG populares.

V.1. Modelo de datos

Aquí hai varios enfoques posibles.

V.1.1. Propiedade Singleton

O enfoque máis literal para harmonizar RDF e GLP é probablemente propiedade singleton:

  • No canto de, por exemplo, o predicado :isMarriedTo utilízanse predicados :isMarriedTo1, :isMarriedTo2 eu t. d.
  • Estes predicados convértense entón en suxeitos de novos trillizos: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc
  • A conexión destas instancias de predicados cun predicado común establécese mediante trillizos da forma :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
  • Obviamente, rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, pero pensa por que non tes que escribir :isMarriedTo1 rdf:type :isMarriedTo.

O problema do "soporte de GLP" resólvese aquí a nivel RDFS. Tal decisión require a súa inclusión no correspondente estándar. É posible que se precisen algúns cambios para as tendas RDF que admiten as consecuencias, pero polo momento, Singleton Property pódese considerar só outra técnica de modelado.

V.1.2. Coificación feita ben

Os enfoques menos inxenuos derivan da conciencia de que as instancias de propiedade son totalmente instanciables por trillizos. Ao poder dicir algo sobre trillizos, poderemos falar de instancias de propiedade.

O máis robusto destes enfoques é RDF*, tamén coñecido como RDR, nacido nas profundidades de Blazegraph. É dende o principio elixidos para ti e para AnzoGraph. A solidez do enfoque está determinada polo feito de que dentro do seu marco ofrecido modificacións correspondentes en Semántica RDF. O punto, con todo, é extremadamente sinxelo. Na serialización Turtle de RDF agora podes escribir algo así:

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

V.1.3. Outros enfoques

Non pode molestarse coa semántica formal, senón simplemente asumir que os trillizos teñen certos identificadores, que son, por suposto, URIs, e crean novos trillizos con estes URI. Só queda dar acceso a estes URI en SPARQL. Entón chega Stardog.

En Alegrógrafo foi dun xeito intermedio. Sábese que os identificadores de triplete en Allegrograph ten, pero ao implementar atributos triplos non sobresaen. Porén, aínda está moi lonxe da semántica formal. Cabe destacar que os atributos tripletes non son URI e os valores destes atributos tamén poden ser literais. Os seguidores do GLP obteñen exactamente o que querían. No formato NQX especialmente inventado, un exemplo similar ao anterior para RDF* ten o seguinte aspecto:

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

V.2. Linguaxes de consulta

Tendo admitido a GLP dun xeito ou doutro a nivel de modelo, cómpre facer posible realizar consultas sobre os datos deste modelo.

  • Blazegraph para consultas RDF* admite SPARQL* и Gremlin. Unha consulta SPARQL* ten o seguinte aspecto:

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

  • Anzograph tamén admite SPARQL* e vai apoiar Cypher, unha linguaxe de consulta en Neo4j.
  • Stardog admite o seu expansión SPARQL e de novo Gremlin. Podes obter o URI do triplete e a "metainformación" en SPARQL usando algo así:

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

  • Allegrograph tamén admite o seu expansión SPARQL:

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

Por certo, GraphDB admitiu nun momento Tinkerpop/Gremlin sen soportar LPG, pero isto parou na versión 8.0 ou 8.1.

VI. Endurecemento das licenzas

Non houbo ningunha adición recente á intersección dos conxuntos "triplestore of choice" e "triplestore de código aberto". Os novos almacéns de datos RDF de código aberto están lonxe de converterse nunha opción viable para o uso diario, e o código fonte dos novos almacéns de datos RDF que nos gustaría usar (como AnzoGraph) está pechado. É máis probable que incluso houbese algunhas reducións...

Por suposto, o código aberto non se pechou no pasado, pero algúns repositorios de código aberto pouco a pouco xa non se consideran como a pena escoller. Virtuoso, que ten unha edición de código aberto, está, na miña opinión, afogando en erros. Blazegraph foi comprado por AWS e formou a base de Amazon Neptune; agora non está claro se haberá polo menos un lanzamento máis. Só queda Jena...

Se o código aberto non é moi importante, pero só queres probalo, entón todo tamén é menos bo que antes. Por exemplo:

  • Stardog para distribuír a versión gratuíta (non obstante, o período de proba da versión normal duplicouse);
  • в GraphDB Cloud, onde antes se podía escoller un plan básico gratuíto, suspendeu os rexistros de novos usuarios.

En xeral, para a persoa informática media, o espazo é cada vez máis inaccesible; o seu desenvolvemento estase a converter no lote das corporacións.

Fonte: www.habr.com

Engadir un comentario