¿Es posible usar el almacenamiento RDF también como una base de datos orientada a documentos?

Question

Supongamos que tengo una gran cantidad de documentos JSON heterogéneos (es decir, llamadas asignaciones de valor clave) y una jerarquía de clases (es decir, conjuntos llamados) a los que están conectados estos documentos. Necesito configurar una estructura de datos que permita:

1. Operaciones CRUD en documentos JSON.
2. Recuperación de documentos JSON por ID muy rápido.
3. Recuperar todos los documentos JSON que se adjuntan a una determinada clase muy rápido.
4. Jerarquía de clase de edición: agregar/eliminar clases, reorganizarlas.

Inicialmente se me ocurrió la idea de almacenar documentos JSON en una base de datos orientada a documentos (como CouchDB o MongoDB) y almacenar la jerarquía de clases en un almacenamiento RDF (como 4store). 1, 2 y 4 luego se resuelven naturalmente, y 3 resuelto manteniendo la lista de ID de documento adjuntas para cada clase en el almacenamiento.

Pero luego pensé que un almacenamiento RDF en realidad podría hacer la parte orientada al documento de recuperar documentos JSON por ID. A primera vista, esto parece cierto, pero todavía estoy preocupado por 2 y 3. ¿Existe un almacenamiento RDF que pueda recuperar documentos (nodos) a los documentos de servicio de DB orientados a documentos de velocidad? ¿Qué tan rápido servirá? 3-El consultas similares? He escuchado un poco sobre los almacenes RDF que son lentos, el problema de reificación, etc.

¿Hay un almacenamiento RDF que también sea tan cómodo para los objetos de recuperación informal por ID, como CouchDB, por ejemplo? ¿Cuál es la diferencia entre el uso de almacenamiento orientado a documentos y RDF para almacenar, recuperar y editar objetos similares a JSON?

Answer 1

Lo más cercano que puede usar en las bases de datos RDF se denominan gráficos. En un gráfico con nombre, puede colocar un conjunto de triples RDF. Este conjunto de triples se puede afirmar a partir de uno o muchos documentos RDF dependiendo de sus necesidades. Digamos que desea un gráfico llamado por documento RDF. Puede nombrar el gráfico con un URI que refleje la ubicación del archivo como URL o un IRI. Por ejemplo ...

http://yourdomain/files/rdf_file_1

o

file:///home/myrdffiles/file1

4store es una cuadrícula. El soporte de las tiendas Quad con el soporte llamado Graphs y 4store es especialmente diseño para manejar esto.

Con 4store puede ejecutar el siguiente comando para afirmar los triples en un gráfico con nombre:

curl -T your_file.rdf http://your_4store_database/data/http://yourdomain/files/rdf_file_1

Después /data/ Puede colocar el identificador de gráfico (IRI) donde se afirmarán los triples. Ver Servidor SPARQL de 4 puertas y Libs de cliente de 4 puertas para más detalles.

Una vez que tenga sus datos, con SPARQL también puede usar el gráfico con nombre para dirigir su consulta a ese gráfico:

SELECT * WHERE {
   GRAPH <http://youdomain/files/rdf_file_1> {
        .... some triple patterns in here ....
   }
}

Además, 4store también admite JSON para que pueda recuperar el conjunto de resultados SPARQL directamente en JSON.

Si decide usar la 4store encontrará un valioso soporte aquí: http://4store.org/contact

Answer 2

Originalmente hizo esta pregunta para bases de datos gráficas (como Neo4j). Por eso me gustaría agregar algunas notas.

1. Las bases de datos de gráficos usan integrados indexación Para nodos (y relaciones), por lo que la búsqueda inicial rápida de los nodos raíz de sus documentos se realiza a través de eso (índices externos o en gráficos)
2. Se puede modelar más en los índices de gráficos para las rutas (en realidad los árboles de la raíz) como una búsqueda de valor clave)
3. Si modela sus documentos como árboles de nodos con propiedades, puede hacer operaciones CRUD simples y complejas (también estructurales)
4. La recuperación de todos los documentos de un "tipo" o "clase" se puede volver a realizar nuevamente (nodos raíz de índice para escribir) o en nodos de categoría de gráfico
5. Puede poner esos nodos de categoría "tipos o clase" en una jerarquía (o gráfico) que luego se puede editar utilizando la API de la base de datos de gráficos habitual
6. atravesar el gráfico se puede hacer usando traversers / lenguaje de consulta gráfica integrada (por ejemplo Cypher para Neo4J)
7. La carga de datos jerárquicos puede ser realizado por importadores personalizados o un importador de sub-gráfico más general (por ejemplo, Geoff)