vol183&4 17Fall/Winter 1994 This paper will discuss why and how to use gopher servers on the internet to provide access to locally developed data. This includes formatting the data, and establishing the links to the data on the server. The responsibilities involved with providing information on the internet will also be discussed. Reasons to Mount Data on the Internet The internet is a vast source of information and chaos, why would anyone want to add to it? Some possible reasons for mounting data on the internet include: -The internet allows remote access to the data. The data and its users are not limited to physical locations. This means that people from other institutions, as well as your own, can get to your data. -The internet allows 24 hours a day, 7 days a week access to your data (barring the usual network outages or maintenance down time for the data server). -By providing the data on the internet, it is by definition in electronic format. This allows for further manipulation or massaging of the data. It allows users to take advantage of the computer’s abilities, such as searching and sorting. -The internet allows for quick and easy publishing or updating of your data. Reasons Not to Mount Data on the Internet Most of the reasons for not mounting data on the internet are based on privacy and legal issues. -The data is copyrighted and can not be re-distributed. -The data is of sensitive nature and should not be accessible to just anyone, i.e. the world. -The data is already out on the internet, in a number of different places. -The internet location for your data is unreliable or not maintained by anyone. Why Use a Gopher Server Currently, gopher clients are widely distributed across the internet community and are available for most types of computer hardware and operating systems. Most gopher client and gopher server software does not require high level computers on which to run, unlike other internet tools such as Mosaic. Gopher clients, as a rule, are easy to use. They provide a common interface to many different types of resources. The Gopher protocol provides the capability to perform searches on databases and files. Currently, this is mostly primitive string or character-by-character searches. Gopher servers have the ability to link or point to other Gopher servers. This linking ability makes it relatively easy to create subject oriented gopher servers. Gopher Servers as a Point of Access by Julie A. Fore1 Assistant Automation Librarian Indiana University Ruth Lilly Medical Library 18 IASSIST Quarterly RESERVES Collection by AUTHOR Abbas, Abul K. Cellular and molecular immunology. Abdellah, Faye G. Patient-centered approaches to nursing. New directions in patient-centered nursing; guidelines for systems of service, education, and research. Ackermann, Uwe. Essentials of human physiology. [...] Fig. 1 — “Reserve Collection by Author” - Printout from Pro-Cite. Indiana University Ruth Lilly Medical Library Gopher Server Pilot Project The Indiana University Ruth Lilly Medical Library has been maintaining a database of its Permanent Reserve Collection holdings using a bibliographic database management system called Pro-Cite, made by Personal Bibliographic Systems (PBS). The Library uses Pro-Cite to keep this database because the software allows the Library to provide a number of different printouts for the library patrons to use. The Reserve Collection is shelved (mainly) in title order. Pro-Cite allows the Library to generate printouts of the collection in shelflist (title) order, as well as lists sorted by author or subject heading. (fig. 1) The Library patrons make great use of these printouts, as do the Library Circulation Staff. The Permanent Reserve Collection database is small at about 225 records. This made it a perfect pilot for testing how well the Library’s various Pro-Cite databases would make the transition from in-house use only to internet accessible information. The pilot project started with an analysis of the data and data fields already in the Pro-Cite database. (fig 2) Rec# 780 Auth Abbas, Abul K.//Lichtman, Andrew H.//Pober, Jordan S. Titl Cellular and molecular immunology PlPu Philadelphia Publ Saunders Date 1991 Extn xi, 417 p ISBN 0721630324 Call QW 568 A122c 1991 Desc Cellular immunity/Immunity—Molecular aspects/Immunity, Cellular/ Lymphocytes- -immunology Fig. 2 — Example of a bibliographic record in Pro-Cite 19Fall/Winter 1994 After the evaluation of the electronic data, a decision was made as to which data elements would be most valuable to a person accessing the database over the internet. I decided to use basic bibliographic citation fields, i.e. author, title, place of publication, publisher and date; as well as the subject heading information. The data from these six fields were then exported from Pro-Cite using Pro-Cite’s import/export utilities. Pro-Cite created a standard comma ( “,” ) delimited file. (fig 3.) The Gopher Server software being used by the Ruth Lilly Medical Library, KA9Q NOS, requires database files to be in dBASE III or dBASE IV format. While most current database management programs such as Paradox by Borland and R:BASE by Microrim can save data in dBASE III format, we chose to use the dBASE III program for the next part of the pilot program. A database structure was created in dBASE III using the six fields exported from the Pro-Cite database. To keep things simple, the Pro-Cite field labels were used as the field labels in the dBASE database. While Pro-Cite, for the most part, does not use fixed field lengths, dBASE requires fixed field lengths. We made educated guesstimates on what the dBASE field lengths should be. Figure 4 shows the final structure for the Reserves dBASE database. The dBASE III import function was used to convert the Pro-Cite produced comma-delimited file into a dBASE III database. A paper report of the new database was then created to verify two things. First, that the data was correctly transmitted from Pro-Cite to dBASE III. Second, to verify that the data, itself, was correct and complete. The data had indeed transferred correctly, but it was found that some of the records in the original database contained incomplete information. Once the dBASE database had been cleaned up, and an ascii text file bibliography was generated from it using R&R Report Writer by Concentric Data Systems, the data was ready to be transferred to the actual microcomputer running the gopher server software. In the case of the Ruth Lilly Medical Library Gopher Server, this meant taking down the gopher “Abbas, Abul K.//Lichtman, Andrew H.//Pober, Jordan S.”,”Cellular and molecular immunology”,”Philadelphia”,”Saunders”,”1991",”Cellular immunity/Immunity—Molecular aspects/Immunity,Cellular/Lymphocytes—immunology” “Abdellah, Faye G.”,”Patient-centered approaches to nursing”,”New York”,”Macmillan”,”<1960>”,”Nurse-patient relations/Education, Nursing” Fig. 3 — Sample of Pro-Cite Export File in Comma Delimited Format. Structure for Database: C:RESERVES.DBF Number of Data Records: 225 Date of Last Update: 4/21/94 Field Field Name Type Width Dec 1 Auth Character 130 2 Titl Character 200 3 PlPu Character 50 4 Publ Character 50 5 Date Character 8 6 Desc Character 254 ** Total ** 693 Fig. 4 — Final dBASE III File Structure 20 IASSIST Quarterly server, that is, exit out of the server program. Then, using the DOS copy command to move the files from the Library’s Novell file server to the gopher server’s DOS-based microcomputer. Once the actual files were residing on the gopher server’s hard drive, a suitable access point in the gopher’s menu structure had to be found. Finally, the gopher server’s menu configuration files had to be edited to include the pointers to the files. The most logical place to include the reserve collection information was in the menu with all the other files specific to the Ruth Lilly Medical Library, i.e. the files containing the Library’s hours, policies, journal holdings, etc... (fig. 5) Fig. 5 — “Library Indexes, Catalogs and Information” Menu from Ruth Lilly Medical Library Gopher In the KA9Q gopher server software, the menus are designed using directories and subdirectories on the server’s hard drive and “GINFO” files (which possibly stands for “gopher information” or “gopher index file”). For every menu on the server (seen by a gopher client) there is a corresponding directory on the hard drive of the gopher server and in that directory a GINFO file. The GINFO file contains five elements: 1) the text shown on the menu to a gopher client, 2) a code for the type of resource that is being pointed to (text file, database, directory, Macintosh Binhexed file, uuencoded file, GIF file, etc...), 3) the name and path of that resource (for example /server/reserve.db/reserves.dbf), 4) the internet address of the gopher server that provides the resource (for example gopher.medlib.iupui.edu) and finally, 5) the port for that gopher server, usually port 70. An example of a GINFO file is seen in figure 6. The GINFO file is were the telnet or ftp links to other internet sites are described. 1Medical Library Reserve List 1c:/server/reserve.db gopher.medlib.iupui.edu 70 1Medical Library Information 1c:/server gopher.medlib.iupui.edu 70 1Medical Library Journal Holdings 1c:/pub gopher.medlib.iupui.edu 70 1Indiana University Libraries Catalog 1c:/pop/catalog gopher.medlib.iupui.edu 70 1Other Libraries’ Catalogs 1/Libraries yaleinfo.yale.edu 7000 1CARL Journal Title Index 1c:/library/CARL gopher.medlib.iupui.edu 70 1First Search Indexes (password required) 1c:/library/FIRST 134.68.85.17 70 . Fig. 6 GINFO File for the “Library Indexes, ....” Menu of the Ruth Lilly Medica l Library Gopher Server. 21Fall/Winter 1994 Figure 7 illustrates what might be found in a directory on a gopher server, note the presence of the GINFO file. Volume in drive M is BVOL Directory of M:\GOPHER\LIBRARY GINFO 523 05-13-94 8:48p CARL