Anchor
_Toc190102197
_Toc190102197
Anchor
_Toc190102308
_Toc190102308
Anchor
_Toc190773341
_Toc190773341
Anchor
_Toc191117893
_Toc191117893
Anchor
_Toc191133183
_Toc191133183
Anchor
_Toc191133331
_Toc191133331
Anchor
_Toc191176428
_Toc191176428
Versions

Date	Version history
18 April 2009	3.0	Start of version 3.0. Based on NEEO document "MPEG21 DIDL Application Profile for Institutional Repositories" version 0.4, which is based on "MPEG21 DIDL Document Specifications for repositories" version 2.3.1. See also history. Note that this is the first version of this document. The version number (3.0) indicates that it is more recent and more up-to-date than the predecessors on which it is based by having a higher number than their latest versions.-date than the predecessors on which it is based by having a higher number than their latest versions.	Download PDF
22 Januari 2008	2.3.1	Minor change in the schema path. ISO changed the path .../dii.xsd/dii.xsd to .../dii/dii.xsd Minor change in the examples the mimetype for humanStartPage resources changed from "application/html" to "text/html". "application/html" is not a valid mimetype.
05 December 2007	2.3	Changes to stress the use of Persistent Identifiers in the DIDL document. The addition of the ORE compliant info:eu-repo namespace	Download PDF
23 May 2007	2.2.2	Some changes and little tweaks.
23 March 2007	2.2.1	Added comment of Peter van Huisstede, small corrections in the example XML.
6 March 2007	2.2	The Committee for Complex Objects looked at this document and came with more elegant improvements. Thanks to: Thomas Place, Renze Brandsma, Henk Ellermann, Peter van Huisstede and Ruud Bronmans.
20 February 2007	2.1	A closer look at the recommendations of Herbert vd Sompel gave more insight in the DIDL semantics, and thus leading to a better XMLspecification.
2 January 2007	2.0	Fundamental change of element and attribute use; for better representation of the semantics. Additional texts for driver guidelines from Martin Feijen, new DIDL according to comments of Herbert vd Sompel, new DIDL schema. (http://purl.lanl.gov/STB-RL/schemas/2006-09/DIDL.xsd)
4 December 2006	1.1.2	Translated into English for DRIVER
11 July 2006	1.1.1	Few typos are removed.
10 July 2006	1.1	Extension with: Version numbering and information Complete namespace declaration in 'metadata'-item. The three Items are not case sensitively discriminated by: metadata, objects and jump-off-page. Extended explanation about the use of Namespace-declarations.
30 March 2006	1.0	Initial document

Anchor
_Toc190102198
_Toc190102198
Anchor
_Toc190102309
_Toc190102309
Anchor
_Toc190773342
_Toc190773342
Anchor
_Toc191117894
_Toc191117894
Anchor
_Toc191133184
_Toc191133184
Anchor
_Toc191133332
_Toc191133332
Anchor
_Toc191176429
_Toc191176429
What's new

...

Some minor editorial changes
3.3.2 - – Object File Item
- Addition of deposit date as a <dcterms:issued>
- Vocabulary for <dcterms:accessRights>

...

Wiki Markup

The digital objects that populate institutional repositories can be seen as compound objects that consist of parts or components that are also digital objects. In the DIDL model the basic entity is a Digital Item. The compound objects and their objects play the role of Digital Items in the model that underlies DIDL. In a DIDL document the Item elements represent the Digital Items. The top Item element that is situated directly below the DIDL root element is used for the compound object. The Item elements that are the children of the top Item element represent the objects that are part of the compound object. The objects that are part of a compound object can themselves be a compound object. When a part object is also a compound object, then its parts are not described in the same DIDL document, but a separate DIDL document is used to describe this compound object with its parts. This means that in this application profile there are only two levels of Digital Items within a DIDL document. Although DIDL allows for a hierarchy of Digital Items, this profile restricts the hierarchy to two levels: the level of the top Digital Item, the compound object and the level of the Digital Items that are parts of the top Digital Item. This version of the application profile doesn't give (yet) guidelines for the case of a compound object that is part of another compound object.
\\
This profile distinguishes three types of digital objects: descriptive metadata, object files and jump-off pages. This list is extensible; other types can be added.
\\
The figure below is a schematic representation of a DIDL document of a compound object that consists of one or more descriptive metadata records, zero or more object files and zero or one jump-off page. Metadata that apply to the metadata records, object files and jump-off pages can be placed in Descriptor elements within the respective Item elements. In the figure the most used Descriptors are shown. The list of Descriptor elements in an Item is extensible. 
\\
A digital object can have one or more representations. A representation is the thing that can be displayed on a computer screen or that can be printed. A representation MUST have a medium type (mimetype). In DIDL, representations are handled by the Resource element. A Resource is contained in a Component element which in its turn is a child of the Item element. There are two ways of including a representation in a Resource element. The first way is *by-value{*}: the representation as such is included as content of the Resource element. This is the usual way that metadata records formatted in XML are included. The second way is *by-ref{*}: the Resource element stays empty, but the representation is referred to by an URL that is the value of the ref-attribute of the Resource element. Normally, the URL will point to a file in the repository.
\\
Each Digital Item MUST have an identifier with the exception of jump-off pages for which the identifier is optional. This identifier MUST be an URI. The URI of a Digital Item should be different from the URLs of its representations. The identifiers of the Digital Items must be persistent. The URLs of the representations and the medium types can change, while the identifier of the Digital Item stays the same. This allows, e.g., for replacing a file that can only be processed by an old-fashioned word processor by a version with the same content that can be read at all contemporary desk tops. Or a file can be moved to another location; the identifier of the Digital Items stays the same indicating that it is still the same file. If the policy of a repository is to preserve the different representations of a Digital Item then the repository is advised to treat the representations as separate Digital Items, each with its own persistent identifier. So it is possible that in one repository the PDF, the Word and the HTML versions of a publication are combined into one Digital Item, while in another repository they are treated as separate Digital Items. Another use of Digital Item identifiers is to relate Digital Items to each other.
\\
DIDL\[1\]Item\[1\]Descriptor/Identifier
(Persistent Identifier)  Component/Resource
(URL of representation of this Item)Item\[1..8\] (of type metadata)Item\[0..8\] (of type object file)
Item\[0..1\] (of type jump-off page)
  Component/Resource
(representation by value (XML) or by refrerence (URL))Descriptor/Identifier
(Persistent Identifier)Descriptor/type  Component/Resource
(representation by ref. (URL))  Component/Resource
(representation by ref. (URL))Descriptor/dateModified (optional)Descriptor/Identifier
(Persistent Identifier)Descriptor/typeDescriptor/dateModified (optional)Descriptor/Identifier (optional)Descriptor/typeDescriptor/dateModified (optional)
\\

...

<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

^{Image Removed}

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

...

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b2ae5ef166a601ad-29276d07-48884df7-bda88e04-78aad8f21f6cd99fc653e5cf"><ac:plain-text-body><![CDATA[

DIDL[1]<metadata>
]]></ac:plain-text-body></ac:structured-macro>
<didl:DIDL ...>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="10f7e88895706e76-3897cd8e-410641e8-832ea80d-89c4c7009fa6b6f0d0af17e7"><ac:plain-text-body><![CDATA[Item[1] <didl:Item>
]]></ac:plain-text-body></ac:structured-macro>
<didl*:Item*>...</didl:Item>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c26474f68e486cac-eeec800b-4a814cb6-9db78c39-283dbd56986453c349a13af5"><ac:plain-text-body><![CDATA[Item[1..8] (of type metadata)Item[0..8] (of type object files)
]]></ac:plain-text-body></ac:structured-macro>
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="b33b7166bca59246-0792ce04-41004b69-8019ad97-af1032fd97233005fefb3613"><ac:plain-text-body><![CDATA[Item[0..1] (of type jump-off page)
]]></ac:plain-text-body></ac:structured-macro>
<didl*:Item*>...</didl:Item>
<didl*:Item*>...</didl:Item>
</didl:Item>
</didl:DIDL>
</metadata>

...

Wiki Markup

\\
DIDL\[1\]Item\[1\]Item\[1..8\] (of type metadata)Item\[0..8\] (of type object files)
Item\[0..1\] (of type jump-off page)
Descriptor\[2.. 8\]Descriptor\[2.. 8\]Descriptor\[2.. 8\]Descriptor\[1.. 8\]
\\
Item Descriptors provide information about the Digital Item. A Descriptor contains a Statement with information about the Item. For each "statement" a new Descriptor is used.
The top level *Item* element *MUST* contain _two_ *Descriptor* elements. One *Descriptor* element for the (Persistent) Identifier and one *Descriptor* element for the modification date.

Modifications MUST be made visible by changing the modification date. When there are no modifications the modification date can be left out from the second level Items.
Changes of the modification date in child Item elements MUST be propagated to the parent Item element.
When a Descriptor element for modification date is used also a Descriptor element with an identifier MUST be used (they go in pairs). Rationale: In order to compare similar harvested Item elements wrt modification date, an identifier must be added.
For the second level Item elements:
1. the "type" Descriptor element MUST always be used
2. the "identifier" Descriptor element MUST be used in the metadata and objectfile Descriptor elements. This is optional for the jump-off page Descriptor element
3. the "modification date" Descriptor element MAY be used in all of the second level Item elements.

...

Example on level one	<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	<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>

...

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

<didl:Item>

<didl*:*Item> <!—one --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 --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 --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>

...

<didl:Item>

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

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

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

<didl:Component>

<didl:Resource mimeType="application/xml"> <!-- 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

^{Image Removed}

"{*}>
<mods:titleInfo>...</mods:titleInfo>
<mods:name>...</mods:name>
<mods:typeOfResource> ... </mods:typeOfResource>
...
</mods:mods>
</didl:Resource>

</didl:Component>

</didl:Item>

...

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^{Image Removed} to be used for its content is as follows :
- http://purl.org/eprint/accessRights/ClosedAccess^{Image Removed}
- http://purl.org/eprint/accessRights/RestrictedAccess^{Image Removed}
- http://purl.org/eprint/accessRights/OpenAccess^{Image Removed}

<didl:Item>
...

<didl:Item> 
<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>

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

<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> 
<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>
</didl:Item>

</didl:Item>

...

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.

<didl:Item>
...

<!- - Below this line; an Item with a link to one optional Intermediate page - ->

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

</didl:Item>

...

Child pages

Versions Compared

Old Version 10

New Version 11

Key

Anchor
_Toc190102197
_Toc190102197
Anchor
_Toc190102308
_Toc190102308
Anchor
_Toc190773341
_Toc190773341
Anchor
_Toc191117893
_Toc191117893
Anchor
_Toc191133183
_Toc191133183
Anchor
_Toc191133331
_Toc191133331
Anchor
_Toc191176428
_Toc191176428
Versions

Anchor
_Toc190102198
_Toc190102198
Anchor
_Toc190102309
_Toc190102309
Anchor
_Toc190773342
_Toc190773342
Anchor
_Toc191117894
_Toc191117894
Anchor
_Toc191133184
_Toc191133184
Anchor
_Toc191133332
_Toc191133332
Anchor
_Toc191176429
_Toc191176429
What's new

Child pages

Page History

Versions Compared

Old Version 10

New Version 11

Key

Anchor_Toc190102197_Toc190102197 Anchor_Toc190102308_Toc190102308 Anchor_Toc190773341_Toc190773341 Anchor_Toc191117893_Toc191117893 Anchor_Toc191133183_Toc191133183 Anchor_Toc191133331_Toc191133331 Anchor_Toc191176428_Toc191176428Versions

Anchor_Toc190102198_Toc190102198 Anchor_Toc190102309_Toc190102309 Anchor_Toc190773342_Toc190773342 Anchor_Toc191117894_Toc191117894 Anchor_Toc191133184_Toc191133184 Anchor_Toc191133332_Toc191133332 Anchor_Toc191176429_Toc191176429What's new

Anchor
_Toc190102197
_Toc190102197
Anchor
_Toc190102308
_Toc190102308
Anchor
_Toc190773341
_Toc190773341
Anchor
_Toc191117893
_Toc191117893
Anchor
_Toc191133183
_Toc191133183
Anchor
_Toc191133331
_Toc191133331
Anchor
_Toc191176428
_Toc191176428
Versions

Anchor
_Toc190102198
_Toc190102198
Anchor
_Toc190102309
_Toc190102309
Anchor
_Toc190773342
_Toc190773342
Anchor
_Toc191117894
_Toc191117894
Anchor
_Toc191133184
_Toc191133184
Anchor
_Toc191133332
_Toc191133332
Anchor
_Toc191176429
_Toc191176429
What's new