Panel | ||||||
---|---|---|---|---|---|---|
Contents
|
History System Protoype for DSpace 1.5
...
Since this is a prototype, there are some things left undone:
- Backup strategy. _NOTE: This has been solved, see -D and -R options of HistoryRepository command-line application.
_The History RDF data is stored in a "native" triple-store, which is an OpenRDF application-defined format. If it were ever corrupted, some or all of the history data would be lost. But don't worry about that just because this is based on an "alpha" release of OpenRDF 2.0...- It is not really good enough to save just the RDF triples (as N3 or RDF/XML); OpenRDF actually records them as "quads", adding an extra resource called the "context". DSpace History uses that context to bind each triple to the URI of a DSpace Object, which makes it very efficient to retrieve all the History records about a particular object.
- You could just export the RDF in the triplestore with the "-x" option; it should be possible to sort out the mapping of records to objects again without the "context", it would be a lot of extra work and there is no code to do it yet. It's much better to simply save the state of the quads.
- See the -Q option of the
; with a little tuning (notably dealing with data types and literals) this export could be used to restore the triplestore, although you'd have to write an ingester too.Code Block org.dspace.history.HistoryRepository
- Experiment with making the History consumer asynchronous.
- Export History data to a SIMILE timeline
...