Database grafici e triplestores RDF: archiviazione dei dati del grafico in python

Question

Ho bisogno di sviluppare un database grafico in python (mi piacerebbe se qualcuno potesse unirsi a me nello sviluppo.Ho già un po 'di codice, ma vorrei discutere con piacere a proposito).

Ho fatto la mia ricerca su internet. in Java, neo4j è un candidato, ma non sono riuscito a trovare nulla sull'effettiva memorizzazione del disco. In Python ci sono molti graph data models (vedi questa proposta pre-PEP, ma nessuno di questi soddisfa la mia necessità di archiviare e recuperare dal disco.

Conosco i triplestores, tuttavia i triplestores sono fondamentalmente database RDF, quindi un grafico il modello di dati potrebbe essere mappato in RDF e memorizzato, ma sono generalmente a disagio (principalmente a causa della mancanza di esperienza) su questa soluzione.Un esempio è Sesame. Il fatto è che, in ogni caso, è necessario convertire dalla rappresentazione grafica in memoria in ogni caso, a meno che il codice cliente voglia incidere direttamente sul documento RDF, il che è per lo più improbabile.Come sarebbe gestire direttamente le tuple di DB, invece di creare un oggetto

Qual è lo stato -d'arte per la conservazione e il recupero (a la DBMS) dei dati del grafico in python, al momento? Avrebbe senso iniziare a sviluppare un'implementazione, eventualmente con l'aiuto di qualcuno interessato a questo, e in collaborazione con i proponenti per la Graph API PEP? Si prega di notare che questa sta per essere parte del mio lavoro per i prossimi mesi, quindi il mio contributo a questo eventuale progetto è dannatamente serio;)

Edit: Trovato anche directededge, ma sembra essere un prodotto commerciale

Answer 1

Ho utilizzato sia Jena, che è un framework Java, sia Allegrograph (binding Lisp, Java, Python). Jena ha progetti gemelli per archiviare i dati del grafico ed è in giro da molto, molto tempo. Allegrograph è abbastanza buono e ha una versione gratuita, penso che suggerirei questo perché è facile da installare, gratis, veloce e si potrebbe andare e venire in pochissimo tempo. Il potere che otterresti dall'apprendimento di un po 'di RDF e SPARQL potrebbe valere la pena. Se conosci già SQL, allora sei partito alla grande. Poter interrogare il tuo grafico usando SPARQL ti darebbe dei grandi benefici. La serializzazione su tripli RDF sarebbe facile, e alcuni dei formati di file sono super facili (NT per esempio). Darò un esempio. Diciamo che avere il seguente grafico ids nodo-edge-nodo:

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

queste sono già soggetti forma oggetto predicato così appena slap qualche notazione URI su di esso, caricarlo nella triplestore e interrogazione a -verrà tramite SPARQL. Qui è in 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> . 

Ora query per tutti i nodi due hop dal nodo 1:

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

Questo sarebbe naturalmente resa < http://mycompany.com#5>.

Un altro candidato sarebbe Mulgara, scritto in puro Java. Dal momento che sembri più interessato a Python, penso che prima dovresti dare un'occhiata a Allegrograph.

Answer 2

Penso che la soluzione dipenda davvero esattamente da cosa si vuole fare con il grafico una volta che si è riusciti a memorizzarlo su disco/database, e questo è un po 'poco chiaro nella tua domanda. Tuttavia, un paio di cose che si potrebbe prendere in considerazione sono:

• se si desidera solo a persistere il grafico senza usare nessuna delle caratteristiche o proprietà ci si potrebbe aspettare da una soluzione RDBMS (come l'acido), allora come riguardo al solo decapaggio degli oggetti in un file piatto? Molto rudimentale, ma come dico, dipende esattamente da ciò che si vuole ottenere.
• ZODB è un database di oggetti per Python (una derivazione dal progetto Zope, credo). Non posso dire di aver avuto molta esperienza in un ambiente ad alte prestazioni, ma alcune restrizioni ti permettono di memorizzare gli oggetti Python in modo nativo.
• se si desidera proseguire con RDF, esiste un progetto RDF Alchemy che potrebbe contribuire ad alleviare alcune delle vostre preoccupazioni sulla conversione dal proprio grafico alle strutture RDF e penso che abbia Sesame come parte dello stack.

ci sono alcune altre persistence tools dettagliato sul sito pitone, che potrebbero interessare, però ho passato un po 'di tempo alla ricerca in questo settore lo scorso anno, e in ultima analisi, ho scoperto che non c'era una soluzione Python nativo che ha incontrato la mia requisiti.

Il maggior successo che ho avuto è stato l'utilizzo di MySQL con un ORM personalizzato e ho inviato un paio di collegamenti rilevanti in una risposta a this question. Inoltre, se si desidera contribuire a un progetto RDBMS, quando ho parlato con qualcuno di Open Query su a Graph storage engine for MySQL, sembrava interessato a partecipare attivamente al proprio progetto.

Mi spiace non posso dare una risposta più definitiva, ma non penso che ce ne sia uno ...Se si inizia a sviluppare la propria implementazione, sarei interessato a tenermi aggiornato su come si va avanti.

Answer 3

Hmm, forse si dovrebbe dare un'occhiata a CubicWeb

Answer 4

Per quanto riguarda Neo4j, avete notato l'esistente Python bindings? Per quanto riguarda l'archiviazione su disco, dai un'occhiata a this thread su mailing list.

Per graphdbs in Python, il progetto Hypergraph Database Management System è stato avviato di recente su SourceForge entro il Maurice Ling.

Answer 5

Saluti dal tuo agente intelligente Serius Cybernetics!

Alcuni link utili ...

• Programming the Semantic Web

• SEMANTIC PROGRAMMING

• RDFLib Python Library for RDF

Answer 6

Redland (http://librdf.org) è probabilmente il soluzione che stai cercando. Ha anche collegamenti Python.