Page History

...

The DIDL document is part of an OAI-PMH response. The DIDL document will be returned within an OAI-record when using didl as value of the metadataPrefix verb. This enables the repository to generate this particular didl format that is described in the document below.
Within the OAI XML structure, the DIDL resides within the metadata element. See below:

Code Block


<OAI-PMH ...>
  ...
  <request ... metadataPrefix="didl">
  ...
  <record>
    <header>...</header>
    <metadata>
      <didl:DIDL
	 xmlns:didl="urn:mpeg:mpeg21:2002:02-DIDL-NS"
	 xmlns:dc="http://purl.org/dc/elements/1.1/"
	 xmlns:dcterms="http://purl.org/dc/terms/"
	 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	 xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"
	 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	 xsi:schemaLocation="
         urn:mpeg:mpeg21:2002:02-DIDL-NS
  http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/did/didl.xsd

         urn:mpeg:mpeg21:2002:01-DII-NS
  http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21_schema_files/dii/dii.xsd">
	  ...
       </didl:DIDL>
    </metadata>
    <about>...</about>
  </record>
  ...
</OAI-PMH>

Remarks:

Don't forget the DIDL tag in the OAI-PMH response.
1. Make a declaration of the didl, dii, dc and dcterms namespaces here, in the DIDL tag.
The about element is optional in OAI-PMH

...

The DIDL document is a document with one top-level Item element. The Item contains several child Item elements. These child Item elements describe three different types: descriptive metadata, object files and jump-off pages. Between brackets the cardinality of the XML elements are shown:

Code Block
<metadata> <didl:DIDL ...> <didl:Item> <didl:Item>...</didl:Item> <didl:Item>...</didl:Item> <didl:Item>...</didl:Item> </didl:Item> </didl:DIDL> </metadata>

Anchor
_Toc191176435
_Toc191176435
Item Descriptors

...

Example on level one

Code Block

<didl:DIDL ...>
  <didl:Item>
    <didl:Descriptor>...</didl:Descriptor> <!-- Identification, mandatory -->
    <didl:Descriptor>...</didl:Descriptor> <!-- Modification date, mandatory -->
    <didl:Item>...</didl:Item>
    <didl:Item>...</didl:Item>
    <didl:Item>...</didl:Item>
    ...
  </didl:Item>
</didl:DIDL>

Example on level two

Object type added

Code Block

<didl:DIDL ...>
  <didl:Item>
    <didl:Item>
      <didl:Descriptor>...</didl:Descriptor> <!-- Identification, mandatory -->
      <didl:Descriptor>...</didl:Descriptor> <!-- Modification date, optional -->
      <didl:Descriptor>...</didl:Descriptor> <!-—- Type, mandatory -->
      ...
    </didl:Item>
    <didl:Item>...</didl:Item>
    <didl:Item>...</didl:Item>
    <didl:Item>...</didl:Item>
    ...
  </didl:Item>
</didl:DIDL>

...

The first Descriptor contains the ID of the Item elements. This is used to uniquely identify the digital object (e.g. with an urn:nbn). This ID is wrapped in a Statement with a DII Identifier element. For example:

Code Block


 <didl:Item>
  <didl:Item>
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <dii:Identifier>urn:nbn:nl:ui:13-6748398729821</dii:Identifier>
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>
  ...
</didl:Item>

Remarks:

In this example the root Item has a Persistent Identifier.
The identifier MUST be an URI. Some repositories can make use of registered URIs, e.g., in the Netherlands the repositories can make use of National Bibliography Numbers. If a repository doesn't have access to registered URIs, UUIDs or TAGs can be used. More information about UUIDs can be found at http://en.wikipedia
Anchor
_Hlt190750088
_Hlt190750088
Anchor
_Hlt190750089
_Hlt190750089
.org/wiki/UUID and for TAGs the best starting point is http://www.taguri.org/. TAGs for the repository of Tilburg University could be constructed in the following way. All TAGs start with 'tag:uvt.nl,<year>:<record id>'. <year> is the year that the compound object entered the repository. The URIs for MODS records can look like 'tag:uvt.nl,<year>:<record id>/mods' and the URIs for object files can look like 'tag:uvt.nl,<year>:<record id>/<file id>'.
The identifiers of the root Item and the second level Item elements SHOULD NOT be equal to the OAI identifier or the DIDL document identifier.
Identifiers should not change. Different identifier implies a different object.
The namespace for dii SHOULD be declared in the DIDL tag.

...

The second Descriptor contains a modification date. When something changes inside an Item, this modification date element has to be up-dated. Modification date is mandatory in the top level Item and is optional in the second level Items. This modification date is being specified by the modified element from dcterms:

Code Block


 <didl:Item>
  <didl:Item>
  ...
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>
  ...
</didl:Item>

Remarks:

Declare the dcterms namespace in the DIDL tag.
The format of the date is Zulu-time; which means that it can be sorted as text.
There can be only one Statement element in a Descriptor element, which means that dii:identifier and dcterms:modified reside in separate Descriptor elements.

...

The third descriptor contains the Digital Item type. This type is mainly used the second level Item elements, however, it is also possible to type the top Digital Item.

Code Block
<didl:Item> <didl:Item> ... <didl:Descriptor> <didl:Statement mimeType="application/xml">

...

        <rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata" />
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>
  ...
</didl:Item>

See for more information about the type statement the next section.

...

The top-Item element contains one mandatory Item sub-element that describes a Digital Item of type 'info:eu-repo/semantics/descriptiveMetadata'. There can be more Digital Items that are descriptive metadata or that are object files.
Optionally there can be a Item sub-element that describes a Digital Item of a third type: 'info:eu-repo/semantics/humanStartPage'. A Digital Item of this type is a jump-off-page, i.e., an html intermediate page that describes in a human readable way which objects are involved. In this way a reader can be informed about the fact that a file is available in different formats such as PDF, MS Word or HTML, or that a dissertation consists of separate files (e.g. when the thesis consists of a set of previously published articles).

Code Block
<didl:DIDL ...> <didl:Item> <didl

...

Item>...</didl:Item> <!-- metadata -->
    <didl

...

Item>...</didl:Item> <!-- object files -->
    <didl:Item>...</didl:Item> <!-- jump-off-page -->
  </didl:Item>
</didl:DIDL>

The DIDL document contains at least one metadata Item element. This metadata can be in different formats, simple Dublin Core, qualified Dublin Core, MODS, MARC21, etc. The metadata can be included by-value or can be pointed to by-reference. one of the metadata Item elements MUST contain MODS, and the MODS record MUST be included by-value.

Code Block
<didl:Item> <didl:Item> <!

...

—one or many occurrences

...

-->
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata" />
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>

  <didl

...

Item>    <!

...

—zero or many occurrences

...

-->
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/objectFile" />
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>

  <didl:Item> <!

...

—zero or one occurrences

...

-->
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/humanStartPage" />
      </didl:Statement>
    </didl:Descriptor>
    ...
  </didl:Item>

</didl:Item>

The URIs will be processed case un-sensitive. It is recommended to use camelCase writing. It is VERY important to use the exact combinations of characters, otherwise automatic processing will not be possible. To make it very clear the following URIs are used:

...

When the metadata are included by-value in an Item element, then the metadata form the content of a Resource element. The case of by-reference is described in the "Object File Item" section. The Resource element is contained by a Component element. If there are several representations of the same metadata record, e.g., a version in MODS and a version in MARCXML, it is recommended to use separate Item elements for each representation.
MODS is mandatory; the MODS records MUST be included by-value. Notice that the guidelines of Driver still mention Simple Dublin Core. To be compliant with both the present Application Profile and Driver, separate metadata Items must be included, one for MODS and the other for Dublin Core.

Code Block
<didl:Item>

Code Block
<didl:Descriptor> <didl:Statement mimeType="application/xml"> <rdf:type rdf:resource="info:eu-repo/semantics/descriptiveMetadata" />

...

    </didl:Statement>
  </didl:Descriptor>

Code Block
<didl:Descriptor> <!-- This metadata instance has its own ID number --> <didl:Statement mimeType="application/xml"> <dii:Identifier>urn:nbn:nl:ui:13-74836724783</dii:Identifier> </didl:Statement>

...

 </didl:Descriptor>

Code Block


   <didl:Descriptor> <!-- This record has its own Modification date -->
    <didl:Statement mimeType="application/xml">
      <dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
    </didl:Statement>
  </didl:Descriptor>

Code Block
<didl:Component>

Code Block
<didl:Resource mimeType="application/xml">

...

Code Block
</didl:Component>

...

Code Block
</didl:Item>

Remarks:

If the date of the metadata has been changed, make sure that the date of the root-level Item modification date is also being changed.
Declare the mods namespace in the start-tag of MODS record, i.e., in the mods element.

...

An Object File Item contains a link to a digital object. This is 'by_ref', and the Item element has a type statement with an info:eu-repo/semantics/objectFile URI. An Object File Item can occur zero, one or more times.
When there are more representations of the same object file, then this can be handled in two ways:

for each representation there is a separate Resource element within the same Component element. The Descriptors of the Item element apply to both representations. The representations only differ in medium type (mimetype).
for each representation there is a separate Item element. The representations can differ not only in medium type but also in other respects as reflected in their respective Descriptors.

...

To indicate whether the file is a (exact copy of the) published version or the version of the author that is accepted by the publisher for publication a Descriptor with a type statement can be used. The proposal is to use the following URIs:
- info:eu-repo/semantics/publishedVersion
- info:eu-repo/semantics/authorVersion

These proposed URIs are not yet officially registered.

To add descriptions like "Introduction", "Chapter1" and "Glossary", the dc:description element can be used within the Statement element of a Descriptor. The dc:description element can also be used for other (unstructured) information for which there is no specific element.

The date at which the object file is deposited can be expressed as a dcterms:dateSubmitted element.

If there is an embargo on a file, the dcterms:available element can be used with the date that the file will become available.

Information about the accessibility of an object file should go in the dcterms:accessRights element. The vocabulary Following SWAP: http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_AccessRights_Vocabulary_Encoding_Scheme to be used for its content is as follows :

...

<!-- the MODS data -->
      <mods:mods
        xmlns:mods="http://www.loc.gov/mods/v3"
        xsi:schemaLocation=
          "http://www.loc.gov/mods/v3
           http://www.loc.gov/standards/mods/v3/mods-3-3.xsd">
        <mods:titleInfo>...</mods:titleInfo>
        <mods:name>...</mods:name>
        <mods:typeOfResource> ... </mods:typeOfResource>
          ...
      </mods:mods>
    </didl:Resource>

Code Block
</didl:Component>

Code Block
</didl:Item>

Remarks:

If the date of the metadata has been changed, make sure that the date of the root-level Item modification date is also being changed.
Declare the mods namespace in the start-tag of MODS record, i.e., in the mods element.

Anchor
_Toc191176442
_Toc191176442
Object File Item

An Object File Item contains a link to a digital object. This is 'by_ref', and the Item element has a type statement with an info:eu-repo/semantics/objectFile URI. An Object File Item can occur zero, one or more times.
When there are more representations of the same object file, then this can be handled in two ways:

for each representation there is a separate Resource element within the same Component element. The Descriptors of the Item element apply to both representations. The representations only differ in medium type (mimetype).
for each representation there is a separate Item element. The representations can differ not only in medium type but also in other respects as reflected in their respective Descriptors.

Additional Descriptor elements can be used to describe certain aspects of the object file:

To indicate whether the file is a (exact copy of the) published version or the version of the author that is accepted by the publisher for publication a Descriptor with a type statement can be used. The proposal is to use the following URIs:
- info:eu-repo/semantics/publishedVersion
- info:eu-repo/semantics/authorVersion

These proposed URIs are not yet officially registered.

To add descriptions like "Introduction", "Chapter1" and "Glossary", the dc:description element can be used within the Statement element of a Descriptor. The dc:description element can also be used for other (unstructured) information for which there is no specific element.

The date at which the object file is deposited can be expressed as a dcterms:dateSubmitted element.

If there is an embargo on a file, the dcterms:available element can be used with the date that the file will become available.

Information about the accessibility of an object file should go in the dcterms:accessRights element. The vocabulary Following SWAP: http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_AccessRights_Vocabulary_Encoding_Scheme to be used for its content is as follows :

Code Block
<didl:Item> ... <!-- Below this line one can find links to

...

 one or more digital objects -->

Code Block
<didl:Item> <!-- First Item for a File/Bitstream -->

...


    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/objectFile" />
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Object Item has its own persistent ID -->
      <didl:Statement mimeType="application/xml">
        <dii:Identifier>urn:nbn:nl:ui:13-36724783</dii:Identifier>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Item has its own Modification date -->
      <didl:Statement mimeType="application/xml">
        <dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
      </didl:Statement>
    </didl:Descriptor>

    <didl:Component>
      <didl:Resource
        mimeType="application/pdf"
        ref="http://my.server.nl/report.pdf"/>
    </didl:Component>
  </didl:Item>

Code Block
<didl:Item> <!-- Second Item

...

for a File/Bitstream -->
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/objectFile" />
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Object Item has its own persistent ID -->
      <didl:Statement mimeType="application/xml">
        <dii:Identifier>urn:nbn:nl:ui:13-36724784</dii:Identifier>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Item has its own Modification date -->
      <didl:Statement mimeType="application/xml">
        <dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!--

...

this file is the appendix -->
      <didl:Statement mimeType="application/xml">
        <dc:description>Appendix</dc:description>

...


      </didl:Statement>
    </didl:Descriptor>

    ...
    <didl:Component>
      <didl:Resource
        mimeType="application/pdf"
        ref="http://my.server.nl/appendix.pdf"/>
    </didl:Component>
  </didl:Item>

Code Block


 <didl:Item> <!-- Third Item for a File/Bitstream -->
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/objectFile" />
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Object Item has its own persistent ID -->
      <didl:Statement mimeType="application/xml">
        <dii:Identifier>urn:nbn:nl:ui:13-36724785</dii:Identifier>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!-- This Item has its own Modification date -->

...


      <didl:Statement mimeType="application/xml">
        <dcterms:modified>2006-12-20T10:29:12Z</dcterms:modified>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!—-

...

 deposit date -->
      <didl:Statement mimeType="application/xml">
        <dcterms:issued>2010-12-01</dcterms:issued>
      </didl:Statement>
    </didl:Descriptor>
    <didl:Descriptor> <!—-

...

 embargo on file -->
      <didl:Statement mimeType="application/xml">
        <dcterms:available>2010-12-01</dcterms:available>
      </didl:Statement>
    </didl:Descriptor>

    ...
    <didl:Component>
      <didl:Resource

...


        mimeType="application/pdf"
        ref="http://my.server.nl/datasheets.xls"/>
    </didl:Component>

Code Block
</didl:Item>

Code Block
</didl:Item>

In the above example, the Resource locations are not repeated within Component element, but each Resource location is wrapped in its own Item element. The rationale behind this is that each Bitstream or file can have its own Identifier and its own Descriptors.

...

The third ObjectType Item element contains a link to the jump-off page or intermediate page. This is done in the same way as for the Object Item element. This Item element is optional. There should not be more than one Item of this type. The identifier element and modified elements are optional.

Code Block
<didl:Item> ... <!-- Below this line; an Item with a link to one optional Intermediate page -->

Code Block


   <didl:Item>
    <didl:Descriptor>
      <didl:Statement mimeType="application/xml">
        <rdf:type rdf:resource="info:eu-repo/semantics/humanStartPage" />
      </didl:Statement>
    </didl:Descriptor>
    ...
    <didl:Component>
      <didl:Resource
         mimeType="text/html"
         ref="http://my.server.nl/mypub.html"/>
    </didl:Component>
  </didl:Item>

Code Block
</didl:Item>

Remarks:

Using a Persistent Identifier for this HTML page means that you always need to resolve this page in the distant future. This is not recommended!

...

Child pages

Versions Compared

Old Version 35

New Version 36

Key

Remarks:

Anchor
_Toc191176435
_Toc191176435
Item Descriptors

Remarks:

Remarks:

Remarks:

Remarks:

Anchor
_Toc191176442
_Toc191176442
Object File Item

Remarks:

Child pages

Page History

Versions Compared

Old Version 35

New Version 36

Key

Remarks:

Anchor_Toc191176435_Toc191176435Item Descriptors

Remarks:

Remarks:

Remarks:

Remarks:

Anchor_Toc191176442_Toc191176442Object File Item

Remarks:

Anchor
_Toc191176435
_Toc191176435
Item Descriptors

Anchor
_Toc191176442
_Toc191176442
Object File Item