The findings of the HOPE Content Providers Survey revealed two main obstacles to mapping metadata provided by HOPE content providers to the HOPE Common Metadata Structure: 1) the cross-domain nature of content provider metadata, i.e the fact that the metadata describes archival as well as library, visual, and audiovisual resources; 2) the idiosyncratic nature of the metadata, i.e the fact that metadata is not encoded according to published encoding standards. This means that even within one domain, content providers would use a wide variety of encoding schemas to prepare their data sets.
In order to overcome these obstacles, HOPE has developed five domain profiles, which serve to intermediate the transformation between the local metadata structures and the HOPE Common Metadata Structure. By mapping local metadata structures to one of these profiles, content providers confront the idiosyncratic features in their metadata in order to make it interoperable within its specified domain. In a second step, the HOPE metadata is transformed from these five domain profiles to the common HOPE Common Metadata Structure. The final step is the transformation of the HOPE metadata to the metadata structure of a discovery service. Content providers are involved only in the first transformation step; the other transformations are internal to the Aggregator and based on crosswalks specified by the HOPE project.
A HOPE domain profile is a subset of metadata elements derived from a domain-specific metadata standard, which accommodates descriptive, administrative, and structural metadata about HOPE collections from a particular domain. HOPE provides five subsets, four domain-specific profiles and a fifth profile for content providers supplying metadata in Dublin Core. In the initial HOPE Content Providers Survey, HOPE defined three domains or communities: archives, library, and museum. These domains referred to both institutions and particular types of resources and reflected the Europeana domains. In light of survey results, HOPE decided to replace the term 'museum' with 'visual' to avoid confusion; several HOPE libraries and archives were found to have photographic or ephemera collections described with museum-type metadata. HOPE also added a separate audiovisual domain, a domain already defined by Europeana and specifically requested by several content providers. A fifth so-called 'cross-domain' was also included as some content providers intended to supply collections encoded using Dublin Core—in essence the generic nature and the limited number of metadata elements specified by Dublin Core made it difficult to map this metadata to one of the four domain-specific profiles defined. The five HOPE domains as currently defined are:
- ''Archives:'' Archival collections or fonds typically include large sets of materials created or received by a person, family, or organization/institution, public or private, in the conduct of their affairs. Due to the sheer size of collections, archival descriptions typically refer to multiple documents regarding the same event or case. Archival finding aids are typically multilevel and lower levels inherit the characteristics of higher level descriptions.
- ''Library:'' Library collections typically accommodate published materials, e.g. monographs, periodicals, leaflets, posters, etc. Metadata typically consists of generic title descriptions, which may include additional information about the copy-at-hand. Bibliographic description can have a hierarchical structure including series, titles, and item/copy descriptions.
- ''Visual:'' Visual collections typically accommodate sets of single objects, e.g. photographs, posters, prints, objects, etc. The metadata typically holds item descriptions for each single object. Visual description often includes rich metadata on single objects or groupings, e.g. a sheet of stamps, a suite of prints, a cycle of paintings, sometimes gathered in formal or informal collections.
- ''Audiovisual:'' Audiovisual collections typically accommodate multimedia resources, such as film, video, broadcasts, sound recordings. The metadata typically holds title descriptions and metadata on related events such as releases and broadcasts. Audiovisual description typically requires a distinction between the creation and the manifestation of the resource.
- ''Cross-domain'': These collections include archival, library, visual, or audiovisual material with generic Dublin Core item descriptions.
Europeana has taken it upon itself to recommend domain-specific encoding standards for each of its identified domains. Currently they recommend an encoding standard for only two of the four: Encoded Archival Description (EAD) in the archives domain and Lightweight Information Describing Objects (LIDO) in the museum domain. HOPE has incorporated these and studied the current best practices in the library and audiovisual domains to come up with its own encoding practice.
When possible, HOPE has also used the domain-specific cataloging standards currently used by content providers to guide its selection and grouping of elements from each of the chosen encoding standards. HOPE's basic approach was to take the minimum elements required by the cataloging standard. These were enriched based on metadata samples and feedback from the HOPE content providers. This process eventually ensured that 90 percent of the existing HOPE content provider metadata could easily be mapped in one of the four profiles or in the Dublin Core profile. These HOPE-defined domain elements were then mapped to EAD, MARCXML, LIDO, and Dublin Core. As the EN15907-compliant XML schema was not yet published at the time of the profile definition, the audiovisual profile remains a prototype.
It is hoped that by closely following cataloging standards used by content providers, HOPE has likewise lightened the burden of selecting a domain profile and mapping domain-specific elements. In addition, several Europeana-related projects have reached consensus on use of common namespaces and metadata dialects to establish semantic interoperability within their network. When applicable, such efforts can also be used by content providers as guidance in identifying and applying the domain profiles.
HOPE Archival Profile
- ''Encoding Standard'': EAD v. 2002
- ''Cataloging Standard'': General International Standard Archival Description (ISAD(G)) 2nd ed., 2000
- ''Europeana Best Practice'': APEnet
In the HOPE Content Providers Survey nine out of twelve content providers indicated that they had one or more archival collections. Of these, five content providers, holding 86.4 percent of the archival metadata records, did not use a published metadata standard for recording archival metadata, but rather one or more idiosyncratic sets of metadata elements—one used the ISAD(G) standard as a basis for its idiosyncratic element set. Of the remaining four, three used EAD 2002 as the basis and one Dublin Core, composing 9.7 percent and .15 percent of the archival records, respectively. In sum, a large majority of the HOPE metadata records on archive resources are encoded with idiosyncratic element sets.
HOPE opted to use EAD version 2002 as the source for the its archival metadata elements. EAD is a well-established encoding standard in the archives domain and reflects the hierarchical nature of archival collections, supporting the description of the whole of a collection as well as its component parts. As noted above, EAD was also used by the Archive Portal of Europe (APEnet) project to develop a European archival metadata aggregator that will be linked with the Europeana portal. Importantly, EAD version 2002 has now established compatibility with the widely-used ISAD(G).
ISAD(G) is a set of cataloging rules providing "general guidance for the preparation of archival descriptions. It is to be used in conjunction with existing national standards or as the basis for the development of national standards." (International Council on Archives, ''ISAD(G): General International Standard Archival Description'', p. 1.) ISAD(G) defines twenty-six elements that may be combined to constitute the description of an archival entity. The structure and content of the information in each of these elements should be formulated in accordance with applicable national rules. As general rules, these are intended to be broadly applicable to descriptions of archives regardless of the nature or extent of the unit being described.
Table 3-E - HOPE Archival Profile v. 1.5. Mapping table with the HOPE archival elements arrayed under general areas and sub-areas. Equivalent elements from standard namespaces are also included.
It is hoped that at minimum the ISAD(G) framework can help guide content providers with idiosyncratic data sets in mapping their elements. In the longer term, the local implementation of the ISAD(G) standard by content providers will further the cause of data harmonization in HOPE.
HOPE Library Profile
- ''Encoding Standard'': MARC 21 XML Schema (MARCXML) v.1.2, 2009
- ''Cataloging Standard'': International Standard for Bibliographic Description (ISBD) consolidated, 2007
In the HOPE Content Providers Survey nine out of twelve content providers indicated they had one or more library collections. Of these, four content providers, holding 13.5 percent of the library metadata records, did not use a metadata standard for recording library metadata but rather one or more idiosyncratic sets of metadata elements—one used the ISBD cataloging rules for the specification of their element set. Three content providers, holding 84.8 percent of the library metadata records, employed a metadata standard from the MARC family. More specifically, a single institution, holding 84.3 percent of the library metadata records, used Maschinelles Austauschformat für Bibliotheken (MAB), the German national library standard based on MARC21, as an export format. The other two listed the Metadata Object Description Schema (MODS) and MARCXML. A single content provider used EAD as an export format though the metadata is native ISBD, and another used Dublin Core.
Since 84.3 percent of the HOPE bibliographic metadata was supplied by a single institution, the major part of the HOPE bibliographic metadata was already encoded using MAB. On the other side, MAB was only used by a single content provider. In this sense, the most commonly used metadata standard was actually the MARC family, including native MARCXML, MARC21-related MAB, and MODS. Moreover, those institutions using the ISBD cataloguing rules as a reference for their idiosyncratic element sets or EAD as an encoding format are able to map their metadata to MARC21 with relative ease. Thus, HOPE opted to use MARC21 Bibliographic as a source for specifying the subset of library metadata elements. MARCXML was selected for encoding metadata mapped to the library profile. The MARCXML Schema supports XML markup of full MARC21 records, featuring lossless conversion to and from MARC21 records, a conversion toolkit, and style sheets. The schema simply duplicates the MARC content designation structure in a native XML encoding format.
Thus, for the specification of the subset of library elements, HOPE borrowed element names and semantics from MARC21 Bibliographic, a standard for the representation and communication of bibliographic and related information in machine-readable form. (MARC is an acronym for MAchine Readable Cataloging). MARC 21 Bibliographic supports bibliographic records on print and manuscript textual materials, computer files, maps, music, continuing resources, visual materials, and mixed materials. Importantly, The European Library (TEL), the Europeana library network as well as its overarching organizational structure, provides a mapping from MARC21 Bibliographic to its Dublin Core based application profile. By selecting MARC21 Bibliographic HOPE has therefore ensured basic compliance with TEL. Since several content providers use the ISBD cataloging rules for the creation of library records, the library profile also includes references to ISBD in the logical units of the profile.
Table 3-F - HOPE Library Profile v. 1.5. Mapping table with the HOPE library elements arrayed under general areas and sub-areas. Equivalent elements from standard namespaces are also included.
It is hoped that content providers will turn to the standards themselves in setting cataloging practice. The use of the ISBD framework and MARC21 elements will help guide content providers with both MARC- and ISBD-based data sets in mapping their elements. HOPE additionally plans to follow up on the research by TELplus on the implementation of Functional Requirements for Bibliographic Records (FRBR) categories in the TEL application profile. The Europeana v.1.0 project is also considering the integration of FRBR categories in a future release of the Europeana Data Model (EDM). HOPE may benefit from tools developed to transform current Dublin-Core-based TEL application profile to an FRBR-compliant EDM profile.
HOPE Visual Profile
- ''Encoding Standard'': LIDO v1.0, 2010
- ''Cataloging Standard'': SPECTRUM Standard for Collections Management v3.1, 2007
- ''Europeana Best Practice'': ATHENA Project
In the HOPE Content Providers Survey, five out of twelve content providers stated that they had one or more museum collections. Of these, a single institution holding 59.9 percent of the identified museum metadata used MARC21 to encode it. Two others, holding 11.9 percent of the museum metadata, used Dublin Core for encoding, and the last two, holding the remaining 28.2 percent, did not use a metadata standard for encoding but one or more idiosyncratic sets of metadata elements. Yet, it is important to note that the HOPE Content Providers Survey specifically asked institutions to identify 'museum collections' rather than 'visual collections'. If the question had been posed differently, a number of the collections marked as archival or library may have been identified as visual. In this case, the pool of potential content providers providing visual metadata grows to eleven out of the twelve and EAD should be included alongside other potential encoding standards. 53.6 percent of the enlarged set of visual metadata was not encoded with any metadata standard but using idiosyncratic sets of metadata elements; 31 percent was encoded in MARC21; approximately 6.1 percent was encoded in EAD; and another 6.1 percent in Dublin Core.
In either case, the variety in metadata standards and idiosyncratic element sets proved too large, and it was not possible identify a commonly used metadata standard. Instead it seemed that content providers either borrowed the standards of other supported domains (e.g. EAD or MARC21) to encode rich item descriptions for visual resources, or used customized element sets—often simply extended versions of archival or library formats. None used an encoding standard taken from the museum community, such as Categories for the Description of Works of Art (CDWA) lite, Visual Resources Association (VRA) core, or museumdat.
For this reason, HOPE opted to use LIDO, the Europeana best practice metadata standard for the museum domain, despite the fact that none of the content providers had previously employed it. LIDO is a metadata format combining the CDWA Lite and museumdat schemas and informed by SPECTRUM concepts and is the result of a joint effort by these communities to facilitate the exchange and discovery of museum resources. As it is also compliant with the International Committee for Documentation of the International Council of Museums conceptual reference model (CIDOC CRM), it can handle rich description of cultural heritage objects of all ilks. Finally, LIDO is endorsed by ATHENA, the Europeana museum-related network, and thus mapping to LIDO will facilitate the integration of rich HOPE visual metadata in the Europeana portal.
In order to provide guidance for mapping the variety of metadata structures for visual resources into the LIDO format, the visual profile refers to the SPECTRUM 'information groups' for grouping the LIDO-based elements into logical sets. As implied by the name, SPECTRUM is intended to support the complete spectrum of activities for documenting and managing museum collections. SPECTRUM defines twenty procedures, laying out the discrete steps for specific tasks in the museum environment, e.g. accession, loans, or risk assessment, as well as the supporting data elements.
Table 3-G - HOPE Visual Profile v. 1.5. Mapping table with the HOPE visual elements arrayed under general areas and sub-areas. Equivalent elements from standard namespaces are also included.
In the case of the visual works HOPE content providers do not currently employ visual standards in local systems. HOPE's use of the SPECTRUM framework and LIDO elements may serve to guide organizations in the standardization of hitherto idiosyncratic visual metadata.
HOPE Audiovisual Profile (Prototype)
- ''Encoding Standard'': European Film Gateway (EFG) XML Schema, 2009
- ''Europeana Best Practice'': EN15907
The HOPE Content Providers Survey did not specifically address audiovisual collections. The domain was introduced only after analysis of the survey results and at the specific request of several content providers. In the survey, audiovisual collections were identified as museum, library, archival, or other. However, potential audiovisual collections were relatively easy to pick out based on the indicated material type. The Content Providers Survey revealed that five of the twelve content providers might supply one or more audiovisual collections. Of this group, three content providers, holding 63.4 percent of the potential audiovisual metadata, did not use a metadata standard for encoding audiovisual metadata but rather one or more idiosyncratic sets of elements; of this group, one used the same idiosyncratic element set as for its visual metadata, the other two used sets based on Dublin Core. One content provider, holding 27.4 percent of the potential audiovisual metadata, used Dublin Core for encoding audiovisual metadata. Another, holding 9 percent of the potential audiovisual metadata, used MARC21.
In view of the large variety of element sets used by these five content providers to describe audiovisual resources, it was not possible to define a common metadata standard. Although three used element sets based on Dublin Core, two borrowed element sets directly from other communities in order to capture rich metadata. In this situation, HOPE looked to best practice within the audiovisual community. Two candidates emerged from this process, both developed by Europeana-related projects specifically dealing with audiovisual resources. The first was EBUCore, the metadata format used by the EUScreen project as the basis of their audiovisual portal as well as for the supply of their metadata to Europeana.
Table 3-H - HOPE Audiovisual Profile (prototype). Table with the proposed HOPE audiovisual elements arrayed under general areas and sub-areas.
The second was the EFG Metadata Schema, the XML schema (and related data model) used by the European Film Gateway (EFG) project as a common interoperability framework for their portal. The EFG model is based on ''inter alia'' Dublin Core and FRBR. Both EFG and EBUCore have already been mapped to the Europeana Semantic Elements (ESE) and work is underway in the EFG community to develop an updated mapping which takes advantage of the possibilities offered by EDM.
Both schemas are implementations of a metadata standard for cinematographic works produced by the European Committee for Standardization (CEN). This Cinematographic Works Standard has two parts: 1) EN15744 is an implementation of the Dublin Core application profile and specifies a minimum set of information elements for the unambiguous identification of film works; 2) EN15907 is a data model specification for structuring machine-processable metadata about cinematographic works and is intended to serve as a guideline for the development of interoperable systems. EN15907 has also been acknowledged by Europeana as best practice in the audiovisual domain. HOPE has thus opted to base the HOPE audiovisual profile directly on the EN15907 data model. As the EN15907-compliant XML schema was not yet published at the time of the profile definition, the audiovisual profile is still a prototype.
HOPE Dublin Core Profile
- ''Encoding Standard'': Qualified Dublin Core
- ''Europeana Best Practice'': Europeana Semantic Elements (ESE) v3.3.1
Based on an analysis of the results from the HOPE Content Providers Survey and feedback from the first test mappings to the domain profiles, HOPE decided to add a fifth more generic cross-domain profile to the four domain-specific profiles. This profile supports content providers that supply only a base set of Dublin Core metadata on archival, library, visual, or audiovisual materials in the cases that this is the only metadata available.
The Dublin Core Metadata Element Set is in essence a vocabulary of fifteen properties for use in general resource description. The element set was developed to serve as a core set of relatively broad and generic fields that could be used for describing a wide range of resources. Europeana developed ESE as an application profile based primarily on Dublin Core descriptive elements and intended to support cross-domain exchange of descriptive metadata. Though ESE has been superseded by EDM, the application profile has been integrated into the new data model, and data supplied using the ESE format will continue to be supported. The implementation of the Dublin Core element set in the HOPE Dublin Core profile is analogous with the ESE implementation with a two exceptions: 1) HOPE has replaced the dc:format element with the dcterms sub-properties dcterms:extent and dcterms:format; and 2) HOPE has likewise replaced the dc:coverage element with the dcterms sub-properties dcterms:spatial and dcterms:temporal.
Table 3-I - HOPE Dublin Core Profile v. 1.5. Mapping table with the HOPE cross-domain elements arrayed under general areas and sub-areas. Equivalent elements from standard namespaces are also included.
The Qualified Dublin Core elements are also the basis of the descriptive metadata in the HOPE Common Metadata Structure.
Hierarchically Structured Descriptions
Hierarchical descriptions may be found in any of the HOPE-defined domains and include ''inter alia'' descriptions of multilevel archival fonds, monograph series and periodicals, audiovisual series and televised serials, and visual series. Nevertheless, the HOPE Content Providers Survey suggested that only fourteen of the 129 collections proposed for submission to HOPE contained hierarchical descriptions, including eleven archival collections and three library collections. Beyond this, several content providers indicated they would like to submit hierarchically structured collections in the near future. Thus, though the issue of hierarchically structured descriptions currently applies to only a small proportion of the metadata, HOPE deemed it of longer-term importance to support hierarchical description (as well as the ordered sequencing of Descriptive Units sharing a common parent) within each domain.
As a general rule, the domain profiles record hierarchical and ordered descriptions in accordance with the specifications of the corresponding encoding standard, as follows:
- ''Archival Profile'' records hierarchical descriptions and sequence information as nested and ordered <c> level records, as specified in EAD;
- ''Library Profile'' records references to a parent record using the marc:774 Constituent Unit Entry metadata element, as specified in MARCXML—note that HOPE does not map metadata from the parent record into the 80X-83X Series Added Entry Fields; sequence information is recorded with the marc:785 Succeeding Entry element;
- ''Visual Profile'' records the relation to a parent record and sequence information through LIDO's relatedWorksWrap using the relation types 'is contained by' and 'is next in sequence';
- ''Dublin Core Profile'' records the relation to a parent record with dcterms:isPartOf; sequence information is not formally captured in Dublin Core.
(Importantly, during the mapping process HOPE also provides the opportunity for content providers to describe in plain language how hierarchical or sequence information is recorded in its data set. For instance, data sets may record ranking numbers for each archival item in a container list.) The HOPE Metadata Schema in turn represents metadata about hierarchical descriptions in a way that is analogous with the EDM in order to ensure a simple mapping to the EDM format.
The HOPE data model also requires that each Descriptive Unit be assigned a Level of Description, i.e. the level of arrangement of the descriptive unit. Borrowed from archival descriptive practice, this element is mandatory in HOPE for library, visual, audiovisual, and Dublin Core encoded materials as well. HOPE has developed a list of generic values for use in this element. (See: Semantic Harmonization, section on Harmonizing Hierarchically Structured Descriptions.) It is hoped that by capturing and normalizing this information, HOPE will provide a valuable search and display option for the HOPE Social History Resource. Beyond this, it was not feasible to develop domain-specific controlled lists for the Level of Description element within the scope of the current project. It is proposed to consider the specification of domain vocabularies for Levels of Description as a priority in a next phase of HOPE.
Application of Domain Profiles to HOPE Collections
The digital objects and related descriptions intended for submission to HOPE must be grouped into coherent data sets, which are by convention known as collections. Content providers are encouraged to provide collections that are as logical, meaningful, and coherent as possible in relation to their content. Each submitted item may belong to one and only one collection.
The data mappings used by the Aggregator are defined per collection, and each HOPE content provider is at liberty to choose the domain profile that is most appropriate for each collection. In many cases, this may not be based on the type of material but rather on the existing metadata.
Example: A content provider currently using MARC21 for encoding audiovisual collections may choose to use the HOPE library profile for this material.
Example: A Content Provider currently using EAD for encoding library resources may choose to use the HOPE archival profile for these resources.
In both examples the mapping procedure to the domain profiles is relatively easy. However in these cases, this metadata will be presented in the IALHI and Europeana portals in a domain-specific context that corresponds to the profile rather than the institutional domain or material type.
Importantly, the domain-specific elements of the Descriptive Unit make up only part of the five HOPE domain profiles; each also includes elements on related digital objects (e.g. Rights, Language, Type, Derivatives) stored as part of the Digital Resource entity and elements to record structural information (e.g. sequence information for Descriptive Units and Digital Resources). (See: Semantic Model: Modelling Digital Objects.) In essence, the profiles 'flatten' information from several entities in the HOPE data model in order to facilitate mapping. PIDs for all entities are captured in order to ensure the relationships between Descriptive Units and Digital Resources and also to serve as links back to objects or metadata presented by local systems. It should be noted that HOPE has created various workarounds which enable the Aggregator to create and manage PIDs; this allows content providers to store only local identifiers.
It remains important to distinguish between the elements as defined in the domain profiles and those that make up the HOPE Common Metadata Structure. The majority of HOPE's descriptive elements are stored and expressed in Qualified Dublin Core. In these cases, the domain profile element name is recorded as a 'label' attribute of the XML element alongside attributes which map the schema element to domain-specific 'encoding' and 'cataloging' standards.
Example of a HOPE schema element with domain attributes:
Creator: a person or organisation primarily responsible for making the collection item. (0,*)
- Archival: <creator label="origination" encoding="ead:origination" cataloguing="ISAD(G):2.1"></creator>
- Library: <creator label="statement of responsibility" encoding="marc:245$c" cataloguing="ISBD:1.5"></creator>
- Visual: <creator label="object production name" encoding="lido:eventActor" cataloguing="spectrum:object production name"></creator>
- Audiovisual: <creator label="director - person" encoding="EN15907:productionEvent/HasAgent/Agent/Name"></creator>
- Dublin Core: <creator label="creator" encoding="dc:creator"></creator>
For a few elements (those that make up the domain sub-entities of the Descriptive Unit entity), the HOPE schema element is not based on Qualified Dublin Core but directly on the domain element. In this case, the label and the element names are synonymous.
Example of similar HOPE schema elements taken directly from domains:
- Archival: <appearanceOfMaterial label="appearance of the material" encoding="ead:physdesc" cataloguing="ISAD(G):1.5"></appearanceOfMaterial>
- Library: <generalMaterialDesignation label="general material designation" encoding="marc:245$k" cataloguing="ISBD 1.2"></generalMaterialDesignation>
- Visual: <objectName label="object name" encoding="lido:objectWorkType" cataloguing="spectrum:object name"></objectName>
- Audiovisual: <instantiationType label="instantiation type" encoding="EN15907:instantiation type"></instantiationType>
- Dublin Core: <medium label="medium" encoding="dcterms:medium"></medium>
(See: Semantic Model: Common Data Model and XML Schema, section on Entities of the HOPE Data Model.)
By the same token, it is important to distinguish between hard-coded requirements and domain requirements. The HOPE Common Metadata Structure contains relatively few hard-coded requirements. These include: 1) the structural metadata needed to identify entities and maintain their integrity in the Aggregator; 2) language information to facilitate indexing; and 3) the elements required by Europeana. For the most part, the domain-specific element requirements discussed in the sections above serve to guide the mapping process. They are not checked by the Aggregator but should be confirmed by the content providers themselves.
Finally, HOPE requires collection-level metadata for each submitted collection. This will serve as a domain-independent access point in the Social History Portal. To this end, a common collection profile with relatively stringent requirements has been defined based on the Dublin Core Collections Application Profile (DCCAP). (See: Semantic Harmonization, section on Metadata Recommendations for Collection Descriptive Units.) Though still treated as a standard Descriptive Unit, the collection description is not part of the mapped data set submitted by the content provider but is created during the mapping process. Collection records may stand directly above sets of item records or sets of series-level records. Collection records may not link directly to digital content.
HOPE Domain Profiles as Best Practice
HOPE has succeeded well in capturing the nuances of the various domains while at the same time fostering cross-domain access. The HOPE Common Metadata Structure facilitates the cross searching of HOPE collections by creating a single index for every Dublin Core element, while attributes and a small number of dedicated elements retain information from the domain context. Such information might form the basis of domain-based searching or display in the IALHI portal. It would likewise enable the Aggregator to export records directly in domain encoding standards. In the specification of its domain profiles, HOPE has greatly benefited from the concrete data provided by its content providers. Such data not only informed the selection of the encoding standards but also guided the selection of elements from each of the chosen standards. As it stands, 90 percent of the existing content provider metadata can be captured by one of the HOPE profiles.
Nevertheless, HOPE's method also raises several issues. In its reliance on the existing metadata of content providers, HOPE has suffered from a certain unevenness in approach. First, there are several instances where elements required in the encoding or cataloging standards are not mandatory in HOPE, even as part of the domain-specific requirements. Moreover, there is inconsistency in the selection and treatment of parallel elements from the different domains. In particular, rights and language elements, though present in most standards, are missing from some of the domain profiles:
Example showing the HOPE Descriptive Unit Language element in the various domains:
Language: language of the collection item. (0,*)
- Archival: <language label="language of the described material" encoding="ead:langmaterial" cataloguing="ISAD(G):4.3"></language>
- Library: none
- Visual: none
- Audiovisual: <language label="original language" encoding="EN15907:language"></language><language label="language used" encoding="EN15907:language@usage="language used""></language><language label="subtitle language" encoding="EN15907:language@usage="subtitle" "></language>
- Dublin Core: none
Example showing the HOPE Descriptive Unit Rights element in the various domains:
Rights: textual information about rights held in and over the collection item. (0,*)
- Archive: <rights label="conditions governing access" encoding="ead:accessrestrict" cataloguing="ISAD(G):4.1"></rights><rights label="conditions governing use" encoding="ead:userestrict" cataloguing="ISAD(G):4.2"></rights>
- Library: none
- Visual: <rights label="credit line" encoding="lido:creditLine" cataloguing="spectrum:credit line">
- Audiovisual: <rights label="IPR registration" encoding="EN15907:IPR Registration/nameOfApplicant"></rights><rights label="access conditions" encoding="EN15907:accessConditions"></rights>
- Dublin Core: <rights label="rights" encoding="dc:rights"></rights>
The inconsistency is mitigated by the fact that HOPE records values for both language and use rights for digital objects (as part of the Digital Resource). (See: Semantic Model: Modelling Digital Objects, section on HOPE Digital Object Modelling as Best Practice; see also: Semantic Harmonization, section on Value Types Selected for Normalization.) Still, this does not explain the varied treatment in different domains. Indeed, in the case of rights information HOPE seems to have fallen short of a base functional requirement:
...end users should be clearly informed of intellectual property rights (IPR) and access rights, including use conditions applicable for each item of the collections made available...
...the structure had to contain metadata elements to record access restrictions on metadata and digital objects as well as use rights for the digital objects and physical material...
(See: Semantic Model: Functional Requirements, section on Discovery-to-Delivery Needs of Designated Community.) It is probable that both of the above issues result from an over-dependence on content provider data. Both can and should be corrected in later versions of the domain profiles.
More troubling perhaps is the lack of consistency in element requirements across the domains. The descriptive metadata requirements by profile are as follows:
- Archival Profile: Level of Description, Call Number, Title;
- Library Profile: Level of Description, Book Number, Title or Title Proper;
- Visual Profile: Level of Description, Object Number, Repository;
- Audiovisual Profile: Level of Description, Inventory Number;
- Dublin Core Profile: Level of Description, Resource Identifier.
The requirement for title information is notably missing from the visual, audiovisual, and Dublin Core profiles. This also flouts domain requirements, as noted above. (Version 1.5 of the library profile has also removed the requirement for Book Number.) Finally, the absence of mandatory date information is notable given HOPE's defined user needs:
...Users must be able to filter result sets by date, language, and media type or format...contextual information and other enhancements of base metadata, e.g. timelines, themes, or tags, should be presented as part of the search and discovery interface.
(See: Semantic Model: Functional Requirements, section on Discovery-to-Delivery Needs of Designated Community.) As noted above, HOPE has kept requirements to a bare minimum; hard coded requirements basically ensure data integrity, facilitate multilingual indexing, and meet the standards defined by HOPE's primary external discovery service, Europeana.
Broadly speaking, by closely following current practice HOPE may have missed an opportunity to shape future practice. In its efforts to accommodate existing data, HOPE has underestimated its important role in raising standards. In so doing, the project likewise seems to have overlooked the fact that many content providers (current and future) will use the HOPE domain profiles as a model for local structures. More to the point, the relatively low acceptance levels set by HOPE are a missed opportunity to forge a coherent resource for use by IALHI researchers. The fault my lie at least in part with a funding scheme that measured success through the quantity rather than the quality of data created. Simply put, HOPE lacked the mandate to raise the quality of metadata.
To redress this to some extent, HOPE has provided a set of general best practice recommendations for descriptive metadata across all domains. The project has also created an additional contextual layer set over and above submitted metadata to attempt to bridge the gaps in linguistic and professional practice. Both are discussed in later sections.
Related Resources
''Dublin Core (DC)'' (http://dublincore.org)
EBU. ''EBU Core Metadata Set (EBUCore), Version 1.8''. EBU Tech 3293. Geneva: 2017. https://tech.ebu.ch/docs/tech/tech3293.pdf
''EN 15907'' (http://filmstandards.org/fsc/index.php/EN_15907)
''Encoded Archival Description (EAD)'' (http://www.loc.gov/ead)
''Europeana Professional'' (http://pro.europeana.eu)
''European Film Gateway Project'' (http://www.efgproject.eu)
''Functional Requirements for Bibliographic Records (FRBR)'' (https://www.ifla.org/files/assets/cataloguing/frbr/frbr.pdf)
HOPE: Heritage of the People's Europe. "Appendix B: HOPE Audiovisual Profile (prototype)." ''The HOPE Common Metadata Structure, including Harmonisation Specifications''. May 2011.
HOPE: Heritage of the People's Europe. ''HOPE Archival Profile Mapping Table, Version 1.5''. August 2012.
HOPE: Heritage of the People's Europe. ''HOPE Dublin Core Profile Mapping Table, Version 1.5''. August 2012.
HOPE: Heritage of the People's Europe. ''HOPE Library Profile Mapping Table, Version 1.5''. August 2012.
HOPE: Heritage of the People's Europe. ''HOPE Visual Profile Mapping Table, Version 1.5''. August 2012.
International Council on Archives (ICA). ''ISAD(G): General International Standard Archival Description, Second Edition''. Ottawa: 2000. (https://www.ica.org/en/isadg-general-international-standard-archival-de…)
International Council of Museums (ICOM-CIDOC). ''LIDO - Lightweight Information Describing Objects, Version 1.0''. 2010. (http://network.icom.museum/cidoc/working-groups/lido/what-is-lido)
International Federation of Library Associations and Institutions (IFLA). ''International Standard Bibliographic Description (ISBD), Consolidated Edition''. 2011. (https://www.ifla.org/files/assets/cataloguing/isbd/isbd-cons_20110321.p…)
''MARC Standards'' (http://www.loc.gov/marc)
''Spectrum Standard'' (https://collectionstrust.org.uk/spectrum)