Several studies have shown that quality metadata is an important component of digital collections. In their article about the challenges of metadata in university digital libraries, Attig, Copeland, and Pelikan assert that successful digital libraries must have a “robust metadata structure that can accommodate and preserve a variety of discipline-specific metadata while supporting consistent access across collections.”⁴ In a 2004 study of Australian digital collections, Hider finds that respondents think using already established standards when describing digital collections is very important.⁵ Bruce and Hillmann point out that while the library community is comfortable with attempting to quantify and measure quality, as evidenced by the acceptance of the BIBCO core record, this acceptance must take place at the community level, and that “most metadata communities outside of libraries are not yet at the point where they have begun to define, much less measure, quality.”⁶ Dushay and Hillmann adapt a commercially available visual graphical analysis tool to evaluate metadata, with the aim of developing a tool for efficiently analyzing large databases of metadata.⁷

Broad agreement on what constitutes good metadata, or even appropriate metadata is difficult. Scalability and relevance have been identified by Intner, Lazinger, and Weihs as features of good metadata as well as “adequate description of the kinds of data elements for which the library’s users search.”⁸ This last factor can vary widely within any consortium’s community. Researchers also have found that designing elaborately perfect metadata schemas may not help provide access in the absence of good data. Attig, Copeland, and Pelikan write that they “were forced to ask how little metadata would be required for discovery” and that “this question is particularly important for image data.”⁹

According to the National Information Standards Organization (NISO) framework, good metadata is appropriate for the materials in the collection, users of the collection, and intended current and likely use of the digital object; supports interoperability; uses standard controlled vocabularies to reflect the what, where, when, and who of the content; includes a clear statement on the conditions and terms of use for the digital object; is authoritative and verifiable; and supports the long-term management of objects in collections.¹⁰

Specific guidelines, such as the Computer Interchange of Museum Information’s (CIMI) “Guide to Best Practice: Dublin Core” and the Collaborative Digitization Program’s (CDP) “Dublin Core Metadata Best Practices,” provide a more detailed account of implementing the metadata component of digital projects.¹¹ These guidelines typically include element-level guidance on semantics (how to interpret an element), syntax (how to format the data that populates an element), and recommended value domains (what controlled vocabularies, coding schemes, etc. are valid for a given element). The CIMI document guides the implementation of Dublin Core (DC) in a museum environment, presenting element level guidelines for all of the fifteen elements in DC Simple.¹²

Information environments also can heavily affect metadata implementation. Providing access to digital libraries differs significantly from providing access to traditional libraries. Intner, Lazinger, and Weihs note that the very fact that the items being described are online is the “most important and obvious difference.”¹³ The authors go on to say that:

Digital libraries are likely to be very large, quickly growing, frequently changing databases; they are likely to be collaborative efforts; they are likely to include more diverse types of materials; and their users do very little searching while they are at the digital library’s home institution, if it has only one. As a result, asking a librarian how to find something one believes should be in the database but does not show up in answer to a search query may not be an option… . Without standard methods for describing database documents and their contents, maintaining authority control, and so on, access to the documents suffers.¹⁴

Baca concurs in her article about applying metadata schemas and controlled vocabularies, stating that the metadata standard for cultural heritage institutions must be “appropriate to the materials in hand and the intended end-users must be selected.”¹⁵

In an article titled “Developing a Metadata Strategy,” Agnew details the steps involved in building a metadata repository, including “modeling the information needs of your community, selecting and adapting a metadata standard, documenting your metadata, populating the database and sharing your metadata with other repositories and metadata initiatives.”¹⁶ OhioLINK institutions emphasize the importance of that consortial community. Bauer and Carlin explain that the DMC is specifically designed to eliminate barriers to institutional participation and they encourage OhioLINK institutions to focus on “content creation, acquisition and development, thus promoting the true nature of an academic collaborative venture.”¹⁷ The impact of this perspective on the quality of the DMC legacy data will be discussed later in this paper.

Cooperative communities have historically struggled to reconcile their independent metadata systems, comprised of legacy data, even in the MARC environment where standards are far more secure. Bruce and Hillmann comment that “legacy data presents special problems for many communities, as it rarely makes a clean transition into new metadata formats.”¹⁸ Bishoff and Meagher find no compelling reason to require institutions with legacy data to create new records since “economic reality requires this level of flexibility.”¹⁹ Cromwell-Kessler points out that the retrospective conversion of already existing legacy data is “expensive and time-consuming. Where no single standard exists, integration will entail ‘translating’ from one structured data system to another.”²⁰

Bishoff and Meagher perceive the challenge for collaborative projects to be the integration of separate collections “using a common set of metadata standards while retaining the unique character of each collection.”²¹ A 2004 Australian study of digital collections found that almost all of the institutions surveyed valued standardized metadata and federated search functionality and that most were working toward interoperability.²² Chopey reasons, “Because metadata for digital collections is not likely to be stored for use by any institution except the one creating and maintaining it, the driving force behind the development of metadata standards for digital collections in the future is most likely to be a desire for uniform access methodology across collections.”²³ Intner, Lazinger, and Weihs state, “Given the choice between a perfect but unique metadata schema utterly lacking in interoperability and a moderately good schema that gets high marks for interoperability, most experts recommend the latter … [because] in a collaborative environment interoperability trumps perfection every time.”²⁴

If interoperability is the key, how is it attained? Much has been written on the process of cross-walking or data mapping between metadata systems, as well as on the integration of disparate metadata systems within a single database. Cromwell-Kessler says that the process entails “difficult decisions about how to handle complex data issues.”²⁵ Baca writes about the importance of the selection of appropriate metadata schemas and the role of metadata mapping and crosswalks.²⁶ Bishoff and Meagher discuss how a collaborative project developed a matrix to look at common elements across metadata standards.²⁷

The Collaborative Digitization Program (CDP), formerly known as the Colorado Digitization Project, experienced many of these issues.²⁸ As early as 2000, Allen described the collaborations inherent in the project and the results, noting the great need for good communications and planning within the collaborative environment, stating “[t]he risks relate to quality of the digital objects, digital preservation, and quality of metadata, and these risks must be ameliorated through extensive education and training.”²⁹ The program focuses on the importance of learning through doing, and recognizes that there are unique challenges in cooperative projects.³⁰ According to Intner, Lazinger, and Weihs, the CDP is currently in the middle of its second strategic plan and doing well.³¹

Attig, Copeland, and Pelikan study the deployment of three separate metadata schema within a single database by creating a merged superset of all the elements in the three standards.³² Although this exercise proves to be relatively uncomplicated, it does not ensure true interoperability. According to Attig, Copeland, and Pelikan, “The main difficulties concern the meaning of the values contained in the elements… . They may arise out of contextual differences in the use of language in different disciplines or differences in the role that the data element itself plays in imparting meaning to the values (the hierarchical context). Regardless of the source of the differences, mapping is about meaning.”³³

Baca advocates the use of structured vocabularies and thesauri for populating metadata schemas “to increase both precision and recall in end-user retrieval.”³⁴ Metadata created by the contributors can be created more quickly and earlier in the information life cycle for rapidly growing digital collections; the process of metadata creation can more actively involve the contributors in collection development; and the contributors, as experts, can provide more accurate and granular access points.³⁵ Unfortunately, according to both Chopey and Weibel, this rosy future has not been realized.³⁶ Weibel calls the prospect of self-archived metadata seductive.³⁷ Attig, Copeland, and Pelikan contend that, in order to accommodate contributor-created metadata, the requirements for data entry must be kept modest at best.³⁸

Few traditional library catalogers have experience outside the MARC and Anglo-American Cataloging Rules paradigm. Data content standards for cultural objects were only recently formalized with the 2006 publication of Cataloging Cultural Objects: A Guide to Describing Cultural Works and Their Images.³⁹ Bishoff and Meagher note that one of the major challenges of the CDP is the lack of cataloging expertise, which they consider “a problem for all types and sizes of institutions, not just the small libraries and historical societies.”⁴⁰ They find that few catalogers participating in the program have experience analyzing and describing digital objects. Chopey observes that the level of granularity within digital collections is often higher than in library catalog.⁴¹

Caplan’s Metadata Fundamentals for All Librarians provides an excellent introduction to a variety of metadata schema and serves as a springboard for analysis of available metadata standards.⁴² Caplan lays out the principles and practices that underlie most standards and then applies these standards through critical descriptions of various families of metadata schemas. One of the metadata schemas that Caplan describes is Dublin Core (DC). This set of metadata elements was one of the products of an invitational metadata workshop held in Dublin, Ohio, at OCLC, the Online Computer Library Center, in March 1995.⁴³ The Dublin Core Metadata Initiative’s (DCMI) element set has been selected for a multitude of metadata projects, primarily because it supports data mapping and sharing, is Open Archives Initiative (OAI) compliant, and is designed for simplicity of use.⁴⁴

Hider found that most responding libraries used some level of implementation of DC in a 2004 Australian study of digital collections.⁴⁵ DC is the metadata element set of choice for the CDP to assure interoperability, although some elements were modified to facilitate the use of DC with digital surrogates of primary source materials.⁴⁶ The CDP developed a set of DC-based best practices that provides one example of how to structure an application profile to describe a wide variety of resources in a complex consortial environment.⁴⁷

In a 2004 study of the usage levels of unqualified DC metadata elements in Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) data providers, Ward found that only five of the fifteen elements are used most of the time and that more than half of the eighty-two data providers use only the creator and identifier elements.⁴⁸ According to Bruce and Hillmann, “Ward’s study indicates that most metadata providers use only a small part of the DC element set, but her study makes no attempt to determine the reliability or usefulness of the information in those few elements.”⁴⁹ A 2001 survey of DC users by Guinchard indicated that most groups choose DC for its perceived international acceptance, the flexibility of the DC elements, and the probability of future interoperability with other metadata schemes.⁵⁰ Critics of the DC element set contend that the fifteen elements are too simplified and calls for expansion have led to the addition of optional qualifiers. Others handle the simplicity issue by including non-DC metadata in addition to DC elements in their projects. In contrast to Ward’s study, most of those surveyed by Guinchard use all fifteen DC elements, lending weight to the argument that DC provides a solid foundation for metadata development. The findings support the need for usage guidelines, and some survey participants even call for the development of a DC library application profile.

Baca concludes that there is no “one-size-fits-all metadata scheme” and that therefore the first step is to select the appropriate metadata schema.⁵¹ Cromwell-Kessler notes that metadata systems may be composed of different data elements functioning at different levels, in different ways.⁵² Intner, Lazinger, and Weihs suggest that metadata schemas change because new schema develop that have new features, and that standard schema are “nearly always preferred over customized or proprietary schemas that cannot be incorporated easily into a multi-institutional, multi-database, multi-community environment.”⁵³ According to Hider’s 2004 survey of Australian digital information providers, the top reasons for choosing a metadata format are:

• most appropriate standard for nature of collection;
• existing standard for non-digital collections;
• community’s favored standard;
• government standard;
• interoperability;
• supported by system;
• existing expertise in the standard at the institution;
• requirement for participation in a cross-institution project; and
• simplicity.⁵⁴

Developing application profiles is an important first step in defining appropriate metadata. According to Agnew, “Implementing a core or root schema implies that one’s organization will be developing an application profile for the schema… . Once one has determined the data elements to be used, the attributes of those data elements, the order in which the data elements will display … and whether each element is repeatable, mandatory or optional, it is time to document the application profile.”⁵⁵ The DCMI Glossary defines an application profile (AP) as:

a declaration of the metadata terms an organization, information resource, application, or user community uses in its metadata. In a broader sense, it includes the set of metadata elements, policies, and guidelines defined for a particular application or implementation. The elements may be from one or more element sets, thus allowing a given application to meet its functional requirements by using metadata elements from several element sets including locally defined sets.⁵⁶

Elements can be further refined or narrowed, but not changed. An application profile is not just a model for documentation or for formulating guidelines; it also represents an approach to metadata that is much more flexible and responsive to local needs than is possible when simply adopting someone else’s guidelines.

Several reasons to use an application profile are presented by Neuroth and Koch.⁵⁷ An application profile provides a standardized way to document the important decisions that have been made about the elements, including content standards and rules for use. Such documentation can facilitate migration, harvesting, and other automated processes. A standard template for documentation makes it easier to maintain consistency across implementations and can assist the development of an overall metadata strategy in the future. An application profile offers a systematic way of developing and sharing a data model. Because an application profile enables tracking across implementations to verify compliance, Heery and Patel suggest it “can provide a basis for different metadata initiatives to work together.”⁵⁸

An application profile addresses local needs while still retaining desired levels of interoperability. Dekkers notes that the development of an application profile facilitates the use of multiple schemas because elements can be selected from more than one existing schema or locally created and defined.⁵⁹ Guidelines unique to a given project or community of practice can be easily documented because, “An application profile is not considered complete without documentation that defines the policies and best practices appropriate to the application.”⁶⁰ Bruce and Hillmann assert, however, that application profiles are more useful for specialized communities because “[a]pplication profiles, which by their nature are models created by community consensus, demand a level of documentation of practice that is rarely attempted by individual projects or implementers.”⁶¹ An application profile provides a framework for a fully developed set of guidelines that contributors can use as a reference or training guide for metadata creators. According to Bruce and Hillmann, “Better documentation at several levels has long been at the top of metadata practitioners’ wish list. The first and most general improvement is in the application of standards.”⁶² Project and collection level application profiles, once archived and made publicly available in an application profile repository, can be used as resources for search terms and other project documentation and by prospective contributors or other project implementers seeking information on projects similar to their own.⁶³

Heery and Clayphan note that an application profile, in the form of meta-metadata, also addresses issues of data preservation.⁶⁴ In the same manner that technical metadata is required for the ongoing preservation of digital objects, documentation of metadata in the standardized form of an application profile is needed for the preservation of metadata that inevitably will become vulnerable to corruption through the many versions and migrations that have come to be commonplace for digital collections.

Application profiles can be created at different levels of abstraction, ranging from community of practice guidelines to project level implementations. Three levels are in common use:

• Discipline- or format-based communities of practice seeking to establish a standard set of guidelines specific to a certain discipline or format. Examples include the DCMI, the CanCore Learning Resource Metadata Initiative, and the Video Development Initiative.⁶⁵
• Consortiums or other collaborative groups seeking to establish a common set of guidelines for their members. Examples include the CDP and Canadian Culture Online.⁶⁶
• Local project implementers needing to document local practice, track project specific details, and ensure compliance with other standards. At this level, application profiles are often called data dictionaries and are somewhat different than a full application profile. These local level application profiles include less detail and are more prescriptive since they document all the final choices made for a specific instantiation. Examples include the University of Washington and Miami University.⁶⁷

In “Metadata Principles and Practicalities,” Duval et al. support using application profiles to facilitate blending of metadata schemas to accommodate the functional requirements of an application while maintaining a necessary level of interoperability with base schemas.⁶⁸ They note, “Metadata modularity is a key organizing principle for environments characterized by vastly diverse sources of content, styles of content management, and approaches to resource description.”⁶⁹ By combining established metadata schemas and observed best practice, a new application can be developed that meets local requirements without sacrificing cross-domain interoperability.

In 2002, the Association of Research Libraries’ Scholarly Publishing and Academic Resources Coalition (SPARC) released “The Case for Institutional Repositories: A SPARC Position Paper,” which envisioned an institutional repository (IR) as a “strategic response to systemic problems in the existing scholarly journal system.”⁷⁰ Lynch defines an IR as a “set of services that a university offers to the members of its community for the management and dissemination of digital materials created by the institution and its community members.”⁷¹ Anuradha explains, “Institutional repositories (IR) are digital collections that capture, collect, manage, disseminate, and preserve scholarly work created by the constituent members in individual institutions. They are born out of problems with the current scholarly communication model developed by commercial publishers and vendors.”⁷² SPARC characterizes these repositories as being institutionally defined, scholarly, cumulative and perpetual, and open and interoperable.⁷³

By studying the growth rates in the usage of electronic scholarly information, Odlyzko finds them sufficiently high to predict that “there will be no doubt that print versions will be eclipsed… . To stay relevant, scholars, publishers and librarians will have to make even larger efforts to make their material easily accessible.”⁷⁴ Allard, Mack, and Feltner-Reichert find that “the growth in literature demonstrates that institutional repositories are gaining in momentum throughout academia.”⁷⁵ In a 2005 study of IR deployment in thirteen nations, Westrienen and Lynch witnessed a great diversity in IRs, and predict that deployment rates will continue to increase.⁷⁶ Shearer acknowledges predicting the long-term success of the IR model is difficult.⁷⁷ Chopey notes that successful implementations require broad collaborations of expertise as well as strong guidance from collection curators or compilers.⁷⁸ In addition, Lynch observes that the success of IRs depends on institutions recognizing IR as a serious and long-lasting commitment.⁷⁹

The DMC was established in 1997 using the Bulldog digital asset management software. When the Task Force began investigating metadata, the DMC contained collections with an eclectic assortment of digital media files of multidisciplinary interest, each with its own unique metadata needs and issues. At the time of this writing, the DMC contains more than 54,000 digital images of art and architecture, more than 1,500 full-length educational videos, and almost 4,000 items in six historic and archival collections. Contributions come from an array of Ohio institutions and arrive in a variety of formats including sound files, digital video, and various standard imaging formats. Commercial collections—the Encyclopedia of Physics Demonstrations, LANDSAT 7 Satellite Images of Ohio, Sanborn Fire Insurance Maps, Saskia Art History Images, and the ART Collection of art and archaeology objects—are also available through the DMC. Licensing agreements for these databases require OhioLINK to restrict access to individuals associated with an OhioLINK member institution.

Metadata for each collection was supplied by the OhioLINK contributor, a commercial vendor, or harvested by the software. Subject terminologies specific to the genre of the collections, terms used by subject specialists, and terms familiar to patrons desiring access to particular collections of digital media were used. Topical overlap was minimal and the structures and specificity of the terminology varied widely. For example, terms used to describe the photographs in the Wright Brothers Collection were very different from those used to describe the videos in the Encyclopedia of Physics Demonstrations.

The Bulldog software allowed keyword indexing of selected fields within each collection. This indexing was augmented by structured index fields from commercial media products or adapted from the indexing supplied with a project. Descriptive terms for subject searches had to be selected from a pool of terms supplied with the software. The variance in initial metadata and subject terminology resulted in the creation of separate databases, each with metadata appropriate to a specific genre or discipline in addition to the more generic terms supplied by the software.

The limitations of the software ultimately hindered searching of the DMC collections. Content in one collection could not be searched from within another collection, nor could users of the repository expect consistent application of subject terms or consistent search results across the collections. Though a common subject thesaurus for the DMC was available, it was not apparent from the user interface, nor was the Bulldog thesaurus available to users. By the time the Task Force was formed, a company called Documentum had acquired the Bulldog digital asset management software and was developing software that integrated document management, Web content management, digital asset management, and metadata with functionality to facilitate federated searching and data harvesting. Any new structure would have to address the quality, consistency, and compatibility of the metadata as well as access to the collections. After further examination of the Documentum system, OhioLINK staff decided to look for an open source system that could handle the varied metadata formats, metadata cross-walks, library-specific protocols, and higher education standards needed in today’s consortial environment.

From the beginning, the data structures in the DMC were not apparent or consistent because of the nature of the information. These metadata were created for collections that were designed for different audiences and based on various metadata standards. The need for a cross-disciplinary core set of elements was apparent. Every collection had unique fields and a few common fields that could be mapped to Dublin Core, the Visual Resources Association (VRA) Core, and the Collaborative Digitization Program Core.⁸⁰ Multiple types of data structures led to discrepancies between databases and with established standards. For example, the ART Collection data did not follow the standard set by the VRA, and, according to the license agreement, the data had to be mounted as provided. OhioLINK chose to accommodate the needs of a wide variety of contributors rather than risk losing the projects.

While all the databases contained a small number of similar fields, some databases included fields that did not apply to other databases. The Task Force prepared an analysis of metadata in each subject database to determine needs, characteristics, and problems. Initial efforts involved mapping existing DMC metadata and metadata from locally held collections not yet submitted to the DMC into one of several emerging metadata standards. The Task Force then compared the DMC elements to elements used by the Collaborative Digitization Program and Dublin Core. These efforts resulted in “The DMC Core Fields Analysis Document.”⁸¹ Further developments of this spreadsheet yielded initial assessments of whether or not each metadata element appeared to be mandatory, required, or optional; whether or not the data field was repeatable; and notations of any issues that appeared to be associated with use of the field.

Cross-domain interoperability is a common theme throughout digital library research. Digital collections with different architectures, metadata formats, and underlying technologies need common protocols and standards in order to interact. The Task Force agreed that the future of the DMC collections and their growth would depend on finding and adopting a set of metadata standards that would be flexible enough to accommodate the needs of the individual OhioLINK digital collections while facilitating federated searching, a challenge in part because no one had examined the relationships between the DMC databases that would facilitate federated searching. Though procedures (in the format of a proposal form) were in place for submitting collections to the DMC, enforced standards or documentation for establishing new data or metadata structures were not available to contributors.⁸² The Task Force anticipated that a core set of metadata elements accommodating existing and future collections must be developed to facilitate potential development and federated searching. This core set of elements would be anchored in metadata standards and accompanied by a best practices document to assist data compatibility of future DMC collections.

In the preceding few years, there had been an explosion in the growth and development of non-MARC metadata standards. The Task Force considered and rejected a variety of standards for adoption in the DMC. Some standards, such as Encoded Archival Description (EAD) and Metadata Object Description Schema (MODS) were rejected because they were deemed too complicated for non-cataloger contributors.⁸³ The Text Encoding Initiative (TEI) standard was not considered because of concerns with attaching the metadata directly to the digital object.⁸⁴ Several educational standards, including Sharable Content Object Reference Model (SCORM), Learning Object Metadata (LOM) and Metadata for Education Group (MEG), were examined and deemed too specific for this project.⁸⁵ The VRA Core Categories also were discussed extensively, but were ultimately discarded as being too cultural object-oriented to accommodate the data.⁸⁶ The Task Force ultimately chose an application profile to document the current decisions and to provide the needed framework for a more fully developed set of guidelines in the future.

The Task Force needed a base schema that would accommodate the heterogeneous content of the DMC represented by multiple formats, multiple subject areas, and multiple contributors, and simultaneously support federated searching and harvesting. The schema also needed to be interoperable with legacy data and be adaptable to change over time. Every effort was made to choose recognized authoritative sources in common use by the digital library community. After a careful review of emerging metadata schemas, best practice documents, and the DMC elements currently in use, the Task Force selected the DC schema as the basis for the core element set because it met the requirements of the DMC environment.

The DC element set was developed with the goals of interoperability, extensibility, and flexibility in mind. Interoperability is important for cross-domain discovery and harvesting. DC provides a high level of interoperability and thus would support federated searching and harvesting. Other standards are too narrow to be applied across all of the DMC collections. The Task Force’s work also indicated that all manifestations of existing DMC metadata, as well as selected schemas used in non-DMC collections at OhioLINK member institutions, could be mapped to elements in DC. Dublin Core Simple had been established as an international standard, which increased the possibility that it would come into common use. DC was also the foundation of the OAI-PMH.⁸⁷ According to Lagoze, “The OAI approach to metadata harvesting exemplifies the notion of metadata modularization, mandating simple Dublin Core metadata for cross-community interoperability while supporting, in parallel, community-specific metadata for ‘drill-down’ searching within domains.”⁸⁸ These trends are important because the larger the community of users for a single standard, the greater the opportunity for resource sharing through harvesting and cross-domain discovery. DC also supports the creation of resource descriptions that are easy to produce and use, which is an important consideration for contributors without access to training or professional catalogers.

The Task Force discussed numerous fields as possible core elements and the implications of including and excluding each in the application profile. These discussions were often long and sometimes contentious. Even though most members worked in libraries, a substantial difference of views existed regarding metadata and what steps should be pursued. In the end, the list was narrowed to twenty-two core fields including elements from DC and supplementary elements deemed necessary in the OhioLINK environment. Mapping to the DC element and the DC definition has been retained for those elements drawn directly from the DC element set. Any refinements have been made according to DCMI principles. Table 1 is a list of the core fields and their relationship to the original, the digital manifestation, and OhioLINK asset management. The Task Force viewed these core elements as a starting point for institutions interested in creating metadata for the collections in the DMC. Each institution would have the option to use only the core fields or to include additional fields beyond the core to adequately describe their collections. The creation of subject-related sets of element extensions and additional fields would be possible at any time.

The DMC Core contains six mandatory elements—Title, Creator, Digital Publisher, Asset Type, Object Identifier, and Permissions. Of these six elements, two are system-supplied—Asset Type and Object Identifier—and three are OhioLINK-specific—Asset Type, Object Identifier, and Permissions. By making Title, Creator, and Digital Publisher the only other mandatory elements and by demonstrating that metadata could be as simple or complex as a project warranted, the Task Force hoped to promote widespread adoption of the Core by DMC contributors.

The Title element, defined as a name given to a resource, was the most difficult element to finalize. Although the Task Force agreed that Title should be mandatory, the occurrence was revised more than once. The Task Force disagreed about whether or not Title should be repeatable or non-repeatable, and whether or not alternate titles should be included in the core elements. If alternate titles were included, should the alternate title be part of the Title element, thus requiring Title to be repeatable, or a separate element? If alternate title was a separate element, should it be a core field? All of these decisions had to be in place before the input guidelines could be finished and the Title element finalized. The Task Force eventually decided to make the Title element non-repeatable and to include any other titles in the additional fields. Additional fields are non-core fields needed for a specific project and are beyond the scope of the application profile document. Figure 1 shows the Title element.

The second mandatory element is Creator, which includes authors, artists, photographers, collectors, or organizations primarily responsible for producing the content of the resource. Entities with a secondary role in the creation process such as editors, illustrators, and preformers are included in the optional Contributor element. Both Creator and Contributor are repeatable fields. Project implementers are instructed to enter names according to established rules (for example, Anglo-American Cataloguing Rules, 2nd ed. (AACR2), and Archives, Personal Papers, and Manuscripts) or use the guidelines outlined in the DMC Metadata Application Profile.⁸⁹ The General Input Guidelines state that the same rules or guidelines should be used for names throughout the project profile. The recommended scheme for both elements is the Library of Congress Authorities file.⁹⁰

The Date element contains the creation or modification date or dates of the original resource. Date is required (if applicable) and repeatable. A resource may have several dates associated with the original resource such as creation date, copyright date, revision date, and modification date. The Digital Creation Date element records the date of creation or availability of the digital resource and may be approximated by the agency of creation. This element is required (if available) and non-repeatable. Date maps to DC.date while Digital Creation Date maps to DC.date.available, a refinement of DC.date. The recommended scheme for both elements is ISO 8601, the International Standard for the representation of dates and times.⁹¹

The Description element is an account of the content of the resource and may include an abstract, table of contents, provenance, or other descriptive text. The Description element holds specialized information that is not included in other elements. Description is required (if available) and repeatable. The Subject element, or topic of the content of the resource, is required (if available) and repeatable. The application profile strongly recommends selecting a value from, or creating values according to, a controlled vocabulary, name authority file, or formal classification scheme to ensure consistency, reduce spelling errors, and improve the quality of search results. Examples include the Library of Congress Subject Headings (LCSH), Medical Subject Headings (MeSH), and the Thesaurus for Graphic Materials I: Subject Terms.⁹²

Spatial Coverage describes the location or locations covered by the intellectual content of the resource, not the place of publication. Examples include place names, longitude, and latitude. Recommended schemes for Spatial Coverage include the Getty Thesaurus of Geographic Names, DCMI Box, DCMI Point, ISO 3166, and LCSH.⁹³ Temporal Coverage refers to the time period covered by the intellectual content of the resource, not the date of publication or digital creation date. The recommended schemes for Temporal Coverage are ISO 8601 and LCSH. Both coverage-related elements are optional, repeatable, and map to DC.Coverage, which includes refinements for spatial and temporal coverage.

The Language element records the language of the intellectual content of a resource and is required (if available) and repeatable. Some resources may contain multiple languages while others, such as images, may not contain a language component at all. The recommended scheme for Language is ISO 639-2, a three letter code set for the representation of names of languages.⁹⁴

Work type refers to the manifestation of the original element and is required (if available) and repeatable. The application profile suggests applying terms from an established scheme such as the Art and Architecture Thesaurus or the Thesaurus for Graphic Materials II: Genre and Physical Characteristics to ensure consistent usage.⁹⁵ Asset Source records the immediate parent or manifestation of the digital object and often will be the same as Work Type. This element is optional and repeatable.

Repository Name lists the organization or institution that holds the original physical object, if applicable. Repository ID holds a number or other identifier for the resource from which the present resource was derived, such as a local accession number. Both of these elements are optional, because some digital resources do not have a repository, and both are repeatable. The Collection Name element records the formal or informal group of objects to which the item belongs. This element is optional and repeatable.

The Digital Publisher is defined as the entity responsible for making the resource available to OhioLINK. Examples include an academic department, corporate body, publishing house, or museum. This element is mandatory and repeatable. If Digital Publisher is the same as Creator or Contributor, the application profile instructs users to enter the information in both elements. This element may or may not be related to the entity listed in the OhioLINK Institution element, which is a consistent reference to the OhioLINK member that contributes the material. OhioLINK Institution is required (if available) and repeatable. Like Creator and Contributor, the recommended scheme for Digital Publisher is the Library of Congress Authorities File.

The Digitizing Equipment element records the equipment or tools used to create the digital object. This element is optional and repeatable. The Rights element records information about rights held in and over the resource. This optional, repeatable field typically contains a rights management statement for the resource or a reference to a service providing the information. Rights information often encompasses Intellectual Property Rights (IPR), copyright, and property rights. The application profile states that if the rights element is absent, no assumptions may be made about any rights held in or over the resource. The Permissions element lists the audience that the publisher agrees to allow access to the content. This mandatory, non-repeatable element has three options—world, state of Ohio, or OhioLINK.

Asset Type records the manifestation of the resource. The software automatically captures this mandatory, non-repeatable element. Values include image, audio, video, or text, and related properties such as file format, file size, and dimensions. This element maps loosely to both DC.Type and DC.Format. Object Identifier (OID) is a mandatory unique identifier automatically assigned to the digital object that is subsequently used to form a persistent URL.

Each element in the application profile contains eight different specifications. Four of the specifications are presented in the condensed view of the DMC Core elements in table 2. “Element Name” represents a single characteristic or property of a resource. The “Definition” specifies the type of information required for the named element. In most cases definitions are taken directly from the Dublin Core Element Set. A definition may also contain comments providing additional information or clarification. “Obligation” indicates whether or not a value must be entered. Three types of obligations are used in this application profile. “Mandatory” is defined as a value that must be entered even if it requires the creation of an arbitrary value. “Required (if available)” is defined as a value that must be included if it is available. “Optional” means that it is not necessary to include a value for this element. “Occurrence” indicates whether a single value or multiple values can be included. Two occurrences are used in the DMC Core—repeatable and non-repeatable.

“Recommended Schemes” refers to established lists of terms or classification codes from which a user can select when assigning values to an element. Two types of schemes—vocabulary-encoding schemes, which are controlled lists of words such LCSH, and syntax encoding schemes, which indicate that the value must be formatted in accordance with a formal notation, such as how a date is to be entered—may be used. “Input Guidelines” list common conventions and syntax rules used to guide the data-entry process. In the case of system-supplied elements, a brief explanation of the process is provided. Two types of input guidelines are provided—general and element-specific. General guidelines that apply to more than one element are located near the beginning of the application profile to cut down on repetition and length of the document. Input guidelines specific to an element are located on the page for that element. “Examples” are provided for each element to illustrate the types of values, conventions, and syntax used for the element. “Maps to DC Element” gives the DC element equivalent, if applicable.

Input guidelines are included to provide a relatively simple way to promote data consistency and assist with data creation while still allowing some flexibility. The application profile was created to accommodate an audience beyond catalogers and others familiar with metadata creation. The Task Force attempted to anticipate questions and to help those unfamiliar with the metadata process plan their projects by providing decision points up front. While anticipating all situations was impossible, every effort was made to assist contributors in metadata creation. External content standards are also referenced as appropriate.