File Store needed #1546
Replies: 3 comments
-
There is https://github.com/nareike/adhs by @nareike and a fork by @splattater who extended it to also support quads/a graph-aware store: https://github.com/splattater/adhs/tree/feature/WSGI+QUADS @splattater and have then built the QuitStore (https://github.com/AKSW/QuitStore) which is a read/write graph-aware store that also versions all of the data in Git. For sure I would like to see improvements to the file system side and we could modularize it to make it a proper RDFlib store and move it into the RDFlib code base |
Beta Was this translation helpful? Give feedback.
-
I don't think this is how stores are intended to work. What is described in the requirements would be some other process that interacts with a memory store. If we were to follow the usual meaning of *Store in rdflib then a FileStore would be a store that Maybe what is described in the OP could be called a SyncMemoryStore or something like that? |
Beta Was this translation helpful? Give feedback.
-
Agree, this speaks more to the requirements.
Perhaps you're right here @tgbugs. Perhaps even a FileSyncMemoryStore or a FilePickleStore Clearly I've not worked out all the modes of operation here and the main conceptual issue (for me) still is whether or not it's still a "Store" if it persists between Python (RDFlib) sessions. This "Store" may:
Perhaps we (@jamiefeiss & I) need to test out a few usage scenarios... |
Beta Was this translation helpful? Give feedback.
-
Currently RDFlib has a
Store
for in-memory data, SPARQL endpoints (read-only & read/write) and other specialised DBs but it doesn't have a general-purpose fileStore
.Such a
Store
would probably:To do this it would likely:
Dataset
for just the file that changedIt would be hard for it to handle graph-aware files, so these might be excluded in v1 of such a store.
Beta Was this translation helpful? Give feedback.
All reactions