PURLs: What Do I Need to Know?
Working with PURLs in Your Local Catalog

Now that Arlene has provided some background on PURL technology, GPO’s use of PURLs, and issues related to link-checking, I am going to move on to the second topic we want to address: "Working with PURLs in Your Local Catalog." Actually, in many ways, this portion could be titled: "Working with URLs and PURLs in Your Local Catalog," since so many issues involving one of them are intertwined with the other, when it comes to daily application in a library’s workload.

Because my portion of our presentation is very much about the nuts and bolts issues of daily survival, I’ve prepared a handout titled "Suggested Checklist for Local Decision-Making: Working with URLs/PURLs in Your Local Catalog." The other page of our handout features useful online sites for: Background on PURLs, Link-Checking Software, Guidelines for Using MARC Field 856, and Local Cataloging Procedures available on the Web. The online procedures were reported to us as a result of a survey.

At the beginning of March, I posted a Survey to the GOVDOC-L discussion list titled: "Issues in Cataloging PURLS." I wanted to obtain feedback from depository librarians and staff regarding their own "real life" experiences dealing with issues of working with PURLs. Prior to my cut-off time of April 2 for figuring statistics, I did receive 54 responses, with several coming in last week as well.

As I tabulated the data from these surveys, I was struck by the variety in the responses. There are only a handful of institutions which have really dedicated significant resources to preventive maintenance through the use of PURLs.

Two libraries which have addressed their commitment to PURLs are California State University at Fullerton and the University of Delaware. They both replace URLs in catalog records with GPO PURLs to support persistent access. By the way, they also both have working procedures online, which you may want to review. The List of Resources is online at: <www.willamette.edu/~aweible/dlc/index.htm>.

In the survey responses, about 60% of responders stated they do accept the use of the PURL convention as a resolution to the link-checking problem. There is probably a considerable range of interpretation as to what this means exactly, but from responses to other questions, it seems clear to me that many libraries are eager for a viable solution to the URL stability problem which does not cost them much in terms of investment of resources.

• Yea = 60%

• Nay = 40%

On the other hand, 40% of survey responders stated either: "No, they do not accept the PURL solution," or that they are undecided. Once again, there are various reasons why librarians hesitate to buy into the PURL, ranging from a lack of understanding of the PURL concept, to the deadlink issue, to concerns that reporting efforts on broken URLs will prove insufficient, to fears that their libraries will not be able to sustain the workload on problem records.

The fear of additional workload is very real. Many of us have had to establish cumbersome "work-arounds" to make up for deficiencies in our systems. But, it is still fair to say that a significant percentage of libraries are simply waiting to begin when the technology and the rules are clearer. In fact, if I have to characterize what all of us are doing regarding PURL technology, I would express it thus: 20% of us are just waiting and 80% of us are doing a little bit of everything... and also waiting!

I’m going to talk just briefly about a statistical breakdown of who responded, and then go on to discuss items in the Checklist. Along the way, I will offer response data gathered from the survey. I do want to make it clear that this is an informal survey. It only provides an overview of the topic, even though it posed some very specific questions.

In a couple of instances it seems that those taking the survey interpreted the questions differently, and occasionally there were answers given by people who seemed not to really understand the question. Overall, however, the survey feedback was extremely useful to me in preparing the Checklist; and, even though 54 depositories are a fraction of the total, I think the responses provide a very good bellwether system for looking at the issues we are all facing.

1. Number of responses by Library Type

39 Academic General Library

6 Public Library

3 Academic Law Library

2 Community College

1 State Library

1 Special Library

1 Federal Agency

While 72% of the responders were from Academic General Libraries, there was useful feedback provided by most of the library types designated by the GPO.

2. Number of Responses by Depository Type:

Seven regional depositories and 47 selectives responded. The regionals were:

New Mexico State Library

Newark Public Library

University of Hawaii - Manoa

University of Iowa

University of Kentucky

University of New Mexico

University of North Dakota

3. Number of Responses by Depository Size:

29 Large

17 Medium

8 Small

Once again, there is representation from all sizes of libraries, with the larger depositories providing over half of the responses.

4. Number of Responses by Depository Selection Percentage:

0 - 20% = 13

21 - 40% = 10

41 - 60% = 13

61 - 80% = 09

81 - 100% = 09

The breakout of figures shows a reasonable five-way split among responders.

5. Library Systems Vendors:

Most of the major vendors are represented, with Innovative (III) being the majority system used by responders, and NOTIS running second. (**Ameritech is a vendor representing potentially three systems. The three responses under that vendor may belong to DYNIX, HORIZON, or NOTIS.)

This leads to our first point in the Checklist:

1. Technology: Does Your Library Cataloging System Have Hotlinks (Or Web Browser Interface?)

Yes 39 depositories (72%)

No 15 depositories (28%)

Or, do you plan to have a hotlinked system in the near future?

Yes = 7 of the 15 currently without hotlinks

Timing is everything! The usefulness of the 856 field data takes on entirely different meaning when a simple "click" transports your patrons to the title online. If the technology is there, you are not only obligated to use it, you are probably excited at the prospect of making it all happen for your users... and you are also probably feeling the obligation to make it happen "right."

In the survey, 72% of those responding say "Yes," they do have Web browser access in their library catalog. Of the remaining libraries who do not yet have this feature (28%), about half of those stated that they have upcoming plans to implement it.

A related issue: Is Your Library Currently Cataloging Internet Resources?

Yes 43 (80%)

No 11 (20%)

When did you begin?

1994 01

1995 03

1996 08

1997 14

1998 11

1999 02

Not sure 4

As you see, 80% of those responding said they are currently cataloging Internet resources. While only 4 stated they had begun prior to 1996, the desire to manage Internet resources within the library catalog gathered steam in 1996 and the majority of responses indicated they had begun in 1997. Several have just begun this year. If you do not yet have hotlinks, you should probably engage in some pre-planning and perhaps develop preliminary strategies for your institution.

Since many more resources must be considered than just having the proper technical equipment for working with Internet records, you should early on ask yourself question number 2 from the Checklist:

2. Is There Administrative Support for Cataloging Internet Resources at Your Library?

Over 80% of the survey responders stated that "yes" they do have administrative support for the cataloging of these resources. Frankly, it would be hard to envision proceeding with such a task without at least the philosophical support of your institution. Financial support in terms of commitment of time and staff resources are important as well.

Of the 9 survey libraries who stated they do not currently have administrative support, half had requested support and had it denied. One librarian stated "I never requested support because I knew it wouldn’t be given. I’m expected to do it all." Altogether, however, reasons given by administrators for non-support are really quite reasonable:

• We don’t have the staff.
• It’s too expensive.
• We don’t have Web access.
• We have no utility to deal with all the changing or dead URLs.
• Technical Services is not trained or prepared - we want to wait for a reorganization.
• We anticipate a change in our system and want to wait.

There are three important points to keep in mind regarding administrative support:

1. Cataloging Internet resources is a library-wide issue and requires the support of the administration to survive the ongoing changes in technology and commitment of library resources.
2. Once you have administrative support, leave little to chance. Use resources wisely by setting goals before you begin the work.
3. If you do not currently have administrative support, do not play dead. Learn as much as you can about the issues of URLs and PURLs, and re-evaluate your options periodically. When the time comes to receive administrative support, be ready to go.

So, to review, your initial considerations should be:

1. Technology: Is your OPAC hotlinked?
2. Administrative support: Do you have it?
3. Resources: What can you commit in terms of staff, time and maintenance?

1. Scope

Who will be involved?

What Level of Commitment Will We Have?

What Goals Should We Set?

2. Tag All the Players

Govdocs? Cataloging? Ref? CD? Systems?

Students? Paraprofessionals? Librarians?

3. Standards

Single vs. Multiple Record Cataloging?

PURL Protocol or Not?

4. Organization of the Workload

Who Will Manage the Work?

Who Will Do the Work?

5. Pilot Project - A Useful Option
6. Write a Mission Statement
7. Prepare for Change; Be Flexible

1. & B. Scope and Tagging the Players:

The steps I suggest for planning are probably familiar to you who are old hands at managing library projects. When you discuss the scope of the project and who the players will be, I suggest that you think big. PURLs are a larger issue than just for cataloging - there are many collection management considerations. The workload may extend to staff in Systems Departments and the selection issues will impact on both Collection Development and Reference. So, try to tag all the "players" at the outset.

Regarding standards, perhaps you are a large library and will build on existing policies for your standards regarding cataloging of Internet resources. However, even what seems like a simple question can lead to extensive discussion, or even become controversial. For example, the survey posed this question:

Here are the responses:

• 29 libraries say they are using single record cataloging - although some characterize this as "whatever GPO does" and a few of these added "so far!"
• 12 responders left this blank.
• Only 2 indicated they have chosen the multiple record standard.
• 11 institutions are using both single and multiple records when necessary, and my prediction is that this will become even more prevalent.

Some of the rationales are as follows:

• "Use single record for serials, separate records for monographs."
• "We maintain separate records for paper and microfiche...adding the URL to both paper and microfiche records."

When you begin adding URLs to more than one record for a title, you are doubling or tripling your workload. Libraries which did not chose single-record cataloging for the duplicate physical formats of paper and microfiche have some thinking to do. While we adhere to single-record cataloging at Wichita State, it is not unusual for us to have more than one record for a title. For example: the CIA World Factbook. We select this in both paper and CD-ROM, and the CD-ROM has its own record. So, when there is also a record for a title in CD-ROM format, there could be a second or third record with an 856 to manage.

At my institution, if there is more than one cataloging record for a title, I provide an additional record for the online title. The index makes it clear to the patron that there is online access. And, my staff does not have to manage the URL/PURL in more than one record. We do add the 530 note to the records for the physical formats stating: "Also available online."

Because we do not use tape-loaded records, we do not have to worry about the implications of overlaying records where the 856 field has been amended by GPO. Since an overlay tags an OCLC number, there are workload implications for libraries with more than one record per title in their databases.

The outcome to the workload planning at your library will, of course, be determined largely by your available resources in staffing, other project commitments, and your current culture. In my opinion, the push to manage Internet resources in a library catalog system has the potential to blend departments in ways not typical in traditional library workflows. For example, when asked in the survey: "Who is responsible for cataloging Internet resources?" only 10% of responders said that it is handled in Government Documents. Forty percent stated that Cataloging is responsible. And, significantly, nearly 50% of answers show that this is a combined departmental effort. I think this movement across departmental lines is healthy, in that there can be a flexibility introduced which can lead to higher productivity.

Moving to the staffing resources in terms of FTE (or time) allotted to cataloging Internet resources, there is also quite a variance in commitment, according to survey responses. On the "haves" side, one library has 2 FTE handling this task, 1.5 in Cataloging and .5 in Documents. Five responses showed 1 FTE assigned to this project. On the flip side, there were also five libraries who answered "none." Far more typical is an assignment of 8 to 10 hours weekly to this task.

As I mention in the checklist, if you or your administration are uncertain about the level of resource commitment to this effort, start small. You can then evaluate the time and talent required, as well as discover problems and rewrite procedures. In Arlene’s half of this presentation, she described the commitment to link checking at her institution. In contrast to Arlene’s institution, my university is in a "wait and see" mode. I’ll explain why in a minute. However, a year and a half ago, we were all ready to tackle the issue of Internet resources, and the Principal Cataloger and I received permission to conduct a pilot project to determine the following:

• To identify problems associated with cataloging Internet resources.
• To develop and test a plan for selecting Internet resources
• To have Cataloging provide access to the selected resources
• To determine costs for selection and cataloging
• To select a method of testing the links electronically
• To explore maintenance issues

The project was divided into phases over a six-month period of time, with an initial reporting phase half way through and a final project analysis. It was an elaborate but rewarding process. We were able to establish policies and procedures for all our work with Internet resources, both in government documents and for other resources. We also chose a link-checking package (for us, it was InfoLink Link Checker 1.9), which required some customization and ran this once. Our plan had been to run the package weekly, but this did not happen.

I stated earlier that we are now in a "wait and see" mode. Perhaps our situation is not unusual. Here is what has happened in the past year.

1. The Computing Center withdrew support for running the link checking package weekly, due to other commitments.
2. The Library Administration did not pressure the Computing Center to cooperate.
3. The Library Dean retired and other priorities took precedence.
4. The add-on module providing Web interface to our library’s online system (WebPac), went down. As a NOTIS site, we had purchased WebPac in order to provide hotlinks.
5. The Vice President of Academic Affairs arranged funding for a new library system, which resulted in RFPs and directed attention away from the ailing WebPac module.
6. The Interim Library Administration did not pressure the Computing Center to find the problems with WebPac and now, seven months later, WebPac hotlinks still do not function, or at least not every day.
7. The focus now is on waiting for the new system, which will have a Web interface and we won’t have to worry about WebPac.
8. In addition, we now want to wait and see how the library database migrates to the new system before we work in any intentional way on Internet resources. Since we do not currently have tapeloaded government document records, we can survive this. And, the pilot project we conducted over a year ago will still provide us with useful insights for working with the new system.

1. Mission Statement:

To complete your planning, it would be useful to write a mission statement to articulate your vision. Such a statement should be simple and straightforward. On the screen, you can see what the member libraries of VIVA, the Virtual Library of Virginia, wrote as their mission:

"VIVA's mission is to provide, in an equitable, cooperative and cost effective manner, enhanced access to library and information resources for the Commonwealth of Virginia's academic libraries serving the higher education community."

I gleaned this piece of information from looking over the online procedures shared with me in the survey, and, again, I commend them to you from our handout.

2. Prepare for change and be flexible:

This statement could be the mantra of the electronic transition! Most of us who have been involved with managing organizational change are well aware of the need for preparation and flexibility, but it bears repeating in any planning outline.

Step 3. Cataloging Considerations:

1. What Will Be the Source of the Records?

As I said earlier, 80% of the libraries responding to the survey indicated they are currently cataloging Internet resources. This probably means everything from vendor tapeloads of government document records to careful scrutiny from professional catalogers. However, there seem to me to be two primary considerations with regard to cataloging: "What will be the source of the records?" and "What are the cataloging issues for us?"

The survey asked "What is the source of your records for government documents?

Vendor tapeloads = 50%

Bibliographic Utility = 30%

Both = 20%

More than half of the libraries responding use vendor tapeloads, with the overwhelming majority using Marcive. The only other vendor mentioned was the OCLC tape service and the ratio was 35:2 - Marcive. The remainder of the libraries are using the bibliographic utility OCLC. However, more than half of the libraries using vendor tapeloads also use OCLC, so there is cross-over activity.

It is very important if you are using a vendor to determine what expectations you have of them and to be clear about the issues which can or cannot be controlled by a vendor. I received voluminous feedback to the question: "Do you have issues with the 856 fields in tapeloaded records?" Many, many of these related as much to the insufficiencies of library systems as they did to vendor concerns. These issues are usually intertwined. I will share a few of these responses with you later when I talk about systems considerations.

Further cataloging-related concerns which produced many comments were "GPO policies" and "GPO cataloging." Some of the comments batched are:

• Maintenance Issues

• Point of entry Issues

• Consistency of Records

Field 856 Data Elements: Another question I asked in the survey related to the 856 field was: "How have you managed your 856 fields when a PURL was placed in the same field with a URL? Thirty-five libraries responded:

When manually changing the data:

There has been considerable debate recently as to the placement of the URL, when replaced by the PURL. Since MARBI has now limited the number of |u’s to one in each 856 field and Tad Downing announced yesterday that GPO cataloging policy will adopt this as a standard, the problem of display should be minimized in the future; however, most of us have hundreds of records in our databases which have multiple delimiter u’s. For any amendment of these, we will either have to wait for record updates or manage manually. Thirty-five libraries responded to the question of where the URL should be placed in a three-way tie between: subfield x (non-public note), subfield z (public note), and other. Several prefer an additional 856 and several requested the 538 field. GPO Cataloging has just announced that they are preparing to use the 530/538 fields for URLs replaced by PURLs.

There are two issues I want to discuss which fall into the category of "evaluation:"

1. Site evaluation: Checking the URL for point of entry and validity; and
2. Resource evaluation: What additional Internet resources should we add to our electronic collection?

Even if you are used to obtaining records from a vendor and pretty much accept them without amendment, questions of evaluation are bound to come up sooner or later.

For example, will you evaluate the point of entry for a URL or PURL? In the survey, over 50% of responders say they are evaluating their 856 fields for point of entry and content. Sixty percent say they check sites for accuracy at the time they initially work on their records.

Is it a problem to you that clicking on an 856 field might take a patron to an agency home page rather than going directly to a specific title? Or, perhaps you prefer the more general entry point for the patron. If the agency home page has a useful list of titles to choose from, the patron could actually benefit from seeing what else is published by them. Too, if the specific electronic address to the title is ever amended, or disappears, you will already be directing the patron to the broader list of choices, so there is a better chance of their not being confused by disappearing resources.

Another example: Perhaps you learn that a URL which used to lead to the 1996 annual report of an agency is now the 1997 report. However, the URL has not changed. The electronic address still has the 1996 included in it. There is no choice between 1996 or 1997--the 1996 annual report is no longer there. AND the 1996 report does not appear to be posted at the agency Web site anywhere.

This happened to me last fall. Clearly, to this agency, Web space is Web space, no matter what the designation on the URL, or they would have created a URL for their 1997 report with the 1997 in it. I e-mailed the agency to inquire about the 1996 report. Where was it? They responded that they had taken it down from the Web, but that it was still available for purchase in paper format. However, they said, 1996 is the last year for which the report will be published in a physical format. I then inquired as to whether they would leave 1997 up when they released the 1998 edition, especially as 1997 would no longer be archived anywhere if they took it off the Web. They responded that they did not know yet.

Now, these comments are not intended so much to complain about the inconsistencies of agency protocols as they are meant to point to the amount of time and thought one has to give to just one decision set when dealing with a hot-linked database record. The magic of electronic access has brought us additional workload. At least books don’t fly around the room to other shelves and microfiche don’t leap from drawer to drawer, although there are times when I think they mate in the night and reproduce themselves!

Staffing:

As a fourth example, your library may set a course of adding electronic resources outside your normal profile for physical items. Perhaps you are downsizing or perhaps you are taking advantage of the virtual library world to provide your patrons with added value. You will need to ask yourselves: Who will do this work? Going back to survey responses on the question of "Who is responsible for evaluating sites?", answers were varied and sometimes point to a group effort. The most typical answers are the "Government Documents Librarian" or the "Cataloger" or the two together. But, others are also assigned to this task:

It is useful to note that twice as many libraries are addressing evaluation of resources for inclusion in the catalog with a team or cooperative effort as those just assigning one person to this task. Clearly, there are inter-departmental ramifications to this decision-making.

• Display of Field 856

• Or, Devise Working Strategies for Problems ("work-arounds")
• Potential for System Migration
• Upgrades from System Vendors

It is extremely important to study how your system displays the 856 field, because some of the potential problems associated with the 856 are system vendor-related. Some of these issues may be resolved by working closely with your programmer or systems staff. At Wichita State, where we currently have the NOTIS system, we have worked with our programmer to pull the 856 into the short view of the patron record, because we know that typically a patron does not even look at the long view.

In other cases, you may have problems which will only be fixed by a new release for your system. An example of this is the Innovative system, which currently will only display to the public the first |u in an 856 field. The majority of Innovative libraries which responded to my survey indicated that they are manually moving the PURL to position it first, when the PURL has been added after the URL was placed in a record.

In addition, there are several systems, including CARL, which do display multiple URLs from a single 856, but often run them together into a single and totally unusable link. SIRSI has been known to repeat identical 856 fields when records are loaded. PALS cannot be set for overlay of individual fields.

In the NOTIS patron display, we can designate the Location as "Internet" and instead of a Call Number, we can input "Electronic Resource." However, we cannot amend the Status, which is "Check Shelf." Of course, this is not what we want to have our users do for an Internet resource, or they could report that the item must be missing from the shelf; but the programming is not amendable for this category.

The good news, of course, is that eventually some of our frustrations will be lessened either because our libraries will migrate systems to one better designed for Web interface, or because systems vendors will develop tools to help us manage display and link-checking issues.

• How important is absolutely accurate URL information in your catalog?
• If accuracy is a priority, how will records be kept up to date?
• Will you systematically check URL/PURL links for validity?
• How will you check links? System-generated or link checking software? Manually?
• How often?
• Who will do the work?
• What will you do with the data you collect?
• Will you have staff and time to be consistent?

Arlene has covered the technical aspects of link checking, so I will say just a few words about the management aspect of maintenance issues. It is important that each institution decide at the outset just how important it is to have absolutely accurate URL information in their catalog. The Checklist handout suggests a range of considerations if your library establishes accuracy as a priority. Primarily those are: how will the records be kept up to date? Which link checking software will you choose, or do you have a system-generated software for this purpose? How often will you run the link checker? What staff will be involved? What will you do with the data you collect? Will you have sufficient staff and time to complete this work periodically?

According to my survey, slightly more libraries are NOT systematically checking URLs than are. There were 24 responders saying "Yes, they do." and 26 saying "no." There was also one that stated "Yes...somewhat," which probably reflects what is true of many libraries: they are doing their best to manage the problem, but on more of an ad hoc basis.

Only three link checking packages were mentioned in the survey: LinkBot (the most popular), MomSpider, and "homegrown." More libraries reported checking URLs manually than those who are using link checking software. Of those conducting the checking on a regular basis, the favored timing is monthly, followed by quarterly. Some reported checking only when problems are reported.

• Develop written policies and procedures.
• Report regularly to your staff and administration on your progress.
• Take advantage of your system’s reporting capabilities, especially for tracking the 856 fields available in the catalog’s records.
• Report broken links you discover to GPO.

Finally, the last step in your process: reporting. Do keep both your administration and your staff advised of problems and progress. As most of you know from experience, written procedures are crucial in dealing with complex technologies. And, finally, I will re-emphasize Arlene’s comments regarding reporting of broken links to GPO.

Finally, my survey comments would not be complete without mentioning the information gathered as to what depository librarians want from the GPO. There is much positive feedback about PURLs. Librarians stated that they are "counting on them" and that they are "essential" if we are not to duplicate work constantly and waste our resources of staff and time. There is an appreciation that GPO determined to take responsibility for record problems by embracing the PURL technology. Librarians also shared their expectations of GPO at this point:

• Make it easier for us to report broken links and other problems.
• Move rapidly to convert the old URLs to PURLs.
• Provide regular online reports listing PURLs assigned.
• Allow depository librarians to assist in maintenance of links on the PURL server.

Thank you very much for your presence here today listening to the issues involved with embracing a new technology: PURLs. At this time, Arlene and I would like to open up the session for questions and answers.