Copy Link
Add to Bookmark
Report
Public-Access Computer Systems Review Volume 03 Number 07
+ 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.
-----------------------------------------------------------------
