Home » Posts tagged 'LOCKSS' (Page 6)
Tag Archives: LOCKSS
Roughly 2/3 of DLC LOCKSS Session Available
We've updated our Spring 2007 DLC conference page with audio and a rough transcript from the LOCKSS panel. We regret that our reporter missed the first 20 minutes. The session began at 1330 and our audio and transcript start at 1351. We figure LOCKSS is so important that missing some of it was better than not posting. If you were at the panel, please fill us in about the first 20 minutes. Continue reading
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?
- In what way does LOCKSS fail to meet the criterion that "that new applications be compatible with FDsys"
- In what way would content processed for LOCKSS not be usable by FDsys?
- 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..."
Continue readingGPO LOCKSS Report: Why does GPO want to use IP Authentication?
GPO's report (GPO LOCKSS Pilot: Final Analysis, Government Printing Office, April 12, 2007), which analyzes the LOCKSS technology and announces GPO's findings and "future recommendations" on using LOCKSS, refers repeatedly to use of IP Authentication*. The document does not, however, discuss the need for IP authentication either in the pilot or in possible future implementations of LOCKSS for government information.
Since LOCKSS does not require IP Authentication, this raises interesting questions.
While it is reasonable to assume that GPO wanted to limit access to the documents it was using for the LOCKSS pilot project to those who were participating in the project, it is not clear why GPO would consider IP Authentication necessary for a live implementation of LOCKSS. But the report clearly states as an "Outstanding Issue":
IP authentication for over 1260 depositories would be cumbersome, and may not be cost effective in relation to the benefit received. (page 6)
And, later, the report stresses the costs of IP Authentication:
LOCKSS technology in itself appears to be relatively cost efficient as a distribution mechanism. Costs appear to be a bigger issue in relation to staff time required to ... administer IP authentication. (page 11)
Since the report does not explain why it would want to use IP Authentication for LOCKSS, we can only speculate why it includes it as a cost. Here are my speculations. I pose them as questions and would welcome answers from GPO.
- Is GPO planning to set up a special distribution system for depository libraries only? This would make sense if GPO wants to use this special distribution channel to meet its commitment to "free and ready public access to" government information "in partnership with Federal Depository libraries" while maintaining a separate, fee-based channel to meet its commitment to "distribute, on a cost recovery basis, copies of printed and electronic documents and other government information products to the general public," [emphasis added] (A strategic vision for the 21st century). For this to work, GPO would have to restrict what FDLP libraries can do with the content they receive, either through technological locks or limitations, or licensing restrictions. We have already seen a precursor to the use of licensing restricitions with the Library of Congress Subject Headings (See: GPO details onerous restrictions on digital materials). This seems to me the most likely reason for the inclusion of IP authentication in the report because it fits in well with the contradictory missions noted above of providing information for free and for a fee and with GPO's previous experience with this very contradiction. (Years ago, when GPO tried to charge for GPO Access, it tried to limit free use of it to those physically inside depository libraries. When that failed because libraries made the same content available on the net, GPO was forced to go to a model of making "it free to the general public." But, as Bruce James said, "This cannot continue." [See Summary, 2003 Fall Meeting Depository Library Council.]) The new model seems clear: "Free" to depository libraries, but with limitations on use, location, and so forth; and "Fee" to the general public.
- Is GPO planning a separate, FDLP-only distribution channel as a way of providing "authentication" of content? This would fit in well with GPO's consistently stated intention of being a "single authoritative resource" for digital Federal documents (A Strategic Vision). Information distributed through such a limited access channel could come with a special cachet of "being deposited" and FDLP libraries and no one else would be able to claim a special authenticity to such distribution. I do not think that it would be either necessary or wise to limit "authenticity" in this way, but, perhaps someone at GPO is thinking along those lines?
- Did those who wrote the report fail to consult policy makers within GPO and make a faulty assumption that GPO wants IP Authentication? This would indicate either that the report is incomplete or badly done.
- Did those who wrote the report fail to understand the technology they were describing and think IP Authentication was necessary to implement LOCKSS? This would also indicate that the report, and perhaps the entire evaluation process, was flawed badly.
- Is IP Authentication just a red-herring intended to confuse the issue, raise the theoretical costs of implementation, and provide evidence for GPO's conclusion that LOCKSS won't work for GPO? This would indicate that GPO, which in its own words only took on the pilot project after receiving "requests from research institutions, universities, depository libraries, and other Federal Government agencies to investigate using LOCKSS", never considered LOCKSS as a viable alternative. Indeed the report makes this fairly clear when it says that it "agreed" to the pilot project to test the LOCKSS technology "...as a potential precursor to GPO’s Future Digital System (FDsys)." [emphasis added]
None of these speculations are encouraging. They lead me to conclusions that do not augur well for free public access to public information. Again, I would welcome a response from GPO.
* In a library environment, "IP Authentication" normally refers to a process that allows access to licensed content. For example, the library subscribes to a journal collection or database and pays the vendor fees that allow certain computers (e.g. all those on a campus) to have access to that content. The library sends the addresses of those computers ("IP addresses") to the publisher. The publisher maintains a service that allows any request from one of those machines to get content. For more information, see Offering remote access to restricted resources by Marshall Breeding, Information Today, Volume 18 Number 18 (May 2001) p52-53.
Depository libraries can use IP Authentication to allow two and only two machines to have access to STAT-USA. (See "STAT-USA Offers Depositories IP Authentication Access" in Administrative Notes Newsletter of the Federal Depository Library Program Vol. 27, no. 03-04 GP 3.16/3-2:27/03-04 March 15/April 15, 2006.)
Continue readingGPO LOCKSS Report: Mistakes and Irrelevancies
As I mentioned a few days ago, the final analysis report of the GPO LOCKSS Pilot Project is now available on GPO Access at http://www.access.gpo.gov/su_docs/fdlp/lockss/index.html. The comments that follow are based on analysis by Jim A. Jacobs and Daniel Cornwall. The most disappointing thing about the report isn't so much that GPO rejects LOCKSS as a distribution mechanism, but its reasons for doing so. The 19 page report doesn't read as much like an evaluation of software than as a document defending a previously made decision on the basis of mere assertions, many of which have nothing to do with LOCKSS itself. We believe the biggest problems with this report fall into two categories; 1) statements about LOCKSS that appeared to be based on a lack of understanding about how LOCKSS works and 2) negative statements made that have little connection to LOCKSS. Under the second class of problems is one so big that Jim will provide a separate posting on this issue. This is the issue of IP authentication. GPO repeats the non-scalability of IP authentication as a major stumbling block to using LOCKSS as a distribution channel. The report never explains why IP authentication is so important to GPO and that will be the subject of Jim's posting. So, what else is wrong with this report? Let's start with some statements about LOCKSS that as a participant in LOCKSS both as publisher and library simply don't make sense. Page 12 - LOCKSS may have format migration issues similar to CD-ROMs and other tangible electronic media in depository libraries. I'm not positive I really know what this means, but if they're talking about LOCKSS hardware, that's no more of an issue than having computers in libraries at all. LOCKSS caches are just regular computers as the report itself says. Because content is duplicated on other LOCKSS caches, migrating hardware is as simple as buying a new computer, installing LOCKSS, picking your content and sitting back as content is reloaded from other caches. If GPO is referring to file format migration, LOCKSS researchers have been working on that issue since 2005 and have come up with a promising approach. Page 12 - Explore options for making content available from a single site that would allow LOCKSS libraries and non-LOCKSS libraries to access content from the same source. This would eliminate duplication of effort required to make content available to both groups of libraries. If you check out any of the nonrestricted materials available through LOCKSS, whether it is Alaska State Documents or BioMed Central Journals, all content available through LOCKSS is already available to non-LOCKSS users from the same interface. No duplication of effort is needed. Simply have the content available in some kind of human-intuitive archive units, and people and LOCKSS caches alike are happy. Unless GPO has plans for restricting public domain government information, this just isn't an issue. Page 12-13 - However, formatting the content to enable LOCKSS use could require more clicks than the current model for non-LOCKSS users to access the content. All LOCKSS needs are issue dates organized by year or some other suitable Archival Unit. Seems to me that is how most journals are laid out. No more clicks would be involved. GPO could have bolstered it's case by providing an example, but I just can't think of one. Page 11 - If LOCKSS were to become the only distribution method for e-journals distributed to the FDLP, all depositories would have to join the LOCKSS Alliance. No. Only libraries wishing to build local digital collections and pursuing preservation through multiple copies. Otherwise the model of access instead of custody will continue to operate. Making content available through LOCKSS is a matter of providing a publisher manifest page and writing a LOCKSS plugin. LOCKSS doesn't restrict your content any more than you already do. No library would be forced into LOCKSS unless GPO chose to make it a requirement. Finally, there is the unspoken issue that indicates a lack of understanding about LOCKSS. GPO consistently refers to LOCKSS as a system of distribution, but never mentions its preservation value. LOCKSS has proved itself since 1999 in the area of commercial journals. I would think that any evenhanded evaluation of LOCKSS would need to examine its a capability as a preservation system, which is has done for eight years longer than FDSys has. The second major problem area is that this purported evaluation of the LOCKSS technology is sprinkled with negative comments that have little to do with LOCKSS itself. In this category I'd put:
- Some libraries may want to “weed†publications from their caches in order to regain disk space at times. (page 11)
- It is unclear what percentage of FDLP libraries want to utilize LOCKSS for e-journal content. (page 11)
- It is not clear whether libraries that do want LOCKSS want it as an exclusive service to depositories, or whether they simply want to enable libraries to archive content locally. (page 11)
- Many agencies will complain if they believe GPO is taking business away from their Web sites by republishing content on GPO Web sites. (page 11)
- The depository library community has not been surveyed to determine whether there is wide enough support for LOCKSS to use it as the only e-journal delivery mechanism to justify requiring all libraries to receive e-journal content through LOCKSS. (page 12)
GPO, LOCKSS, IP Authentication, and the future of FDLP — more clarification needed
April 11, 2007 / Leave a comment
If you have not had a chance to read the message from Joseph P. Paskoski (Clarification on GPO LOCKSS report), I encourage you to do so. It does indeed help clarify GPO's intentions in ways that, I believe, seriously endanger long-term, free, public access to government information.
For those confused by the recent thread about GPO, LOCKSS, and IP authentication, allow me to try to summarize what we now know:
GPO is not "advocating" use of IP authentication for LOCKSS.
On the other hand, GPO is considering "an exclusive service for depository libraries" and is recommending exploring "other user authentication options" to implement such a system.
Further, GPO is only willing to "consider" (not guarantee) making content available without user authentication. This is evidently true of FDsys as well as any use of LOCKSS.
To me, this means that GPO is, indeed, planning a two-tier system of digital distribution: one exclusively for depository libraries (and, presumably, free) and, by implication, a second system presumably for the general public and based on cost recovery.
For this to work, GPO would have to do two things. First, it would have to restrict what FDLP libraries can do with the content they receive, either through technological locks or limitations, or licensing restrictions (including restrictions on re-distribution). Second, if GPO offered any content to the general public for free, it would have to offer similarly technologically dumbed-down, less-than-fully-functional, non-reusable content -- much the way Amazon offers one-page-at-a-time viewing of books as a teaser to get you to purchase the entire book. (For more on this see Why does GPO want to use IP Authentication?)
This model seems clear: distribution to depository libraries for free, but with limitations on use, location, and so forth; and distribution to the general public for a fee.
This sounds like an implementation of what GPO's strategic vision promised: a commitment to "free and ready public access to" government information "in partnership with Federal Depository libraries" while maintaining a separate, fee-based channel to meet its commitment to "distribute, on a cost recovery basis, copies of printed and electronic documents and other government information products to the general public," [emphasis added] (A strategic vision for the 21st century).
Why is this a threat to long-term, free, public access to government information? Imagine what such a system would look like to your users: They could use the net to get what they need, but they may have to pay or use a dumbed-down version. Or they could go offline, go to their library and use a "free" version, which would also have DRM or licensing restrictions, or both.
This is a far cry from DLC's underlying assumption that "much of the access to federal information resources is available 24/7 on the Internet" (Knowledge Will Forever Govern" A Vision Statement For Federal Depository Libraries In The 21st Century).
What this sounds like to me is a revival of the GPO bookstore concept for the digital age with the (fee-based) bookstore as the primary means of access to most government information and the go-to-the-library-building FDLP as the "free" path. This puts libraries and free access as second-tiers, non-networked alternatives for users. It would mean that libraries would be unable to participate in the open and free flow and re-use of government information (Web 2.0, Semantic Web, etc.). It is a vision of government information closer to Jack Valenti's vision of movie distribution than to Jefferson or Madison's visions of government information.
Imagine what this would mean to FDLP libraries and their ability to preserve access to information. Would systems like LOCKSS even be permitted? Or would locked-down-with-DRM or technologically-dumbed-down free versions made available to libraries be technically (or by license) un-preseravable?
I may be misinterpreting GPO's statements and I hope I am. I would welcome hearing further clarifications from GPO including that it does not intend to use DRM and that it does not intend to restrict what FDLP libraries or others can do with free content. I would welcome hearing from GPO that it does not intend to provide dumbed-down or technologically locked or functionally-disabled content for free while providing fully-functional content for a fee. I invite GPO to commit itself to open, free, reusable, preservable, distributable, unencumbered, fully-functional government information. I urge DLC to insist on digital distribution so that FDLP libraries can be fully functional online partners in the organization and preservation of government information and not by-standers who hope GPO will get funding to do so.
GPO could also show its good faith by continuing to study LOCKSS as one (not the exclusive) method of preservation and not just a method for distribution. The project could be expanded to include more than just e-journals. GPO could evaluate automated harvesting using tools that automatically create new directory structures and actively seek ways to help other depository libraries participate (e.g., reviewing automated harvesting).
Perhaps there can be some discussion of these issues at DLC.
Until we get further clarification, we'll all be left wondering.
Continue reading →Continue Reading →