510s in CONSER records. Hirons discussed the fate of the 510 abstracting and indexing/coverage fields in CONSER records, noting that a survey taken a number of years ago came out exactly 50/50. The PCC Policy Committee discussed in November and decided it was time to remove the fields without trying to store the data. Hirons and Glenn Patton (OCLC) wanted to reaffirm the sense of the group as to the desirability of doing so. A poll of participants showed that a majority favored removal. 510 data for titles maintained by the National Library of Medicine and Chemical Abstracts will be retained in the records, however.
Friday, February 28, 2003
From the CONSER At Large ALA Midwinter January 26, 2003, Philadelphia Summary of meeting.
at 4:49 PM
An alternative to the proposed LCRI 25.5B is offered in Archival Moving Image Materials: A Cataloging Manual: Comments on Library of Congress Draft Revision and AMIA Proposals for New and Alternative Chapters. There seem to be serious flaws in the proposed LCRI.
at 2:24 PM
My summary of the PURLs/Handles aspect of the creation of persistent identifiers:When deciding on what system to use to help manage collections pointed at with URIs, there are two major systems people use: Handles and PURLs. I have looked at several comparisons of the two systems. Most of them are now getting dated and do not summarize the issues I see as important, so I'm offering my own.This may be somewhat biased towards the PURL system. It is my staff that maintains the PURL code here at OCLC, but I think this lays out the main points that need to be considered:Either system will work. Both have been successfully employed in helping to maintain persistent identifiers to digital itemsThe systems are not quite direct competitors. Handles are built at a slightly higher level than PURLs (more on this below). PURLs have no pretensions other than a way to maintain URIs, and to do this with URLs. Handles have a definition outside the current URL implementation of them.Handles have several advantages
2003 March--Posted with permission. Appeared on DC-General mail list.
- More active software developmentMore active promotion of useJava implementationMigration of a collection of handles from one resolution server to another is 'built in'Defined outside DNS and URLs
- Open Source software license, OSI compliantLower overhead: no centralized server involved in resolution unless wantedSimplerPartial redirects
- Handles can resolve to several versions of an object (whether this is an advantage depends on your point-of-view and application)A Handle system could probably be built on top of PURLs, while PURLs on top of handles would be more difficult. This shows that the systems are operating at slightly different levels. If the Handle system's functionality is just what you need, then it will probably be simpler to use. If not, the PURL system offers more flexibility.
- A good bibliography of some of these issuesSome practical guidelines on creating links with some persistence even without PURLs or Handles ('Cool URIs')Clifford Lynch's 'five questions' about identifier systemsPapers about the Handle SystemHandle System homePURL home
2003 March--Posted with permission. Appeared on DC-General mail list.
at 12:34 PM
"Using a Web OPAC to deliver digital collections" by Eileen C. Mathias appears in Online Information Review (2003) vol. 27 no. 1 pp. 28-36
The Ewell Sale Stewart Library of the Academy of Natural Sciences has just completed a major digital imaging project. This article describes the project, options that were considered for Web delivery of images and text, and reasons for choosing Innovative Interfaces, Inc.'s image management function. The article includes a description of the data entry process as well as a review of the Millennium Media management product, which will be available through Innovative later this year. Evolving image metadata standards are also discussed.
at 8:55 AM
Thursday, February 27, 2003
Wednesday, February 26, 2003
On the DC-General mail list there is a discussion going on about persistence identifiers for Web resources. I've always thought the OCLC PURL resolver was an elegant solution and wondered why it was not more widely used. There also exists CNRI's handle system and the DOI. DOI works just fine, but to join the club one needs deep pockets. That is not yet a solution for small non-profit publishers. There are also other considerations such as designing the Web site to prevent changes, avoiding names based on a current technology, and the long-term needs of the institution.Some of the resources mentioned in the discussion include:
- W3C Persistence PolicyURIs for W3C namespacesCool URIs don't changeUnique Identifiers: a brief introductionUnique Identifiers in a Digital World Information IdentifiersInternational Standard Text Code (ISTC)Persistent Identifiers (documents at the National Library of Australia)On Making and Identifying a "Copy"Identifiers and Their Role In Networked Information ApplicationsUniversal Description, Discovery and Integration (UDDI) protocol
at 9:46 AM
Tuesday, February 25, 2003
The Frequently Asked Questions about changes to the ISBN page covers many questions, including:
at 5:21 PM
I have heard from someone involved in a project to make available examples of the best practices in the forms we use. That is a fine idea, but they have to have someone write them. Lots of them, if they are going to be useful to most libraries. What is best for a large urban library system might not be best for a small rural school library. What is best for a community college will not work for the research university in the same city.I think having lots of examples from all types of libraries would better serve the community than a few examples created by a committee, no matter how well qualified. A repository could also give such a committee some place to start their research.
at 2:06 PM
Those with access to a Mac might be interested in Konfabulator and widgets. Widgets are small open-source programs, easy to create. Currently ones exist to search the Internet Movie Database, Google, and Yahoo. It would be slick for some libraries to create ones that search their catalog. This looks so cool it makes me want access to a Mac.
at 10:04 AM
Avanti MicroLCS version 1.0 beta 2 has been released. It is available for trial and downloading.New in this release is a standalone GUI client application. This graphical client has the same clean, elegant look and feel of the Applet client, but it does not require a web browser to run. This greatly enhances the flexibility of Avanti MicroLCS by allowing it to run end-to-end, from server to client, in environments where a web server and browser are not available or desired. It only requires a computer supporting Java. Also featured in this release are numerous bug fixes and improvements to the API, along with a few minor changes to the user interface.There will be at least one more beta release preceeding the final version 1.0. Development work for beta 3 will focus on very intensive debugging, testing, and refactoring of the existing system. Minimal new functionality will be introduced. The aim is to ensure that what exists is rock solid in every way, is scalable, and works extremely well.Circulation capabilities may appear in the final version 1.0.--Seen on oss4lib