MESL Implementation at the Universities

Howard Besser, MESL Management Committee

UC Berkeley School of Information Management and Systems


All seven MESL universities mounted the identical set of approximately 10,000 images and accompanying text records--each in their own way. These implementations varied widely, each university making different choices as to the search options, the indexed fields, display choices, and the overall look-and-feel of the access systems. Methods for access control, authentication, and the choice of text fields that displayed with an image differed not just from one university to another, but even within some universities these changed over time.
This article reviews the steps the universities took to process and mount the images and data and examines the different deployment systems primarily from the standpoint of the user's interactive experience. It also speculates on the reasons the implementations differed from one another, including the lack of standard practices and procedures, the varying goals and models of the implementors, and the role of technological change in areas like authentication.
University Deployment: Early Decisions

From the beginning the MESL Management Committee encouraged the universities to pursue independent solutions when they deployed the images and data. Many of the universities had joined the MESL project hoping to experiment with ways to integrate image delivery with their existing text-based information delivery systems. This fact, as well as the short lead time, precluded the development of a single deployment solution across all sites[1].
The seven independently developed deployment systems that emerged allowed us to compare them and begin to speculate about the effects local implementation decisions had on search results.
Receiving the Data

During each of MESL's two main content distributions, the Michigan central distribution site received batches of images and text from the museums and forwarded these on to each university. This section briefly describes the variety of different processes and issues each university faced in preparing this data to load into its local information delivery system.

Processing of Text

In most cases the universities took the flat delimited text files they received and used a variety of application tools (e.g., Perl scripts, Excel, Filemaker Pro, Microsoft Access) to parse (or separate) these to create HTML pages for each record, and to load the data into a database for user retrieval. The exception was Virginia which used PERL scrpts to create records from the MESL data in "pseudo" SGML format, ran database queries against this stored data (using Open Text), and generated HTML results pages from it on the fly.
During the first distribution, the universities had significant problems parsing and loading the text data. Some of the reasons cited were:
1) some records did not have all the prescribed fields present;
2) some fields were not properly delimited;
3) museums did not all use the same set of delimiters;
4) some records had line feeds embedded in them; and,
5) museums used different character sets for their text records.
Many of these problems disappeared in the second distribution, as the MESL participants agreed on more extensive specifications and standardized practice with respect to delimiters and character sets.
The MESL experience made it clear that the specifications for data export must be extremely precise, and that a pilot study involving a heterogeneous pool of institutions can reveal the results of divergent practices that were not taken into consideration during initial attempts at specification. Over the course of the project, MESL participants developed a set of standard specifications intended to be precise enough to assure consistent data structure; other follow-on projects will have to tackle the even more difficult problems associated with normalizing data values to improve retrieval (see article by Robin Dowden elsewhere in this volume).

Image Processing

Most university sites based their user interface and general design decisions on the particular image sizes and/or other qualities. Some sites already had an investment in a particular size of image, based on experience and software development in previous projects. During the MESL project, instructors expressed concerns over image size including: that they be big enough for classroom projection, be as big as possible yet fit on the "average" screen without scrolling, fit within a specific application without scrolling, etc.
None of the implementations supported the on-the-fly derivation of smaller images, so when the images were received from the central distribution site each university generated several sizes of derivative images (thumbnail, large image, and often one or more in-between) in advance for delivery.[2] Applications like Debabelizer and ImageMagick made this process relatively simple to accomplish (completely unattended) in batch mode. However, many of the MESL images had been previously compressed by the museums in such a way (using "lossy" compression) that it was necessary to to uncompress, reduce or resize, and then recompress them so that they could be deployed in a parcular information environment supported by the university. As suggested elsewhere (Besser and Stephenson 1996), in future distribution schemes both image derivation and lossy compression might be performed at a central distribution site receiving uncompressed images, thus eliminating duplication of effort by the entire set of deploying institutions, as well as avoiding the problems of multiple lossy compressions. For this strategy to be effective, all of the deploying sites would need to agree upon common specifications for image sizes, bit depth, and compression ratios.
Table I illustrates how image sizes varied widely between the different deployment sites, even among well-recognized "sizes" such as thumbnails. Though most sites delivered compressed images, a comparison of compression ratios or quality is inhibited by the lack of a standard scale for measuring these.[3]

University


Thumbnail


Medium
(Screen Size)


Large


Other


American


50 x 50


640 x 400


off-line



Columbia


100 x 70 GIF 89


350 x 250 JPEG


700 x 500 JPEG


1200 x 900 JPEG


Cornell


120 pixels max
dimension


390 pixels max dimension


as supplied;
Photo CD images converted to JPEG



Illinois


125 pixels high
JPEG/JFIF


400 pixels high
JPEG/JFIF


Compressed but not resized
JPEG/JFIF



Maryland


150 pixels max
dimension
BMP/GIF


700 pixels max
dimension
BMP/GIF


As supplied; delivered by ftp on request



Michigan[4]



90 pixels max dimension
GIF 89A


640 pixels max dimension
JPEG/JFIF


960 pixels max dimension


maximum--the full size image supplied by the museum


Virginia


130 pixels high
GIF


600 pixels high
JPEG/JFIF


off-line



Table I. Image sizes and formats delivered at each site
[5]
Though the batch post-processing worked well for creating most derivative images, certain kinds of image types posed problems. For example, all of the universities noted that PhotoCD images were quite difficult to work with. And batch compression did not work well across different content format types (e.g., line drawings, engravings, paintings); future projects might address this problem by separating the images by content types (line drawings would be handled together, as would continuous tone images), and using compression techniques that have been optimized for the different content types.
In general the universities were pleased with the quality of the digital images they received from the museums. Nevertheless, they experienced a number of problems with image quality. According to the Columbia technical report, "The quality of the digital images varied from museum to museum, but in general we found the resolution to be too low when compared with [digital] images we have been able to obtain commercially." And when Columbia faculty compared projected slides alongside projected MESL digital images of the same object, they found the quality of the digital image sorely lacking.
Some university disappointment stemmed from the scanning process the museums had used; others from the fact that some images had been scanned from poor-quality intermediates. Other quality issues included: images that were too small for the universities to make effective use of them, and images that were dark and muddy probably because they had either not been color-balanced, or had been viewed only on one particular monitor/platform combination; (there are not yet proper color management tools to assure that images will look good and consistent from one platform and monitor to another). As "best practices" continue to evolve and be promulgated in the museum community, many of these image quality issues will inevitably disappear.
Museums also differed in their policies and practices regarding such things as the placement of borders around images or the matting of backgrounds (particularly on thumbnails) to create images of a consistent aspect ratio. Such alterations makes it difficult to handle images "en masse" and will need to be "regularized" if a single source is to produce all derivative images in the future.
Other challenges the universities experienced arose in the process of passing the images from point to point, and linking them properly to accompanying text., Some image files were corrupted, and others were missing, misnamed, or misreferenced. These problems may have been introduced anywhere along the distribution chain, which led from the museums to the central distribution site to the various steps within the universities. Explicit procedures and quality assurance checks would minimize such problems in the future .
Designing the Deployment System and User Interface

Each university independently designed its own system for deploying images and text on its campus. This section discusses some general differences between the various university implementations. It also discusses how the different implementations looked to users and the ways in which search results differed. Although a precise empirical study of user response to each implementation could not be usefully undertaken (due to the vast heterogeneity), observations about the ways in which various design approaches affected the look and performance of the individual deployment systems was still possible.

General differences between the implementations

Six out of seven of the universities eventually chose the World Wide Web as the primary access mechanism for their users. Initially Illinois and Cornell began with different delivery systems, but moved onto the Web midway through the first year of the project. For a number of Maryland provided user access through a local network,[6] and enabled more limited secondary access through the Web.[7]
University implementations of the MESL data varied dramatically. The differences resulted primarily from the fact that institutional situations--e.g. the local information delivery architecture, encoding and searching systems, as well as staff expertise--had a major influence on the choices that were made at each site. In addition, a few of the project staff at MESL sites had been involved with digital imaging projects and drew on these experiences when making interface design and other related decisions. The degree of institutional support for MESL implementation--manpower, equipment, classroom facilities, and available expertise--constituted another significant variable from one university to another.
[I only got to this point, 1/23/98--PAMcC; started below but it needs much more]
[HB: The Berkeley Study is really part of "Initial Presentation and Query Options"; ideally it needs some kind of introduction to keep it from looking like it came out of left field.]

Initial Presentation and Query Options: The Berkeley Study

There was a wide variety in the way the various university implementations looked to a user. A group of Berkeley students performed the only cross-implementation study, 8 comparing six of the MESL implementations. The findings of their informal study are reported here.
Eight students in a UC Berkeley graduate class were given access to the implementations at six university sites for a one-month period.[8] The students had different academic backgrounds, and the expectation was that they would search in a variety of ways and also notice different features of the various systems. By design, none had extensive art history training so that their queries would be more like those of naive users than experienced art historians. They were given the following assignments:
_ Compare the user interface and display options on all the MESL sites. Look at how the user is supposed to navigate through the system (including how the information is "chunked," the order in which options are presented to the user, and the placement of buttons). Also examine search options and the layout of search results.
_ Compare size and quality of thumbnail (as well as larger) images on all the MESL sites. Note the approximate sizes of images offered, and how these differ between implementations.
_ Perform three identical searches on each of the MESL sites and note whether or not the same query on the same data set yielded different results.
The results of the student study are reported here.[9]
[HB: below are two dangling facts--neither of which is very clear yet. It looks to me as if you are making a point or two about database browsability, and then are introducing the Table on backend database/search engine information. Both of these paragraphs need a lot more explanation and context to be useful.]
Five of the six implementations studied[10] provided a browse function that allowed the user to scan through large batches of images and records without first performing a query. In most of the other systems the browse applications limited the user to browsing within only a single museum at a time [did they need to perform a query first?].
[perhaps this can be incorporated below under the introductory section on back-end database/search engines?] All of the Web-based delivery systems provided searching via HTML forms [explain] that generated cgi-scripted calls [jargon] to a back-end database/search engine [jargon]. Back-end databases/search engines included products such as Filemaker Pro, Microsoft SQL server, and Glimpse, and locally designed systems such as Full Text Lexicographer (see Table II). [expand this so that a general reader understands what this is about. By the way, is a flat database a search engine type??? I couldn't rewrite this because I didn't understand it.]

University


Search Engine


American


Flat database files
(in-house)


Columbia


Glimpse


Cornell


Filemaker Pro


Illinois


Microsoft SQL Server


Maryland


Microsoft Access; customized with Visual Basic (Maryland ISIS)
MIniSQL (Web)


Michigan


Full Text Lexicographer
(locally developed)


Virginia


Open Text


Table II. Back-end search engines employed at each site

[Begin with a paragraph that explains what a "back-end search engine" is and what it does--and then introduce what is to follow .]
Most sites presented the user with several layers of explanatory information before allowing the user to compose a query. This information was designed to interest users in the MESL data, to contextualize the project and clarify its scope, and to explain conditions of use. One of the students felt that bynesting the search page deeply within the web hierarchy, repeated user queries would be discouraged It was recommended that future designers should provide one set of paths for initial users and another set for repeat users.
Query screens for most implementations employed HTML forms [be sure this term is explained in introductory paragraph above] with menu choices. Most sites provided forms for both simple and complex (e.g. Boolean) searches, either as separate pages or combined on the same page. Examples of query screens from Cornell and Michigan site are shown in Figures 1 and 2. These screen captures show how the same search result data can be presented to users in different ways, depending on the choices made by interface designers.
Most interfaces offered searchers the option of undertaking either simple or complex searches. Several Berkeley students found this distinction [between simple and complex searches] confusing. In most cases the difference was that the "complex" searches permitted the user to search for a single value in each of two fields (such as Artist=Cezanne and Date=1876). They felt that "complex" was a poor word to use for this type of search.
Each site chose to index a different subset of the available MESL fields. Some sites chose to provide keyword access while others did not. Some sites provided access by categories of local interest (such as by course using the image). And in many cases "searchable fields" on the user's query form were really composed of indexes made by concatenating a variety of related fields in the database rather than by presenting the fields defined by the MESL data dictionary. Different sites combining their indexes in different ways was one of the factors that led the same query to yield radically different search results between sites.

Comparing Search Results

As part of the study, each Berkeley student created three search strategies which they then performed at each site. Because the set of searchable fields presented to the user differed from site to site, students needed to use their own judgment in an effort to replicate the search as closely as possible at each site. These searches yielded vastly different results from site to site. For example:
_ Searching for title="birth" yielded a different result set from each site (with one site returning a null set). [can you say more about the different results? I'm left with a "so what" feeling, not knowing how different--or the range of responses--or what is interesting about this point.]
_ A simple search query for "german landscape" yielded no results at Virginia. A compound (or "complex") [give example: was it "german" and "landscape" ?? HB: I have no easily accessible record of whether that is how it was done] search produced no results at American, Michigan, and Maryland, yet 6 results at Virginia and Cornell, and 5 results at Illinois.
_ Searching for "haystack" retrieved 6 results at Michigan, 5 at Cornell and Virginia, 3 at Maryland, 2 at Illinois, and 1 result at Columbia. (see figures 3, 4, and 5)
_ Searching for oil portraits of children (using the terms child, oil, and sometimes qualified by portrait ) yielded a wide range of results. All searches at American and Maryland and a "quick" search at Michigan yielded no results. Searches at Illinois yielded 2 items, neither of which had anything to do with oil paintings of children: rather they were works created by an artist named "Child" about the Free Soil Party. However, a fielded search ("child" within subject and "oil" within medium) at Michigan yielded 31 results, over half of which were oil portraits of children [what were the other ones--relevant or totally unrelated to search intentions? HB: Again, my records are not easily accessible]. Fielded searches at Cornell (material-medium=oil and concepts-subject=child) and at Virginia (subject=child and material=oil) both yielded 82 records, over half of which were oil portraits of children [same question re other results? HB: Again, my records are not easily accessible].
_ The keyword phrase "black and white" yielded 0 results at Maryland, 3 results at Illinois, the identical 9 results at American and Cornell, and the same 22 results at both Virginia and Michigan.
_ A search for French Still Life yielded no results at American and Maryland, 20 results at Illinois, 22 at Cornell, and 23 at Michigan and Virginia. (see figures 6, 7 and 8)
_ A search for Madonna and Child yielded 0 at Maryland, 57 at American, 60 at Cornell and Michigan, 61 at Illinois, and 66 at Virginia.[isn't there more to say about the accuracy of the results that we got at these places--the 66 isn't necessarily as interesting as the fact that not all of them were actually of Madonna and Child.]
_ A search under Surreal yielded 2 at Cornell, Illinois, Maryland, and Michigan, and 4 at American and Virginia.
There were a number of reasons for these divergent search results: some sites combined different sets of the original data fields into unified indexes, different search engines and their different approach to indexing, and whole-word versus character-string searches on various fields [e.g. a character string search would pull up "soil" in a search for oil, and a whole word search would not].
The most significant reason for discrepancies in search results on the same data (at different implementation sites) had to do with choices institutions made when they combined data fields in order to simplify searching for users. The MESL data dictionary contains 32 fields, far too many to present effectively in a typical search interface. Consequently, institutions made local decisions about how to group sets of fields within the MESL database and what to label each of these combined indexes. As a result, at each site users were presented with different indexes to the same underlying content.
The way "keyword" indexes were constructed accounted for most of the discrepancies that occurred when the same search was tried at different sites. Keyword indexes can be formed by combining prominent fields like subject, description, and title, by relying completely on the words within the label field, and by other variations on these themes. The choice of which fields to index for keywords can have a significant impact on search results, such as finding an artist named "Child" when looking for portraits of children. The importance of these choices is compounded by the fact that simple searches, which are often used by less experienced users, tend to rely on the keyword approach. [I deleted last sentence because it wasn't obvious what was interesting about a casual user getting different results at different sites--this wasn't even possible in MESL. HB: But it does explain why the Berkeley users got the results they did!]
Another reason the results differed across sites had to do with search engine design--that is whether all matches must start exactly the same, beginning from the left side of any field, whether the system looks for character-strings or whole words, whether the system matches stems, truncates, or performs other search tricks. The impact of such searching design decisions drastically affected search results in this study.
The preliminary results yielded by the Berkeley study suggest that additional research can be done to further refine our understanding of the complex interaction between database design, search engines, interface design and user behavior. Efforts to develop successful systems for image delivery, undertaken in tandem with those to repurpose collection management data for public access to images, present formidable challenges.

Access Control

In addition to testing a variety of search and retrieval choices, the MESL experiment explored issues surrounding the provision of access and security to the museum data mounted on campus servers. Each implementation used fixed Internet Protocol (IP) addresses as its initial form of access control.[11] This form of security is quick and easy to implement, and only requires that a list of valid campus domains or IP addresses be compiled and checked whenever a search on the "secure" database is initiated. While this IP access controlworked relatively well for this experimental project, it poses serious problems for a true production-level delivery system.
Groups of IP addresses tend to be too general, and often include too many users in some areas and not enough in others. For example, commercial entities leasing campus space, private technology-transfer spin-offs, alumni dial-up access, and other groups that might not be valid members of a "campus community" (as defined within a licensing agreement) are often included within the campus IP domain. In many cases it is not possible to isolate these invalid users from permissable student, faculty, and staff users. Another problem stems from the fact that many legitimate users (e.g. those from satellite campuses and programs in other cities, students and faculty who dial up through their own Internet service providers, faculty on sabbatical at other campuses, etc.) do not share the main campus domain or do not have fixed IP addresses, and may be blocked from accessing the system. (Even if a campus could create a list incorporating most of these other valid fixed external IP addresses, managing such a fluctuating list would quickly become unwieldy.)
Because most Web security has used IP addressing to control access to an individual directory (see explanation footnoted above), this approach can require that different sizes of images and text be stored into directories based on access control rather than upon logical arrangement. For example, a university wanting to control access to all images bigger than thumbnails, but allow any user to see textual descriptions, would have to store thumbnails and text in an uncontrolled-access directory and all other images in a controlled-access directory.
Midway through the MESL project, several of the campuses began to implement experimets with more sophisticated means of access control. In the second year of MESL, Illinois added log-in and password access to supplement IP access as a way of serving those outside its core IP cluster. In 1997 both Michigan and Columbia implemented systems requiring log-in names and passwords for users of MESL and other restricted collections, and authenticated them against already developed databases of valid campus users.
It is clear that simple IP access control will not support the kind of security measures that most image rightsholders expect. More sophisticated methods need to be found, based upon individual users rather than upon workstation addresses. Most of these methods will require universities to keep track of their users various affiliations (e.g. to isolate alumni or drop-outs, to identify valid users of material intended only for a particular course, etc.). Because of privacy concerns, universities have the responsibility to maintain authentication systems based upon this level of information about their users, even when distributors are delivering licensed material directly to members of the university community Some universities have begun experimenting with public key encryption and digital certificates to try to solve the authentication problem while still maintaining user privacy.
General Observations

[I could keep going on these general observations, but am more inclined to suggest they be deleted, or in some instances incorporated above. They don't follow logically from the preceding sections, and are all treated more fully in other articles. Instead it might be nice to have a summary paragraph on the main points that were made above--and then stop.]
[suggest deleting this section and substituting a brief concluding summary.]
The MESL distribution and delivery architecture proved to be adequate for this demonstration project. But many MESL participants doubt whether this model will work in a large-scale production mode. In particular, the handling of distributions, (including updates and corrections) is problematic; on an ongoing basis the MESL approach of "full redistribution of the entire dataset for every update" might not scale up.
The architecture chosen for the MESL project is by no means the only possible distribution and delivery scheme. It is very possible that at some time in the future universities may negotiate licenses with image repositories (or agents acting for a group of repositories) on behalf of the university community, but rely upon the repositories to deliver these images and accompanying text directly to the users. For certain high-use items or special combinations and configurations the universities might choose to mount a small subset of the data, but still rely upon an external repository/distributor to deliver most items to the university community. Before such a configuration becomes viable, a number of other problems must be solved, among them: reliable high-bandwidth delivery over wide-area networks, secure authentication of users as being part of the authorized university community, and protection of user privacy.
Another critical issue for instructors is the development of a set of tools that go beyond a library catalog model of merely finding an image and displaying it. For many instructors, finding a set of images was not enough; they wanted tools for organizing and using these images.[12] The most notable tool development occurred at Maryland and Virginia. Maryland built an application called SearchSlide (now Maryland ISIS)[13] which mimicked a light table, allowing an instructor or student to re-order and organize a set of images, or to prepare a set for projection. Virginia built into its query screens the capability to mark individual images with checkboxes, allowing the user to then view only the set of checked images. Virginia also designed a set of templates that made it easy for faculty to design side-by-side comparisons of images and text records or to have their students model virtual exhibits. Other desirable tools include image zooming, image annotation, and manipulation of color and gamma functions. Until faculty have access to easy-to-use tools for performing functions they deem important, widespread faculty use of digital images is unlikely.
The heterogeneous mix of deployment systems in MESL has revealed a number of interesting factors that would have been difficult to discover in a more homogeneous environment. This mix also permitted an iterative refinement of delivery specifications.
While the design of an information retrieval system may at first appear to be trivial, decisions over how to combine indexes to present to the user and how to implement searching strategies are critical in determining the user's experience. By examining the different ways in which an identical data set can be searched and presented to users, implementers should be able to better design future interactive projects.
It is clear that a number of problems must be resolved before there will be widespread use of digital images on university campuses. Infrastructure problems (such as labs with high-resolution workstations and high-quality classroom projection) pale in comparison with the problem of faculty buy-in and enthusiasm. The need for a critical mass with which to teach, and having exemplary projects to show other faculty, are both dealt with in other chapters in this and the companion volume.
Acknowledgments

Portions of this chapter appeared in a paper by Howard Besser titled "If it's the same museum information, why don't these look the same?" Comparing five implementations of identical data from the Museum Educational Site Licensing Project" in the Proceedings of the 1997 International Conference of Hypermedia and Interactivity in Museums, edited by David Bearman and Jennifer Trant.
Thanks are due to the MESL participant institutions for providing permission and access to the images, records, and retrieval implementations, and for compiling data for their technical reports. Financial assistance from the Andrew W. Mellon Foundation helped gather and compile technical data about the University implementations. Christie Stephenson compiled information about image delivery, and offered keen observations on many other aspects of the topics covered in this chapter, as well as significant editorial assistance. Students in Howard Besser's Spring 1997 SIMS 296A course at UC Berkeley participated in the cross-implementation study.
References

Besser, Howard. (1997a). "`If it's the same museum information, why don't these look the same?' Comparing five implementations of identical data from the Museum Educational Site Licensing Project," in David Bearman and Jennifer Trant (eds.) Proceedings of the 1997 International Conference of Hypermedia and Interactivity in Museums.[place, date]
Besser, Howard. (1997b). The Transformation of the Museum and the Way It's Perceived, in Katherine Jones-Garmil (ed.), The Wired Museum: Emerging Technology and Changing Paradigms, Washington, D.C.: American Association of Museums, pp 153-169.
Besser, Howard and Christie Stephenson. (1996). The Museum Educational Site Licensing Project: Technical Issues in the Distribution of Museum Images and Textual Data to Universities, in James Hemsley (ed.), E.V.A. '96 London (Electronic Imaging and the Visual Arts), Thursday 25th July 1996 (vol. 2), Hampshire, UK: Vasari Ltd, 1996, pages 5-1 - 5-15. [http://www.gii.getty.edu/mesl/about/docs/EVA.html]
Museum Educational Site Licensing Project. (1997). World Wide Web site. [http://www.gii.getty.edu/mesl/]


[1]

see Besser and Stephenson 1996
[2] Applications to generate derivatives on-the-fly were not available at that time, but in the future these may prove useful.
[3] JPEGs were produced with a variety of different batch image processing programs (HiJaak95, Lview, PhotoShop, Image Magick, Debabelizer, Graphic Converter, Multimedia Converter, Alchemy.) at a variety of quality settings. It is difficult to compare quality settings across software as each has a unique method of representing the quality/compression ratio scale.[4] Michigan also supplied an intermediate "small" size JPEG, with a max pixel dimension of 320 pixels. Availability of derivatives in the full range of sizes was dependent on the size of the original.
[5] compiled by Christie Stephenson
[6] see Hays and Borkowski article in Perspectives volume.
[7] Examples from Maryland cited herein were gathered from their Web implementation which was never intended as the primary means of access for Maryland users. Consequently they are not indicative of the access that most Maryland users experienced via their campus network system.
[8] The Columbia site was inaccessible to the students during the study period.
[9] This paper summarizes the preliminary findings, focusing primarily on the searching process. Future reports from this study will will examine how search results are presented to users at each of the university sites, and will compare record display features, thumbnail sizes, and other interface variables.
[10] Virginia did not provide a browse function.
[11]IP Access Control allows a systems manager to create a file containing a list of valid internet addresses, and to prevent access to all the information in that directory by any users not coming from one of those listed internet addresses. The most common IP access control at Universities is to limit access to the university's domain name. (Thus, by placing just a few lines of code (specifying "cornell.edu") in a file in a particular directory, Cornell could prevent access to all files in that directory by anyone at a workstation whose address did not end in "cornell.edu".)
[12] In recent years applications like this for text have been developed to operate in conjunction with text-based library catalogs. Tools like ProCite allow the user to download formatted records from a library catalog, load these into a citation database, and manipulate them or incorporate them into footnotes, citations, bibliographies, etc.
[13] For a detailed description of this software, see "Maryland ISIS (Interactive System for Image Searching)" by Catherine Hays and Ellen Borkowski in the accompanying volume, Perspectives on the Museum Educational Site Licensing Project.

Last modified: 2/17/1998