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
Your tax dollars at work, literally
Here are two news items for taxpayers to chew on:
Continue readingLunchtime 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
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)
GPO LOCKSS Report: Why does GPO want to use IP Authentication?
April 9, 2007 / Leave a comment
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":
And, later, the report stresses the costs of IP Authentication:
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.
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 →