La Web Semántica y los Datos Conectados son como el espacio cercano: no hay vida allí. Para ir allí durante un período más o menos largo... bueno, no sé qué te dijeron en tu infancia cuando dijiste "quiero ser astronauta". Pero puedes observar lo que sucede desde la Tierra; convertirse en un astrónomo aficionado o incluso profesional es mucho más fácil.
En este artículo se hablará de las tendencias recientes, no más antiguas de unos meses, en el mundo de los almacenes RDF. La metáfora en el primer párrafo fue inspirada por una imagen publicitaria de dimensiones épicas que se encuentra a continuación.
Imagen épica
I. GraphQL para acceder a RDF
, que GraphQL pretende convertirse en el lenguaje universal de acceso a bases de datos. Pero, ¿cómo están las cosas con la posibilidad de acceso utilizando GraphQL a RDF?
"Fuera de la caja" esta posibilidad la ofrecen:
- Stardog (, );
- los productos de TopQuadrant (, ).
Si el almacén no ofrece esta posibilidad, se implementa por uno mismo, escribiendo un "resolutor" correspondiente. Así lo hicieron, por ejemplo, en el proyecto francés . O ya no hace falta escribir nada, simplemente toma .
Desde el punto de vista de un ortodoxo defensor de la Web Semántica y los Datos Conectados, todo esto es, por supuesto, desalentador, ya que parece estar destinado a integraciones construidas alrededor de nuevos data silos, y no adecuadas para esas plataformas (por supuesto, almacenes RDF).
Las impresiones de comparar GraphQL con SPARQL son contradictorias.
- Por un lado, GraphQL parece un pariente lejano de SPARQL: aborda problemas característicos de REST como la sobreselección y la multiplicidad de consultas — sin los cuales, supongo, no podría considerarse lenguaje de consultas, aunque solo para la web;
- Por otro lado, decepciona la rígida esquematización de GraphQL. Por lo tanto, su "introspectividad" parece muy limitada en comparación con la completa reflexividad de RDF. Y no hay ningún análogo a los property paths, así que incluso no está muy claro por qué se llama "Graph-".
II. Adaptadores para MongoDB
Una tendencia complementaria a la anterior.
- en Stardog ahora — en particular, todo a través del mismo GraphQL — es configurar la visualización de datos de MongoDB en gráficos RDF virtuales;
- GraphDB desde hace poco permite insertar fragmentos de MongoDB Query en SPARQL.
Hablando más ampliamente sobre los adaptadores a fuentes JSON, que permiten representar más o menos "sobre la marcha" el JSON almacenado en estas fuentes como RDF, se puede recordar también el ya bastante antiguo , que se puede adaptar, , a Apache Jena.
Resumiendo las primeras dos tendencias, se puede decir que los almacenes RDF demuestran una total disposición para integrar y funcionar en un entorno de "almacenamiento polivalente" (polyglot persistence). Sin embargo, es conocido que esta última ya no está de moda, y está siendo reemplazada por ¿Y cuál es la situación de la multimodalidad en el mundo de los almacenes RDF?
En resumen, es inexistente. La temática de las bases de datos multimodales merece un artículo aparte, por ahora se puede notar que no existen bases de datos multimodales "basadas" en el modelo gráfico (una variedad de este podría considerarse el RDF). Sobre una pequeña multimodalidad — el soporte de modelos gráficos alternativos por parte de los almacenes RDF — se hablará en .
III. OLTP vs. OLAP
Sin embargo, el mismo Gartner , señala que la multimodalidad es una condición sine qua non en primer lugar para las bases de datos operacionales. Esto es comprensible: en la situación de "almacenamiento polivalente" los principales problemas surgen con la transaccionalidad.
Pero, ¿dónde se encuentran los almacenes RDF en la escala OLTP—OLAP? Yo respondería así: ni aquí, ni allí. Para designar a lo que están destinados, se necesita algún tipo de tercer acrónimo. Como opción, propondría OLIP — Procesamiento Intelectual Online.
Sin embargo, aún así:
- los mecanismos de integración realizados en GraphDB no están diseñados en menor medida Stardog va aún más allá y reescribe completamente
- el motor, nuevamente con el objetivo de mejorar el rendimiento de escritura. AnzoGraph.
La imagen de la publicidad del producto se incluyó al inicio del artículo. AnzoGraph se posiciona como una solución GOLAP. ¿Qué les parece SPARQL con funciones de ventana? — IV. RocksDB
Ya se mencionó anteriormenteun enlace
al anuncio de Stardog 7 Beta, donde se mencionaba que Stardog tiene la intención de utilizar RocksDB como sistema de almacenamiento subyacente — un almacén de "clave-valor", un fork de Facebook de LevelDB de Google. ¿Por qué ya se puede hablar de una cierta tendencia? un artículo de Wikipedia
, no solo los almacenes RDF están "migrando" a RocksDB. Hay proyectos que utilizan RocksDB como motor de almacenamiento en ArangoDB, MongoDB, MySQL y MariaDB, Cassandra. , en RocksDB no solo se 'transplantan' almacenes RDF. Hay proyectos que utilizan RocksDB como motor de almacenamiento en ArangoDB, MongoDB, MySQL y MariaDB, Cassandra.
En segundo lugar, se están desarrollando proyectos (es decir, no productos) relacionados con RocksDB.
Por ejemplo, eBay utiliza RocksDB en para su «gráfica de conocimiento». Por cierto, es curioso leer: the query language started as a home grown format, but more recently it has been transitioning to be much more like SPARQL. Como en el chiste: no importa cuántas gráficas de conocimiento hagamos, siempre resulta ser RDF.
Otro ejemplo es el que apareció hace unos meses . Antes de su aparición, los datos históricos de Wikidata tenían que obtenerse a través de al estándar Mediawiki API. Ahora, mucho es posible con puro SPARQL. «Bajo el capó», también está RocksDB. Por cierto, parece que WDHQS fue hecho por alguien que trabajó en la importación de Freebase en Google Knowledge Graph.
V. Soporte de LPG
Recuerdo la principal diferencia entre los gráficos LPG y los gráficos RDF.
En LPG, se pueden adjuntar propiedades escalares a las instancias de las aristas, mientras que en RDF solo se pueden adjuntar a los «tipos» de las aristas (aunque no solo propiedades escalares, sino también relaciones comunes). Esta limitación de RDF en comparación con LPG con diversas técnicas de modelado. La limitación de LPG en comparación con RDF es más difícil de superar, pero los gráficos LPG son más similares a las imágenes del libro de Harari, por lo que la gente los prefiere.
Es obvio que la tarea del «soporte de LPG» se divide en dos partes:
- realizar cambios en el modelo RDF que permitan simular las construcciones LPG;
- realizar cambios en el lenguaje de consultas RDF que permitan acceder a los datos en este modelo modificado, o implementar la posibilidad de realizar consultas a este modelo en lenguajes de consulta populares de LPG.
V.1. Modelo de datos
Aquí hay varios enfoques posibles.
V.1.1. Propiedad Singleton
El enfoque más literal para armonizar RDF y LPG es, probablemente, :
- En lugar, por ejemplo, de un predicado
:isMarriedTose utilizan los predicados:isMarriedTo1,:isMarriedTo2etc. - Luego, estos predicados se convierten en sujetos de nuevos tríos:
:isMarriedTo1 :since "2013-09-13"^^xsd:datey demás. - La relación entre estas instancias de predicado y el predicado común se establece mediante tríos del tipo
:isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo. - Es obvio que
rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, pero piensa en por qué no deberías escribir simplemente:isMarriedTo1 rdf:type :isMarriedTo.
La tarea del «soporte de LPG» se resuelve aquí a nivel de RDFS. Esta solución requiere realizar cambios en el correspondiente . Algunos cambios pueden ser necesarios en los almacenes RDF que admiten la conexión de inferencias, y mientras tanto, la Propiedad Singleton puede verse simplemente como otra técnica de modelado.
V.1.2. Reificación Hecha Correctamente
Enfoques menos ingenuos provienen de la conciencia de que las instancias de propiedades pueden ser instanciadas por tripletas. Al poder hablar de tripletas, obtendremos la capacidad de hablar también sobre instancias de propiedades.
El enfoque más sólido de estos es , también conocido como RDR, en el seno de Blazegraph. Desde el principio para sí mismo y AnzoGraph. La solidez del enfoque se determina por el hecho de que en su marco los cambios correspondientes en . La esencia, sin embargo, es extremadamente simple. En la serialización Turtle de RDF, ahora se podrá escribir algo así:
<> :since "2013-09-13"^^xsd:date.V.1.3. Otros Enfoques
No es necesario complicarse con la semántica formal, sino simplemente considerar que las tripletas tienen ciertos identificadores, que son, por supuesto, URI, y formar nuevas tripletas con estos URI. Solo quedará otorgar acceso a estos URI en SPARQL. Así Stardog.
En Allegrograph un camino intermedio. Se sabe que los identificadores de tripletas en Allegrograph , pero al implementar atributos de tripleta no se exponen externamente. Sin embargo, la semántica formal todavía está muy lejos. Es notable que los atributos de tripletas no son URI, y los valores de estos atributos también pueden ser solo literales. Los adeptos de LPG obtienen exactamente lo que querían. En un formato inventado llamado NQX, un ejemplo similar al anterior para RDF* se ve así:
:bob :marriedTo :alice {"since" : "2013-09-13"}V.2. Lenguajes de Consultas
Habida cuenta de que se apoya de alguna manera a LPG a nivel de modelo, es necesario permitir realizar consultas a los datos en dicho modelo.
- Blazegraph para consultas a RDF* admite y Una consulta en SPARQL* se vería así:
SELECT * { <> :since ?since }- AnzoGraph también admite y tiene la intención de soportar , el lenguaje de consultas en Neo4j.
- Stardog admite su propio SPARQL y Gremlin. Se puede obtener en SPARQL el URI de la tripleta y la "metainformación" utilizando una construcción similar a la siguiente:
SELECT * {
BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
?id :since ?since
}- Allegrograph también admite su propio SPARQL:
SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) }Por cierto, GraphDB durante un tiempo admitió Tinkerpop/Gremlin, sin admitir LPG, pero en la versión 8.0 o 8.1 eso cesó.
VI. Endurecimiento de licencias
No ha habido novedades recientes en la intersección de los conjuntos «triplestore of choice» y «open source triplestore». Los nuevos almacenes RDF de código abierto todavía están lejos de ser una opción adecuada para el uso diario, y el código fuente de los nuevos almacenes RDF que desearíamos emplear (como AnzoGraph) está cerrado. Podríamos hablar incluso de reducciones...
Por supuesto, el código abierto no se cierra por sí mismo, pero algunos almacenes con código abierto gradualmente dejan de considerarse opciones dignas. Virtuoso, que tiene una edición de código abierto, en mi opinión, está plagado de errores. Blazegraph fue adquirido por AWS y se convirtió en la base de Amazon Neptune; ahora no está claro si habrá otro lanzamiento. Solo queda Jena...
Sin embargo, si el código abierto no es muy importante y solo se quiere probar, la situación no es tan prometedora como antes. Por ejemplo:
- Stardog distribuir una versión gratuita (aunque ha duplicado el período de prueba de la versión normal);
- en , donde anteriormente se podía elegir un plan básico gratuito, ha suspendido el registro de nuevos usuarios.
En general, para el ciudadano IT común, el espacio se está volviendo cada vez más inaccesible, y su dominación es cada vez más una tarea de las corporaciones.
Fuente: habr.com
