ISLANDORA AND THE SPANISH COLONIAL ARCHITECTURE COLLECTIONNicholas Woodward, Russell Holley-Hurt, Brent Sipes, Franny Gaede

Introduction The Spanish Colonial Architecture Collection is the digital representation of a curated collection by the Alexander Architectural Archive at the University of Texas at Austin. The Alexander Architectural Archive (AAA) was created to preserve materials related to the architecture industry, particularly those related to southwestern architectural heritage. Their collections are intended to support the research of students, faculty, and staff at the School of Architecture, as well as other interested researchers. This collection features 260 drawings and photographs of eighteenth-century Spanish missions and the San Antonio Governors Palace drawn from the collections of the AAA and the Texas Architecture Archive. These were created between 1920 and 1975 by professional architects and students at the School of Architecture and digitized in coordination with both archives. The previous site hosting this collection was built in 2005 and organized by property name. The collection could be further broken down by location, creator, image type, or year through a drop-down menu browse function. A JavaScript-powered map model on the main page offered another point of access to each property, which could be selected in a link menu triggered by hovering over locations highlighted on the map. These JavaScript link menus were also used in the breadcrumb navigation on each item page to facilitate browsing within sets of images. Each property page contained its own collection of images which were further subdivided into these sets based on creator name, image type, and year of creation. All of the full-size TIFF images were placed into an early version of the popular Flash-based imaging tool Zoomify, which required slicing the large images into tiles to be displayed in the viewer. These high resolution files were not made available to users for download; a derivative JPEG was offered instead. Qualified Dublin Core metadata was only partially exposed on each item page, displaying a selection of fields required for citation but little else. This collection was ideal for our purposes because it was not already located within a repository environment and had substantial metadata aggregated and available on the purpose-built site that served as a digital exhibit. Our objective was to harvest the digital images and associated metadata, transform them into formats compatible with our chosen digital repository platform, and configure and customize the new repository to best display and make available the collections materials. About Islandora Islandora is an open-source project based at the University of Prince Edward Island Library that combines a FEDORA Repository back-end with a Drupal front end. This powerful combination offers a content agnostic, preservation-minded, and extremely flexible repository with an attractive and usable interface. We were interested in Islandora because it can be implemented or removed without otherwise impacting the underlying content. It is possible to have multiple interfaces for a single collection or to adopt a new interface without having to drastically alter ingested objects.

FEDORA acts as the repository layer; its digital object model is extremely flexible, permitting linkages between data, metadata, and between objects. FEDORA was designed to be easily integrated with other applications so as to take advantage of advances in web technology: This ability to grow and change builds longevity into a [...] system built on the Fedora architecture.1 Ultimately, this will improve long-term access and preservation. Drupal acts as a collaborative interface for the FEDORA repository and makes the vast stores of community-developed themes and modules available to the repository designer. These themes and modules offer extended functionality, interactivity, and customization previously inaccessible. Drupals robust and savvy development community are on the cutting edge of web technologies, helping repository designers implement creative, engaging displays of curated materials. The primary advantage of Drupal and Islandora is that they allow users to create attractive and functional web pages without working in HTML or CSS. Islandora provides the ties that bind the two layers, enabling the definition and integration of workflows through Solution Packs, which combine content models, metadata forms, workflows, ingest forms, and viewers2. These Packs can be customized or used out of the box to manage popular types of data, such as images, books, PDFs, and audio and are capable of managing ingestion, automating the creation of derivatives, and editing repository data. Design The initial design of the repository was heavily influenced by the University of Prince Edward Island Librarys Islandora test cases, particularly the Island Imagined collection of historical maps. This site offered a number of design models: the large, rotating image on the homepage to feature interesting content from the collection, the faceted search/browse function to eliminate gratuitous results, and the metadata- and graphic-rich intermediate browse page. The priority of Island Imagined is to simplify access and improve discovery. Content is key: images are large and used wherever possible, metadata is straightforward and included in search results, and the interface is minimal to provide as much space as possible to show off the item. Stylistically, the Univeristy of Queensland eSpace, a FEDORA-powered repository with a custom interface, was particularly influential. We felt the tabbed navigation scheme was clean and familiar to most users; its an effective way to locate the user within the site. The search bar is prominent, simple, and, again, familiar; like a Google search bar, it places no restrictions on what can be entered. In pursuit of accessibility, usability, and an appealing design, we used the Austin sub theme of popular Drupal theme system Zen. Austin was developed at SXSW 2009 during the Ultimate Showdown of Content Management System Destiny by Mark Boulton, lead of the Drupal.org

1 Davis, Daniel. Fedora Commons, "Tutorial 1 - Introduction to Fedora." Last modified February 01, 2011. https://wiki.duraspace.org/display/FEDORACREATE/Tutorial 1 - Introduction to Fedora.2 Stapelfeldt, Kirsta. University of Prince Edward Island Library, "Chapter 1 - Introducing Islandora." Last modified February 09, 2012. https://wiki.duraspace.org/display/ISLANDORA6121/Chapter 1 - Introducing Islandora.

redesign team. This theme offered the tabbed browsing, clean and minimalist interface, and focus on content that captured the spirit of our original design proposal. Implementation The ingest process was developed in PHP using pre-compiled Simple Object Access Protocol (SOAP) libraries and the FEDORA Web Services Interface (API-M) for remote connections. FEDORAs API-M defines methods for creating, editing and purging digital objects, as well as datastreams within those objects. Our ingest script was designed to parse the master XML file of the Spanish Colonial Architecture Collection in order to harvest the existing metadata and the locations of the image files on the remote server. The metadata is then converted to unqualified Dublin Core using a crosswalk, while the images are transferred to the local filesystem and ImageMagick is used to create medium-sized and thumbnail versions of the blueprints. Everything is put into FOXML-1.1 format, and the script then makes a call to FEDORA to create a digital object with the datastreams required by the Islandora Basic Image Solution Pack. The Islandora Basic Image Solution Pack typically has five datastreams: DC for unqualified Dublin Core metadata, OBJ for the full image, MEDIUM_SIZE for a smaller copy of the image, TN for a thumbnail, and RELS-EXT to assign the object to a collection and a content model in FEDORA. We created an additional datastream called INFO to store the original metadata, some of which does not conform to the unqualified Dublin Core standard, for future use with the collection. The ingest script repeats this process for all 260 blueprints in the original collection, recording the return status information from FEDORA that can be reviewed in the event of a problem with the process. For organizational reasons we created a subcollection for each of the properties represented in our collection. This will make browsing much more manageable for users. To achieve this we took the FOXML (Fedora Object XML, which contains all of the details for an object and links to all of the binary files it contains) document for a previously existing subcollection, exporting it, editing several values and ingesting the new document. The relationship between the image objects and the subcollection objects is specified in the RELS-EXT document for each image object. The original metadata format was expressed in a custom qualified Dublin Core (DC) term set. During the transition, it was decided that the record metadata should be as simple possible. The final format decided upon, therefore, was a standard unqualified DC term set. With few exceptions, the custom terms developed for the original repository mapped cleanly to the standard set. In a few cases, where the mappings had no direct port or the port provided ambiguity or vagueness, the relatively limited taxonomy makes it reasonably simple to infer the meaning of the metadata element. In addition, the benefits of using standard and simple DC, like the compatibility with OAI harvesters, in this case outweighs the small gains obtained through a custom DC term namespace. The use of standard DC also obviates the problems that plague custom namespaces like schema opacity, and collection isolation and neglect as well as the need for crosswalks for inter-domain transmission. This conversion also provided the

opportunity to consolidate formerly discrete elements for ease of use. The table below provides the mappings from the previous metadata terms and elements to the new unqualified set. Old MD New MD

cn identifier

contributor contributor

contributor contributor

contributor contributor

contributorclient source

coverageplacenamecity coverage

coverageplacenamecountry coverage

coverageplacenamecounty coverage

coverageplacenamestate coverage

coverageplacenamestreet coverage

creator creator

date date

description description

identifier identifier

identifierimageno (same as cn above so redundant)

publisher publisher

relation relation

relationispartof relation

rights rights

sourcedate date

sourceformatextent format

sourceformatmedium type

sourceidentifieraccessionno date

sourceidentifiercollcode source

sourcetitle title

subjectkeyword subject

subjectlcsh subject

subjectlcsh subject

title title

type format

urn (same value as identifier above so redundant)

Islandora is designed to work with the Solr open source search engine. The Islandora module for Solr incorporates some useful advanced features such as customizable faceted search results, customized namespace restriction, and field limitation. Unfortunately, Solr was not installed on the server hosting our instance of Islandora. Islandora oddly appeared to recognize Solr as installed, which caused the team a great deal of confusion. Solr is not functioning as of the site going live. It would be an important addition to the functionality of the repository so work will continue to get Solr working. One of the most challenging problems faced by the group was that we did not initially possess admin rights to the Unix servers running FEDORA and Islandora. FEDORA especially is not controlled by changing options strictly within the program. Instead, it is necessary to manipulate files that reside on the server hosting the program. When we were granted permissions to the servers we discovered that even these rights did not allow us access to all of the folders on the server. This is likely a common frustration for library staff who must work with IT staff to resolve these issues.

Policies The policy documentation for this repository is stored in a wiki hosted by Wikispaces (owned by Tangient LLC).3 The features of wiki technology are well-suited to managing documentation processes, particularly version tracking, which is useful for understanding policy evolution, and collaborative editing. We selected Wikispaces as our host because they offer free wikispace for educational use, permit the creation of private wikis, and create attractive pages with a minimum of coding effort. While the wiki will not remain private once the repository is live, the ability to experiment with formatting and work collaboratively on policy drafts was very convenient. Policy needed to address the important fact that the Spanish Colonial Architecture Collection materials are part of an established collection accessioned and maintained by professionals at the Alexander Architectural Archive. Their pre-existing policy regarding copyright, licensing, and collection management needed to be incorporated and compatible with any new policy we might put forward. They were responsible for digitization of this content and implemented their own quality, image file format, and metadata standards which greatly impact the policy we ultimately developed. We focused our attention and energy on creating documentation for policies governing repository function. This collection was created under the aegis of the Alexander Architectural Archive to serve the needs of their stakeholders, namely students, faculty, and staff affiliated with the School of Architecture and other interested researchers from other departments and institutions. Theirs is not an open collection, and as such, it would be inappropriate to create policy for submission of materials. AAA archivists will manage the process of integrating new items into the existing collections in accordance with archival processing and quality standards. The copyright and licensing policy was also established by the AAA and applies not just to this collection, but the archive as a whole. The AAA requires researchers interested in using materials from this collection to determine who the copyright holder is for an individual item and submit An Authorization of Form for Copyright Release. This is not necessarily the policy we might have implemented given the open-source, open-access philosophy of the repository, but we recognize that in taking responsibility for these materials, the AAA has made agreements with donors to ensure their or their forebears wishes are honored. Responsibility for preservation of this collection lies with the University of Texas Library, which hosts both the original site and our repository. Their policies regarding backups, distribution, and storage media refreshment will also apply to these sites. The FEDORA Repository supports digital preservation through a number of its features, including its digital object model that links data to metadata, support for version management, conformance with OAI-PMH, a FEDORA Rebuild Utility (which can be used to recover from corruption or to migrate from Islandora to a new platform), and the persistent identifier created with each object. We understand that the digital preservation policies of AAA and the UT Libraries are always under review to ensure that practice remains current as technology and standards emerge and change.

3 Frey, Adam. Tangient LLC, "Wikispaces - about." Last modified March 28, 2012. http://www.wikispaces.com/about.

Future Work Islandora is still very much an emerging platform and development continues apace. Islandora received an important update on April 26, 2012 from 11.3.1 to 12.1.0, with updates to the Collection Manager, Solr, and Harvester modules. The changes to Solr offer improvements to advanced search capabilities, while the changes to Harvester simplify the harvesting of metadata records. Perhaps even more significantly, Drupal updated to version 7.0 in January 2011, but Islandora still runs on Drupal 6. While the earlier version is still maintained, Drupal 8 is looking at an August 2013 release, which has encouraged Islandoras developers to push toward integration with Drupal 7 sooner rather than later.4 Since Drupal does not support backward compatibility between versions, bringing Islandora up to date will be no easy task. All of the Solution Packs that provide Islandoras workflows are dependent on Drupal modules for their functionality and will have to be redesigned to accommodate the major changes in Drupal code. The update to Drupal 7 will make the software compatible with the most recent versions of PHP, improving security and efficiency. These updates will require future re-evaluation of our implementation. Given additional time and administrative resources to work on this project, there were a number of features we were interested in implementing. First, we were unable to find an adequate module that replicated the features of the News/Most Popular/Tags widget inspired by the University of Queensland eSpace. Second, we were unable to implement a slideshow of featured content on the main page due to a lack of time and difficulties getting the JW Image Rotator module to function. Third, in addition to the Solution Pack for basic images, Islandora offers a Large Image Solution Pack designed specifically for TIFF files. We developed an alternate ingest script to work with TIFF versions of the blueprints in the collection, but our development server lacked a few dependencies required by this solution pack. As a result, we were unable to develop our collection with the more functional solution pack for large images. Finally, implementing the faceted browse function in the time allotted proved to be too difficult, but is a feature we would strive to develop. Work Distribution Russell - Researched Islandora and how to create collections and website content. Created website content and edited menus and display features. Researched FEDORA metadata handling and experimented with qualified and unqualified DC. General troubleshooting. Located the checkbox that allows anonymous users to access the collection. Brent - General research on FEDORA and the various xml doc types it requires, Islandora theme install and CSS (minor tweaks), Metadata schema development and crosswalk and attendant documentation, and workflow documentation on the wiki. Franny - Wireframe for initial repository design. Designed logo for site. Created wiki for

4 Buytaert, Dries. Drupal Association, "Drupal 8 feature freeze: December 1st, 2012." Last modified February 15, 2012. http://buytaert.net/drupal-8-feature-freeze-december-1st-2012.

documentation. Developed documentation for collection, copyright, and preservation policy. Wrote much of the project report. Selected thumbnails for the subcollections. Nick - Ingest process. Developed functions in PHP to parse XML documents, harvest metadata and accompanying images, process them, and then ingest digital objects and their corresponding datastreams using methods from FEDORAs API-M interface.