+ Page 1 + ----------------------------------------------------------------- The Public-Access Computer Systems Review Volume 3, Number 7 (1992) ISSN 1048-6542 ----------------------------------------------------------------- To retrieve an article file as an e-mail message, send the GET command given after the article information to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet). To retrieve the article as a file, omit "F=MAIL" from the end of the GET command. CONTENTS FOCUS ON CAMPUS-WIDE INFORMATION SYSTEMS, PART III REFEREED ARTICLES The Development of an Information Policy for the University of California at Berkeley's Infocal Campus Information Service By Margaret Baker (pp. 4-18) To retrieve this file: GET BAKER PRV3N7 F=MAIL As an increasing amount of diverse material is made publicly available on campus computer systems, universities face some provocative new areas of concern. When the University of California at Berkeley's Information Systems and Technology (IST) department began developing its Infocal campus information service, it had an important responsibility to develop the system so that the University's vulnerability to legal action and adverse publicity was minimized. A formal information policy was needed, and it was established by means of an advisory committee. In July 1991, the committee finalized its recommendations. These recommendations, which are included in the paper, have been implemented. EDITOR@CYBERSPACE Fostering Technical Innovation in Libraries By Charles W. Bailey, Jr. (pp. 19-22) To retrieve this file: GET BAILEY PRV3N7 F=MAIL + Page 2 + ----------------------------------------------------------------- The Public-Access Computer Systems Review Editor-in-Chief Charles W. Bailey, Jr. University Libraries University of Houston Houston, TX 77204-2091 (713) 743-9804 LIB3@UHUPVM1 (BITNET) or LIB3@UHUPVM1.UH.EDU (Internet) Associate Editors Columns: Leslie Pearse, OCLC Communications: Dana Rooks, University of Houston Reviews: Roy Tennant, University of California, Berkeley Editorial Board Ralph Alberico, University of Texas, Austin George H. Brett II, Clearinghouse for Networked Information Discovery and Retrieval Steve Cisler, Apple Walt Crawford, Research Libraries Group Lorcan Dempsey, University of Bath Nancy Evans, Pennsylvania State University, Ogontz Charles Hildreth, READ Ltd. Ronald Larsen, University of Maryland Clifford Lynch, Division of Library Automation, University of California David R. McDonald, Tufts University R. Bruce Miller, University of California, San Diego Paul Evan Peters, Coalition for Networked Information Mike Ridley, University of Waterloo Peggy Seiden, Skidmore College Peter Stone, University of Sussex John E. Ulmschneider, North Carolina State University Publication Information Published on an irregular basis by the University Libraries, University of Houston. Technical support is provided by the Information Technology Division, University of Houston. Circulation: 4,945 subscribers in 46 countries (PACS-L) and 709 subscribers in 35 countries (PACS-P). + Page 3 + Back issues are available from LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet). To obtain a list of all available files, send the following e-mail message to the LISTSERV: INDEX PACS-L. The name of each issue's table of contents file begins with the word "CONTENTS." ----------------------------------------------------------------- ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. The Public-Access Computer Systems Review is Copyright (C) 1992 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. ----------------------------------------------------------------- + Page 19 + ----------------------------------------------------------------- EDITOR@CYBERSPACE ----------------------------------------------------------------- ----------------------------------------------------------------- Bailey, Charles W., Jr. "Fostering Technical Innovation in Libraries." The Public-Access Computer Systems Review 3, no. 7 (1992): 19-22. To retrieve this article, send the following e- mail message to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET BAILEY PRV3N7 F=MAIL. ----------------------------------------------------------------- The 1990s offer libraries significant opportunities for developing innovative computer systems--powerful computer platforms and sophisticated software tools have become affordable, and they continue to drop in price and improve in performance. How can libraries take advantage of this opportunity? Grant funding offers one way to foster innovation, and, for large-scale projects, it may be essential; however, there are limited opportunities to secure such funding and many small projects may not warrant it. When grant funding is sought, the library's proposal is strengthened if it can demonstrate prior effort and expertise in the proposal area. Every opportunity to secure grant funding should be seized; however, libraries should not limit themselves to this funding option. Here are some brief guidelines for encouraging technical innovation without depending on grant funding. (1) Cultivate staff technical expertise and encourage interdepartmental cooperation. As computing and networking technologies evolve, the effective application of these technologies in libraries requires a considerable breadth and depth of technical expertise. It is becoming increasingly difficult for a single staff member to master all relevant aspects of these technologies; a team approach is often required. Typically, libraries have small systems departments that provide a core of technical expertise. Increasingly, staff in other departments are mastering computing tools that have direct relevance to their job duties. These technical experts should be encouraged to broaden and deepen their skills through academic courses, training seminars, and self-study opportunities. As the budget permits, libraries should provide leave time and funding for technical training opportunities, and they should formally recognize the acquisition of technical skills for promotion and tenure purposes. + Page 20 + Libraries should encourage experts in different departments--and at different levels of the organization--to work together on technical projects. Matrix project management can be challenging; however, it can also create productive new bonds between staff that have both short- and long-term benefits. (2) Provide seed money for pilot projects. [1] Libraries do not need to invest massive amounts of money to make progress; however, they do need to establish a technical innovation fund that staff can tap to create small-scale pilot projects. Although a variety of funding strategies are possible, a straightforward approach would be to allocate a fixed budget for this purpose at the start of the fiscal year and to use it to fund projects that have a predetermined maximum funding ceiling. At this stage, funding a number of small projects is preferable to funding a few very expensive ones. A simple procedure for requesting funds should be established that encourages administrators to make swift decisions. Librarians should complete a brief proposal form that provides project objectives and benefits, a timetable with a firm completion date, staffing needs, and required hardware and software. Given budget constraints, not every meritorious project can be funded. The goal is to fund enough proposals to produce a few projects that show significant promise. (3) Build on success. Some pilot projects will have an immediate payoff; they can used as is without further development effort. Additional money may or may not be required to implement the system. For example, a library may want to install a microcomputer-based reference advisor system at different service desks and public-access clusters throughout the library. If the appropriate hardware and software is in place to support the system, no additional funds will be required to implement it. If not, needed hardware and software will have to be purchased. + Page 21 + Other pilot projects will show promise, but will require additional money, time, and effort to reach fruition. Often this is because the task is more complex than anticipated. If they are not so complicated that they defy solution, complex problems are good problems--the systems that solve these problems are likely to have significant benefits. However, hard problems are usually best approached by a successive approximation strategy: solve one part of the problem at a time, accepting the imperfection of each interim solution, until the whole problem is solved. (4) Reward effective innovation. The efforts of staff who develop successful systems should be rewarded. If system development activities are recognized when decisions are made about merit pay increases, promotion, and tenure, more staff will be interested in engaging in these activities. Other types of recognition are also effective, including institutional awards and publicity in library publications. (5) Accept failure. The hunt for the guilty when a project fails accomplishes little, but it does make other staff reconsider taking risks in the future. If the resource investment in pilot projects is kept small, little is lost. Often valuable lessons can be learned from failure: dead ends are identified, new avenues of inquiry may be revealed, and parts of the failed system may form the core of a successful, new effort. With the proper encouragement, staff can develop systems that improve library operations; however, to foster technical innovation, libraries must prudently invest scarce resources and take calculated risks. References and Notes 1. Jerry Campbell, University Librarian at Duke University, has suggested that libraries allocate three percent of their budgets for research and development. See: Jerry D. Campbell, "Shaking the Conceptual Foundations of Reference: A Perspective," Reference Services Review 20, no. 4 (1992): 29-35. + Page 22 + ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. This article is Copyright (C) 1992 by Charles W. Bailey, Jr. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1992 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. ----------------------------------------------------------------- + Page 4 + ----------------------------------------------------------------- Baker, Margaret. "The Development of an Information Policy for the University of California at Berkeley's Infocal Campus Information Service." The Public-Access Computer Systems Review 3, no. 7 (1992): 4-18. (Refereed Article.) To retrieve this article, send the following e-mail message to LISTSERV@UHUPVM1 or LISTSERV@UHUPVM1.UH.EDU: GET BAKER PRV3N7 F=MAIL. ----------------------------------------------------------------- 1.0 Introduction As an increasing amount of diverse material is made publicly available on campus computer systems, universities face some provocative new areas of concern. When the University of California at Berkeley's Information Systems and Technology (IST) department began developing its Infocal campus information service, we were fully aware of the headlines of the time: porn on the Internet, racist jokes in newsgroups, and constant copyright violations. We saw it as an important responsibility to develop Infocal so that the University's vulnerability to legal action and adverse publicity was minimized. In short, we decided that we needed a formal information policy for Infocal, and we established it by means of an advisory committee. [1] In July 1991, the committee finalized its recommendations. These recommendations have been implemented, and it has been reassuring to know that they provide a solid basis for guiding the operation of the system. 2.0 Infocal We call Infocal an "information service" instead of a campus-wide information system (CWIS) because these systems can have far more functionality than we are dealing with. Someday our campus may develop a coherent, integrated, comprehensive CWIS, but Infocal is not that system. What we wanted to build was simply a vehicle for the online distribution of information. As John Kunze [2] described in a prior article, the decision to use Z39.50 to communicate with other servers complicated things a bit, but the basic Infocal concept was a simple one. + Page 5 + We envisioned a distributed system with multiple servers. A campus unit might choose to have its own server because IST didn't have enough disk space or because the unit wanted to administer their server independently. Other servers would be administered by other institutions, including other campuses, libraries, software vendors, and value-added data vendors. Local clients could query these servers, and the queries could pass through one server to another. For example, one choice within Infocal might be to access a departmental server. Infocal queries might come from multiple types of clients. A new client could be built because a new computer platform was acquired or because a specialized user interface was required. Users could employ clients that met their needs. Communicating via the Z39.50 protocol, the client could query the server, irrespective of client/server differences in platform, administrative authority, or originating source. For example, a user might employ a menu-driven client, running on a UNIX workstation, to query many servers, including MELVYL--an OPAC that runs on an IBM mainframe. (The Infocal server currently runs under Ultrix on a DEC 5900.) The user would view MELVYL through his or her client, and it might not look very much like native MELVYL. Another user might be querying the same servers for the same information from a graphical user interface (GUI) client running on a Macintosh. In turn, MELVYL devotees might be viewing the information on Infocal through a MELVYL-oriented client. We expected users to want their clients to behave as much like their normal computing environments as possible. 3.0 Defining the Problem There were two principles that we established early on, which helped to restrict the policy areas we needed to worry about. First, Infocal would be, for the users, a read-only system. Only authorized information providers could post information. This decision has kept us out of issues that proved troublesome for many bulletin boards. Second, we always intended to have a client/server arrangement, with our server connected to other servers through the network. Consequently, we confined our efforts to our own server--we never tried to establish policies for all servers in the University. + Page 6 + The advisory committee concurred with our early ideas about the scope of Infocal: it was for the distribution of "institutional information"--information distributed by the University as well as information needed by the University for its own internal business purposes. Under the former heading is material such as class schedules, campus job listings, and public notices. The second category might include material from outside the campus (e.g., course catalogs from other UC units or a suitably licensed dictionary) or access to external systems. This definition excludes, for example, a faculty member's thoughts on 18th century French economics; however, we would encourage the faculty member (or his or her department) to use our software to set up another server to distribute this information. Within the Infocal environment, we also envisioned a distributed data provision system where campus units would be responsible for providing and updating data that "belonged" to them; these units would have considerable influence about the way their data appeared on Infocal clients. Since most campus information is originally entered on computers, this seemed to present the possibility of achieving wider information dissemination without great additional effort by the originating units. However, we would need to be able to use information in many different file formats (e.g., word processing and database management system formats) and from many kinds of computers (e.g., PCs, Macs, and various mainframes). Information would be provided both by network transmission and by dial-up access. In a service with so much distributed responsibility, it would be easy to let anarchy reign and find ourselves quickly mired in inappropriate, inaccurate, out-of-date, or incomplete information. Thus, we had a situation in which policies were clearly important, but there was no obvious avenue to establish those policies. Infocal was a bootstrap operation, which meant that we had to identify, define, and seek resolution to problems on our own. There was no higher level authority saying "thou shalt" or "thou shalt not." This independence was exhilarating; however it was desirable to have rules to guide our actions. We did not want to be perceived as acting capriciously, either by acting as censors or by establishing inappropriate priorities. Computing centers have less experience than libraries in dealing with difficult information provision issues. + Page 7 + 4.0 The Advisory Committee Probably the most important step I took was to ask my superior, former Vice Provost Curtis Hardyck, to set up an advisory committee drawn from various parts of the University to address Infocal issues. This was an ad hoc committee consisting of eight members, six from the Berkeley campus and two from the UC Office of the President. In suggesting possible committee members to the Vice Provost, we sought two kinds of expertise: first, people who knew and understood existing university policies, and, second, people with significant experience in the public dissemination of information. Most of the committee members had little experience with computers, but this wasn't a problem. Although we frequently had to explain certain technical aspects of Infocal, all of the committee members contributed important perspectives and experience. The committee members were from the following UC units: Berkeley campus: Academic Senate Business and Administrative Services Human Resources and Public Safety Information Systems and Technology (Chair) Legal Affairs Public Information Office UC Office of the President: Division of Library Automation Office of the General Counsel Two lawyers on the committee were unable to attend our meetings regularly, but they did attend when the agenda seemed to require them. Despite the logistic difficulties introduced by having the lawyers on the committee, their involvement was of great value since we would have felt far less secure moving forward using policies that had not undergone informed legal scrutiny. Also, the lawyers were able to educate us about the legal basis for some University policies that would otherwise have been unfathomable. + Page 8 + For example, a strict uniformity of application underlies many University rules. Legal vulnerability is minimized if the University can demonstrate that the same rules apply to all outside organizations. Thus, if we do not allow local record stores to advertise their wares on Infocal, we cannot allow local computer vendors to place ads. However, if a campus department like IST chooses to announce that a computer vendor is giving a demonstration, this becomes institutional information under the sponsorship of that department. Of the other committee members, one left the University toward the end of our deliberations and was not replaced; another became too busy with other things and sent a replacement. The choice of committee members from such diverse units stood us in good stead because upper-level administrators were reassured by having representation on the committee. The committee members felt that the most critical requirement was a statement of purpose, and we spent most of our time working on that. The statement of purpose has proven to be more effective than I had expected, and it has helped to define priorities. The final section of the statement, which promotes the use of compatible software and standards, was a little difficult for the nontechnical committee members to support. As it turned out, their difficulty with this was truly a matter of misunderstanding, not of disagreement, and, on two occasions, technical briefings resolved this problem. Once the statement of purpose was settled, the other parts of the recommendations were more easily written. As a result of this process, the committee became concerned about the education of information providers, especially about what constituted a real data security issue. The committee also made some recommendations regarding the maintenance of good relations with information providers. These are not reflected in the formal recommendations, but we try to follow them in spirit. I was particularly pleased that the committee spontaneously chose to include a paragraph regarding the quality of the online information, since I had imagined this to be a truly obscure (though important) point. + Page 9 + 5.0 Issues The following are the areas of concern that the committee felt needed attention; another institution may have a radically different list. o Audience: Who was our audience? Just the UC Berkeley campus or the entire UC system? Did our audience include the affiliated labs (Lawrence Livermore, Lawrence Berkeley, and Los Alamos), University Extension, and other units? o Control: How much control over the information was in our hands and how much was in the hands of the information providers? Were we merely in an advisory role, or could we say "No"? Conversely, could we insist on posting information despite its "owner's" resistance? Would we want to? o Quality: We were increasingly convinced that the accuracy, completeness, timeliness, and authoritative value of the information were the most compelling factors in the success of a campus information service. Could we ensure the quality of Infocal information? o Confidentiality: We didn't have to worry about truly confidential material, such as grades or payroll data, but what about borderline privacy issues, such as home telephone numbers? This issue included the privacy of the user of the information, an important area in its own right, but one that is beyond the scope of this article. o Legality: There were numerous legal issues, including disclaimers of liability, censorship, and theft of proprietary material. o Taste: Since Infocal wasn't a bulletin board-type system, there would be minimal opportunity for demonstrating bad taste, unless a known information provider was malicious or careless. o Commercial information: What about commercial information? We knew that we wouldn't be running advertisements, but what about milder forms of commercial involvement, such as the announcement of a demonstration put on by a computer vendor? + Page 10 + o Priorities: How should our work on different datasets be prioritized so that our limited resources were used wisely? Whose needs should come first? IST? The campus? The UC system? o Policies: What about the application of existing policies? Like any other large university, UC had existing policies on just about everything that predated computers. How much of the existing canon could be of use in this new context? o Adequate computing power: What about potential system overload? The crippling load experienced by McGill's Archie system in its early days indicated that this was not a frivolous concern. o Connections to other servers: When a request was redirected via Z39.50 to another server, our clients would alert the user that a redirect was occurring. Was that all that we should do about it? The committee's recommendations, which address these issues, are presented in Appendix A. Some issues deserve additional discussion. Our intended audience has not been explicitly defined, but the statement of purpose makes it clear that the priorities are: (1) UC Berkeley, (2) the rest of the UC community, and (3) the public. We haven't run into real problems with any information provider as to whether certain information should be made available online or not, so this is another area that will have to be worked through in the future. From our perspective, all we can do about the quality issue is to take care that the source and date of the information are conspicuously included in Infocal. If we aren't comfortable about a potential information provider, we may have to recommend that they run their own server. Generally, we have managed to stay a few steps ahead of the information providers on sensitive confidentiality matters such as home telephone numbers--we have identified the problem, done some research, and developed a proposal before the information provider realized that the problem existed. If a campus unit takes responsibility, commercial information becomes "institutional information," thus avoiding the nonuniform application of University rules. + Page 11 + To help set priorities, we are setting up a second advisory committee, intended to be an ongoing one, whose primary purpose will be to identify and assess proposed datasets and determine implementation priorities. One of the secondary charges to this committee is to extend the work done by the previous committee as new areas of concern are identified and as the needs of the campus change. Finally, when users connect to another server, we will notify them that they're leaving Infocal. There is no way to require another server to identify itself accurately, nor is there any way to require other clients to present any particular information. 6.0 Conclusion Although Infocal is not yet available over the network (due to our inability to fully support it with current staff), we have released a pilot version on dedicated library terminals, as a joint venture with the campus library. The pilot release initially contained the class schedule, the campus telephone directory, a listing of job vacancies, a list of faculty research funding opportunities, and the IST newsletter. Each of these datasets is carefully tended and updated by the organization providing it, and several are definitely superior to their printed versions because they are up-to-date. We did run into some unpredictable problems just as the pilot version was released because, at the same time, the Registrar's Office ran out of printed class schedules and the new campus dial-in registration system was overloaded. This happened just before the beginning of fall semester, and it put an immediate load on the pilot release, which was suddenly the only source of this timely and essential information. We haven't run into any new areas of concern that were not anticipated, but I'm sure that we will. Given our experiences, I strongly recommend that any institution planning a CWIS develop appropriate policies early in the process. Establishing a formal policy was more important than we realized at the outset, and involving other campus units in policy making was an immensely valuable byproduct of the process. The committee's deliberations occurred simultaneously with the technical development of Infocal. They didn't hold up progress, and having the policies in place has enabled us to move quickly. + Page 12 + Berkeley is a campus where every group is vocal, empowered, and demanding. Berkeley lives up to its reputation; however, it's not a unique situation. In these times of tight budgets, a computer center doesn't expect to satisfy all of its users, but it doesn't want to alienate them either. IST's Infocal information policy has enabled us to walk this tightrope with some comfort and confidence. References and Notes 1. This work has been supported in part by Apple Computer Inc., Digital Equipment Company, and Sun Microsystems. 2. John A. Kunze, "Nonbibliographic Applications of Z39.50," The Public-Access Computer Systems Review 3, no. 5 (1992): 4-30. To retrieve this article, send the following e-mail message to LISTSERV@UHUPVM1: GET KUNZE PRV3N5 F=MAIL. Appendix A. The Advisory Committee's Recommendations Statement of Purpose The server and clients administered and maintained by IST (Information Systems and Technology) have the following purposes: (1) To distribute institutional information to the Berkeley campus community, and secondarily, to other UC campuses. This includes information from IST as well as from other campus academic and administrative units. (2) To make institutional information that is applicable for wide distribution, such as job listings, publicly available online. (3) As budgets allow, to distribute to the campus and UC communities UC business-related information of wide utility, including proprietary information such as a dictionary, where licensed for this purpose and method of distribution. (4) To encourage other campus units, UC campuses, and external institutions and organizations to use compatible software and standards in developing servers of their own. Policies regarding the content and administration of the information resident on the IST server are described separately. + Page 13 + Information Policies General Comments Any given server may be administered by any set of policies--as other campus units develop their own servers they may choose to follow different policies regarding the information on their servers. The policies below apply specifically to the IST Information Server. Both the policies and the guidelines that follow were determined by an Advisory Committee drawn from several Berkeley Campus and Office of the President units. The content of this server is to be in accordance with all relevant UC and Berkeley Campus policies. Different policies will be more or less applicable to individual information providers, but the following policies should certainly be considered: o University staff policies regarding what is public information and what is not; o University policies regarding employee organizations; o University policies regarding politically-oriented material; o University policies regarding commercial advertising and vendor relationships; o University policies regarding protection of copyrighted or proprietary material. IST will actively seek legal advice when questionable issues arise. Policies Regarding External Servers Information may come to campus users from other servers as well. On the advice of General Counsel's office, a disclaimer will be displayed by IST user interfaces when information comes from a server that is not an institutional University of California server. The administrator of any external (i.e., non-IST) server is responsible for its contents. + Page 14 + Guidelines for Units Providing Information Each participating department will need to consider for each piece of information whether it is appropriate online, and determine and follow an internal approval and authority process. If the information is also to be made available on paper, perhaps when the printed version is approved, the (matching) online version may be automatically approved. However, there may be situations in which separate approval steps are necessary, for instance, if the two versions differ significantly, or if the provider is not convinced of the wisdom of offering the information online. In other situations, information is intended to be made available only online, and providers will need to develop internal procedures to handle its review and approval. For example, does your department consider an "electronic signature" to be the equivalent of a written signature? Do those in the department who would need to be involved in the review process have ready access to computers? Internally, IST has followed the premise that information to be viewed online should be reviewed online as well. It is also important that the editorial and quality control process applied to online information be as rigorous as that applied to printed information. Spelling and other errors are just as unacceptable online as on paper, even though they may be repaired more quickly. Online information raises new quality control issues as well; for example, information may be expected to be more up-to-date than printed material. Things to Consider (1) Each information-providing unit should consider what level of access is appropriate for each piece of information, and inform IST accordingly. The following are the three levels of access available: (a) All information will be available to known Berkeley campus network hosts. This includes networked personal computers, workstations, and shared systems. Anyone with a user account on any campus host, including the IST shared systems, will have access to the information. Users from off campus who have such accounts will also have access to this information. + Page 15 + (b) A more limited set of information will be available to hosts (as described above) known to be on any UC campus, the Office of the President, the labs, etc. (c) The most limited set of information will be available to anyone who can dial in or access the server over the network. This means basically anyone. (2) Each information-providing unit should consider the frequency with which they might update their information, and inform IST accordingly. A given piece of information might be subject to updating hourly, daily, or monthly. A very stable set of information, such as a unit's newsletter, might not be subject to updating at all--when it is published, it is published. (3) Each information-providing unit should consider the life span of a given piece of information. To use the unit's newsletter example again, the unit might wish to make the most recent six issues available. A balance should be maintained between making only the most recent information available versus using the server as an archive. (4) Information providers should keep in mind that restrictions on viewing this material are no more secure than restrictions on account access (login name and password) and on the underlying network. Individuals with valid access to campus-only material may inappropriately share that access with others. The server is no place for restricted or confidential information. On the other hand, the integrity of the information itself is fairly well protected. No one except the known information provider will be able to change or install it, so information providers have the responsibility of protecting passwords and other write- access restrictions themselves. + Page 16 + Problem Resolution (1) When problems of inappropriate information come to IST's attention, IST will attempt to resolve them through normal University channels. However, if the problems seem to be unresolvable, or recurring, IST will cease putting that particular information on the IST server. (2) In the future, some campus departments may decide to act as sponsors for information coming from other agencies such as student groups, user groups, etc. Any campus department that chooses to do this will be responsible for the appropriateness of the other group's information, and should carefully consider University policies, including those mentioned above: o University staff policies regarding what is public information and what is not; o University policies regarding employee organizations; o University policies regarding politically- oriented material; o University policies regarding commercial advertising and vendor relationships; o University policies regarding protection of copyrighted or proprietary material. If there is any doubt about adherence to these or other University policies, the sponsoring department should consult with the appropriate campus authorities for clarification. Again, if problems appear that are unresolvable through normal University channels, or are recurring, IST will cease putting that particular information on the IST server. [Appendix A. is reproduced with the permission of the University of California, Berkeley.] + Page 17 + Appendix B. CWIS Resources There are many more resources about this topic now than there were when our advisory committee was formed. The following is an informal list of some other resources that we have found valuable. o The CWIS-L@WUVMD list distributes ideas and experiences on many relevant topics. This is also a good place to ask questions about specific concerns. To join this list, send an e-mail message to LISTSERV@WUVMD that says: SUBSCRIBE CWIS-L First Name Last Name. o ACM's SIGUCCS (Special Interest Group on University and College Computing Services) often has presentations on related topics at its fall User Services Conferences. In particular, see: Timothy J. Foley, "Developing a Computing and Information Policy," in Proceedings ACM SIGUCCS User Service Conference XVIII (New York: Association for Computing Machinery, 1990), 127-130. o The Coalition for Networked Information and EDUCOM are two organizations that focus on these issues: Coalition for Networked Information, 1527 New Hampshire Ave., N.W., Washington, DC 20036, (202) 232-2466. EDUCOM, 1112 16th Street, N.W., Suite 600, Washington, DC 20036, (202) 872-4200. + Page 18 + About the Author Margaret Baker, Information Systems and Technology, 289 Evans Hall, University of California at Berkeley, Berkeley, CA 94720. Internet: MARGARET@GARNET.BERKELEY.EDU. ----------------------------------------------------------------- The Public-Access Computer Systems Review is an electronic journal that is distributed on BITNET, Internet, and other computer networks. There is no subscription fee. To subscribe, send an e-mail message to LISTSERV@UHUPVM1 (BITNET) or LISTSERV@UHUPVM1.UH.EDU (Internet) that says: SUBSCRIBE PACS-P First Name Last Name. PACS-P subscribers also receive two electronic newsletters: Current Cites and Public- Access Computer Systems News. This article is Copyright (C) 1992 by Margaret Baker. All Rights Reserved. The Public-Access Computer Systems Review is Copyright (C) 1992 by the University Libraries, University of Houston. All Rights Reserved. Copying is permitted for noncommercial use by academic computer centers, computer conferences, individual scholars, and libraries. Libraries are authorized to add the journal to their collection, in electronic or printed form, at no charge. This message must appear on all copied material. All commercial use requires permission. -----------------------------------------------------------------