La Web Semántica y los Datos Vinculados son como el espacio exterior: no hay vida allí. Para ir allí por un tiempo más o menos largo… No sé qué te decían de niño en respuesta a “Quiero ser astronauta”. Pero puedes observar lo que sucede mientras estás en la Tierra; convertirse en un astrónomo aficionado o incluso en un profesional es mucho más fácil.
El artículo se centrará en tendencias recientes, de no más de unos pocos meses de antigüedad, del mundo del almacenamiento RDF. La metáfora del primer párrafo está inspirada en una épica imagen promocional bajo el corte.
foto épica
I. GraphQL para acceso RDF
que GraphQL afirma ser el lenguaje universal de acceso a bases de datos. ¿Y qué hay de la capacidad de acceder usando GraphQL a RDF?
Fuera de la caja, esta oportunidad es proporcionada por:
- perro estrella(, );
- Productos de TopQuadrant (, ).
Si el repositorio no brinda esa oportunidad, se implementa de forma independiente escribiendo el "resolver" (resolver) apropiado. Esto se hizo, por ejemplo, en el proyecto francés . O ya no puedes escribir nada, pero solo toma .
Desde el punto de vista de un seguidor ortodoxo de la Web Semántica y los Datos Vinculados, todo esto es, por supuesto, triste, ya que parece destinado a integraciones construidas en torno al próximo silo de datos y plataformas no adecuadas (por supuesto, almacenamientos RDF) .
Las impresiones de comparar GraphQL con SPARQL son dos.
- Por un lado, GraphQL parece un pariente lejano de SPARQL: resuelve los problemas de reselección y consultas múltiples típicos de REST, sin los cuales, probablemente, no sería posible considerar lenguaje de consulta, al menos para la web;
- Por otro lado, el rígido esquema de GraphQL trastorna. En consecuencia, su "introspección" parece ser muy limitada en comparación con la plena reflexividad de RDF. Y no hay un análogo de las rutas de propiedad, por lo que ni siquiera está muy claro por qué es "Graph-".
II. Adaptadores para MongoDB
Una tendencia complementaria a la anterior.
- En Stardog ahora - en particular, todo en el mismo GraphQL - configure la visualización de datos MongoDB en gráficos RDF virtuales;
- Ontotext GraphDB recientemente insertar en fragmentos SPARQL en MongoDB Query.
Hablando más ampliamente, sobre adaptadores a fuentes JSON que permiten más o menos "sobre la marcha" representar el JSON almacenado en estas fuentes como RDF, entonces también podemos recordar el existente durante bastante tiempo. que se puede ajustar , a Apache Jena.
Resumiendo las dos primeras tendencias, podemos decir que los repositorios RDF demuestran plena preparación para la integración y el funcionamiento en condiciones de "almacenamiento múltiple" (persistencia políglota). Se sabe, sin embargo, que este último ha pasado de moda durante mucho tiempo, y para reemplazarlo multi-modelado. ¿Y el multimodelado en el mundo del almacenamiento RDF?
En resumen, de ninguna manera. Me gustaría dedicar un artículo separado al tema de DBMS multimodelo, pero por ahora puede ver que no hay DBMS multimodelo "basados" en el modelo gráfico (RDF puede considerarse una variación de este) ahora. Algunos pequeños modelos múltiples (soporte de almacenamientos RDF de un modelo de gráfico LPG alternativo) se discutirán en .
tercero OLTP frente a OLAP
Sin embargo, el mismo Gartner que el multi-modelado es una condición sine qua non principalmente para quirófanos SGBD. Esto es comprensible: en una situación de “almacenamiento múltiple”, los principales problemas surgen con la transaccionalidad.
Pero, ¿en qué parte de la escala OLTP-OLAP se encuentran los repositorios RDF? Yo respondería así: ni allá ni aquí. Para indicar para qué están destinados, se necesita una tercera abreviatura. Como opción te sugiero OLIP — Tramitación Intelectual en Línea.
Sin embargo, todavía:
- los mecanismos de integración implementados en GraphDB con MongoDB no son los menos importantes para evitar problemas de rendimiento de escritura;
- Stardog va aún más allá y completamente motor, de nuevo con el objetivo de mejorar el rendimiento de escritura.
Y ahora permítanme presentarles un nuevo jugador al mercado. De los creadores de IBM Netezza y Amazon Redshift: . Al comienzo del artículo se colocó una imagen de un anuncio de un producto basado en él. AnzoGraph se posiciona como una solución GOLAP. ¿Qué le parece SPARQL con funciones de ventana? —
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }IV. RocasDB
Arriba ya al anuncio de Stardog 7 Beta, que decía que Stardog iba a usar RocksDB como un sistema de almacenamiento subyacente: almacenamiento de valores clave, la bifurcación de Facebook de LevelDB de Google. ¿Por qué vale la pena hablar de cierta tendencia?
Primero, a juzgar por , no solo los repositorios RDF se "trasplantan" a RocksDB. Hay proyectos para utilizar RocksDB como motor de almacenamiento en ArangoDB, MongoDB, MySQL y MariaDB, Cassandra.
En segundo lugar, los proyectos (es decir, no productos) de la materia correspondiente se realizan en RocksDB.
Por ejemplo, eBay usa RocksDB en para su "gráfico de conocimiento". Por cierto, es divertido leer: el lenguaje de consulta comenzó como un formato propio, pero más recientemente ha estado en transición para parecerse mucho más a SPARQL. Como en una broma: no importa cuánto gráfico de conocimiento hagamos, todavía obtenemos RDF.
Otro ejemplo - apareció hace unos meses . Antes de su introducción, se tenía que acceder a la información histórica de Wikidata a través de a la API estándar de Mediawiki. Mucho es ahora posible en puro SPARQL. "Bajo el capó" también está RocksDB. Por cierto, WDHQS lo hizo, parece la persona involucrada en la importación de Freebase a Google Knowledge Graph.
V. Soporte GLP
Permítame recordarle la principal diferencia entre los gráficos LPG y los gráficos RDF.
En LPG, las propiedades escalares se pueden adjuntar a instancias de borde, mientras que en RDF solo se pueden adjuntar a "tipos" de borde (pero no solo propiedades escalares, sino también enlaces ordinarios). Esta limitación de RDF en comparación con GLP algún tipo de técnica de modelado. Las limitaciones de LPG en comparación con RDF son más difíciles de superar, pero los gráficos de LPG se parecen más a las imágenes del libro de texto de Harari que a los gráficos de RDF, por lo que la gente los quiere.
Obviamente, la tarea de "apoyar al GLP" se divide en dos partes:
- realizar cambios en el modelo RDF que permitan simular construcciones LPG en él;
- realizar cambios en el lenguaje de consulta RDF que hacen posible acceder a datos en este modelo modificado, o la implementación de la capacidad de consultar este modelo en lenguajes de consulta LPG populares.
V.1. Modelo de datos
Hay varios enfoques posibles aquí.
V.1.1. propiedad única
El enfoque más literal para armonizar CDR y GLP es probablemente :
- En lugar de, por ejemplo, el predicado
:isMarriedTose utilizan predicados:isMarriedTo1,:isMarriedTo2etcétera - Estos predicados se convierten entonces en sujetos de nuevos tripletes:
:isMarriedTo1 :since "2013-09-13"^^xsd:dateetcétera - La conexión de estas instancias de predicados con un predicado común se establece mediante tripletas de la forma
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Obviamente, la
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, pero considera por qué no deberías simplemente escribir:isMarriedTo1 rdf:type :isMarriedTo.
La tarea de "soporte LPG" se resuelve aquí en el nivel RDFS. Tal decisión requiere la inclusión en el correspondiente . Es posible que se requieran algunos cambios de los repositorios RDF que admiten las consecuencias adjuntas, pero por ahora, la propiedad Singleton puede considerarse simplemente como otra técnica de modelado.
V.1.2. Cosificación bien hecha
Los enfoques menos ingenuos se derivan de la comprensión de que las instancias de propiedad están perfectamente ejemplificadas por tripletes. Al poder hablar de trillizos, también podemos hablar de instancias de propiedad.
El más sólido de estos enfoques es también conocido como RDR, en las entrañas de Blazegraph. es desde el principio para mí y para AnzoGraph. La solidez del enfoque está determinada por el hecho de que en su marco cambios correspondientes en . El punto, sin embargo, es extremadamente simple. En la serialización RDF Turtle, ahora puede escribir algo como esto:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .V.1.3. Otros enfoques
No puede molestarse con la semántica formal, simplemente considere que los tripletes tienen algunos identificadores, que, por supuesto, son URI, y compone nuevos tripletes con estos URI. Solo queda dar acceso a estas URIs en SPARQL. Entonces perro estrella
en alegrografo de manera intermedia. Se sabe que los identificadores de trillizos en Allegrograph , pero cuando se implementan atributos triples, no sobresalen. Sin embargo, incluso la semántica formal está muy lejos. En particular, los atributos de triplete no son URI, y los valores de estos atributos también pueden ser solo literales. Los partidarios del GLP obtienen exactamente lo que querían. En el formato NQX especialmente inventado, un ejemplo similar al anterior para RDF* se ve así:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Idiomas de consulta
Habiendo admitido LPG de una forma u otra a nivel de modelo, debe hacer posible la consulta de datos en dicho modelo.
- Soporte de consultas Blazegraph para RDF* и . Una consulta SPARQL* se ve así:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }- Anzograph también es compatible y va a apoyar , el lenguaje de consulta en Neo4j.
- Stardog mantiene su propia SPARQL y Duendecillo. Puede obtener la URI de un triplete y la "metainformación" en SPARQL usando algo como esto:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph también es compatible con su propia ESPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Por cierto, GraphDB admitió Tinkerpop/Gremlin en un momento sin admitir LPG, pero eso se detuvo en la versión 8.0 u 8.1.
VI. Apriete de licencias
No ha habido adiciones recientes a la intersección de los conjuntos "triplestore of choice" y "open source triplestore". Las nuevas tiendas RDF de código abierto están lejos de ser una buena opción para el uso diario, y el código fuente de las nuevas tiendas triples que me gustaría usar (por ejemplo, AnzoGraph) está cerrado. Más bien, podemos hablar de reducciones...
Por supuesto, el código abierto anteriormente no está cerrado, pero algunos repositorios de código abierto gradualmente ya no se consideran dignos de elección. Virtuoso, que tiene una edición de código abierto, en mi opinión, se está ahogando en errores. Blazegraph comprado por AWS y formó la base de Amazon Neptune; ahora no está claro si habrá al menos un lanzamiento más. Solo queda Jenna...
Si el código abierto no es muy importante, pero solo quiere probar, entonces todo es menos optimista que antes. Por ejemplo:
- Perro estrella distribuir la versión gratuita (sin embargo, el período de prueba de la normal se ha duplicado);
- в , donde antes se podía elegir el plan básico gratuito, se suspende el registro de nuevos usuarios.
En general, el espacio se está volviendo cada vez más inaccesible para un laico de TI ordinario, su desarrollo se está convirtiendo en la suerte de las corporaciones.
Fuente: habr.com