Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel

Contents

Table of Contents
outlinetrue
stylenone

History System Protoype for DSpace 1.5

...

Since this is a prototype, there are some things left undone:

  1. 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...
    1. 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.
    2. 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.
    3. See the -Q option of the
      Code Block
      org.dspace.history.HistoryRepository
      ; 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.
  2. Experiment with making the History consumer asynchronous.
  3. Export History data to a SIMILE timeline

...