{alias:Names of Persons and Organisations}

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 "info:eu-repo/semantics/DescriptiveMetadata".

(...)
<didl:Item>

  <!-- Semantic Type -->
  <didl:Descriptor>
    <didl:Statement mimeType="application/xml">
      <rdf:type rdf:resource="info:eu-repo/semantics/DescriptiveMetadata"/>
    </didl:Statement>
  </didl:Descriptor>

  (...)


  <!-- Content -->
  <didl:Component>
    <didl:Resource mimeType="application/xml">
      (...) <!-- MODS goes here -->
    </didl:Resource>
  </didl:Component>

</didl:Item>
(...)


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 

(...)
<didl:Resource mimeType="application/xml">

  <mods xmlns="http://www.loc.gov/mods/v3"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-4.xsd"
      version="3.4">
    (...)
  </mods>

</didl:Resource>
(...)

1. Title, abstract, semantic type and language

Title

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.

(...)
<titleInfo>
  <title>Main Title</title>
  <subTitle>Subtitle</title>
</titleInfo>
(...)

With the previous Dublin Core-based application profile, title and subtitle information were placed in a single element as dot separated values.

Abstract

An abstract of the contents are contained within the top-level element abstract. 

(...)
<abstract xml:lang="en">A short abstract.</abstract>
(...)

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 xml:lang attribute.

Semantic Type

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.

(...)
<genre>info:eu-repo/semantics/BachelorThesis</genre>
(...)

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.

Document language

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).

The 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 objectPart attribute.

It is RECOMMENDED to use the RFC3066 codes. 

(...)
<language objectPart="summary">
  <languageTerm type="code" authority="rfc3066">eng</languageTerm>
</language>
<language objectPart="main">
  <languageTerm type="code" authority="rfc3066">nld</languageTerm>
  <languageTerm type="text" lang="nld">Nederlands</languageTerm>
  <languageTerm type="text" lang="eng">Dutch</languageTerm>
</language>
(...)



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 affiliation element.

The use of roles and affiliations is different from the previous Dublin Core application profile

(...)
<name>
  <namePart>Name<namePart>
  <role>
    <roleTerm authority="marcrelator">term</roleTerm>
  </role>
  <affiliation>Term</affiliation>
</name>
(...)

Personal Names

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 family and given respectively.

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:

(...)
<name type="personal">
  <namePart type="family">Vries, de<namePart>
  <namePart type="given">J. (Jan)<namePart>
  <role>
    <roleTerm authority="marcrelator">aut</roleTerm>
  </role>
  <affiliation>Lector</affiliation>
</name>
(...)

Corporate Names

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 organisation, department and lectorate.

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 name element. 

(...)
<name ID="nameID_1" type="corporate">
  <namePart>Hogeschool van Amsterdam. Media, Creatie en Informatie. Electronisch Uitgeven</namePart>
  <role>
    <roleTerm authority="marcrelator">pbl</roleTerm>
  </role>
</name>

(...)

<extension>
  <hbo:name xmlns:hbo="info:eu-repo/xmlns/hboMODSextension" ID="nameID_1" type="corporate">
    <hbo:namePart type="organisation">Hogeschool van Amsterdam </hbo:namePart>
    <hbo:namePart type="department">Media, Creatie en Informatie</hbo:namePart>
    <hbo:namePart type="lectorate">Electronisch Uitgeven</hbo:namePart>
  </hbo:name>
</extension>
(...)

See also: HBO MODS Extension

.



3. Dates

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.

Publication date

Date of first publication is specified in the dateIssued element. 

(...)
<originInfo>
  <dateIssued encoding="iso8601">2011-03-23</dateIssued>
</originInfo>
(...)

Date of creation

The date of creation is included in the dateCreated element. 

(...)
<originInfo>
  <dateCreated encoding="iso8601">2010-12-07</dateCreated>
</originInfo>
(...)

Embargo date

Embargo dates are placed in the dateOther element with "embargo" specified in the type attribute. The date should be considered inclusive. 

(...)
<originInfo>
  <dateOther type="embargo" encoding="iso8601">2011-05-17</dateOther>
</originInfo>
(...)

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".

(...)
<originInfo>
  <dateOther type="approved" encoding="iso8601">2011-02-28</dateIssued>
</originInfo>
(...)



4. Keywords, Classifications and Target Audiences

Keywords

The 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 subject element. 

(...)
<subject xml:lang="nl">
  <topic>metadata</topic>
  <topic>digitale brievenbus</topic>
</subject>
<subject xml:lang="en">
  <topic>keyword</topic>
</subject>
(...)

Classification

Unstable

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 displayLabel attribute. 

(...)
<classification authorityURI="info:eu-repo/classification/Nbc" displayLabel="Informatica">54</classification>
(...)

Target Audience

Unstable

Target audiences may be included within the targetAudience top-level element. The value MUST a term from the MARC Target Audience Term List.

(...)
<targetAudience authority="marctarget">general</targetAudience>
(...)

Geographical information

Unstable

(...)
<subject>
  <geographic>Netherlands</geographic>
</subject>
(...)

Temporal information

Unstable

(...)
<subject>
  <temporal encoding="iso8601">1985-05</temporal>
</subject>
(...)



5. Related bibliographic material

Currently, only the host-type is used.

(...)
<relatedItem type="host">
  <identifier type="uri">URN:ISSN:0304-3940</identifier>
  <titleInfo>
    <title>Neuroscience Letter</title>
  </titleInfo>
  <originInfo>
   <place>Amsterdam</place>
   <publisher>Elsevier</publisher>
  </originInfo>
  <part>
    <detail type="volume">
      <number>77</number>
    </detail>
    <detail type="issue">
      <number>1</number>
    </detail>
    <extent unit="page">
      <start>71</start>
      <end>75>
    </extend>
  </part>
</relatedItem>
(...)



6. Bilbliographic Identifiers

Author identifiers

(...)
<name type="personal" ID="n1">
  <namePart type="family">Vries, de</namePart>
  <namePart type="given">J. (Jan)</namePart>
  <role>
    <roleTerm authority="marcrelator" type="code">aut</roleTerm>
  </role>
</name>
(...)
<extension>
  <dai:daiList 
    xmlns:dai="info:eu-repo/dai"
    xsi:schemaLocation="info:eu-repo/dai
    http://www.surfgroepen.nl/sites/oai/metadata/Shared%20Documents/dai-extension.xsd">
    <dai:identifier IDref="n1" authority="someAuthority">123456789</identifier>
  </dai:daiList>
</extension>
(...)

Local identifiers

(...)
<identifier type="someType">1234567890</identifier>
(...)

Location

Unstable

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.

(...)
<location>http://thirdparty.org/resource</location>
(...)

7. Copyright

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. 

(...)
<extension>
	<wmp:rights
		xmlns:wmp=http://www.surfgroepen.nl/werkgroepmetadataplus
		xmlns:dc="http://purl.org/dc/elements/1.1/"
		xsi:schemaLocation="http://www.surfgroepen.nl/werkgroepmetadataplus rights.xsd">
		<dc:description>
			© 2010 Hogeschool van Amsterdam
			This work is licensed under a Creative Commons
			Attribution-Noncommercial-No Derivative Works 3.0 Unported License.
		</dc:description>
		<dc:rights>http://creativecommons.org/licenses/by-nc-nd/3.0/</dc:rights>
	</wmp:rights>
</extension>
(...)

See also the Use of MODS#Copyright for the associated schema.