8.1 Prototype Database Service Page 1 of 15

VIUS Reports 8.1 Development of the Prototype Database Service

As an experiment in supplying some of the needs identified during the first phase of the VIUS project, an image database service was established. The focus of this part of our work was to answer questions such as:

• Since content is such a critical factor, can we identify and obtain needed content rapidly enough to generate real use?

• Can personal collections contribute to a centralized service in a meaningful way? • What can be done to help users understand permitted uses? • Given the software tools available, what is an appropriate interface design and

architecture? • How important is interface design in the acceptance of a system?

As we began to answer these questions we also sought to make the transition from experimental work to more permanent services. This report traces the initial development of the prototype service and also the designs for the more permanent service. A specific audience was targeted for the database service so that a useful number of images could be built rapidly. Through contacts made during the survey of individual collections, a group of 4 courses was identified with a shared interest in images of the history of landscape design and urban development. These courses were offered in three departments (Geography, Horticulture, and Landscape Architecture). We had hoped that this range of disciplinary perspectives on the same set of images would create some interesting user responses to the types of descriptive texts we provided. Although the faculty for these courses expressed substantial enthusiasm, as the database was being built, two of the courses (Geography and Horticulture) dropped or reduced participation. The reasons were very practical. The chief reason was that timing of the project plan conflicted with timing of faculty work on course revisions. (That is to say, other work took precedence for two faculty members.) A less important but more interesting reason was that one faculty member needed time to consider how student access to the course images would effect other student requirements. In particular, attendance in large classes was identified as a potential issue. Seeing the projected images in class had previously helped to ensure good attendance and foiled the commercial note-taking services and fraternity test files that target heavily enrolled courses. Providing students with easy access to the images shown in class might require adjustments to other course requirements and assignments. (This type of concern was expressed by two faculty members, both teaching courses with very large enrollments.) Nonetheless, problems of faculty work-load seemed the principal reason that the content of the prototype database focused upon two courses, both in the history of landscape architecture.

8.1 Prototype Database Service Page 2 of 15

Content The answer to the first of our questions was “yes.” Generally speaking, we were able to rapidly produce an image database in support of the targeted courses. In just over 2 ½ months the database was designed, populated with approximately 3,000 images, and made available to the public (on August 16, 2002). It grew to approximately 5000 images by mid-January 2003 and to 11,500 by mid-June. (Database work during that year was often interrupted by other tasks.) Two sources of information were used to develop a “want list” of images to support the courses: 1) Direct requests from faculty came in the form of specific images lists and as generalized requests (such as “historic images of Brush Valley and Penn’s Valley, Pennsylvania”). 2) A list was built of the monuments illustrated in 12 books surveying the history of world landscape or American landscape history. (This Concordance of Monuments from Landscape Architecture Survey Texts, is available as a downloadable spreadsheet from VIUS Reports.8.2 Concordance of Monuments in History of Landscape Architecture Texts) The want list was used to solicit images from Penn State’s institutionally managed collections, from the private collections of faculty, from digital image vendors, and from free exchange web sites such as the Society of Architectural Historians’ Image Exchange and Art Images for College Teaching. In addition, some images were scanned from books and used under fair use or public domain privileges. Useful images were obtained from each of these sources. In fact, collecting from the want list would have been difficult without having employed such a variety of sources. The table below details the sources employed. A large number of the images in the database are detail shots of complex monuments and sites. (A rough estimate suggests that the database contains an average of 10 images per monument.) Approximately one third of the monuments represented in the database were not on the want list, but added because of discounted package licenses from vendors. Nearly all of these unsought monuments were major architectural works, but not as important to landscape design. This approach to developing a want list could have been extended to the other targeted courses. If the horticulture class had been included, the want list would have been expanded to include a set of identification images for ornamental plants. Identification of plants in landscape architecture images might also have been attempted. If the geography course in urban development would have been included, major monuments – cities and portions of cities -- could have been identified using text books, but the number of potential views of those monuments would have been much larger than for landscape architecture sites. (The problem of having the “right” view of Paris, seems more difficult than having the right view of the gardens at Versailles.) The question of individual collections was partially answered. A particularly useful source of images for the history of landscape architecture was the original photography of faculty members. The survey of individual collections revealed that some faculty had substantial collections of original photography of the monuments on our want list. Copies of these photos were donated to the University via a written agreement that detailed the University’s right to distribute the copies in perpetuity. When scanning was required, our highest standard of resolution and archiving were employed. Greater care was also taken in the identification and cataloging of these images. The level of identification of these images was limited. (For example, a group of 80 slides were labeled simply “Villa Lante, 1997”.) More detailed identification of each image was handled by a graduate student in art history. She developed fairly detailed descriptions by verifying the slides with information in publications. For a typical group of 400 slides covering four complex sites, this process of identification required a total of 81 hours, which included initial research, gathering publications, comparing, and making detailed notes. This averages only 12.14 minutes per slide or nearly 5 slides per hour, but that

8.1 Prototype Database Service Page 3 of 15

may be a deceptive way of estimating time for other projects. The number of sites was a critical factor in this work because the initial research and building an understanding of the site was a larger percentage of the labor. A safer way to consider this effort is roughly 20 hours per 100 images per site. At these rates identification of the pictures was more costly than the subsequent cataloging, which required putting the identifications in the proper form and adding subject categories. Future growth of the database service is planned to expand beyond the landscape subject focus of the VIUS experiment. Several thousand images from the Art History Department Visual Resource Centre and a collection of historic lantern slides of forest management have very recently been added.

Penn State collections: Subjects Media Typical

Size 1/15/0

3 6/15/03 By 12/03 University Archives, Town and Environs Collection Central Pennsylvania

photos varies 95 95 95

University Archives, Campus Buildings Collection Univ. Park planning mixed varies 195 195 195+ Palmer Mus. of Art, O'Conner-Yeager Collection

Prints of Pennsylvania (The Tavern) slides 800X1000 265 265 340?

Art History Slide Library Roman piazzas mixed 800X1000 47 47 4534 Center for Landscape History Landscape history slides 650X800 34 34 34 Landscape Architecture 060 Landscape history jpegs varies 1,016 1,016 1,016 Gifts (of copies) from individuals: James DeTuerk gift (his on-site photography)

Landscape Architecture: Italy/Portugal slides 800X1000 164 247 569

George Dickie gift (his on-site photography) Public Spaces of Rome jpegs

1000X1200 151 151 151?

Copies obtained by permission: Society of Architectural Historians, Image Exchange

Landscape & architectural history jpegs 400X600 787 787 787?

Art Images for College Teaching

Landscape & architectural history jpegs 500X750 119 119 119?

Licensed to Penn State:

Archision, Inc. Landscape & architectural history jpegs 800X1000 1,541 8,071 8,071?

Davis Art Slides (Davis Publications, Inc.)

Landscape & architectural history jpegs 500X750 276 276 276?

Public domain or fair use: scanned from books or downloaded Landscape history books varies 240 240 240? _____ _____ Totals 4,930 11,543 16,427+

8.1 Prototype Database Service Page 4 of 15

Scanning Specifications When images came to us in digital forms, we accepted them with their existing specifications. All of these turned out to be JPEGs with varying sizes and densities. One large gift of slides was scanned by the University Libraries. From the slides we produced archival masters that are uncompressed TIFFs (600 dpi 24-bit RGB). In a few cases, we reduced the dpi to 300, due to production needs, but never below 300 dpi. JPEGs were generated from the TIFFs for use in the database. The JPEGs were 72 dpi and in sizes in the range of 800 X 1000 pixels. A collection of prints from the Palmer Museum of Art was scanned with these same specifications. A small number of items were scanned from books or slides and considered to be less permanent additions to the collection. No TIFFs were created for these. The CONTENTdm™ software generates its own thumbnail images. Use The image database service was used primarily by students. The image database was not used by faculty as a source for projecting images in the classroom. (In the large, introductory course large numbers of digital images were projected but these had been assembled into presentations before the VIUS project. The seminar of 35 students required much less classroom projection and other sources and media were used.) Most of the use of the image database was by students – either to illustrate papers and presentations with printouts, or to supplement projected presentations in the seminar. Students in the seminar, which was only offered in Fall, 2002, were provided with a demonstration of the database and used it as one of many resources for their research into the history of certain Pennsylvania locations. Students in the much larger introductory course (repeated in Fall, 2002, and Spring, 2003, and with approximately 700 students enrolled each semester) were given an extra credit assignment that required use of the database. The assignment asked students to use the database to find one picture of a monument or site that was shown in a lecture, to print it, then to explain how the image exemplifies any two of the concepts presented in the lectures. Approximately 370 students completed this optional assignment. Other students in this class probably used the database to help with preparation for exams. (See the VIUS Reports 8.5 Survey of History of Landscape Architecture Students – Fall and 8.6 Survey of History of Landscape Architecture Students – Spring) Students and faculty outside these classes seem to have used the database as well, especially after it was publicized. Publicity consisted of a sidebar on the University Libraries database selection page throughout the Fall 2002 semester, email to teaching assistants for the targeted courses, and a large postcard, with color illustrations, that was posted and distributed during the week of March 24, 2003. Counts and demographics for logons to the database service are reported in VIUS Reports 8.7 Authentication Logs. Image Descriptions A procedure for original cataloging was established. When the focus on landscape architecture became apparent, the project team developed simple cataloging procedures for any original cataloging that would be required. Since CONTENTdm™ software only supports flat record structures, a record template of 18 fields was designed. Library of Congress Authority Files (LCAF) were to be used for the names of designers, locations, buildings, and sites. Subject heading lists were built for use with fields describing the functions of buildings and places or the materials used. These lists were composed of selected terms from the Art and Architecture Thesaurus (AAT). A small group of graduate students were employed to do most of the cataloging. A single experienced cataloging specialist reviewed their work and applied the LCAF forms of names.

8.1 Prototype Database Service Page 5 of 15

In addition to original cataloging, pre-existing descriptive data was employed. To speed construction of the database, separate record structures were designed to accommodate data from vendors and from existing Penn State collections. Data obtained from image vendors became the largest source for imported descriptions. While this approach permitted rapid batch additions of licensed data and images, it obviously led to inconsistencies in forms of names and other entries. Since some existing Penn State collections were employed, a record design tailored to their existing cataloging was created. For example, a collection of Pennsylvania town views from the Palmer Museum of Art was included in support of the seminar. Detailed descriptions were exported from the museum’s database and most of that record structure was used. This not only saved time, but this independence in the design of their file was appreciated as a potential method of “publishing” additional collections in the future. Each of these record structures was mapped to the Dublin Core elements, a useful feature of the CONTENTdm™ software that makes searches across these differing collections feasible. Two realities forced us to abandon the procedures for original cataloging after one or two months of work. The experienced cataloger had difficulty keeping pace with the group of graduate students. Also, the high percentage of imported data with different name authority control made our attempts to maintain consistency for our own cataloging somewhat pointless. Name authority control on the use of subject descriptors were both relaxed, employed only when convenient, and speed was given the highest priority. This approach made our deadline (Spring, 2002 coursework) feasible but left us with a certain cacophony of descriptive information. Since all searching with CONTENTdm™ essentially keyword many of the inconsistencies had little effect. The decisions to import existing data and to relax our own cataloging standards obviously caused some problems, but they were made consciously – in consideration of the high priority expressed by users for content. The searching features often helped to overcome shortcomings in data, but the most serious problem with the quality of data was incorrect identifications. Some incorrect identification occurred due to errors made by catalogers, but the majority occurred as a by-product of uploading data from vendors. A script was written to convert vendor data with a hierarchic structure into a tab-delimited set of “flat” records that could be uploaded into CONTENTdm™. Occasional inconsistencies in the data file cause the script to mix elements of description for one monument with elements for another. Several faculty complained about these scrambled identifications. After evaluations of the database service were completed, a database clean-up campaign was begun. It lasted from May through September, 2003 and has dramatically improved the quality of the database. However, since vendor-supplied data constituted such a large percentage of the records, many compromises were made to hasten the clean-up work. In some cases, forms of entry used by vendors became the norm to which other data was made to conform. Our original cataloging procedures have been revised for some fields in order to employ the vendor-provided forms of names as our standard. Use of subject headings in the image databases was intended to create useful groupings rather than to describe images uniquely. This approach attempted to recognize the importance and efficiency of browsing thumbnail displays. The CONTENTdm™ software produces these displays rapidly and humans are very efficient at this form of browsing. Another reason for these groupings was that the image database service offered a relatively small group of records (thousands rather than millions). As a small set of information with relatively few words available to match search terms, groupings could be used to advertise the contents of the collections. Indexers were limited to short lists of potential subject headings (From the many potential AAT terms, a list of only 100 terms was chosen to describe the function of a building or site. Only 18 terms were chosen for describing materials.) This limitation created the desired groupings and

8.1 Prototype Database Service Page 6 of 15

also suited the skills of inexpert catalogers. Keeping up with assigning these headings in a consistent way was not feasible during the initial database building work, but a team of 12 participants and volunteers were able to effectively assign the categories within 4 weeks, working part time, during the recent remodeling of the database service. This enabled redesign of the interface that included pull-down menus for types of structures and landscapes. These pull down menus for broad categories was a feature imitated from the application of CONTENTdm™ at the University of Washington, which tested well in our protocol studies. (See VIUS Reports 8.4 Think-Aloud Protocol Study of CONTENTdm™ Interfaces.) Permitted Uses The question about helping users to understand permitted uses was difficult to address. Sorting out the permitted uses of images and conveying these uses to users required two types of work: the construction of brief statements describing permitted uses and designing a system architecture that could help enforce them. This work was conducted throughout the development of the database service and is being implemented in the Fall of 2003. While our mission dictated that we distribute our image information resources as broadly as possible, we chose not to distribute the database service beyond Penn State during the project period. This allowed us to focus on the relationship of the database service to the preceding needs assessment and time to devise a system for permitted uses that would suit all of the relevant stakeholders. We chose to specify permitted uses at the level of individual images for several reasons:

• Users expressed a desire for more help with understanding permitted uses and this seemed clearer than general statements about entire collections.

• The largest collection we were building contained images from several sources that came with differing rights.

• When CONTENTdm™ searches across multiple collections the results are returned as a single set, which may mix images from several collections.

This approach requires a group of statements to be used in database records. After consulting the collection managers, donors, and administrators involved, 4 types of statements were chosen: a statement for public domain images, a statement for fair use images, a statement for licensed images, and a statement for images for which Penn State held copyright or rights to broad distribution. These statements indicated what types of uses could be made of the image. In some cases the statement of permitted uses was lengthy and detail was offered via a hotlink. (For example, licensed image descriptions were linked to a page that displayed the terms of the license.) In addition 6 different statements were prepared to specify the form of acknowledgement to be used in publication and/or the contact for obtaining permission for publication. The problem of permitted uses had a large influence on the questions regarding system architecture. Penn State wishes to distribute images to the broadest possible public when this is allowed. In the ideal system specifications we drafted, access to the images in a single database could be controlled at the individual image level. But with the CONTENT dm software all images and all “collections” within the database had the same level of access. This left us only with server control as a way of separating Penn State users from other users. This solution required 2 instances of the software (and two licensing fees). It required routine duplication of data that we wanted both Penn State and other users to see. In the case of the collection that was composed from several sources, it required making 2 databases look, to Penn State users,

8.1 Prototype Database Service Page 7 of 15

like one. This was accomplished by the HTML interface, which passed searches to both databases and combined the returned results into a single set. The work required to configure this arrangement has been formidable and is only now nearing completion. Since the work was difficult, we attempted to design a configuration that would handle broad service needs beyond the immediate problems of our user study. Since many of the institutional partners which had contributed images to the research project had hopes of future cooperative development, an arrangement of collections was planned that allowed individual identity for each collection without sacrificing much of the ability to search across collections. While this scheme seems to suit our immediate needs, we do not see it as a long-term solution. We hope for future software tools that might allow item level control of user groups and use privileges -- a problem similar to the grid of user categories and material categories that underlies automated library circulation systems. This would allow us to streamline our system architecture, eliminate duplication, and reduce maintenance chores.

Initial CONTENTdm™ Deployment on a Penn State-Only Server

Search Page Default searches across all, or search on any one of the three

Architecture and Landscape Pictures

O’Connor-Yeager Collection

University Park Campus History Collection

Vendor data with a different record structure. Penn State data with

a different record structure.

8.1 Prototype Database Service Page 8 of 15

Current Plan for CONTENTdm™ Deployment

Multiple Collection Pages Individual Collection Pages Routes to Any Page

Art, Architecture & Landscape Pictures [PSU-Only] 4 choices, or search across all

Art History Dept. Slide Collection

Worldwide Building & Landscape Pictures [public portion]

O’Connor-Yeager Collection

University Park Campus History Collection

Worldwide Building & Landscape Pictures [PSU-only portion]

[Public] Pennsylvania History Pictorial Collections 3 choices, or search across all

Mira Dock Forestry Lantern Slides

O’Connor-Yeager Collection

University Park Campus History Collection

Architecture & Landscape Pictures [public] 3 choices, or search across all

Worldwide Building & Landscape Pictures [public portion]

Catalog Records May Link to Any Page

Links to any page from other web pages, EAD pages, etc,

Links to any page from crawlers because of meta-tagging

Pub

lic S

erve

r à

<

-- P

enn

Sta

te-o

nly

Ser

ver

8.1 Prototype Database Service Page 9 of 15

Interfaces The questions regarding interface design were easier to address. During the Fall semester of 2002, the interface used for the prototype database service was the native one provided by CONTENTdm™ (the “out-of-the-box interface”). It is illustrated below.

Again, speed was the key factor in our decision. During the Fall semester, we used the HTML tools provided with CONTENTdm™ to build an HTML interface that mediated between the user and the database. It reduced search features slightly but was much easier to new users to learn. That interface was made public early in December, 2002. (See below.) This interface was tested in think-aloud protocols against the out-of-the-box interface and found to be much more usable. (See VIUS Reports 8.4 Think-Aloud Protocol Study of CONTENTdm™ Interfaces) It simplified searches. It also simplified database selection by combining files that we had separated only for technical reasons.

8.1 Prototype Database Service Page 10 of 15

As part of the transfer from a prototype to ongoing services, another campaign of interface design was undertaken. This design, presently in deployment, reflects several needs in the ongoing service plan:

• Provision of drop-down menus offering categories of images to browse. • Individual identity for a broader range of collections, including an organizational priority

to feature local history collections. • Further simplification of the search screen design.

The design of this interface was based closely upon the CONTENTdm™ application at the University of Washington. It also tested well in our think-aloud protocol study. The UW scheme supports a larger number of collections that we currently offer, so that the design suits our expectations for expansion. The new design features one subject category of collections, “Pennsylvania History Pictorial Collections,” that is stationed only on the publicly accessible server. (See below.)

8.1 Prototype Database Service Page 11 of 15

Users may search across all collections (with the option of limiting searches to 10 Dublin Core categories) or may choose any one collection. That choice calls forth a screen that permits searching the individual collection (with limits to the fields specific to that collection) or browsing. (See below.)

8.1 Prototype Database Service Page 12 of 15

A similar, but distinct hierarchy is presented for “Art Architecture and Landscape Pictures.” (See below.)

8.1 Prototype Database Service Page 13 of 15

This arts grouping must be duplicated on both servers. On the publicly accessible server the “Art History Department Visual Resource Selections” and large portions of the “Worldwide Building and Landscape Pictures” collection are omitted because of rights restrictions. Software While we do not wish to venture into a full evaluation of the CONTENTdm™ software, our experience in working with it for more than a year revealed the following strengths and weaknesses in terms of our application. Our experience is based on version 3.4. Version 3.5 was released in July 2003, but we have not employed it at the time of this writing.

8.1 Prototype Database Service Page 14 of 15

Strengths: • It provides local control of data input & editing. (We can respond to content needs in

single-item or batch mode.) • It is ready-to-use for large numbers of images and simultaneous users (and thus well-

suited our project timetable) • It provides an easy tool for searching across multiple collections with differing records

structures via Dublin Core mapping. • The displays of thumbnails and full images are surprisingly rapid. • Many options are available for exporting data • Customizable HTML interfaces are flexible and fairly easy to build. • Creating web links database images is easy. So is creating links to external pages from

within database records. • The My Favorites feature provides users with a useful, if short-term shopping cart

feature. • Light table functions are present and usable, if a bit awkward.

Weaknesses

• The software provides no help with managing image rights. • The tools for grouping similar images are poor. • The out-of-box interface proves too difficult for new users. • The display of thumbnails is inflexible. Title is the only caption available and sorting by

other fields is not available (although version 3.5 provides this). • The data editing interface has few features to make data entry efficient. Copying a

previous record, for example, is not feasible. When a large number of similar records are added, it is often more efficient to create them in a spreadsheet and batch upload a tab delimited file.

• The authority control tools are awkward, especially in relation to uploading data in batches.

• Only one file format is permitted for batch uploading of textual data. • The Acquisitions Client (data editor) and PowerPoint tool (to assist downloading into

PowerPoint) are only available for Windows platforms. • Supported server options are limited. • The system alters filenames as part of importing image files, making file naming systems

difficult to maintain. • Data integrity problems (such as added characters) appear in batch uploads. • The My Favorites screen is not customizable in the HTML interfaces. (This has been

changed in version 3.5) • As proprietary software, development is slower and choices fewer than with open source

software.

8.1 Prototype Database Service Page 15 of 15

Assessment of the Prototype Database Service The results of our user-based assessments of the prototype database service are not simple to interpret, but might be explained as reinforcing the idea that content is the most important determinate of user satisfaction. The traffic on the database service (as measured in initiated connections) was higher than traffic on the two licensed image databases that were monitored (the AP Multimedia Archive™ and the AMICO Library™). Obviously, this was primarily due to close work with the two very large groups of students in the history of landscape architecture course. However, the numbers are still meaningful. Even though our prototype service covered a much narrower subject with fewer images than a database such as the AP Multimedia Archive™, it served a larger number of users. Close work with specific curricular needs does seem to generate use. When surveyed, the students in the targeted classes expressed considerable satisfaction with the service, giving it a B+. We were surprised that this level of satisfaction did not change from the Spring group of students to the Fall group. We expected a change because the change in interfaces. The out-of-the-box interface had proven extremely difficult to use in the think-aloud protocols and those tests also showed that our custom HTML interface was much easier to use. Yet, responses to several “easy to use” questions in that survey did not change significantly from Fall to Spring. We can only guess that “easy to use” described a number of factors, including the simple fact that students were directed to an appropriate information resource and that it contained the needed information. Perhaps this created a positive attitude toward the service that colored responses to other questions. Aside from the change in interfaces, the most significant changes in the service were a larger number of images and the problematic scrambled identifications which had crept into the database. These factors might explain some of the very slightly reduced satisfaction scores for the Spring.

Henry Pisciotta

11/03