Home » post » GPO LOCKSS report: Why LOCKSS vs. FDsys?

Our mission

Free Government Information (FGI) is a place for initiating dialogue and building consensus among the various players (libraries, government agencies, non-profit organizations, researchers, journalists, etc.) who have a stake in the preservation of and perpetual free access to government information. FGI promotes free government information through collaboration, education, advocacy and research.

GPO LOCKSS report: Why LOCKSS vs. FDsys?

I do not understand why the GPO report on LOCKSS ( GPO LOCKSS Pilot: Final Analysis, Government Printing Office, April 12, 2007) seems to take an “either LOCKSS or FDsys” approach.*

It is my understanding that FDsys uses the Open Archival Information System (OAIS) reference model and that LOCKSS is 100 percent OAIS compatible (OAIS Formal statement of Conformance to ISO 14721:2003).

To me, this means that the bulk of the work that GPO did to get content ready for LOCKSS would be work that would also prepare content for FDsys. If that is true, the two systems are not incompatible, but complementary. It should not be necessary for GPO to choose one or the other, but, instead, could choose both.

The report notes in its Final Recommendations that “GPO’s emerging enterprise architecture requires that new applications be compatible with FDsys or face the risk of near-term obsolescence” but it does not explain how LOCKSS does not meet this criterion.

In both the report and the Clarification, GPO says that it would require 9 FTEs to harvest and re-publish content to GPO servers in a LOCKSS-friendly format and only 1 FTE to write LOCKSS plugins. This is the “much larger use of staff time” that evidently is the primary reason GPO is using to decide to “devote its resources to the development of FDsys…” and devote no resources to using or enabling use of LOCKSS.

This leads me to more questions about the GPO LOCKSS report. Perhaps these can be addressed at DLC?

  1. In what way does LOCKSS fail to meet the criterion that “that new applications be compatible with FDsys”
  2. In what way would content processed for LOCKSS not be usable by FDsys?
  3. What will the cost be to process into FDsys the 592 serial titles identified in the GPO LOCKSS report?

Finally, the report consistently refers to LOCKSS as a “distribution” system and ignores LOCKSS as a preservation system. The report only mentions the benefits of LOCKSS once (“IP authentication for over 1260 depositories would be cumbersome, and may not be cost effective in relation to the benefit received.” p.6) but does not specify what GPO sees as the benefits of LOCKSS. I would suggest that a better evaluation of LOCKSS by GPO would have included the benefits of LOCKSS, particularly as a redundant (fiscally, physically, and technologically) preservation system, and would have included a perspective of LOCKSS as complementary to FDsys, not a competitor to it.


* The report says that GPO tested the LOCKSS technology “as a potential precursor to GPO’s Future Digital System (FDsys)” not as a complement to FDsys. It speaks of a choice between “duplicating effort” or requiring all libraries to use LOCKSS. It sets up scenarios such as “If a title such as this were to be distributed through LOCKSS only…” and “If LOCKSS were to become the only distribution method for e-journals distributed to the FDLP…”

CC BY-NC-SA 4.0 This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.


Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Archives