Home » Library (Page 27)

Category Archives: Library

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: 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)
What all of the above statements have in common is that GPO doesn't know the answers to the implied questions, hasn't asked despite being formally interested in LOCKSS for more than three years, and have no bearing on LOCKSS capability. They really sound like excuses rather than reasons. Aside from these two major sets of problems, I believe that most of the problems that GPO attributes to LOCKSS apply equally to the Future Digital System (FDSys). Think about it. If GPO serves agency content through FDSys, won't that take business away from agency web sites? Or when GPO states on page nine "technical sustainability and longevity of the LOCKSS platform as a long-term archiving solution needs to be assessed", how is this different from the Future Digital System, except that LOCKSS has been around since 1999 and the FDSys is still in development? Since I'd like to note when I agree with an opponent's point, I'd like to say that GPO does have a point about the time intensive nature of manually harvesting journals. Their collection times are similar to what I have in collecting Alaska State Journals and annual reports. That's part of the reason that Alaska's LOCKSS program focuses on monographs distributed on our monthly shipping lists. This allows it to distribute hundreds of titles in a single plugin in a way that adds at least minimal metadata to the LOCKSS system. Rather than abandoning LOCKSS because manually harvesting journals is too hard, GPO or some enterprising library or group of libraries should explore the automated download and posting of materials found in GPO's New Electronic Titles on a monthly basis. Even an experiment with a single item number or small agency might be useful. In as much as the Future Digital System could produce an output like the new electronic titles page, all they might have to do would be to include a LOCKSS permission statement on their "new titles" results page and let the LOCKSS community write the plugins. They could have their centralized system and interested libraries, some depository and some not, could have assurance that publications would be preserved outside of a chronically underfunded federal agency. Continue reading

Continue Reading →

Selective-deposit and the technical requirements of a digital-deposit FDLP

There was one issue that evidently came up in the discussions of digital deposit at the Fall 2006 Depository Library Council meeting that we at FGI think deserves highlighting and clarification from Council or GPO or both.

This issue relates to "general assumption 5"

Libraries receiving FDLP digital publications would be responsible for providing sufficient infrastructure, including bandwidth and storage, to provide timely and effective public access.

In the notes about the proceedings that we have read (here and here), there were questions about "streaming video" and other bandwidth-intensive infrastructure needs.

Our concern is that a library might assume from this discussion that if it wants digital deposit, it will be required to support things like streaming video.

We don't believe that is the intent of the GPO or Council even in these early discussions, but it would be useful to have GPO or Council or both clarify that selectivity in a digital-FDLP is still a valued concept and that there is no intention to develop a one-size-fits-all technical infrastructure requirement.

To elaborate on this just a bit and state what is probably obvious to most of us, what we are thinking about here is analogous to what FDLP has always had in the paper world. In the paper world, not everyone had the physical infrastructure or resources to deal with the serial set or Y4's from every little committee. We might think of those as the streaming media of the paper world. But the availability of those large sets in the depository program did not mean that every library had to select them; it did not mean that every depository library had to have the infrastructure to deal with them. But availability of those materials in a selective-depository program did mean that some libraries could select them.

And so it should be, we believe, in a digital-depository FDLP. Selective depositories would still be able to select what information content and types they would want. That would mean that a small library and a large library with vastly different technical infrastructures could both participate in a digital-deposit FDLP.

That still leaves the issue of regional depositories and how the community will define them in the digital age. But that is a different question that should be dealt with separately. We shouldn't confuse the issue of technical requirements for most FDLP libraries with the technical requirements for a future regional-depository model.

We can foresee, for example, one selective depository library hosting databases and multimedia files, another having a large collection of PDF and HTML files on a topic or subject area gathered together from several agencies along with commercial information into a digital subject collection, and another library having a few PDF files and CD-ROMs and DVDs available to users on a library workstation or library local area network. There should be room in a digital-deposit FDLP for all these scenarios and more.

One of the advantages we will gain in a digital FDLP is the ability for each library to select what it wants with great precision. Selection by media-type, subject, agency and pre-coordinated item-numbers will just be the beginning. Selecting based on content as determined by keywords or authors, on technical requirements for delivery, on popularity, on availability (or lack of availability) of the content in other formats, and more should all be possible.

A digital FDLP can have more flexibility than we ever had in the paper world and GPO and Council can and should make that point now by affirming that the technical infrastructure requirements will be flexible.

We encourage everyone to participate in this important discussion that will determine the future FDLP. We'd like to remind you to check out the notes and audio of Fall DLC and by all means please give us your thoughts on digital deposit.

Continue reading

Continue Reading →

Toward a definition of “virtual depository”

virtual: 1. Existing or resulting in essence or effect though not in actual fact, form, or name. 2. Existing in the mind, especially as a product of the imagination. 3. temporarily simulated or extended by computer software.
Usage note: When virtual was first introduced in the computational sense, it applied to things simulated by the computer, like virtual memory; that is, memory that is not actually built into the processor. --from Dictionary.com Depository: 1. a place where something is deposited or stored, as for safekeeping: the night depository of a bank. 2. a depositary; trustee. 3. of or pertaining to a depository or depositories.
--from Dictionary.com
A recent post on govdoc-l regarding virtual depositories, piqued my etymological interest. please bear with me as I explore the meaning of "virtual depository." It should be obvious that the two words "virtual" and "depository" are oxymoronic, like jumbo shrimp or military intelligence. The word "Depository" infers that something (money, govt documents...) is actually given to a trusted entity (a bank or library) to be stored for safekeeping. But how can something that's not actually there but only hinted at or pointed to, something simulated and not tangible, be placed in the care of some trusted entity? The term "virtual depository" then, is a misnomer. Putting aside this perplexity for the time being, let's look at "virtual depository" within a library context. The Govt Printing Office (GPO) has been experimenting with "virtual depositories" since 2002 when they teamed up with the University of Arizona for a pilot virtual depository in which the library selected online resources instead of printed/tangible items. Basically, the project substituted actual deposit of paper documents in the library's collection for links in the library's online catalog to digital documents housed on GPO servers. The FDLP community has been steadily moving toward "virtual depositories" since then as more and more government documents become born digital with no paper equivalent. As many of our loyal readers know, we at FGI have long advocated for GPO to actually deposit digital documents in depository libraries. Actual deposit (as opposed to virtual deposit) of digital documents, we feel, is an important way to assure access to and preservation of government information (see "Government Information in the Digital Age: The Once and Future Federal Depository Library Program"). A search of current depository management publications failed to turn up any formal definition of a "virtual depository", much less management procedures. So, since there appears to be no official definition of "virtual depository," I'd like to take this opportunity to propose one:
Virtual depository: a collection of digital government documents published by the Government Printing Office (GPO) and/or various government agencies and distributed to and hosted on the local servers of FDLP libraries so as to adhere to Title 44 of the US code and assure the provision of no fee and fully-functional access, distributed digital preservation and better and more expanded services to government information.
This is of course a definition in progress meant to open discussion on what exactly it'll mean to be a depository library in the digital future. I realize that I've proposed a definition after showing it to be meaningless; however, the term has already been released into the wilds of the govt documents community lexicon (and GPO, I assume, will continue to use the term). I thought it best to define it in order to highlight the core roles of libraries (collecting, organizing, preserving and giving access to information). "Digital depository" might be a more meaningful term, so community members may want to start using that instead. The first step is of course to define our terms clearly and succinctly and hopefully I have done that here. We'd greatly appreciate any comments you may have. And if you can coin a better term, please leave that in the comments as well. Continue reading

Continue Reading →

Nonlawyer’s Journey through Title 44: Collected Postings

In May 2006, Daniel Cornwall started an irregular series examining Title 44 of the United States Code from a documents librarian, nonlawyer's perspective. Title 44 is called PUBLIC PRINTING AND DOCUMENTS and contains numerous provisions. This series focuses on three aspects of the law - the Federal Depository Library Program (Chapter 19), the Sales Program (Chapter 17), and Access to Federal Electronic Government Information (Chapter 41). Comments on any sections of highlighted provisions, especially from attorneys or those with greater experience with interpreting Title 44 than Daniel are welcome either here or in the listed blog entries. Private comments can be sent to dnlcornwal AT alaska dot net. Series postings for Nonlawyer's Journal through Title 44

Update October 2007: Daniel has decided to end the series with the last part published back in 2006.

Last updated October 22, 2007

Continue reading

Continue Reading →

Access to Government Information, pre and post 9/11

Access to Government Information, pre and post 9/11. By James A. Jacobs An examination and discussion of the impact the events of Sept. 11 have had on Government Publications and libraries. A presentation at the event Intellectual freedom in libraries post 9/11 April 9, 2002 Sponsored by Librarians Association of the University of California Riverside […]

Continue Reading →

Latest Posts

Latest Comments

Blogroll

Archives

Meta

Archives

Powered by WordPress / Academica WordPress Theme by WPZOOM