¿Es posible utilizar 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, asignaciones de clave-valor con nombre) y una jerarquía de clases (es decir, conjuntos con nombre) a los que están adjuntos estos documentos. Necesito configurar una estructura de datos que permita:

1. Operaciones CRUD en documentos JSON.
2. Recuperando documentos JSON por ID muy rápidamente.
3. Recuperando todos los documentos JSON que están conectados a cierta clase muy rápidamente.
4. Editar la jerarquía de clases: agregar/eliminar clases, reorganizarlas.

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

Pero luego pensé que un almacenamiento RDF realmente podría hacer la parte orientada a documentos de recuperación de documentos JSON por ID. A primera vista, esto parece cierto, pero todavía estoy preocupado por 2 y 3. ¿Hay un almacenamiento RDF que pueda recuperar documentos (nodos) a una velocidad orientada a documentos documentos de servicio de db? ¿Qué tan rápido servirá 3 -como consultas? He escuchado un poco acerca de que los almacenamientos RDF son lentos, problema de reificación, etc.

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

Answer 1

Lo más parecido que puede usar en las bases de datos RDF se denomina gráficos. En un gráfico con nombre, puede poner un conjunto de RDF triples. Este conjunto de tripletas se puede afirmar a partir de uno o varios documentos RDF según sus necesidades. Supongamos que quiere un gráfico con nombre por documento RDF. Podría nombrar el gráfico con un URI que refleje la ubicación del archivo como una URL o un IRI. Por ejemplo ...

http://yourdomain/files/rdf_file_1 

o

file:///home/myrdffiles/file1 

4store es una tienda de quad. Las tiendas Quad admiten gráficos con nombre y 4store está especialmente diseñado para manejar esto.

Con 4store puede ejecutar el siguiente comando para hacer valer triples en un gráfico designada:

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

Después /data/ se puede poner el identificador gráfico (IRI), donde se van a valer los triples. Vea 4store sparql server y 4store Client Libs para más detalles.

Una vez que han afirmado sus datos, con SPARQL también puede utilizar el gráfico llamado para dirigir su consulta a ese gráfico:

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

Por otra parte, 4store también es compatible con JSON para que pueda recuperar el conjunto de resultados de SPARQL directamente JSON.

Si decide utilizar 4store encontrará valioso apoyo aquí: http://4store.org/contact

Answer 2

Originalmente hecho esta pregunta para bases de datos de gráficos (como Neo4j). Es por eso que me gustaría agregar algunas notas.

1. bases de datos Gráfico uso integrado indexing de nodos (y relaciones) por lo que la rapidez de búsqueda inicial de los nodos raíz de los documentos se realiza a través de eso (índices de gráficos externos o en)
2. adicional en los índices de gráficos para las trayectorias (de hecho, los árboles hasta la raíz) se pueden modelar de forma más limpia que solo una búsqueda de valores-clave.
3. Si modela sus documentos como árboles de nodos con propiedades, puede hacer cualquier operación CRUD simple y compleja (también estructural)
4. recuperación todos los documentos de un "tipo" o "clase" se pueden volver a hacer mediante un índice (nodos raíz de índice para escribir) o r en la categoría de nodos de gráficos
5. puede poner esos "tipos o de clase" categoría-nodos en una jerarquía (o gráfico) que luego puede ser editado usando la base de datos gráfica habitual API
6. atravesando el gráfico se puede hacer usando traversers/lenguaje de consulta de gráficos integrado (por ejemplo, cypher for Neo4j)
7. Carga de datos jerárquicos o bien pueden ser realizadas por los importadores de encargo o un importador sub-gráfico más general (por ejemplo GEOFF)