Newkirk Barnes, BOTM for April, 2007

Newkirk Barnes is an Assistant Professor and Government Documents Librarian at the Mitchell Memorial Library at Mississippi State University (MSU). She also serves as the Library Liaison to the MSU Departments of Communication and Foreign Languages. Her research interests include legal research instruction and reference services for non-law students, the effects of Internet migration on public access to U.S. government publications, and outreach programs in academic libraries. Barnes earned her Bachelor of Arts degree in Communication from Tulane University in 2003, graduating magna cum laude. She earned her Master of Library and Information Studies degree from The University of Alabama in 2004. Barnes joined the faculty of the MSU Libraries in 2005 as an Assistant Professor/Reference Librarian. Continue reading

Continue Reading →

Your tax dollars at work, literally

Here are two news items for taxpayers to chew on:

Continue reading

Continue Reading →

Lunchtime Listens: Info Island Project on Second Life

A recent SirsiDynix Institute presentation by Michael Sauers and Rhonda Trueman titled The Info Island Project on Second Life is a hour long overview of Second Life in general and library/university activities in Second Life in particular. I was particularly surprised to find that the Kansas State Library has a Second Life branch. I'll try to check it out sometime this week and get back to you if there is a govdocs angle. This is a great presentation if you want to know what all the fuss is about. The talk even has a set of "reality checks" to help you decide whether you want to check out Second Life. If I haven't mentioned it before, I have to admit that I haven't been active in Second Life for quite awhile and only just recently reinstalled the software. But I'm glad to see people with more time than I exploring and using these kinds of technology. Continue reading

Continue Reading →

GPO 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.

  1. 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.
  2. 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?
  3. 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.
  4. 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.
  5. 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 reading

Continue Reading →

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 →

Archives

Powered by WordPress / Academica WordPress Theme by WPZOOM