From Dynamic to Static: the challenge of depositing, archiving and publishing constantly changing content from the information environment

A repository used for storing and disseminating research is a canonical example of a system which strives to produce stable artefacts which can be reliably referenced, if not actually reserved, over time. This is a difficult task, since the normal state of information is constant flux: being updated, revised, rewritten, removed and republished. Recent work in deposit technology has tended to centre around the use of a repository as a 'final resting place' for some research item. It has typically used packages of content, roughly analogous to the SIP (Submission Information Package) in OAIS (http://public.ccsds.org/publications/archive/650x0b1.pdf), to insert 'finished' works into the archive. An example of this is SWORD (http://www.swordapp.org/), which addresses in great detail the deposit mechanism, but is largely reliant on the payload being a single file (for example, a zip), containing all the information that the repository needs in order to create an archival object. This places a burden on the depositor to make an assertion that an item is finished and ready for archiving, and pushes tasks that the repository is traditionally good at (i.e. storing content) out to whatever system the user is creating their work in. Over the past year, Symplectic Ltd (http://www.symplectic.co.uk/) has attempted to break down this reliance on the "package", and move repository deposit in the direction of not only full CRUD (Create, Retrieve, Update, Delete), but also to give repository workflows the opportunity to define when a work is "finished" (at least, provisionally). This will give the repository the opportunity to do what it does best (i.e. store content), and to allow the administrators - experts in repositories and archiving - to have a hand in determining whether an item is "finished", relieving these burdens from the depositor and their research process