Base de datos de gráficos y triplestores RDF: almacenamiento de datos de gráficos en python

Question

Necesito desarrollar una base de datos de gráficos en python (me encantaría que alguien pueda unirse a mí en el desarrollo. Ya tengo un poco de código, pero con mucho gusto al respecto).

Hice mi investigación en internet. en Java, neo4j es un candidato, pero no pude encontrar nada sobre el almacenamiento en disco real. En Python, hay muchos graph data models (vea esta propuesta anterior a PEP, pero ninguno de ellos satisface mi necesidad de almacenar y recuperar del disco.

Sé que hay almacenes triples, pero las triplestore son básicamente bases de datos RDF, por lo que un gráfico El modelo de datos podría mapearse en RDF y almacenarse, pero en general estoy intranquilo (principalmente debido a la falta de experiencia) sobre esta solución. Un ejemplo es Sesame. La realidad es que, en cualquier caso, debe convertir desde la representación gráfica en la memoria. a la representación RDF y viceversa en cualquier caso, a menos que el código del cliente quiera piratear el documento RDF directamente, lo cual es poco probable. Sería como manejar las tuplas de DB directamente, en lugar de crear un objeto.

¿Cuál es el estado? de la técnica para el almacenamiento y recuperación (a la DBMS) de datos de gráficos en python, por el momento? ¿Tendría sentido comenzar a desarrollar una implementación, con suerte con la ayuda de alguien interesado en ella, y en colaboración con los proponentes de Graph API PEP? Tenga en cuenta que esto va a ser parte de mi trabajo durante los próximos meses, por lo que mi contribución a este eventual proyecto es muy muy grave;)

Editar: Se encuentra también directededge, pero parece ser un producto comercial

Answer 1

He usado tanto Jena, que es un framework de Java, como Allegrograph (Lisp, Java, enlaces de Python). Jena tiene proyectos hermanos para almacenar datos de gráficos y ha sido por mucho, mucho tiempo. Allegrograph es bastante bueno y tiene una edición gratuita, creo que sugeriría esto porque es fácil de instalar, gratis, rápido y puedes estar listo en poco tiempo. La potencia que obtendrías al aprender un poco de RDF y SPARQL bien podría valer la pena. Si ya conoces SQL, has tenido un gran comienzo. Ser capaz de consultar su gráfica usando SPARQL le reportaría grandes beneficios. Serializar a RDF triplica sería fácil, y algunos de los formatos de archivo son súper fáciles (NT, por ejemplo). Daré un ejemplo. Digamos que tiene el siguiente gráfico identificadores de nodo de borde de nodos:

1 <- 2 -> 3 
3 <- 4 -> 5 

estos ya son materia objeto predicado por lo que sólo una palmada alguna notación URI en él, cargarlo en el triple tienda y consulta en -will a través de SPARQL. Aquí está en formato NT:

<http://mycompany.com#1> <http://mycompany.com#2> <http://mycompany.com#3> . 
<http://mycompany.com#3> <http://mycompany.com#4> <http://mycompany.com#5> . 

Ahora la consulta para todos los nodos de dos saltos desde el nodo 1:

SELECT ?node 
WHERE { 
    <http://mycompany.com#1> ?p1 ?o1 . 
    ?o1 ?p2 ?node . 
} 

Esto haría de rendimiento supuesto < http://mycompany.com#5>.

Otro candidato sería Mulgara, escrito en Java puro. Dado que pareces más interesado en Python, creo que primero deberías echarle un vistazo a Allegrograph.

Answer 2

Creo que la solución realmente depende de qué es exactamente lo que quiere hacer con el gráfico una vez que ha logrado almacenarlo en el disco o en la base de datos, y esto es poco claro en su pregunta. Sin embargo, un par de cosas que usted puede ser que desee tener en cuenta son:

• si lo que desea es persistir el gráfico sin necesidad de utilizar cualquiera de las características o propiedades que se podría esperar de una solución RDBMS (tales como ácido), entonces, ¿cómo acerca de simplemente decapando los objetos en un archivo plano? Muy rudimentario, pero como digo, depende exactamente de lo que quieres lograr.
• ZODB es una base de datos de objetos para Python (un spin off del proyecto Zope, creo). No puedo decir que haya tenido mucha experiencia en un entorno de alto rendimiento, pero algunas restricciones le permiten almacenar objetos de Python de forma nativa.
• si desea seguir RDF, hay un proyecto RDF Alchemy que podría ayudar a aliviar algunas de sus preocupaciones sobre la conversión de su gráfico a estructuras RDF y creo que tiene Sesame como parte de su stack.

Hay algunas otras persistence tools se detalla en el sitio pitón que puede ser de interés, sin embargo pasé bastante tiempo buscando en esta zona el año pasado, y en última instancia, encontré que no había una solución nativa de Python que conoció a mi requisitos.

El mayor éxito que tuve fue el uso de MySQL con un ORM personalizado y publiqué un par de enlaces relevantes en una respuesta al this question. Además, si desea contribuir a un proyecto RDBMS, cuando hablé con alguien de Open Query sobre a Graph storage engine for MySQL, parecía interesado en obtener una participación activa en su proyecto.

Lo siento, no puedo darle una respuesta más definitiva, pero no creo que haya una ...Si empiezas a desarrollar tu propia implementación, me gustaría mantenerte al tanto de cómo te va.

Answer 3

Hmm, tal vez debería echar un vistazo a CubicWeb

Answer 4

En cuanto Neo4j, ¿se fijaron Python bindings el vigente? En cuanto al almacenamiento en disco, eche un vistazo a this thread en el mailing list.

Para graphdbs en Python, el proyecto Hypergraph Database Management System se inició recientemente en SourceForge por Maurice Ling.

Answer 5

¡Saludos desde su Serius Cybernetics Intelligent Agent!

Algunos enlaces útiles ...

• Programming the Semantic Web

• SEMANTIC PROGRAMMING

• RDFLib Python Library for RDF

Answer 6

Redland (http://librdf.org) es probablemente el solución que está buscando. También tiene enlaces de Python.