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
Document information
Title: |
Document History
Date | Version | Owner | Changelog | |
---|---|---|---|---|
|
|
|
|
|
Abstract
The abstract describes what the application profile is about. It should contain a problem definition, the standards described by the application profile and the goal of the application profile.
From here, content can be added. Remember to start chapters with a header in h1., h2. or smaller
XML may be added between {code:xml|collapse=true|linenumbers=true|title=Title} {code} (remove the \ to use tags)
When creating a draft, comments and proposal can be added that allow a dicussion. Please read the http://wiki.surffoundation.nl/display/standards/Wiki+guidelines
Result
Description
title
Field (NL) | Title |
Field (EN) | Titel |
Description (NL) |
|
Description (EN) |
|
Cardinality |
|
Constraints |
|
Value: Data type | LangString |
Value: Data encoding | ISO/IEC 10646-1 | @RFC4646 |
Value: Example | Een Nederlandse titel. |
Value: Remarks | [http://www.ietf.org/rfc/rfc4646.txt |
Validation: Schematron rule |
|
Xpath Default namespace | mods: |
Xpath Serialisation | //mods/titleInfo[@xml:lang]/title |
Usage: OAIS Package | SIP; AIP; DIP |
Usage: Community | HBO-KB; NARCIS |
Representations
Landing page
Field (NL) |
| URL human start page |
|
Field (EN) |
| URL human start page |
|
Description (NL) |
| Web-locatie van de informatiepagina (html) van de publicatie in de repository |
|
Description (EN) |
| ||
Cardinality |
| ||
Constraints |
| ||
Value: Data type |
| URI |
|
Value: Data encoding |
| RFC3986 |
|
Value: Example | http://example.org/pageinrepository.html | ||
Value: Remarks | |||
Validation: Schematron rule |
| ||
Xpath Default namespace | didl: | ||
Xpath Serialisation |
| //Item/Item[Descriptor/Statement/rdf:type/@rdf:resource='info:eu-repo/semantics/humanStartPage]/Component/Resource/@ref |
|
Usage: OAIS Package | AIP; DIP | ||
Usage: Community | HBO-KB; NARCIS |
Object files
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.
Roles
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.
Affiliations
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:
Lector
LectorateMember
Student
StudentResearcher
Teacher
(...) <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.
| LangString |