|
Abstract
Various XML-based approaches aimed at representing complex digital
objects have emerged over the last several years. Approaches that are of specific
relevance to the Digital Library community include the Metadata Encoding
and Transmission Standard (METS), the IMS Content Packaging XML Binding,
the Sharable Content Object Reference Model (SCORM), and the XML packaging
approach developed by CCSDS Panel 2. The MPEG-21 Digital Item Declaration
Language (DIDL) is another XML-packaging specification that, so far,
has received little attention in the Digital Library community. This
article gives a brief insight into the MPEG-21 standardization effort, and
indicates its potential relevance to the Digital Library community.
It also highlights major characteristics of DIDL, and details research
conducted at the Research Library of the Los Alamos National Laboratory
(LANL) into the applicability of DIDL for the representation of complex
objects in the LANL repository. The positive outcome of this research
has led to a decision to make DIDL-conformant documents the unit of
storage in the LANL repository, and suggests that DIDL could also be
a valuable building block for other Digital Library projects.
1. Introduction
Digital Libraries have reached a point where acceptable architectures
must accommodate objects that aggregate datastreams of a wide variety
of media-types, and must allow for the association of secondary data – including
metadata supporting discovery, digital preservation and rights management – with
those datastreams. Also, the notion of the – static or dynamic – association
of dissemination capabilities with such objects must be entertained
by contemporary Digital Library architectures.
The seminal Kahn/Wilensky framework [10] refers to a digital object
as the basic entity for storing, managing and disseminating information
in a Digital Library architecture. The framework defines a digital
object as more than just a set of bits: it should be regarded a data
structure with a unique persistent identifier that, apart from the
datastream(s), holds secondary information about the contained datastream(s).
It comes as no surprise that, since the publication of the Kahn/Wilensky
framework, various approaches have emerged from different communities
aimed at representing digital objects. Approaches that are of specific
relevance to the Digital Library community include the Metadata Encoding
and Transmission Standard (METS) [30], the IMS Content Packaging XML
Binding [8], the Sharable Content Object Reference Model (SCORM) [1]
and the XML packaging approach developed by CCSDS Panel 2 [5]. All
these efforts specify an XML-based data structure for digital objects.
Through collaboration with the Multimedia Lab of Ghent University
[note 6], the authors became aware of another XML-based
packaging format that emerged from the ongoing MPEG-21 standardization
effort [3]. The MPEG-21 work has received little attention in the Digital
Library community, possibly because specifications are not freely available
online, as a result of an ISO strategy. MPEG Standards
must be purchased from ISO [note 1], while reference
software is made publicly available. Digging deeper into MPEG-21 documentation,
the authors became increasingly intrigued, and decided to actively
explore the applicability of MPEG-21 concepts in the context of ongoing
Digital Library repository work at the Research Library of the Los
Alamos National Laboratory (LANL). The main motivations for this decision
can be summarized as follows:
- Potential impact of MPEG-21 – MPEG [note 2] is an ISO/IEC Committee,
and provides a mechanism to feed research results into an ISO standard.
So far, several MPEG Standards have had a significant impact on the
multimedia landscape. For example, MPEG has produced the MPEG-1 and
MPEG-2 Standards, on which formats such as Video CD, MP3, Digital
Television, and DVD are based. It is likely that the MPEG-21 Standard
will have a similar impact.
- MPEG-21's modular architecture – The vision
for MPEG-21 is ‘to define a normative open framework for multimedia
delivery and consumption for use by all the players in the delivery
and consumption chain’. The envisioned framework covers the
entire media content delivery chain, encompassing content creation,
adaptation, and dissemination. The unfinished Standard consists of
12 high-level, modular Parts, including:
- MPEG-21 Part 2 – Digital Item Declaration Language (henceforth
referred to as DIDL), detailing the representation of complex
digital objects [15]
- MPEG-21 Part 3 – Digital Item Identification Language
(henceforth referred to as DII), detailing the identification
of complex digital objects and their contained entities [17]
- MPEG-21 Part 4 – Intellectual Property Management and
Protection (henceforth referred to as IPMP), detailing a framework
to enforce rights expressions pertaining to complex digital objects
[21].
- MPEG-21 Part 5 – Rights Expression Language (henceforth
referred to as REL), detailing a language to express rights pertaining
to complex digital objects and their contained entities [22]
- MPEG-21 Part 7 – Digital Item Adaptation (henceforth referred
to as DIA), detailing the adaptation and transcoding of datastreams
based on contextual information such as agent capabilities, network
characteristics and user preferences [18]
- MPEG-21 Part 10 – Digital Item Processing (henceforth
referred to as DIP), detailing the association of processing methods
with complex digital objects and their contained entities [19,
20]
- Ability to accommodate any media type and genre – Although
MPEG-21 originates in a community that focuses on motion picture,
audio, and video, the MPEG-21 framework can accommodate any kind of
complex digital objects including electronic texts, electronic journals,
scientific datasets, etc.
- Applicability to Digital Libraries – There is a clear
overlap between the problem domain addressed by the MPEG-21 effort,
and ongoing efforts regarding the representation, storage, and dissemination
of complex digital objects in the Digital Library community. For example,
MPEG-21 DIDL and DII directly relate to the aforementioned XML-based
packaging approaches. Also, MPEG-21 DIP and DIA reveal a remarkable
parallel with sophisticated architectures that emerged from the Digital
Library community [23], specifically FEDORA [7,
26, 29] and SODA [12,
24]. And, recently, the usage of MPEG-21 REL has
been proposed in the ISO/IEC SC36 E-Learning standardization effort
[9].
This article describes the results of research into the applicability
of the MPEG-21 DIDL and DII for packaging complex digital objects to
be submitted to, stored in, and disseminated from the repository of
the LANL Research Library. A future article will report on the
repository architecture used to store and disseminate the complex digital
objects, which builds on DIDL [note 3], the OAI-PMH [11],
the NISO OpenURL Framework [25] and concepts from
the MPEG-21 DIP.
2. DIDL: MPEG-21 Digital Item Declaration
Language
In the MPEG-21 Framework, complex digital objects are declared using
the Digital Item Declaration Language (DIDL). DIDL introduces a set
of abstract concepts that, together, form a well-defined data model
for complex digital objects [note 4]. Based on those
abstract concepts, DIDL defines a W3C XML Schema [note 5]
that provides broad flexibility and extensibility for the actual representation
of compliant complex digital objects. In the remainder of this article,
a complex digital object represented according to the DIDL Schema will
be referred to as a Digital Item Declaration, or DID. Core characteristics
of the DIDL data model, the DIDL XML Schema, and DIDs are described
in the remainder of this section.
2.1 Data Model
This section provides an informal, and simplified explanation of the
DIDL data model. The DIDL data model recognizes the following entities,
which are visually represented in Figure 1:
- A Container is a grouping of Containers
and/or Items. In the XML representation, a Container
is accommodated by the didl:Container element ({1} in Figure
1 and Appendix A)
- An Item is a grouping of Items and/or
Components. In the XML representation, an Item
is accommodated by the didl:Item
element ({2} in Figure 1 and Appendix
A)
- A Component is a grouping of Resources.
Multiple Resources in the same Component
are considered equivalent and consequently an agent may use any one
of them. In the XML representation, a Component is accommodated
by the didl:Component
element ({3} in Figure 1 and Appendix
A)
- A Resource is an individual datastream. In the XML
Schema, a Resource is accommodated by the didl:Resource
element ({4} in Figure 1 and Appendix
A)
- Secondary information pertaining to a Container, an
Item, or a Component can be conveyed by
means of a Descriptor. In the XML representation, a
Descriptor is accommodated by the didl:Descriptor
element ({5} in Figure 1 and Appendix
A). By definition, a didl:Descriptor
is associated with its parent element in the XML representation. For
example, a didl:Descriptor
provided as a child element of a didl:Component
is associated with that didl:Component.
The DIDL specification provides abstract definitions for each of the
aforementioned entities and their interrelations. Those definitions
can hardly be used as a cookbook for representing a collection of related
datastreams as a DID; they actually allow for various approaches to
do so. For example, when representing an audio album using DIDL, one
could create a DID which has an Item per audio track,
or a DID with a single Item containing multiple Components,
etc. In many cases, the actual choice for one representation or another
will be inspired by the requirements of the target application. Figure
1 shows the structure of a DID that is conformant with the DIDL
specification. The figure clearly illustrates the elaborate nesting
capabilities of DIDL.
|
Figure 1: Example of a DID
structure conformant with the DIDL specification |
2.2 Providing datastreams and secondary
data
Table 1 shows the techniques available in DIDL
to deliver datastreams and secondary information. As can be seen, DIDL
allows these to be contained in a DID – By Value – or to
be pointed at from within a DID – By Reference. Table
1 also shows how the nature of the datastreams and secondary information
relates to the way in which they are provided in a DID. The triangles
in Table 1 indicate functionality that most likely
will become available as a result of amendments proposed by the authors
and their colleagues from Ghent University. The MPEG Committee has recently
approved these amendments [2] as a Working Draft for
the DIDL Extension specification [16].
|
Table 1: By Value and By Reference
provision of datastreams and secondary information in a DID |
2.3 More about Descriptors
Descriptors provide an extensible mechanism to convey
secondary information about entities of the DIDL data model. For example,
in order to associate – say – an identifier with an Item,
a didl:Descriptor
containing the identifier can be created as a child element of the didl:Item
element.
As will be shown in the remainder of this section, the MPEG-21 framework
itself defines ways to use Descriptors as a means to convey
identification information, rights information, processing information,
etc. But, to facilitate the provision of community-specific or application-specific
information, Descriptors may also be defined by third
parties. In order to do so, typically, an XML Schema with an associated
XML Namespace is created to contain elements and attributes required
to address specific needs. This approach is illustrated in Section
3.3 by detailing the Descriptors defined at LANL.
2.3.1 DII: Using a Descriptor for Identification
MPEG-21 Digital Item Identification (DII) specifies the usage of Descriptors
for the identification of DIDs and their contained entities. It introduces
a DII XML Namespace with elements that can be used to associate identifiers
and/or types with Containers, Items, Components
and Descriptors. For example, Table
2 shows the use of the dii:Identifier
element to associate the URI “urn:isbn:0-395-36341-1”
with a didl:Item.
Through the introduction of a special Part dedicated to the identification
of entities, MPEG-21 recognizes the importance of identifiers in network-based
applications. Some packaging approaches, including METS, address identification
in less fundamental and less extensible manners.
<didl:Item>
<didl:Descriptor>
<didl:Statement mimeType="text/xml;
charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:isbn:0-395-36341-1</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
…
</didl:Item> |
Table 2: dii:Identifier
(Item level) |
2.3.2 Using Descriptors to convey processing
information
MPEG-21 Digital Item Processing (DIP) specifies an architecture pertaining
to the dissemination of DIDs. This Part – yet to be standardized –
introduces a special type of Item named Processing
Item, which may be used to specify the methods by which a DID
and its contained entities can be processed. Items are
identified as Processing Items by including a Descriptor
containing the dii:Type
element from the DII XML Namespace, and by assigning it the reserved
value “urn:mpeg:mpeg21:2002:01-DIP-NS:PI”. It is
worthwhile noting that the MPEG-21 Processing Item concept
is closely related to Fedora’s “behavior” concept
[7, 26, 29]. A
Processing Item is physically contained in the same DID
as the entity of the data model with which it is associated. For example,
a Processing Item can be associated with a Container,
an Item, or a Component. Because DIP remains
to be standardized, a more detailed description of Processing
Items is out of the scope of this article. It suffices to say
that, typically, a Processing Item either contains or points
at code that can be used to process an entity of a DID.
An entity of the data model can be accorded a dip:ObjectType
element from the DIP XML Namespace. A dip:ObjectType
associated in this manner with an entity can be used as a key to actual
bind the entity to a Processing Item. As a matter of fact,
this approach conveys that the processing method specified by the Processing
Item uses as argument the entity of the DID for which the content
of the dip:ObjectType
element is the same as the content of the Processing Item’s
dip:Argument.
It is helpful to think of the dip:ObjectType
as a ‘link’ between an entity and a Processing Item,
not as an indication of the ‘genre’ of an entity.
Table 3 shows an Item associated
with a Processing Item by means of the value ‘urn:my:Argument'.
That value is used as the content of both the dip:ObjectType
element of the Item, and the dip:Argument
element of the Processing Item. It is also shown that
the Processing Item is assigned the identifier 'urn:bar:a333766936'
through the use of the dii:Identifier
element from the DII XML Namespace. The DIP specification allows entities
to have more than one dip:ObjectType.
Also, a Processing Item can bind to more than one entity
by using multiple dip:Argument
elements, each of which connects via the dip:ObjectType
to the entities.
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container>
…
<!-- Item containing content
-->
<didl:Item>
…
<!-- ObjectType
of Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dip:ObjectType
xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS">
urn:my:Argument</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
…
</didl:Item>
…
<!-- Processing Item -->
<didl:Item>
<!-- Qualification
of the Item as Processing Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Type xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:mpeg:mpeg21:2002:01-DIP-NS:PI</dii:Type>
</didl:Statement>
</didl:Descriptor>
<!-Processing
Item identification -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:a333766936</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!-- Actual
processing method -->
<didl:Component>
<didl:Descriptor>
<!-- Argument of processing method -->
<didl:Statement mimeType="text/xml; charset=UTF-8">
<dip:Argument
xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS">
urn:my:Argument</dip:Argument>
</didl:Statement>
</didl:Descriptor>
<!--
Actual code for processing method-->
<didl:Resource
mimeType="…">
…Link to processing code…</didl:Resource>
</didl:Component>
</didl:Item>
</didl:Container>
</didl:DIDL> |
Table 3: Processing Item
and dip:ObjectType
Descriptor for the associated Item |
2.3.3 Using Descriptors to convey rights
expressions
MPEG-21 Rights Expression Language (REL) specifies the usage of Descriptors
to associate rights expressions with DIDs and their contained entities.
This is achieved through the introduction of a language inspired by
XrML [6] with elements and attributes in a REL XML
Namespace. Table 4 shows the use of the r:license
element to associate simple copyright information with a didl:Item.
MPEG-21 Intellectual Property Management and Protection (IPMP) will
provide tools to enforce rights expressions declared by means of REL.
<didl:Item>
…
<didl:Descriptor>
<didl:Statement mimeType="text/xml;
charset=UTF-8">
<r:license
xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS">
<!--
optionally, specific rights can be added here.-->
<r:otherInfo>
<dc:rights xmlns:dc="http://purl.org/dc/elements/1.1/">
Copyright 2003; American Physical
Society</dc:rights>
</r:otherInfo>
</r:license>
</didl:Statement>
</didl:Descriptor>
…
</didl:Item> |
Table 4: A simple Rights Expression |
3 Usage of MPEG-21 DIDL at the LANL Research
Library
When researching the usage of the MPEG-21 Digital Item Declaration
Language to represent complex digital objects in the repository at the
LANL Research Library, two major questions emerged:
- How to map the – related – datastreams to be contained
in a complex object of the LANL repository to the DIDL data model
- How to use Descriptors to meet the design goals of
the repository and its associated applications
Both questions will be addressed in the remainder of this section,
by providing an insight into the major design choices that were made
when implementing DIDL at the LANL Research Library. The described design
choices result in a DID profile, which has formally been expressed
as a Schematron schema [note 3]. DIDs conformant to the design choices must be
valid according to the DIDL XML Schema as well as according to this
Schematron schema.
In the remainder of this article, XML excerpts of a LANL DID are provided
to illustrate the main design choices that were made. A full representation
of the DID from which excerpts are taken is provided in Appendix
A. This DID is the DIDL-based representation of a complex object
consisting of:
- A LANL technical report, which is a single PDF file with identifier
‘urn:bar:99-7537’.
- Descriptive metadata about the LANL technical report expressed by
means of the MARC format. Actually, two versions of the MARC data
are provided: the original MARC record, and a MARCXML representation
derived from it. The identifier of the MARC record is ‘urn:bar:56-8730’.
3.1 LANL DIDs grow in breadth, not in
depth
DIDs at LANL make no use of the extensive nesting capabilities provided
by the DIDL data model or the associated XML Schema. All DIDs use a
simple 3-level hierarchy Container / Item
/ Component. As a result, the DIDs cannot grow in depth,
but can do so in breadth through the addition of Items
to a Container, Components to an Item,
and Resources to a Component. Figure
2 illustrates this approach. As will be shown, hierarchical relationships that could be expressed by
nesting entities are instead represented by means of a special purpose
Descriptor.
|
Figure 2: Example of a LANL DID structure
following the LANL DIDL profile |
3.2 All LANL data is created equal
The LANL repository harbors tens of millions of records from abstracting
and indexing databases. These metadata records are "stand-alone" in
that they do not come with their full-content counterparts. As a result,
when embedding such a record in a DID, it can hardly be provided as
secondary data because there is no primary datastream to which to attach it.
Therefore, it is provided as a datastream in its own right. This approach
is generalized to also embed descriptive metadata as an autonomous datastream
in a DID when the DID contains both the descriptive metadata and the
content it describes. While this might be contrary to the mainstream
approach in this respect, a case in its favor can be made. First,
descriptive metadata – in many cases expensive to create – should also
be the subject of digital preservation, and as a result be treated as
a potentially endangered datastream in its own right. Second, as technologies
evolve and datastreams of a variety media-types become directly searchable,
the special status of descriptive metadata as the sole point of entry
to those datastreams might eventually weaken, turning descriptive metadata
and datastreams into peers. As will be shown, the relationship between
the metadata and the content it describes is represented by means of
a special-purpose Descriptor.
Table 5 shows a DID that represents the LANL
technical report. The Container accommodates 2 Items.
The first Item contains the MARC metadata about the LANL
technical report. This Item contains two Components:
the second has a Resource that is the - base64 encoded
- original MARC record, the first has a Resource that
is a MARCXML version of the original MARC record. The second Item
contains the technical report provided by means of two Resources
in a single Component, indicating the equivalence of both
Resources. In the first Resource, the PDF
is provided By Value, and hence is base64-encoded. For illustrative
purposes, the PDF is also provided By Reference in a second Resource
through the inclusion of a reference to its network-location.
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container>
<!-- DID-identifier -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
…
<!-- Item accommodating descriptive
metadata about technical report -->
<didl:Item>
…
<!-- Content-identifier
of descriptive metadata -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:56-8730</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
…
<didl:Component>
…
<didl:Resource
mimeType="text/xml; charset=UTF-8">
<record xmlns="http://www.loc.gov/MARC21/slim">
<leader>01142cam 2200301 a 4500</leader>
<controlfield tag="005">19930521155141.9</controlfield>
…
</didl:Resource>
</didl:Component>
<didl:Component>
…
<didl:Resource encoding="base64"
mimeType="application/marc">
j0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxjb2xsZWN0aW9uIHhtbG5zSJodH
RwOi8vd3d3LmxvYy5nb3YvTUFSQzIxL3NsaW0iPg0KICA8cmVjb3JkPg0KICAgID
PD94bWwgdmVyc2lvb…
</didl:Resource>
</didl:Component>
</didl:Item>
<!-- Item accommodating technical
report -->
<didl:Item>
<!-- Content-identifier
of technical report -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:99-6537</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
…
<didl:Component>
…
<didl:Resource
encoding="base64" mimeType="application/pdf">
PSJjIj5jMTk5My48L3N1YmZpZWxkPg0KICAgIDw9uIHhtbG5zSJodHgKICAgIDxk
dGFnPSIzMDAiIGluZDE9IiAiIGluZDI9IiAiPg0KICAgICAgPHN1YmZpZWxkIGNv
cmVzdG9yZWQgdG8g…
</didl:Resource>
<didl:Resource
mimeType="application/pdf"
ref="http://foo/bar/733902fg992.pdf"/>
</didl:Component>
</didl:Item>
</didl:Container>
</didl:DIDL> |
Table 5: A DID representing the LANL technical report
|
3.3 LANL's usage of Descriptors
3.3.1 Identifiers
In Digital Library applications, identifiers are of utmost importance.
Identifiers were at the core of the seminal Kahn/Wilensky Framework
[10], and they rightfully received special attention
in the OAIS model [28]. Therefore, identifiers became
a core element in the design of LANL DIDs, and their implementation
is based on MPEG-21 DII:
- Identifiers are mandatory for the identification of the DIDs themselves.
These ‘DID-identifiers’ (see Figure 2) are provided as
the content of the dii:Identifier
element in a didl:Descriptor
which has the sole didl:Container
element of the DID as its parent. These identifiers are dynamically
assigned when DIDs are created, and they are UUID URNs [13].
- To map datastreams to the DIDL data model, a strong relationship
has been defined between Items and identifiers:
- When a single datastream has an identifier, it must be treated
as an Item.
- When multiple datastreams share an identifier, their combination
must be treated as an Item.
- All Items must have an identifier.
These ‘Content-identifiers’ (see Figure 2) are provided
as the content of the dii:Identifier
element, which, in this case, is contained in a didl:Descriptor
child element of the didl:Item
element. Multiple 'Content-identifiers' for a single Item can exist. As is the case with 'DID-identifiers',
'Content-identifiers' can be dynamically assigned when DIDs are created. Also, at LANL, ‘Content-identifiers’ are in many cases
inferred from the data to be contained in the Item. For example, when a record from the PubMed database is included in a DID,
it receives a 'Content-identifier' such as 'info:pmid/14577066', where
14577066 is the unique PubMed number for the record, and 'info' is
a proposed URI scheme [31].
This identifier-centric approach to XML-packaging of datastreams is
somehow in contrast with the hierarchy-centric perspective of approaches
such as METS and IMS, in which structural metadata are at the core of
the document models (cf. the mandatory structural map in METS). As will
be shown, in LANL DIDs, structural and relational metadata is represented
by means of a special-purpose Descriptor.
Table 5 shows the use of both the ‘DID-identifiers’
and ‘Content-identifiers’. A dii:Identifier
element associates the ‘DID-identifier’ “urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b”
with the didl:Container
element. And, a dii:Identifier
is used to attach the ‘Content-identifiers’ ‘urn:bar:56-8730’
and ‘urn:bar:99-6537’ with the MARC record and the
technical report, respectively.
3.3.2 Processing Items and their 'Placeholders'
In LANL, DIDs will be used as a mean to store and disseminate complex
digital objects. The authors felt a general level of discomfort with
embedding Processing Items - which express the methods
that can be used to process contained entities – in stored DIDL
objects. This discomfort is related to the anticipated need to frequently
update the content of Processing Items as new processing
methods emerge, or existing ones are updated. This anticipated need
to regularly “touch” stored DIDs is a poor fit with the
rather static nature of the contained content at LANL, and with the
OAIS-inspired strategy to create new DIDs – instead of updating
existing ones – when some form of editing has been performed.
As a result, it was decided not to embed Processing Items
in DIDs, but instead to embed ‘Placeholders’ for Processing
Items. When the dissemination of a stored DID is requested,
the contained ‘Placeholders’ will dynamically be exchanged
for actual processing-related information. The ‘Placeholder’
concept is implemented by means of a didl:Descriptor
that contains a diph:PlaceHolder
element from a self-defined XML Namespace. It can be attached at the
didl:Container,
didl:Item and
didl:Component
level. When a stored DID is disseminated, the following is achieved
by looking up the content of each embedded diph:PlaceHolder
element in a special-purpose registry:
- Based on correspondences expressed in the registry, a diph:PlaceHolder
element is replaced by one or more dip:ObjectType
elements
- Based on registry-information, Processing Items are
added to the DID, and connected to the inserted dip:ObjectType
elements in the manner described in Section 2.3.2.
The result of this approach is a dynamic way of binding stored DIDs
to specific dissemination methods. These methods, however, are not hard-coded
into the DIDs, and hence they can easily evolve over time. The ‘Placeholders’
can be regarded as a flexible bridge between an Archival Information
Package and a Dissemination Information Package.
Table 6 shows the use of the diph:PlaceHolder
element to include ‘Placeholders’ at the level of the Container,
Item and datastreams. Table 7 shows
the result of replacing the diph:PlaceHolder
element of one of the Components with a corresponding dip:ObjectType
and Processing Item. The correspondence between a diph:PlaceHolder
element, the dip:ObjectType
element, and the Processing Items is retrieved from the
special-purpose registry. It should be noted here that one diph:PlaceHolder
element may be replaced by multiple dip:ObjectType
elements.
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container>
…
<!-- PlaceHolder of Container
-->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:TechReport</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
…
<!-- Item containing MARC
content -->
<didl:Item>
…
<!-- PlaceHolder
of Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:Metadata</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
…
<didl:Component>
<!--
PlaceHolder of datastream -->
<!--
Table 7 shows the result after replacement of this PlaceHolder
-->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:Metadata:MARC/XML</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
…
</didl:Component>
</didl:Item>
<didl:Item>
…
<!-- PlaceHolder
of Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:FullReport</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
…
</didl:Item>
</didl:Container>
</didl:DIDL> |
Table 6: Placeholders implemented using
diph:PlaceHolder.
Table 7 shows the result after replacement
of the highlighted section |
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container>
…
<!-- Item containing MARC
content -->
<didl:Item>
…
<didl:Component>
…
<!--
ObjectType of Component as retrieved from registry -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<dip:ObjectType
xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS">
urn:foo:Argument1</dip:ObjectType>
</didl:Statement>
</didl:Descriptor>
…
<didl:Component>
…
</didl:Item>
…
<!-- Processing Item as retrieved
from registry -->
<didl:Item>
<!-- Qualification
of the Item as Processing Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Type xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:mpeg:mpeg21:2002:01-DIP-NS:PI</dii:Type>
</didl:Statement>
</didl:Descriptor>
<!-- identifier
Processing Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:a766654336</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!--
Actual processing method -->
<didl:Component>
<didl:Descriptor>
<!-- Argument of processing method -->
<didl:Statement mimeType="text/xml; charset=UTF-8">
<dip:Argument
xmlns:dip="urn:mpeg:mpeg21:2002:01-DIP-NS">
urn:foo:Argument1</dip:Argument>
</didl:Statement>
</didl:Descriptor>
<!--
Actual code that can be used to process the MARC/XML -->
<didl:Resource
mimeType="…">
…Link
to processing code…</didl:Resource>
</didl:Component>
</didl:Item>
</didl:Container>
</didl:DIDL> |
Table 7: Processing Item
and dip:ObjectType
Descriptor for the associated Item,
after replacement of the highlighted section of Table
6 |
3.3.3 Relationships
A special-purpose Descriptor is introduced to express
relationships between entities contained in DIDs. This Descriptor
is based on a self-defined Digital Item Relations (DIR) XML Namespace,
which contains RDF Statements expressing relations such as “isDerivationOf”,
“isPartOf”, “isTranslationOf”, “isDescriptiveMetadataOf”,
etc.
The core characteristics of the relationship approach are:
- RDF [34] is used as the language to express the
entities involved in a relationship and the nature thereof.
- The RDF statements are based on a vocabulary of relationships. This
vocabulary remains to be defined, and terms will probably be created
when required. It may be possible to import terms from existing XML
Namespaces, such as dcterms [4] and PRISM [27].
- For the identification of resources involved in relationships, the
following approach is taken:
- A DID is identified by means of its DID-identifier
- An Item and Component are identified by means of an XML fragment
identifier - XPointers [33, 35]
- expressed relative to the DID. The actual nature of these XPointer
expressions is the subject of ongoing research. One approach is
to base XPointers on ID-typed elements. IDs are a robust identification
method, as they remain valid even after repositioning an element
in a document. However, this approach requires the introduction
of IDs for every entity involved in a relationship. Another approach
is to use XPointers based on the DID structure itself. This approach
comes with little initial overhead, but processing XPointers of
this type may be more cumbersome than processing ID-based XPointers.
- The following conventions were introduced to include relationship information
in a DID:
- Relationships between DIDs, and
between a DID and resources external to the
actual DID are expressed by attaching a DIR Descriptor
to the corresponding
didl:Container element.
- Relationships between an Item and other Items
contained in a DID, and between an Item and the
Components within that Item, and relationships
between an Item and resources external to the actual
DID are expressed by attaching a DIR Descriptor
to the corresponding didl:Item
element.
- Relationships between Components within an Item,
and between Components and resources external to
the actual DID are expressed by attaching a DIR Descriptor
to the corresponding
didl:Component element.
These conventions are inspired by the distinct treatment of Context
Information and Representation Information in the OAIS model. The
OAIS Model defines Context Information as information that documents
the relationships of a Data Object (i.e., the identified digital object)
to its environment and how it relates to other Data Objects. Representation
Information describes the internal structure (including hierarchies)
of the Data Object. As such, it seems that relational information
pertaining to the Items resorts under the OAIS Context
Information, while relational information pertaining to Resources
resorts under OAIS Representation Information. Pragmatism also played
a role in deciding upon these conventions, because - from an application-perspective
- it is easier to manipulate Items that contain their
own relationships as this makes the Items self-contained.
Table 8 shows a Descriptor, describing
the metadata/content relationships between the MARC record and the technical
report described by the MARC record. It also shows the relationship
between the Items and a larger collection. Because these
are interrelations between Items and relations between
Items and an external resource, the Descriptor
is attached to the didl:Item
element of the MARC record.
<didl:Item>
…
<!-- Relationships on an Item level -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml;
charset=UTF-8">
<dir:Relations
xmlns:dir="http://library.lanl.gov/2003-11/MPEG-21/DIR">
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xml:base="urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b">
<rdf:Description
rdf:about="#//didl:Item[1]">
<a:isPartOf xmlns:a="http://purl.org/dc/terms/#">
<rdf:Description rdf:about="info:sid/library.lanl.gov:lanl-opac">
<b:hasType
xmlns:b="http://…/Relations#"
rdf:resource="http://…/Relations#Collection"/>
</rdf:Description>
</a:isPartOf>
<rdf:Description>
<rdf:Description
rdf:about="#//didl:Item[1]">
<b:isDescriptiveMetadataOf
xmlns:b="http://…/Relations#"
rdf:resource="#//didl:Item[2]"/>
</rdf:Description>
</rdf:RDF>
<dir:Relations>
</didl:Statement>
</didl:Descriptor>
…
</didl:Item>
|
Table 8: Item relationships |
3.3.4 Creation date
A special-purpose Descriptor is introduced to express
the datetime of creation of the DID entities contained in DIDs. This
Descriptor contains a didt:Created
element from a self-defined Digital Item DateTime XML Namespace. The
date and time values are formatted according to the W3C profile of ISO
8601 [32]
Table 9 shows a didl:Container
with a Descriptor that conveys the datetime of creation
of the Container structure, namely ‘2003-09-05T21:51:01Z’,
and a didl:Item
with a Descriptor that accommodates the datetime of creation
of the Item structure, namely ‘2003-09-05T18:30:07Z’.
The Descriptor is also used to convey the datetime of
creation of an actual datastream.
<didl:DIDL
xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container>
…
<!-- Creation-datetime of
Container -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2003-09-05T21:51:01Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
…
<didl:Item>
…
<!-- Creation-datetime
of Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2003-09-05T18:30:07Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
…
<didl:Component>
…
<!--
Creation-datetime of datastream -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2002-05-03T14:30:03Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
…
</didl:Component>
</didl:Item>
…
</didl:Container>
</didl:DIDL> |
Table 9: didt:Created
at Container, Item and datastream level |
4 Conclusion
This article has described the application of the MPEG-21 Digital Item
Declaration Language to represent complex digital objects from the collection
at the LANL Research Library. Although the article has not explicitly
touched on the matter, the authors hope to have shown that, generally,
usage of MPEG-21 DIDL as a complex object document model for Digital
Library applications is a feasible, and actually attractive option:
- From a strategic perspective, DIDL is appealing because it is part
of the MPEG-21 suite of Standards which is likely to receive strong
industry backing. Also, DIDL is part of a broader architecture that
is relevant to many communities, including the Digital Library community.
- From a functional perspective, DIDL is attractive because of the
flexibility offered by its well-specified data model, and because
of the extensibility provided by the Descriptor approach.
The MPEG-21 Standard itself makes use of those Descriptors to provide
a fundamental solution for the identification of entities, to associate
processing methods with entities, to express rights related to entities,
and to allow for the enforcement of those rights. As has been shown
by means of the LANL DIDs, Descriptors can be used to
meet specific design requirements. At LANL, Descriptors
have been used to enforce an identifier-centric document model, to
implement a dynamic association between entities and processing methods,
and to introduce a novel way to express relationships. More generally,
Descriptors can be used as a tool to address community-specific
interoperability requirements. For example, one of the authors has
done initial research regarding the use of DIDL for the representation
of complex digital objects for the purpose of digital preservation,
using Descriptors as a technique to map OAIS metadata
categories to the DIDL data model.
DIDs created at LANL are fully compliant with the DIDL specification.
Compliance with the LANL DID design is enforced by first validating
DIDs against the DIDL XML Schema, and next against a Schematron schema
that formalizes the design characteristics of LANL DIDs. The DIDs will
be the unit of storage in the LANL repository. Soon ingestion will start,
and millions of DIDs will be created. A forthcoming article will describe
the characteristics of the repository architecture used to store and
disseminate DIDs. In that architecture, the OAI-PMH, the OpenURL and
concepts from the MPEG-21 Digital Item Processing specification play
a fundamental role.
Acknowledgements
The research reported in this article was supported by the Belgian Science
Foundation (Section Flanders) and the LANL Research Library.
The authors want to thank:
- Their colleagues of the Prototyping Team of the Research Library
of the LANL Laboratory for their invaluable input in this research:
Luda Balakireva, Henry Jerez, Xiaoming Liu and Thorsten Schwander.
Rick Luce at the Research Library for making this research possible
and for continued encouragement. Miriam Blake and Beth Goldsmith from
the Development Team of the LANL Research Library for valuable feedback
regarding the LANL DID.
- Thomas DeMartini at ContentGuard Inc. for his helpful input on the
use of MPEG-21 Rights Expressions in the LANL DID.
- Sandy Payette at Cornell University, Michael Nelson at Old Dominion
University and Tony Hammond at Elsevier Science for reviewing a draft
of this article.
Jeroen Bekaert also wishes to thank:
- His supervisors Prof. Rik Van de
Walle (Multimedia Lab, Ghent University) and Prof. Mil De Kooning (Dept.
of Architecture and Urbanism, Ghent University) for their ongoing
support and encouragement.
- His colleagues of Multimedia
Lab for sharing their MPEG-21 knowledge.
References
-
Advance Distributed Learning, “The Sharable
Content Object Reference Model (SCORM) - Version 1.3 - WD,”
March 2003
-
Bekaert, J., Hochstenbach, P., De Neve, W., Van
de Sompel, H. and Van de Walle, R. “Suggestions concerning
MPEG-21 Digital Item Declaration,” ISO/IEC JTC1/SC29/WG11
M9735, Trondheim, July 2003.
-
Burnett, I., Van de Walle, R., Hill, K., Bormans, J., and Pereira, F., “MPEG-21: Goals and Achievements,” IEEE Multimedia, Oct-Dec 2003, pp. 60-70.
-
Dublin Core Metadata Initiative, Dublin Core, http://dublincore.org/
-
Giaretta, D. CCSDS Panel 2, “Steps towards
CCSDS standards for information packaging using XML,” December
2001.
-
Contentguard, XrML - eXtensible rights Markup Language,
http://www.xrml.org/
-
FEDORA, “Mellon Fedora Technical Specification,
Version 1.1,” http://www.fedora.info/,
December 2002.
-
IMS Global Learning Consortium, “IMS Content
Packaging XML Binding - version 1.1.2 - Final specification,”
2001.
-
Information Technology for Learning, Education,
and Training, “Liaison Statement on MPEG-21 Rights Expression
Language (MPEG-21 REL),” ISO/IEC JTC 1/SC 36/WG 4 N0052,
Seoul, September 2003.
-
Kahn, R. and Wilensky R. “A Framework for
Distributed Digital Object Services. Corporation for National Research
Initiatives,” http://www.cnri.reston.va.us/k-w.html,
1995.
-
Lagoze, C., Van de Sompel, H., Nelson, M. and
Warner, S. “The Open Archives Initiative Protocol for Metadata
Harvesting - Version 2.0”, http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm,
2003.
-
Maly, K., Nelson, M. and Zubair, M. “Smart
Objects, Dumb Archives: A User-Centric, Layered Digital Library
Framework,” <doi:10.1045/march99-maly>, D-Lib Magazine, March 1999.
-
Mealling, M., Leach, P. and Salz, R. “A
UUID URN Namespace”, http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 1: Vision, Technologies and Strategy,” ISO/IEC
TR 21000-1:2001, December 2001.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 2: Digital Item Declaration,” ISO/IEC 21000-2:2003,
March 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 2: Digital Item Declaration Extensions - Amendment 1
- WD v.1,” ISO/IEC JTC1/SC29/WG11 N5837, Trondheim,
July 2003.
-
MPEG-21, Information Technology, Multimedia Framework
, “Part 3: Digital Item Identification,” ISO/IEC
21000-3:2003, March 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 7: Digital Item Adaptation,” ISO/IEC JTC 1/SC
29/WG 11 N5845, Trondheim, July 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 10: MPEG-21 Digital Item Processing,” ISO/IEC
JTC1/SC29/WG11 N5855, Trondheim, July 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
Part 10: MPEG-21 Digital Item Processing, “Technologies under
Consideration (TuC) v.1,” ISO/IEC JTC1/SC29/WG11 N5622,
Pattaya, March 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 4: MPEG-21 Intellectual Property Management and Protection,”
ISO/IEC JTC1/SC29/WG11 N5874, Trondheim, July 2003.
-
MPEG-21, Information Technology, Multimedia Framework,
“Part 5: MPEG-21 Rights Expression Language,” ISO/IEC
JTC1/SC29/WG11, N5838, Trondheim, July 2003.
-
Nelson, M., Argue, B., Efron, M., Denn, S. and
Pattuelli, M.C. “A Survey of Complex Object Technologies for
Digital Libraries,” NASA/TM-2001-211426, http://techreports.larc.nasa.gov/ltrs/PDF/2001/tm/NASA-2001-tm211426.pdf,
December 2001.
-
Nelson, M. “Buckets, smart objects for digital
libraries, Ph.D. Dissertation,” Old Dominion University, August
2000.
-
NISO AX Committee, “The OpenURL Framework
for Context-Sensitive Services,” Proposed Standard, http://library.caltech.edu/openurl/Standard.htm,
2003.
-
Payette, S. and Lagoze, C. “Flexible and
Extensible Digital Object and Repository Architecture,” Second
European Conference on Research and Advanced Technology for Digital
Libraries, http://www.cs.cornell.edu/payette/papers/ECDL98/FEDORA.html,
Heraklion, September 1998.
-
PRISM, Publishing Requirements for Industry Standard
Metadata, http://www.prismstandard.org/
-
Space data and information transfer systems, “Open
Archival Information System, Reference Model,” ISO 14721:2003,
February 2003.
-
Staples, T., Wayland, W. and Payette S. “The
Fedora Project: An Open-Source Digital Object Repository System,”
<doi:10.1045/april2003-staples>,
D-Lib Magazine, April 2003.
-
The Library of Congress, “Metadata Encoding
and Transmission Standard,” http://www.loc.gov/standards/mets/,
February 2002.
-
Van de Sompel, H., Hammond, T., Neylon, E., and
Weibel S.L. “The "info" URI Scheme for Information
Assets with Identifiers in Public Namespaces”, http://www.ietf.org/internet-drafts/draft-vandesompel-info-uri-00.txt
-
W3C, “Date and Time Formats,” Note,
http://www.w3.org/TR/NOTE-datetime,
September 1997.
-
W3C, “Proposal for XML Fragment Identifier
Syntax 0.9,” Working Group Note, http://www.w3.org/TR/xml-fragid/,
September 2003.
-
W3C, “RDF, Resource Description Framework,”
Recommendation, http://www.w3.org/RDF/,
August 2003.
-
W3C, “XML Pointer Language,” Recommendation,
http://www.w3.org/TR/xptr/,
August 2002.
Notes
-
ISO: http://www.iso.ch/
-
MPEG Website: http://mpeg.telecomitalialab.com/
-
LANL DID: http://lib-www.lanl.gov/proto/MPEG-21/
-
MPEG-21 DIDL Working Draft: http://xml.coverpages.org/MPEG21-WG-11-N3971-200103.pdf
-
MPEG-21 DIDL Working Draft Schema: http://download.webct.com/public/ims/2.0/MPEG21.xsd
-
Multimedia Lab: http://multimedialab.elis.ugent.be/
Appendix A: LANL DID representing a technical
report and metadata describing it
<?xml
version="1.0" encoding="UTF-8"?>
<didl:DIDL xmlns:didl="urn:mpeg:mpeg21:2002:01-DIDL-NS">
<didl:Container> {1}
<!-- DID-identifier -->
<didl:Descriptor> {5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!-- PlaceHolder of Container
-->
<didl:Descriptor> {5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:TechReport</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!-- Creation-datetime of
Container -->
<didl:Descriptor> {5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2003-09-05T21:51:01Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
<!-- Item accommodating descriptive
metadata about technical report -->
<didl:Item> {2}
<!-- Content-identifier
of descriptive metadata -->
<didl:Descriptor>
{5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:56-8730</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!-- PlaceHolder
of Item -->
<didl:Descriptor>
{5}
<!--
PlaceHolder of Item -->
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:Metadata</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!-- Creation-datetime
of Item -->
<didl:Descriptor>
{5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2003-09-05T18:30:07Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
<!-- Relationships
on an Item level -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dir:Relations
xmlns:dir="http://library.lanl.gov/2003-11/MPEG-21/DIR">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xml:base="urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b">
<rdf:Description rdf:about="#//didl:Item[1]">
<a:isPartOf xmlns:a="http://purl.org/dc/terms/#">
<rdf:Description
rdf:about="info:sid/library.lanl.gov:lanl-opac">
<b:hasType xmlns:b="http://…/Relations#"
rdf:resource="http://…/Relations#Collection"/>
</rdf:Description>
</a:isPartOf>
<rdf:Description>
<rdf:Description rdf:about="#//didl:Item[1]">
<b:isDescriptiveMetadataOf
xmlns:b="http://…/Relations#"
rdf:resource="#//didl:Item[2]"/>
</rdf:Description>
</rdf:RDF>
<dir:Relations>
</didl:Statement>
</didl:Descriptor>
<didl:Component>
{3}
<!--
PlaceHolder of datastream -->
<didl:Descriptor>
{5}
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:Metadata:MARC/XML</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!-Creation-datetime
of datastream -->
<didl:Descriptor>
{5}
<didl:Statement mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2002-05-03T14:30:03Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
<didl:Resource
mimeType="text/xml; charset=UTF-8"> {4}
<record xmlns="http://www.loc.gov/MARC21/slim">
<leader>01142cam 2200301 a 4500</leader>
<controlfield tag="005">19930521155141.9</controlfield>
<datafield tag="010" ind1="
" ind2=" ">
<subfield
code="a">92005291</subfield>
</datafield>
…
</didl:Resource>
</didl:Component>
<didl:Component>
{3}
<!--
PlaceHolder of datastream -->
<didl:Descriptor>
{5}
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:Metadata:MARC/RAW</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!--
Creation-datetime of datastream -->
<didl:Descriptor>
{5}
<didl:Statement mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2001-02-12T11:34:02Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
<didl:Resource
encoding="base64" mimeType="application/marc"> {4}
j0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxjb2xsZWN0aW9uIHhtbG5zSJodH
RwOi8vd3d3LmxvYy5nb3YvTUFSQzIxL3NsaW0iPg0KICA8cmVjb3JkPg0KICAgID
PD94bWwgdmVyc2lvb…
</didl:Resource>
</didl:Component>
</didl:Item>
<!-- Item accommodating technical
report -->
<didl:Item> {2}
<!-- Content-identifier
of technical report -->
<didl:Descriptor>
{5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dii:Identifier xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS">
urn:bar:99-6537</dii:Identifier>
</didl:Statement>
</didl:Descriptor>
<!-- PlaceHolder
of Item -->
<didl:Descriptor>
{5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:FullReport</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!-Creation-datetime
of Item -->
<didl:Descriptor>
{5}
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2003-09-05T18:30:07Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
<!-- Relationships
of Item -->
<didl:Descriptor>
<didl:Statement
mimeType="text/xml; charset=UTF-8">
<dir:Relations
xmlns:dir="http://library.lanl.gov/2003-11/MPEG-21/DIR">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xml:base="urn:uuid:10ba6842-ec45-3b19-8kub-hy8ff58c58a8b">
<rdf:Description rdf:about="#//didl:Item[2]">
<a:isPartOf xmlns:a="http://purl.org/dc/terms/#">
<rdf:Description
rdf:about="info:sid/library.lanl.gov:lanl-tr">
<b:hasType xmlns:b="http://…/Relations#"
rdf:resource="http://…/Relations#Collection"/>
</rdf:Description>
</a:isPartOf>
<rdf:Description>
<rdf:Description rdf:about="//didl:Item[2]">
<b:hasDescriptiveMetadata
xmlns:b="http://…/Relations#"
rdf:resource="#//didl:Item[1]"/>
</rdf:Description>
</rdf:RDF>
<dir:Relations>
</didl:Statement>
</didl:Descriptor>
<didl:Component>
{3}
<!--
PlaceHolder of datastream -->
<didl:Descriptor>
<didl:Statement mimeType="text/xml; charset=UTF-8">
<diph:PlaceHolder
xmlns:diph="http://library.lanl.gov/2003-09/MPEG-21/DIPH">
urn:foo:FullReport/PDF</diph:PlaceHolder>
</didl:Statement>
</didl:Descriptor>
<!-Creation-datetime
of datastream -->
<didl:Descriptor>
{5}
<didl:Statement mimeType="text/xml; charset=UTF-8">
<didt:Created
xmlns:didt="http://library.lanl.gov/2003-09/MPEG-21/DIDT">
2000-03-11T18:22:33Z</didt:Created>
</didl:Statement>
</didl:Descriptor>
{5}
<didl:Resource
encoding="base64" mimeType="application/pdf"> {4}
PSJjIj5jMTk5My48L3N1YmZpZWxkPg0KICAgIDw9uIHhtbG5zSJodHgKICAgIDxk
dGFnPSIzMDAiIGluZDE9IiAiIGluZDI9IiAiPg0KICAgICAgPHN1YmZpZWxkIGNv
cmVzdG9yZWQgdG8g…
</didl:Resource>
{4}
<didl:Resource
mimeType="application/pdf"
ref="http://foo/bar/733902fg992.pdf"/>
</didl:Component>
</didl:Item>
</didl:Container>
</didl:DIDL> |
Copyright ©
Jeroen Bekaert, Patrick Hochstenbach, and Herbert Van de Sompel
|