Committee Members

Philip Herold, Nan Hyland, Bob Kibbee, Jim LeBlanc (Chair), Tim Lynch

Charge

Reporting to the Library Gateway Committee and in consultation with Library Technology, Public Services, and Technical Services staff, the Working Group on Networked Resources Access Before the ENCompass Era (WGNRABENCE) will develop a proposal specifying how CUL should provide for the effective discovery of and access to networked resources over the next 18 months, i.e., until Endeavor's ENCompass product becomes fully operational. In this investigation, the Working Group will:

• Consider the strengths and weaknesses from both the user and staff support perspectives of CUL's current environment consisting of the Gateway's Networked Resources browse and search functions and the Library Catalog;
• Reevaluate and build upon Tom Gale's document "Networked Resources Integration Team Proposal" based on CUL's experience with, and expanding knowledge of Voyager and the changing environment at CUL with regard to the bibliographic control of networked resources;
• Take into account the relative development and maintenance costs of the alternatives considered.

Executive Summary

After an extensive review of the scope and structure of the Networked Resources catalog (NR) from the point of view of various stakeholders, including recent feedback from focus groups, the Instruction/Reference Program Committee and the Working Group on Cataloging, WGNRABENCE reached the following basic conclusions regarding NR and its relation to the Voyager OPAC:

• NR is still is a highly useful resource for the discovery of, and access to networked resources, especially those of obvious reference and research value (e.g. indexes, abstracts, directories, digests, etc.); the ability to browse by NR subject, to limit searches by genre, and to mount locally-created intermediary help pages and connection-related error messages are especially useful attributes of the NR catalog.
• On the other hand, NR is reaching the limits of its scalability; in many cases, previously concise retrieval sets have become too large and unwieldy to be useful.
• The prominence of important reference and research titles would be greatly enhanced through a reduction in the number of titles available through NR and/or through some type of reorganization of the retrieval set (e.g., if hits could be displayed in terms of importance, not necessarily alphabetically).
• Given that NR does not, and never has represented all of CUL's networked resources, users and staff alike would greatly benefit from a clearly-defined policy of what kind of resources NR contains and what it does not contain.
• The Voyager OPAC provides sufficient access to many networked resources, most notably to electronic journals and e-books, as to make their inclusion in NR somewhat redundant.
• Reducing the scope of NR by excluding e-journals, e-books, and perhaps other categories of non-reference material from that database, would enable more streamlined and timely cataloging of electronic resources and increased access to more resources in all formats for the CUL collection as a whole.
• There is still a need to provide easy access to lists of electronic journals.
• Significant structural changes to NR would not be cost-effective at this time, given CUL's commitment to a timely implementation of ENCompass.

With these criteria in mind, the group found the three options outlined in the document, "Networked Resources Integration Team Proposal," to be inadequate for our current needs. We also chose to examine the idea of simply doing away with the NR catalog altogether and making the current Voyager OPAC interface our single point of entry for the interim period. This option, too, we dismissed as inadequate for our current needs. In the end, we compiled a recommendation that we feel would go the furthest to address the eight basic concerns outlined above. That recommendation is presented in depth below.

Rejected Options

Given the terms of our charge, we re-examined the options laid out in Tom Gale's "Networked Resources Integration Team Proposal," as well as the idea of eliminating the NR catalog altogether. These options are:

Option 1:  Stay the course

Brief Description:
Do nothing until we implement ENCompass, maintaining access to networked resources through both NR and the Voyager OPAC.

Pros:

• Would preserve the current end-user interface;
• Would require no retraining of users and staff;
• Would entail no redesign or development costs.

Cons:

• Would do nothing to make reference e-resources more prominent or to reduce the size of local subject browse retrieval sets;
• Would not address the NR contents definition problem;
• Would not eliminate the need to catalog networked resources in two databases;
• Would not facilitate the import of aggregate collections by automated means.

Costs:

• For IT: the continued expense of maintaining connection scripts, etc.;
• For Technical Services, the continued processing and maintenance expense of cataloging networked resources in two databases and the currently limited ability to import aggregate collections by automated means ($4-$16 per title*);
• No new costs.

Option 2:  Eliminate the NR catalog

Brief Description:
Remove NR from the Library Gateway and rely exclusively on the current Voyager OPAC to present networked resources through the use of search limits.

Pros:

• Would eliminate the need to catalog networked resources in two databases;
• Would facilitate the import of new catalog records by automated means;
• Would eliminate confusion over where to find library resources;
• Would place e-journal holdings in the context of the library's complete journal holdings for all formats;
• Would eliminate the need to define what is or is not available through NR.

Cons:

• Would do nothing to make reference e-resources more prominent;
• Would eliminate the NR subject browse feature;
• Would eliminate locally-created intermediary help pages and connection-related error messages;
• Would eliminate NR pathfinders such as "i", "C", and "+/-";
• Would eliminate automated selection for MyLinks of those resources no longer available through NR;
• Would require significant retraining of users and staff;
• Would be wildly unpopular.

Costs:

• For IT: because most IT work involves connection script maintenance, there would be no reduction in workload; some redesign work would be required (estimate = 1-2 months, 1 FTE);
• For Public Services: moderate-to-heavy re-education and public relations expense;
• For Technical Services: none, in fact TS would realize significant savings ($4-$16 per title*).

Option 3:  The Logical Volume Option  (Option 1 from Tom Gale's "Networked Resources Integration Team Proposal" -- see Appendix)

Brief Description:
This technological initiative would integrate NR as a "logical volume" in the Voyager OPAC. Under this setup, the corresponding MARC records in Voyager would be virtually grouped into a separate Voyager database to be queried via WebVoyage.

Pros:

• Would eliminate the need to catalog networked resources in two databases.

Cons:

• Would do nothing to make reference e-resources more prominent or to reduce the size of local subject browse retrieval sets;
• Would not preserve the current end-user interface;
• Would eliminate locally-created intermediary help pages and connection-related error messages;
• Would eliminate NR pathfinders such as "i", "C", and "+/-";
• Would eliminate automated selection for MyLinks of those resources no longer available through NR;
• Design of end-user interface would be limited by WebVoyage; dependence on WebVoyage creates potential for failure whenever Endeavor updates or changes that interface;
• Would require the addition of the complete hierarchy of subject browse terms to MARC records, if such browsing were even possible given the limitations of the WebVoyage front end;
• Would not facilitate the import of new catalog records by automated means.

Costs:

• For IT: this alternative would impact both the central ITD group and Mann ITS; to create the appearance of an NR database within the OPAC (i.e. the "logical volume") would require 2-4 months, 1 FTE on the part of ITD and 2-4 months, 1 FTE on the part of ITS; after that initial redesign work, maintenance workload would be similar to what it is currently;
• For Technical Services: none, in fact TS would realize significant savings ($4-$16 per title*).

Option 4:  Build a Z39.50 or Perl DBI interface to the Voyager Database  (Option 2 from Tom Gale's "Networked Resources Integration Team Proposal" -- see Appendix)

Brief Description:
This option builds on Option 3, integrating NR into the Voyager OPAC, to provide a more complete emulation of the current Gateway. This approach could potentially restore some of the features lost in implementing the "logical volume" option. Gale's paper outlines one possible technical solution (Z39.50) for restoring the lost functionality; there may be other technical options. Further study by ITS and ITD would be required, though, to ascertain exactly what functionality could be retained and what would be lost as well as the overall effort needed to implement this option.

Pros:

• Would preserve the current end-user interface;
• Would require no retraining of users and staff;
• Would eliminate the need to catalog networked resources in two databases;

Cons:

• Would do nothing to make reference e-resources more prominent or to reduce the size of local subject browse retrieval sets;
• Would not address the NR contents definition problem;
• Might require the redesign of keyword indexing and subject browsing;
• Complete hierarchy of subject browse terms would need to be added to MARC records;
• Would not facilitate the import of new catalog records by automated means.

Costs:

• For IT: since this approach builds on the idea of the logical volume, extending that concept to reestablish some of the functionality that would be lost in Option #3, both ITD and ITS would incur expenses; to build a new Gateway-like interface to the logical volume would require 2-4 months, 1 FTE on the part of ITD and 4-6 months, 1 FTE on the part of ITS;
• For Technical Services: none, in fact TS would realize some modest savings ($4/$5 per title*).

Recommendation

Redefine the scope of the NR catalog to give more prominence to resources of significant reference or research value by excluding certain genres of material, most notably e-journals and e-books, from the public view of NR. For these excluded categories, only brief, display-suppressed NR records would be needed from which to hang Access Info records (where scripting and authentication information for all Cornell-only resources is recorded). In addition, implement a small technical enhancement to provide for the generation of lists of e-journals either from the Library Gateway home page or from some intermediate "Networked Resources" index page.

Description:
This initiative calls for a redefinition of the scope of NR to include all networked resources of certain types (especially those of significant reference or research value), while excluding all networked resources of other types (especially e-books and e-journals). We are, in any case, sorely in need of a clear policy definition of what is and is not contained in the NR catalog, and such a definition, inscribed prominently on the NR search page or in some other appropriate location, is at the heart of our recommendation. In addition, the need to continue to provide locally-created intermediary help pages and connection-related error messages for all Cornell-only e-resources (even those represented only in the OPAC) can be addressed through a small change in workflow, at a negligible cost (brief NR records including Voyager ID, title, and URL would still need to be created for most Cornell-only resources). Finally, we need to examine how best to organize and present e-journals -- for example, a complete list of e-journals, generated periodically through SQL queries of the Voyager database, could be made available via the Library Gateway home page, again for a minimal technical and development cost.

Pros:

• Would make reference e-resources more prominent in NR through the reduction in size of local subject browse retrieval sets;
• Would preserve NR pathfinders such as "i", "C", and "+/-" icons for those titles of significant reference or research value;
• Would preserve locally-created intermediary help pages and connection-related error messages for all Cornell-only resources;
• Would make it clearer to users and staff alike what NR contains and what it does not contain;
• Would eliminate the need to catalog certain categories of resources in two databases;
• Would facilitate the import of new catalog records by automated means;
• Would give more prominence in the Gateway to the capacity to generate lists of e-journals;
• Would place e-journal holdings in the context of the library's complete journal holdings for all formats.

Cons:

• Would require a certain amount of retraining of users and staff;
• Might be difficult to decide what does and does not belong in NR, outside of broad categories such as e-journals, e-books, indexes, abstracts, aggregator sites, encyclopedias, etc.;
• Access to those e-resources excluded from NR would be limited by Voyager functionality;
• Would eliminate automated selection for MyLinks of those resources no longer available through NR.

Costs:

• For IT: minimal upfront costs to suppress from the NR public interface those existing records for categories of material that will no longer be represented in NR; minimal development costs (a few days of programmer time) for periodically-generated e-journal lists, or whatever approach we take to organizing and presenting e-journals;
• For Public Services: some re-education and public relations expense;
• For Technical Services: significant savings ($4-$16 per title^*) when processing those e-resources that will not be included in NR; though NR records would still be required such resources (when access to them is Cornell-only), the creation of these records would be extremely straightforward and could probably be accomplished in a more cost-effective manner than it is currently.

WGNRABENCE also recommends:

• A new user study to determine current needs and behavior patterns of NR users before any significant redesign or redefinition is undertaken;
• A re-examination of the NR public interface to provide better visual cues to distinguish between those types of resources that will remain in the NR catalog;
• A re-examination of the NR browsable subject captions to provide more balanced access across disciplines to those types of resources remaining the NR catalog;
• The formation of an implementation team to carry out the terms of this recommendation; this team should include representatives from Reference, Technical Services, Information Technology, and Collection Development.

^* Technical services costs are based on two estimates:
      - The supplemental cost of cataloging an item for NR, above and beyond the costs of
         preparing the MARC record for the Voyager OPAC: $4/$5 per title; and
      - The average cost of adding an individual title to the catalog "by hand," rather than
         by automated means: $16.

As part of its charge, the Web Voyage OPAC Implementation Team was recently asked to investigate the migration of the current Networked Resources facilities of the Cornell University Library Gateway with the new Voyager LMS. The group made a recommendation to the Implementation Steering Committee for "… the continued support of a two catalog system …" in the short term with the intention of further investigation and an implementation plan for the migration of Networked Resources into the new LMS.

In light of this recommendation, I was asked to begin investigating the issues surrounding the migration of the Networked Resources and to make a recommendation for implementation. As a part of the procedure, I have begun to take an inventory of the issues. From this initial inventory, it has become clear to me that I will require the input of members from various divisions of the library to collect a comprehensive inventory of all the issues involved, resolve the issues I have already identified and to put forth a plan for implementation.

To this end, I propose a Team be formed whose membership would consist of representatives from Technical Services, Public Services, Gateway Committee, and the WebVoyage OPAC Team. I have included an annotated inventory of issues to elucidate the need for cross-division and committee representation. The inventory of issues is divided into what are the three most likely integration options.

Annotated Inventory of Migration Issues

1. Logical Volume Option

   The first option for migration might be the integration of the Networked Resources section via a logical volume in the Voyager system. Under this set up, all of the bibliographic records in the Voyager system would be virtually separated into a separate voyager database.

   From a user interface perspective, those records would be queried from the 'Database' section of Web Voyage and would be treated as though you were querying a separate Voyager Database called 'Networked Resources'.

   1. Benefits
      1. Merger
         It completely merges the Networked Resources section with the new LMS.

      2. Elimination of Duplication
         It eliminates the duplication of effort for Technical Services Staff when cataloging Networked Resources because resources wholly reside within the Voyager Catalog.

   2. Surrounding Issues
      1. Subject Browsing Functionality:
         In migrating Networked Resources to an integrated system, the loss of the current Gateway subject hierarchical browsing is very likely owing to the limitations of cataloging our custom subject headings into MARC records in Endeavor and the limitations associated with customizing WebVoyage to incorporate our customized interface. From Feb. 1 to Feb. 3, 2000, subj.cgi (the script that provides subject access) was recorded 6755 times in the access_log of the library Gateway. This figure, of course, does not indicate that every instance was a unique user because it represents all instances of the subj.cgi which would include users drilling down through the subject hierarchy. However, even if you assume a user clicked up and down through the hierarchy an average of 10 times in one session, that indicates 675.5 unique uses of the subject browsing facility in a 3 day period. A further note, a librarian from Auckland recently contacted us and asked about the Z39.50 piece of the Gateway. When I explained how it worked, he replied back that they were going to incorporate their subject headings into their MARC record in the 691 field. Perhaps we could mimic their procedure. To discard subject hierarchy without deriving a useful alternative with the help of Technical Services, Public Services and IT staff would be a disservice to users.

      2. Intermediary Error Pages:
         If Networked Resources are migrated into the online catalog by using a logical file of Endeavor records, this means the URLs that will be used for connection via the Web will be those provided by the Endeavor (i.e., the PURLs which lead to direct connections to the resource). Direct connection to the resource rather than going through the connect.cgi that is provided through the Gateway means that when a user tries to connect and fails, they will receive the error pages of the vendor rather than our customized error pages. These custom error pages explain our policies on access and pointers to help and solutions such as the proxy server. Public Services staff need to be consulted to develop alternatives to these point of problem error/help pages and IT staff need to discuss whether or not alternate methods of capturing this functionality are available and how to create them.

      3. Migration of Help:
         With the new WebVOYAGE interface, we have decided to keep the Gateway Help and the WebVOYAGE help separate with pointers between the two. If we migrate the Networked Resources into the OPAC with a completely different searching mechanism and interface, it will require a modification of help and the need to move some of the help from it's current place on the Gateway into the help section for WebVOYAGE. This will require decisions and consultation from the Documentation Committee.

      4. Context Sensitive Pathfinders:
         If Networked Resources are migrated into the online catalog, the context sensitive path finders such as the 'i', 'c' and '+/-' icons that are presented to users to provide them with more information on a resource, identify resources non-Cornellians can use and benefits/drawbacks of varying interfaces will be lost in the WebVoyage interface which is paralyzing in it's customization options. Public Services staff need to be consulted on the gravity of the loss of these facilities and possible alternatives.

      5. New Work Flow:
         If option I were implemented, the current workflow for the addition of records to the GW would have to be reviewed. It would likely retain a similar format, but it should be reviewed at the very least. This would require input from IT and cataloging staff.

      6. MyLibrary Integration:
         The MyLibrary system has at least one component that relies on the current Gateway's Networked Resources section. The piece I'm referring to is the customized search of the Gateway that allows users to search Networked Resources and with the click of a button, add those resources to the 'MyLinks' portion of MyLibrary. This modification will need IT & PESWG support.

      7. Putting Our Eggs into the Endeavor Basket:
         With Option I, we are heavily relying on the WebVOYAGE Catalog and Interface for the presentation of Networked Resources. If there limitations inherent in MARC records, or if there are problems with the presentation of the material to the users owing to interface limitations, we have no customizable catalog or scripts to manipulate the records and output. We must wait for Endeavor to change to accommodate our needs. With a less integrated solution, we may have more control.

2. (Option II) Z39.50 or Perl DBI Interface to Voyager DB

   One alternative to migrating Networked Resources into the Catalog, might be to build a new back end to the Gateway that keeps the old Gateway interface for users, but relies on a Z39.50 component or Perl DBI component for the collection of bibliographic information from the Voyager database. In this scheme, when a user queries the Gateway system, a Z39.50 or Perl DBI interface could be used to query the Voyager database for their search criteria. The record would be retrieved in MARC format from the Voyager Database and then parsed and presented to the user. Alternatively, each time a new record was created on the Voyager database, the voyager record ID might be used to query the Voyager database, retrieve the record in MARC format, parse the record and store it in a local database for indexing and use in the Gateway. This model would be similar to the current model.

   1. Benefits
      1. Retain Gateway Interface Benefits:
         Under this option, we could retain Gateway features such as the intermediary help pages, and the ability to customize the interface as desired.

   2. Surrounding Issues
      1. Duplication of Effort / Subject Browsing:
         There are certain fields (including the Gateway subject heading field) in the Gateway MySQL database. In order to maintain features such as the Subject Browsing feature, these items would have to be accommodated in the Voyager MARC records. If they are not accommodated in the MARC record, they will need to be maintained in the separate MySQL database as they are now if we are to retain the GW browsing and other such facilities. As mentioned above, the folks at Auckland have said "Cataloguers will modify records in Voyager (probably the 691 field) with our own home grown subject hierarchy." Technical Services and IT people will need to discuss which field in the MARC record and how to migrate that data to the new system.

      2. Mass Update:
         Pursuant to a., If a MARC field is found, a Mass Update using the Perl DBI or the Z39.50 piece will need to happen to retroactively update all of the old Networked Resources in the Voyager catalog to reflect the changes to the field (e.g., the 691 field) in the MARC records. Technical Services and IT staff will be needed in this operation.

      3. Keyword Indexing and Subject Browsing Update:
         Further, if the Perl DBI/Z39.50 Solution is undertaken, the portion of the Gateway and the Subject Browsing facility will have to be revisited. Currently, we build our own local index for keyword searching rather than querying the database. Would we continue to do this under a Perl DBI/Z39.50 model or would we query the Voyager database itself. Also, we cache pages rather than query the database for subject browsing pages. Would we continue to pursue this model or change it. If we keep the indexing separate, users could still search the Gateway if the Catalog went down. Performance testing by a prearranged group may determine which system is optimal. IT and Public Services staff could assist in these decisions.

3. Stay the Course Option

   The final option would be to stay the course. That is, after the Z39.50 piece of the gateway is fixed so that it queries Voyager rather than the NOTIS database and parses the record for the overlay function of the staff interface, we could just stay the course and maintain two catalogs in the same fashion that we do now. It is not likely we will pursue this option in the end.

   1. Benefits
      1. Ease of Migration:
         The migration process would be painless. This is why we have elected this option for the short term solution.

   2. Surrounding Issues
      1. Duplication of Effort:
         The main problem put forth with this solution is the duplication of effort problem that catalogers face in creating/updating Gateway records.