La Web Semántica y los Datos Vinculados son similares al espacio cercano: la vida no está allí. Ir allí por un período más o menos largo ... bueno, no sé lo que te dijeron en la infancia en respuesta a "Quiero ser astronauta". Pero puedes observar lo que está sucediendo y estar 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 las nuevas tendencias, no anteriores a unos pocos meses, del mundo de los repositorios RDF. La metáfora del primer párrafo se inspiró en esta imagen publicitaria de tamaño épico.
Contenido
I. GraphQL para acceder a RDF
II Adaptadores a MongoDB
III. OLTP vs. OLAP
IV. RocasDB
V. soporte de GLP
V.1 Modelos de datos
V.1.1. Propiedad Singleton
V.1.2. Reificación bien hecha
V.1.3. Otros enfoques
V.2 Idiomas de consulta
VI. Licencias más estrictas
I. GraphQL para acceder a RDF
Dicen que GraphQL afirma ser un lenguaje universal para acceder a bases de datos. ¿Qué pasa con la capacidad de usar GraphQL para acceder a RDF?
Fuera de la caja, esta oportunidad es proporcionada por:
Si el repositorio no brinda esa oportunidad, se implementa de forma independiente escribiendo el resolutor correspondiente. Esto se hizo, por ejemplo, en el proyecto francés DataTourisme . O ya no puede escribir nada, pero simplemente tome HyperGraphQL .
Desde el punto de vista del seguidor ortodoxo de la Web Semántica y los Datos Vinculados, todo esto, por supuesto, es triste, ya que parece destinado a integraciones que se construyen alrededor de silos de datos regulares y no son adecuados para esa plataforma (por supuesto, el almacenamiento RDF).
Las impresiones de comparar GraphQL con SPARQL son dobles.
- Por un lado, GraphQL parece un pariente lejano de SPARQL: resolvió los problemas específicos de REST de volver a buscar y multiplicidad de consultas, sin lo cual, probablemente, sería imposible ser considerado un lenguaje de consulta, incluso para la web, y tener "-QL" en el nombre;
- Por otro lado, los circuitos rígidos de GraphQL alteran. En consecuencia, su "introspectividad" parece muy limitada en comparación con la plena reflexividad de RDF. Y no hay análogos a las rutas de propiedad, por lo que no está muy claro por qué es "Graph-".
II Adaptadores a MongoDB
Una tendencia complementaria a la anterior.
- En Stardog ahora es posible , en particular, todo en el mismo GraphQL, configurar la asignación de datos MongoDB en gráficos virtuales RDF;
- Ontotext GraphDB recientemente le permite insertar fragmentos en SPARQL en MongoDB Query.
Hablando de manera más amplia, sobre los adaptadores a las fuentes JSON que permiten que más o menos "sobre la marcha" representen a JSON como RDF, vale la pena recordar el SPARQL Generate , bastante antiguo, que se puede conectar, por ejemplo , a Apache Jena.
Resumiendo las dos primeras tendencias, se puede decir que los almacenamientos de RDF demuestran su plena disposición para integraciones y funcionamiento bajo las condiciones de "almacenamiento multivariante" (persistencia políglota). Sin embargo, se sabe que este último ha pasado de moda y que el multimodelo lo reemplazará. ¿Y qué pasa con el multimodo en el mundo del almacenamiento RDF?
En resumen, de ninguna manera. Me gustaría dedicar un artículo separado al tema de DBMS multimodelo. Mientras tanto, puede observar que no hay DBMS multimodelo en los que el modelo principal sería un gráfico (RDF), ahora no es una variedad. En la Sección V se discutirá algún pequeño multimodelo (soporte de repositorio RDF para un modelo de gráfico LPG alternativo) .
III. OLTP vs. OLAP
Sin embargo, el mismo Gartner escribe que la multimodelación es una condición sine qua non principalmente para los DBMS operativos . Es comprensible: en una situación de "almacenamiento multivariante", los principales problemas surgen con la transaccionalidad.
Pero, ¿dónde están los repositorios RDF en la escala OLTP - OLAP? Yo respondería de esta manera: ni allí ni aquí. Para indicar para qué están destinados, se necesita una tercera abreviatura. Alternativamente, sugeriría OLIP - Procesamiento intelectual en línea.
Sin embargo, todavía:
- Los mecanismos de integración GraphDB implementados con MongoDB no están diseñados para evitar problemas de rendimiento de escritura;
- Stardog va más allá y reescribe por completo el motor, nuevamente con el objetivo de mejorar el rendimiento de grabación.
Ahora permítanme presentarles un nuevo jugador al mercado. De los creadores de IBM Netezza y Amazon Redshift - AnzoGraph . La imagen del anuncio del producto basada en ella se colocó al principio del artículo. AnzoGraph se posiciona como una solución GOLAP. ¿Cómo te gusta SPARQL con funciones de ventana? -
SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE { … }
IV. RocasDB
Arriba, ya había un enlace al anuncio de Stardog 7 Beta, que decía que Stardog iba a usar RocksDB como el sistema de almacenamiento subyacente: almacenamiento de valor clave, bifurcación de Facebook de LevelDB de Google. ¿Por qué vale la pena hablar de cierta tendencia?
Primero, a juzgar por el artículo de Wikipedia , no solo los repositorios RDF se transfieren a RocksDB. Hay proyectos sobre el uso de RocksDB como motor de almacenamiento en ArangoDB, MongoDB, MySQL y MariaDB, Cassandra.
En segundo lugar, los proyectos (es decir, no productos) del tema correspondiente se están realizando en RocksDB.
Por ejemplo, eBay usa RocksDB en la plataforma para su "gráfico de conocimiento". Por cierto, es divertido de leer: el lenguaje de consulta comenzó como un formato interno, pero más recientemente se ha estado convirtiendo en mucho más parecido a SPARQL . Al igual que en el chiste: no importa cuánto gráfico de conocimiento hagamos, todavía obtenemos RDF.
Otro ejemplo es el Servicio de consulta de historial de Wikidata , que apareció hace unos meses. Antes de su aparición, Wikidata tuvo que acceder a la API estándar de Mediawiki a través de MWAPI . Ahora es mucho posible en SPARQL puro. "Debajo del capó" también hay RocksDB. Por cierto, WDHQS hizo, al parecer, la persona que importó Freebase en Google Knowledge Graph.
V. soporte de GLP
Permítame recordarle la principal diferencia entre los gráficos LPG y los gráficos RDF .
En LPG, las propiedades escalares se pueden colgar en instancias de borde, mientras que en RDF solo se pueden colgar en los "tipos" de bordes (pero no solo en las propiedades escalares, sino también en las relaciones regulares). Esta limitación de RDF en comparación con LPG se supera mediante diversas técnicas de modelado. Las limitaciones de LPG en comparación con RDF son más difíciles de superar, pero los gráficos de LPG son más grandes que los gráficos de RDF, similares a las imágenes del libro de texto de Harari, por lo que la gente los quiere.
Obviamente, la tarea de soportar GLP se divide en dos partes:
- introducir cambios en el modelo RDF que hacen posible simular construcciones de GLP en él;
- realizar cambios en el lenguaje de consulta RDF que permite acceder a los datos en este modelo modificado, o la implementación de la capacidad de realizar consultas a este modelo en los populares lenguajes de consulta LPG.
V.1 Modelos de datos
Hay varios enfoques posibles.
V.1.1. Propiedad Singleton
El enfoque más literal para armonizar RDF y LPG es probablemente la propiedad singleton :
- En cambio, por ejemplo
:isMarriedTo , se utilizan predicados :isMarriedTo1 , etc. - Entonces estos predicados se convierten en sujetos de nuevos trillizos ::
:isMarriedTo1 :since "2013-09-13"^^xsd:date , etc. - La relación de estas instancias de predicados con un predicado común se establece mediante tripletes de la forma
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo . - Obviamente,
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type , pero piense por qué no debería escribir simplemente :isMarriedTo1 rdf:type :isMarriedTo .
La tarea de soportar LPG se resuelve aquí en el nivel RDFS. Dicha solución requiere su inclusión en el estándar relevante. Es posible que se requieran algunos cambios de los repositorios RDF que admiten efectos adjuntos, pero por ahora, la propiedad Singleton se puede tomar simplemente como otra técnica de modelado.
V.1.2. Reificación bien hecha
Los enfoques menos ingenuos surgen de la comprensión de que las instancias de propiedades son instanciadas por trillizos. Al tener la oportunidad de decir algo sobre los trillizos, tenemos la oportunidad de hablar sobre instancias de propiedades.
El más sólido de estos enfoques es RDF * , también conocido como RDR, nacido en las entrañas del Blazegraph. Desde el principio, AnzoGraph lo eligió para sí mismo. La solidez del enfoque está determinada por el hecho de que dentro de su marco se proponen los cambios correspondientes en RDF Semantics . El punto, sin embargo, es extremadamente simple. En la serialización de Turtle, RDF ahora se puede escribir de la siguiente manera:
<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .
V.1.3. Otros enfoques
No puede molestarse con la semántica formal, sino simplemente asumir que los trillizos tienen ciertos identificadores, que son, por supuesto, URI, y componer nuevos trillizos con estos URI. Todo lo que queda es dar acceso a estos URI en SPARQL. Esto es lo que hace Stardog.
Allegrograph fue un camino intermedio. Se sabe que los identificadores de triplete existen en Allegrograph, pero cuando implementan atributos triples no se destacan. Sin embargo, la semántica formal está muy lejos. Cabe señalar que los atributos de los tripletes no son URI, y los valores de estos atributos también pueden ser literales. Los adherentes al 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 soportado LPG de una forma u otra a nivel de modelo, debe dar la oportunidad de realizar solicitudes de datos en dicho modelo.
- Blazegraph para consultas RDF * admite SPARQL * y Gremlin . La consulta para SPARQL * se ve así:
SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }
- Anzograph también admite SPARQL * y admitirá Cypher , un lenguaje de consulta en Neo4j.
- Stardog admite su propia extensión SPARQL y nuevamente Gremlin. Puede obtener triplete y "metainformación" en SPARQL URI usando algo como esto:
SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since }
- Allegrograph también admite su propia extensión SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }
Por cierto, GraphDB admitió en algún momento Tinkerpop / Gremlin, aunque no admitía LPG, pero en la versión 8.0 u 8.1 esto se detuvo.
VI. Licencias más estrictas
Recientemente no se han producido adiciones en la intersección de los conjuntos "triplestore de elección" y "open triplestore". Los nuevos repositorios de código abierto RDF están lejos de ser una buena opción para el uso diario, y el código fuente de los nuevos triplicadores que nos gustaría usar (el mismo AnzoGraph) está cerrado. Más bien, podemos hablar de disminuciones ...
Por supuesto, el código fuente abierto anteriormente no se cierra, pero algunos repositorios de código abierto 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 fue comprado por AWS y formó la base de Amazon Neptune; ahora no está claro si habrá al menos una versión más. Todo lo que queda es Jena ...
Si el código abierto no es muy importante, pero solo quieres probarlo, entonces todo es menos atractivo que antes. Por ejemplo:
- Stardog deja de distribuir la versión gratuita (sin embargo, ha duplicado el período de prueba de la versión normal);
- en GraphDB Cloud , donde anteriormente se podía elegir un plan básico gratuito, se suspende el registro de nuevos usuarios.
En general, para el lego informático promedio, el espacio se está volviendo cada vez más inaccesible; su desarrollo se convierte en la gran cantidad de corporaciones.