The use of MARC and the Anglo-American Cataloguing Rules (AACR) has been a less popular approach for capturing descriptive metadata for special format digitization projects. MARC as a tool in digitization projects has been criticized in the past for being “too complex, requiring highly trained staff and specialized input systems,” and for being too focused on print material and not extendable for digital collections.⁵ More recent reviews and comparisons have looked upon MARC more favorably. Beall outlines twelve criteria for comparing metadata schema, suggesting numerous advantages for the use of MARC in library projects.⁶ Significant among Beall’s criteria is the availability of systems and software to support any given metadata scheme, meaning that MARC metadata can be created and searched in library ILSs, a desirable feature often taken for granted. Layne reported as early as 1991 the use of the MARC format for a digitization project of images in medieval manuscripts.⁷ Recognizing that MARC is very often not the method of choice for manuscript materials, her primary question related to the usefulness of MARC for this purpose, which was to provide description and access, while applying widely known and accepted standards. She concluded that the flexibility of the format was effective, and it continues to be used. Other small, special format digitization projects described in the literature using MARC include the joint University of Pennsylvania Library–Cambridge University Library project in 2006 to create online catalog records and an image database on the Web of dispersed manuscript fragments and the mixed collections of ephemera (Pennsylvania German broadsides and Fraktur) taking place at Pennsylvania State University Libraries.⁸ The former selected MARC principally to integrate the descriptive metadata into the existing library system while the website uses a crosswalk to convert the records to DC. The latter focussed on the challenges of using the multiple sets of cataloging rules accompanying formats of monographic broadsides, graphic materials, and manuscripts.

These cases represent comparatively small projects limited to finite collections. MARC is also applied for ongoing, nonproject-based digitization. Two major institutions using MARC for ongoing maps digitization are the LC Geography and Maps Division, as part of the American Memory Project (http://memory.loc.gov/ammem), and the Harvard Map Collection (http://hcl.harvard.edu/libraries/maps). Both of these use MARC records for descriptive metadata and to provide access to scanned map images from the online public access catalog (OPAC) through hyperlinking. When the link in the OPAC is selected, an external viewer is launched that allows interactive features with the image, such as panning and zooming.

Previously published research relating experience with the use of MARC for special format digitization projects enriches understanding of the benefits of using MARC as a format and the challenges and methods of interpreting Anglo-American Cataloguing Rules, 2nd ed. (AACR2) cataloging standards for such collections.⁹ Thus far, however, no detailed practical reports on the way in which MARC analytics can be applied to reveal visual materials hidden within another bibliographical unit (e.g., maps in books) or how bibliographical data would be structured to accommodate this have been published.

Many digitization projects are employing metadata standards specifically designed to capture information about digital image data, and these schemas reflect the flexibility possible in the new and continually emerging systems used to manage them. Projects handling cartographic materials, in common with wider practice, use any number and combination of standards and methods of capturing metadata, including the well-established DC, MARC, Federal Geographic Data Committee (FGDC), Encoded Archival Description (EAD), Metadata Encoding Transmission Standard (METS), and Metadata Object Description Schema (MODS). The projects including maps are too numerous to detail comprehensively, so a select few are highlighted to illustrate the diversity and flexibility of solutions being developed.

In many cases, a defined scheme is adapted to the project. In the case of the Collaborative Digitization Program (originally the Colorado Digital Program), no one standard was deemed appropriate; the participating institutions’ existent metadata schema were all mapped to a minimal DC element set in order to facilitate efficient crosswalking of metadata from the archival, museum, and library collaborators.¹⁰ The same type of amalgamation was applied by the project librarian Nicholas Graham for North Carolina Maps (www.lib.unc.edu/dc/ncmaps), a collaborative project merging images and records from library and archives catalogs in both MARC and EAD.¹¹ The data from existing catalog records were downloaded to a spreadsheet, additional fields were added, and the plan is to eventually export these data to MODS. Such a method requires consistent mapping between the various metadata fields, and Graham’s work crosswalking between four standards is invaluable.

In other cases, more than one set of metadata is captured, allowing different standards for different purposes. METS, an Extensible Markup Language (XML)–based schema for packaging related sets of digital objects, was used for digitised Sanborn maps at University of Colorado at Boulder Libraries, but only after MARC records were created for the digital and analog versions in the library catalogs, with the data then converted to XML.¹² In combination with locally developed tools, the project used MarcEdit, a freely available utility developed by Terry Reese at Oregon State University for batch editing and converting MARC between formats.¹³ The same tool was used by Brenner in her innovative project with the Oregon Sustainable Community Digital Library (http://oscdl.research.pdx.edu) to merge metadata from disparate contributors, display scanned materials through Google Earth, and provide MARC metadata, all directly from the library’s OPAC.¹⁴

Scanned maps that are converted to geospatial data, as in McGlamery’s monumental distributed project of scanned and geo-referenced topographic maps of the Austro-Hungarian Empire, require more specialised content standards.¹⁵ Although the International Organization for Standardization standard for geographic information (ISO 19115) was considered, FGDC’s Content Standard for Digital Geospatial Metadata, with its antecedents in MARC, was ultimately selected, and a customised application was developed for metadata input.

These standards are used effectively with a host of new commercial software products devised to manage metadata collection, discovery, distribution, and display of digitized images. Referred to collectively as Digital Visual Information Management, these systems include library OPACs, content management systems, digital asset management systems, and digital repositories.¹⁶

A number of approaches are currently being taken to manage digitized content in the BL. Although MARC and AACR2 are used for the majority of BL cataloging, the BL has used different standards for specific circumstances, and a combination of in-house BL work and components provided by third parties for metadata and systems is usually used.

The BL Application Profile (BLAP), an extended DC-based declaration of descriptive metadata terms encoded as XML, was developed to support a high-level cross-searching facility among BL resources of different types and with different metadata formats, and has been used in several large BL digitization projects. An early implementation was Collect Britain (www.collectbritain.co.uk), one of the largest digitization projects thus far carried out by the BL, the aim of which was to digitize a selection of historic content from several BL collection areas. BLAP metadata was stored in an Structured Query Language (SQL) Server 2000 database and digital objects in a file store, using content management systems to upload and deliver Web content. Another large project, British Newspapers 1800–1900 (www.bl.uk/reshelp/findhelprestype/news/newspdigproj/ndproject), digitizing up to two million pages of British national, regional, and local newspapers, used a customization of BLAP and an Open Archives Initiative for Metadata Harvesting (OAI-PMH) data provider service for interoperability requirements within third party content management systems. BLAP also has been used to describe sound recordings in the Archival Sound Recordings project (http://sounds.bl.uk) and to provide a metadata standard for use with BL Web resources.

Many small, discrete digitization projects fall into the Themed Collections Programme, defined as “systems developed using a standard software architecture designed to hold varied and complex data and allow it to be searched, edited, and presented in various ‘themed’ ways, usually on the internet.”¹⁷ These were devised to provide cataloging and a search interface for collections considered incompatible with the ILS; bibliographic data is stored in XML in SQL Server 2005. The Themed Collections has been used successfully for several BL projects that mix metadata, text, and images. These include databases of, for example, Renaissance Festival Books (www.bl.uk/treasures/festivalbooks/homepage.html), Database of Italian Academies (www.bl.uk/catalogues/ItalianAcademies), and Historic Photographs (www.bl.uk/onlinegallery/features/photographicproject/index.html). In addition to resource discovery through the BL website, the system facilitates data exchange with other organizations, links to digital objects, and item requesting. METS has already been used in the BL as a “wrapper” for the Archival Sound Recordings project (http://sounds.bl.uk) and is now also being used to package the various types of metadata associated with e-journals (e.g., MODS, PREservation Metadata: Implementation Strategies (PREMIS)). The use of METS will no doubt be extended to other content types.

OAI-PMH is currently being investigated by the BL to harvest data from digital objects stored in the BL’s Digital Library System so that it can be used for a variety of resource discovery initiatives such as the European Union–funded Europeana project (http://dev.europeana.eu). OAI-PMH is still being used in the BL only for specific projects such as these, and although not ready to be used for this project, the BL plans to expand its usage into more general areas.

The data structure for a book in the ILS takes the form of a MARC 21 bibliographic record for the book, a separate MARC 21 holdings record linked to the book record and containing data about the book’s location as well as its physical condition and other aspects specific to the individual copy, and an Aleph-specific item record representing the physical copy. The item record is linked to the holdings record. The presence of an item record introduces some conceptual problems because the holdings record represents the individual copy in MARC; however, item records are essential because Aleph administrative functions are carried out against them.

The analytic bibliographic record representing the map does not have its own holdings record because holdings policy in the BL dictates that holdings below the item level may not be expressed. Instead, it is linked to the bibliographic record for the host item. This link enables viewing the location of the host item and requesting the item through the map analytic record, even though the holdings record is not linked directly to it. Figure 2 presents a model of this data structure.

The project team realized quickly that individually cataloging each map would be the most efficient means of identifying each and recording its location and context. Creating a new record for the map using the MARC format and the AACR2 standards for cartographic materials would capture the bibliographical information by which items might be searched. Additionally, the linking functionality offered by MARC and the ILS would properly express the relationship between the map and its host item.

The project template consisted of a set of core data elements. Common to other online catalog records for cartographic materials, they were already accommodated in the ILS and follow AACR2 rules. Other fields, such as notes, added entries, and additional subject headings, were added when appropriate. The LC access-level record standard was not specifically considered for this project, but many data elements it includes were replicated.²⁰ Some data elements it contains were inappropriate for this project, for example the MARC linking fields 580 and 780 for reasons given in the following section.

The appendix presents a list of the fields in the template for the analytic bibliographic record for the map, with standard options and anomalies or features specific to the project noted. Numerous other fields appear in the records. The Aleph Linker (LKR) field expresses the link between the analytic and the host record in the ILS. Among the copy-specific information fields used at the BL, the 562 Copy and Version Identification Note was employed, the development of which is described in the similarly titled section below. Additional required ILS–specific fields are also used. Figure 3 is an example of a completed record and describes the image shown in figure 1.

Bibliographic records representing the pre–1700 books in which the maps were contained were already present in the ILS. This project did not require changing or upgrading these records in any way.

The analytic bibliographic records representing the maps had to be created where they did not already exist according to the standard described above. Initially, the link between the child analytic map record and the parent book record was a tenuous one, built by manually entering the host and shelfmark as MARC fields 740 (added entries for related or analytical titles), 773 (information concerning the host item for the constituent unit described), and 852 (location) in each analytic record. The linking functionality afforded by the MARC linking fields, although technically possible in Aleph, was not used in the BL implementation; instead, the dedicated Aleph LKR field was used. The ILS can accommodate several different types of links between records using the LKR field; for example, it is used to link the holdings record to the bibliographic record. The link that was used for this project was the “Up/down” analytic link between bibliographic records of different levels, in this case between the parent book record and the child analytic map record.

Record system numbers, which are unique to each record in the ILS (and are used as the unique identifiers throughout the project), are fundamental to the linking process. Although the LKR field has the functionality to create the links, the system number of the linked record in the LKR field identifies which record should be linked to which. The LKR field appears in the sample bibliographic record in figure 3.

Systems Management assisted in the development of a macro for inserting and populating an LKR field into the child record to generate a hyperlink between the two automatically, and this was integrated into the cataloging workflow. By entering the LKR field in one record, the ILS functionality generates reciprocal links between the parent and child records. One effect of this is to expand the location information given in the holdings record for the book into the analytic bibliographic record, facilitating requesting in the BL’s onsite retrieval system.

Recording the condition description of each individual map was considered to be vital to identify unequivocally the unique copy of each image owned by the BL. This presented a challenge as basic copy-specific information was previously only recorded in item records and inconsistently and sporadically in bibliographic and holdings records. In response to the specific needs of this project and others throughout the BL, a new policy to enter copy-specific information at the holdings and bibliographic level in standard MARC fields was devised, allowing for such cases where analytics are used to represent part of a work.²¹ Following this policy, the condition description is transcribed in the 562 field of the analytic bibliographic record instead of in the holdings record (as analytics may not have their own holdings records).

The content of the condition note (field 562) included the location of the map in the volume; description of paper, including location of watermarks or inequalities; printing, noting strength of impression, bleeding, offsetting, or plate marks; damage, such as stains, wormholes, tears, and repair work; or other markings including coloring or annotations. Because of the free-text nature of this field, a style sheet was developed with colleagues in the BL’s Early Printed Collections to establish agreed vocabulary, abbreviations, and punctuation.

Identifying the copy as belonging to the BL within the relevant field was essential if the record was shared with another institution. Copy-specific fields in BL collection items are distinguished by the shelfmark of the copy being described preceding all content in the first subfield within each copy-specific field. This is because, although each note is linked to a single holdings record, it will be displayed in a bibliographic record that may be linked to several holdings. Also, as the details described only pertain to the BL copy, $5Uk is added to the end of each copy-specific field to identify the institution where the copy is held.

Including an indication that the map has been digitized (with the project affiliation) in each record was desirable to ease retrieval of maps included in the digitization project. This information was recorded in the area of Preservation and Digitization Actions (field 583), an area that could be compared to elements in preservation metadata schema. Use of this field is, as a matter of BL policy, normally reserved for use by conservation staff who use the dedicated Preservation and Conservation Management System, a separate instance of Aleph reserved for conservation work. Nevertheless, this field was used throughout this project so that the existence of a digital copy could be readily ascertained. This field is suppressed from public view by specifying a particular indicator value, which the OPAC has been configured to take into account.

Most of the relevant fields in the bibliographic record were already indexed and visible, and so searchable and viewable in the ILS configuration. As part of the work to compile the “British Library Policy for Copy-Specific Information,” all relevant fields in the bibliographic and holdings record were reviewed, and relevant changes were made to the ILS to ensure that they were indexed and visible within the staff view.²² This guaranteed searching and access to the records across the staff view. For display in the OPAC, fields considered sensitive or unnecessary for the public to view (e.g., 583) were suppressed from public display as described above. Interaction with the BL’s requesting system was integrated in that, just as the parent book can be requested directly using the standard requesting function in the OPAC, the analytic may be requested in the same way. As previously stated, this is because the analytic also contains the location details of the parent book because of the functionality of the LKR field.

The needs of users searching the OPAC differed little from the original, internal-only audience. To staff and to the public educated in the structure and elements contained in library catalogs, searching by title, author, or subject are the expected retrieval methods for published materials. Within the OPAC, searches for records in the project may be limited by searching only within the Digital Items subset of the overall collection, or by searching for the Local Subject Heading, Scanned Maps, and Views. Outside of the OPAC, the new presence of these materials is highlighted within BL Help for Researchers webpages, offering guidance on searching the ILS for maps, so it was not considered necessary to create additional webpages.

The project team wanted to provide precise and quick retrieval of the images through a bibliographic search. The image and its metadata are linked to the bibliographic record. Immediate access to images serves several functions:

• It enables project staff to verify the ILS record and image authenticity as well as check the correct file naming assignment using a single system.
• It provides a visual finding aid (or a digital surrogate, depending on what is being investigated) to assist users in determining whether the material is of sufficient interest to warrant requesting the original volume.
• The storage of the image in the OPAC, with the bibliographic record and the requesting system, provides increased access in an immediate and familiar interface while sparing the fragile materials from unnecessary handling.
• The ADAM module allows capture of further technical metadata for rights management and access control with the image.

The ADAM module, which enables image files to be managed, delivered, and discovered, allowed “access images” (i.e., cropped, low-resolution JPEG images) to be attached to the analytic bibliographic records. Though the module is not yet widely used in the BL, permission was granted by the ILS Service Management Group to the project team for this initiative. A low-resolution access image of approximately 100–250 kb was created at the time of image capture for storage in ADAM. Like the TIFF master file to be stored in the library’s digital archive, it is named according to the maps’ unique identifier, the ILS system number of the bibliographic record. These images are added manually to each of the records, thereby going through another process of ensuring the number, metadata, and record match. Figure 4 presents the object opened alongside the bibliographic record in the staff interface of the ILS.

In preparation for the records and attached images to be made visible in the OPAC, a batch service was run by the ILS team to create thumbnails for all of the objects. A screen shot of the appearance of records in the OPAC, with the thumbnail alongside, may be seen in figure 5. At the bottom of each record is an icon that links to the access-sized image of the file in a separate window.

The use of ADAM meant that some of the MARC fields that have become standard at other institutions for cataloging digital images and electronic reproductions were not used. In such cases, when an item is available on the Web, the MARC 856 field (Electronic Location and Access for “information needed to locate and access an electronic resource”) will contain the URL with an active hyperlink to the raster image. In the case of a reproduction of a print item, the record may include a second 007 field in the bibliographic record to describe the digital reproduction. Because the location of the file was not being provided, and the 006 field was applied to designate the secondary digital form, neither of these fields was used. The first template began with a MARC 530 (Additional Physical Form Available) note, but this was eschewed by the time of the second mutation because it repeated data already present in the record.

This tool is successful in managing the digital images for internal project purposes; for users, it provides an irreplaceable visual aid for an essentially graphic format that is difficult to visualize on the basis of the textual information supplied in a bibliographic record. Clicking on the thumbnail image produces a pop-up window with the enlarged access image, as in figure 6. Unlike most projects that make images available through a Web browser, however, there is no interactive functionality with the images. This could be a serious disadvantage if a user is interested in conducting research solely within the OPAC rather than using the images as a finding aid to consider if the original is relevant or worth consulting. The smallest typeface and other details on the map may not be sufficiently legible in the access images.

Along with item and holdings records, the digital object record created using ADAM forms part of the array of administrative data linked to the bibliographic records for the image and its host item. The ADAM record can contain metadata on copyright, access permissions to view the image, and technical details of the image. These are not as detailed or as sophisticated as they could be in METS, but they served the purpose of this project.

Using established international cataloging rules and format standards throughout the library ensures flexibility with changing technology, leaving open the possibilities for alternate systems, expanded functionality, and secondary uses. Amid the rapid changes taking place in library systems, image management, and metadata standards, this is particularly important for small-scale project work, which can easily be left behind by larger changes. In the future, the BL will presumably move to an XML–based schema to represent descriptive metadata (though it is too early to speculate exactly what form this will take). The general trend in libraries is to move away from traditional OPACs and to replace these with Web interfaces that offer more sophisticated and configurable display options and more user-controlled activities, such as tagging. An XML–based format is required for effective integration of bibliographic data in Web interfaces. Although MARC and the current data structures in the BL ILS are satisfactory, any move to an XML–based format will provide an opportunity to look at the data afresh with a view to improve its structure and display.

The BL is already planning to move to RDA, the successor to AACR2, in 2010. RDA is based on FRBR principles. In traditional cataloging, bibliographic units are described out of context; in FRBR, items must be described in context in a manner sufficient to relate the item to the other items making up the work. In the fullest implementation of RDA (Scenario 1), data is stored in a relational or object-oriented database structure that mirrors the FRBR and FRAD conceptual models. This more effectively supports what this project attempted to achieve—expressing the relationship between individual digitized images and their host work, documenting information about the image and making it accessible. The BL will initially implement Scenario 2 of RDA (currently scheduled for the first half of 2010), in which bibliographic and authority files are linked and which the BL ILS supports. This means that the introduction of RDA into the BL will not have any effect on this project.

The issue of security arose as a result of the proposal to make the information available to the public. Curators questioned whether exposure (i.e., making users aware of the existence of library materials) would make those items more vulnerable to theft. This attitude is an enduring one and counters widespread library practices such as cataloging, digitization, and creation of indexes, research guides, and finding aids. There has been extended discussion among professionals on library security of maps, a topic beyond the scope of this paper.²³ It is generally felt that a descriptive catalog record, especially one that includes copy-specific information, is a record of ownership and serves to protect materials.

Digitized images and associated metadata are often presented through separate, dedicated project websites, even when prepared by libraries with an OPAC. This may be because of limitations of library system technology or metadata structures in the past. Alternately, it could be attributed to the inevitable progression of research methods, user expectations, and information access in society, which can make OPACs, AACR2, and MARC 21 seem inadequate and obsolete.²⁴

Though this paper only discusses a single element of the project (i.e., metadata capture), the project team was relatively successful in bringing together various departmental interests and input. This brought out questions, however, as to who should be doing what and for whom within the institution, given the number of tasks that were new and not neatly designated in job descriptions or by precedents. Frequently, libraries have dedicated staff for digitization, but even in the best cases the institutional infrastructure is relied upon to make it functional. This raises the question as to whether many librarians will move from project to project, or if project tasks will be written into jobs.