The license could not be verified: There is no license certificate installed for 'CustomWare Redirection Plugin for Confluence'. Administrators, please check your license details here.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Table of Contents
The following sections present a description of all bibliographic metadata fields of the HBO Bibliographic Metadata application profile of MODS.
0. MODS in DIDL
The MODS records is placed inside a DIDL
Resource element of a
Component in an
Item with semantic type set to
A MODS record starts with the
mods root element. If not declared elsewhere in the XML document, the
mods element MUST declare a namespace by setting the
xmlns attribute of the
mods element to
http://www.loc.gov/mods/v3. We are using version 3.4. This SHOULD be made explicit by using the
version attribute. Referencing the XML schema is optional
1. Title, abstract, semantic type and language
The title information of the bibliographic work is split into two elements: a main
title and an optional
subTitle. Both are being placed under the
titleInfo top-level element.
With the previous Dublin Core-based application profile, title and subtitle information were placed in a single element as dot separated values.
An abstract of the contents are contained within the top-level element
The previous application profile did not offer solutions for multilingualism. With the introduction of MODS, this feature is now present through the use of the
The semantic type of the work is specified in the top-level element
genre. Its value is based on a controlled vocabulary in the info:eu-repo semantics namespace.
In the previous application profile the value of the equivalent element was a literal. For the new situation URIs are used. The use of the info:eu-repo namespace also offers additional values.
Information about the language is placed in the top-level element
language. This element contains a subelement
languageTerm which includes the use of a
type attribute indicating the value of the
languageTerm element being a code or text and the optional
authority attribute referencing a particular standard (e.g. RFC3066 or ISO639-2b).
languageTerm element may be repeated in order to describe the language in different ways (e.g. both through a formal code and a descriptive text).
In case a text consists of multiple languages (for instance a Dutch text and a English summary), the
language top-level element MUST be repeated with the use of the
It is RECOMMENDED to use the RFC3066 codes.
2. Names of Persons and Organisations
MODS has a generic name construct consisting of a
name toplevel-element containing one or more
namePart subelements. This construct can be used for both names of natural person as for organisation names. The
type attribute may be used to distinguish between the two.
One or more roles may be assigned to a name. For this a term from the MARC Code List for Relators or
marcrelator term may be used.
This is the entity's role in relation to the bibliographic work and not in relation to a given affiliation, e.g. a person to an organisation, thus the values "student", "teacher" or "lector" are invalid.
Information about a person's affiliation to an organisation may be added in the
The use of roles and affiliations is different from the previous Dublin Core application profile
For names of natural, the
type attribute of the
name toplevel element has the value
personal. The family and given name may be placed in seperate
namePart subelements with the type attributes containing
At this point, MODS does not contain a separate type-value for 'infix' (tussenvoegsel).
At this point, five affiliation roles are being distinguished using the following terms:
Corporate names may be included in a
name toplevel element with the
type attribute containing the value
corporate. Names of organisational units such as faculties and 'lectorates' should be included in a dot separated array in a single
namePart element. Because the hierarchical structure of these organisational units varies between institions, the semantics of the different values in the array are lost.
The community however has a strong need to explicitly capture these semantics. This enables applications to execute queries based on the values without the need to parse and identify the values based on ontologies. For this an extension has been defined that is based on the generic MODS construct for names, but that allows additional values for the type attribute of the
namePart element, namely
To maintain backwards compatibility with other systems it is recommended to define the toplevel organisation using both the default MODS guidelines and the HBO extension. Supplying the underlying organisational units using a dot separated array is optional. The MODS instance and the extension instance of a organisation may be joined using the
ID attribute of the toplevel
See also: HBO MODS Extension
Dates are specified according to ISO-8601 using the RECOMMENDED notation
YYYY-[MM-[DD]]. In this notation, only the year is a REQUIRED part. A month MUST be specified when the day is present. It is RECOMMENDED to specify both year, month and day.
All dates are placed under the
originInfo top-level element.
Date of first publication is specified in the
Date of creation
The date of creation is included in the
Embargo dates are placed in the
dateOther element with "embargo" specified in the
type attribute. The date should be considered inclusive.
Date of approbation
The date of approbation is specific for theses and dissertations and is specified in the
dateOther element with
type attribute contained the value "approved".
4. Keywords, Classifications and Target Audiences
topic element is used to specify a keyword that is applicable to the content and is placed under the
subject top-level element. This
subject element is multilingual thus keywords in different languages MUST be placed in separate instances of the
The top-level element
classification offers space to include classifications. In this element, different classification-source codes from the Library of Congress may be used. For the context of this application profile, the use of the Nederlandse Basis Classificatie (NBC) is also permitted. This classification however is not included in the list of classification sources by the Library of Congress. The use of the NBC MUST be indicated by the value "info:eu-repo/classification/Nbc" in the
authorityURI attribute. The value of the element MUST be the identifier. The descriptive name of the identifier MAY be included in the
Target audiences may be included within the
targetAudience top-level element. The value MUST a term from the MARC Target Audience Term List.
5. Related bibliographic material
Currently, only the host-type is used.
6. Bilbliographic Identifiers
This field is used for copies of the document that are not in the custody of the repository, for instance a copy at the editor.
Objects contained within the repository MUST be placed in the structural metadata in the DIDL.
MODS provides no native mechanism to publish copyright statements for described material. For this, an extension has been defined that is used in the NARCIS infrastructure. This extension will also be use in this specification.
See also the Use of MODS#UseofMODS-Copyright for the associated schema.