Contents
A Guide to Creating DOPs
A DOP is a specification of the structure and the behavior of a group of digital objects. Such specifications are expressed in XML form. The XML DOP definitions are loaded by the framework at start up and are used as class and/or type definitions of digital objects. The framework then is able to treat an individual object as being an instance of its prototype, automatically complying with the prototype's specifications.
Keep in mind that the power of DOPs lies in allowing you to define your own classes and/or types of digital objects. This page highlights what attributes you can specify in a DOP definition and how each such attribute is handled by the framework.
Example Scenario
As discussed in the Overview, consider the case of a DL comprised of Books and Paintings:
Paintings contain Dublin Core (DC) metadata along with three versions of the painting's digital image: a high quality, a web quality and a thumbnail image.
Books, contain DC metadata but do not contain any digital content; links directing to Pages are used instead.
Pages contain no descriptive metadata but contain three versions of the page's digital image, as in Paintings.
We will use DOPs to define these three types / classes of objects.
Painting DOP
<dop id="painting"> <label lang="en">Painting DOP</label> <description lang="en"> This DOP defines paintings as comprised of DC metadata and three forms of the painting's digital image. Moreover, a shortView and detailView behavior scheme is also defined. </description> <metadata> <set id="DC"> <label lang="en">Dublin Core Metadata</label> <fields> <field id="dc:identifier" isMandatory="true"> <label lang="en">Identifier</label> </field> <field id="dc:relation_isPartOf"> <label lang="en">Parent's Identifier</label> </field> <field id="dc:title" isMandatory="true"> <label lang="en">Title</label> </field> <field id="dc:date"> <label lang="en">Date</label> </field> <field id="dc:creator" isMandatory="true"> <label lang="en">Painter</label> </field> <field id="dc:description" isBigText="true"> <label lang="en">Description</label> </field> </fields> </set> </metadata> <digitalContent> <stream id="hq"> <label lang="en">High Quality Image</label> <description lang="en"> The Hiqh Quality Image is used for preserving the painting's image </description> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> <stream id="web"> <label lang="en">Web Quality Image</label> <description lang="en"> The Web Quality Image is used for publishing the painting's image </description> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> <stream id="thumb"> <label lang="en">Thumbnail Image</label> <description lang="en"> The Thumbnail Image is used for publishing the painting's thumbnail image </description> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> </digitalContent> <behavior> <scheme id="getDCMetadata"> <label lang="en">The painting's DC metadata.</label> <elementSet ref="DC.*"/> </scheme> <scheme id="shortView"> <label lang="en">Painting's short view</label> <element id="identifier" ref="DC.dc:identifier"/> <element id="title" ref="DC.dc:title"/> <element id="painter" ref="DC.dc:creator"/> <element id="thumb" ref="thumb"/> </scheme> <scheme id="detailView"> <label lang="en">Painting's detail view</label> <elementSet ref="DC.*"/> <element id="painting" ref="web"/> </scheme> </behavior> </dop>
Book DOP
<dop id="book"> <label lang="en">Book DOP</label> <description lang="en"> This DOP defines books as comprised of DC metadata and links to paintings. A table of contents, shortView and a detailView behavior scheme is also defined. </description> <metadata> <set id="DC"> <label lang="en">Dublin Core Metadata</label> <fields> <field id="dc:identifier"> <label lang="en">Identifier</label> </field> <field id="dc:relation_isPartOf"> <label lang="en">Parent's Identifier</label> </field> <field id="dc:title"> <label lang="en">Title</label> </field> <field id="dc:date"> <label lang="en">Date</label> </field> <field id="dc:creator" isRepeatable="true"> <label lang="en">Author(s)</label> </field> <field id="dc:description" isBigText="true"> <label lang="en">Description</label> </field> <field id="dc:publisher"> <label lang="en">Publisher</label> </field> </fields> </set> </metadata> <relations> <structuralRelationContext> <child dop="dl.books.page"/> </structuralRelationContext> </relations> <behavior> <scheme id="getDCMetadata"> <label lang="en">The book's DC metadata.</label> <elementSet ref="DC.*"/> </scheme> <scheme id="shortView"> <label lang="en">Books's short view</label> <element id="identifier" ref="DC.dc:identifier"/> <element id="title" ref="DC.dc:title"/> <element id="author" ref="DC.dc:creator"/> <element id="publisher" ref="DC.dc:publisher"/> <element id="frontPage" ref="structure[0].thumb"/> </scheme> <scheme id="detailView"> <label lang="en">Books's detail view</label> <elementSet ref="DC.*"/> <element id="frontPage" ref="structure[0].web"/> </scheme> <scheme id="toc"> <label lang="en">Book's table of contents view</label> <elementSet ref="structure.*"/> </scheme> </behavior> </dop>
Page DOP
<dop id="page"> <label lang="en">Book's Page DOP</label> <description lang="en"> This DOP defines pages as comprised of three forms of the page's digital image. A shortView and a detailView behavior scheme is also defined. </description> <digitalContent> <stream id="hq"> <label lang="en">High Quality Image</label> <description lang="en"> The Hiqh Quality Image is used for preserving the page's image </description> <mime type="image/tiff"/> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> <stream id="web"> <label lang="en">Web Quality Image</label> <description lang="en"> The Web Quality Image is used for publishing the page's image </description> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> <stream id="thumb"> <label lang="en">Thumbnail Image</label> <description lang="en"> The Thumbnail Image is used for publishing the page's thumbnail image </description> <mime type="image/jpg"/> <mime type="image/jpeg"/> </stream> </digitalContent> <behavior> <scheme id="shortView"> <label lang="en">Page's short view</label> <element id="thumbnail" ref="thumb"/> </scheme> <scheme id="detailView"> <label lang="en">Page's detail view</label> <element id="image" ref="web"/> </scheme> </behavior> </dop>
Attributes of a DOP
Supported DOP attribute specifications are defined in the DOPs XML DTD. In terms of XML, a DOP is defined as follows.
<!ELEMENT dop (label*, description*, metadata*, digitalContent*, batchImports*, relations*, behavior*)>
<!ATTLIST dop
id CDATA #REQUIRED
>
Not only DOP definitions, but all attribute specifications can contain multi-lingual labels and descriptions as follows.
<!ELEMENT label (#PCDATA)>
<!ATTLIST label
lang CDATA "default"
>
<!ELEMENT description (#PCDATA)>
<!ATTLIST description
lang CDATA "default"
>
Metadata
Metadata related attribute specifications can be defined as follows.
<!ELEMENT metadata (set+, mappings*)>
<!ELEMENT set (fields)>
<!ATTLIST set
id CDATA #REQUIRED
>
<!ELEMENT fields (field+)>
<!ELEMENT field (label*, description*, defaultValue*)>
<!ATTLIST field
id CDATA #REQUIRED
isMandatory (true|false) "false"
isHidden (true|false) "false"
isRepeatable (true|false) "false"
isBigText (true|false) "false"
>
<!ELEMENT defaultValue (#PCDATA)>
<!ATTLIST defaultValue
lang CDATA "default"
>
<!ELEMENT mappings (mapping+)>
<!ELEMENT mapping EMPTY>
<!ATTLIST mapping
id CDATA #REQUIRED
from CDATA #REQUIRED
to CDATA #REQUIRED
>
A DOP may contain zero or more metadata set specifications. For example, both Paintings and Books define a "DC" metadata set, each one comprised of its own dc:* field definitions.
Metadata Set
A metadata set attribute specification has a unique identifier and it is comprised of the specifications of its fields.
Metadata Field
A metadata field attribute specification has a unique identifier and may also define various characteristics of the field including:
- whether it is mandatory - isMandatory.
- whether it is hidden - isHidden.
- whether it is repeatable (accepts multiple values) - isRepeatable.
- whether it contains "big text" - isBigText.
- its default value, defined in many languages.
All these characteristics exist in order to allow high-level DL services to handle diverse metadata field usages effectively. For instance, a service (e.g. Navigation or Cataloging) that operates upon Paintings and Books has to be supplied with a means to adapt to each field's requirements, without having to hard-code the actual class and/or type of the object. Put in other terms, a field, such as dc:description, may need to be handled differently for different classes and/or types of objects and these field characteristics are used to assist on this.
In DOPs Core 1.0 beta, two new field attribute characteristics will be available, namely validators and formatters.
Metadata Mapping
A DOP may contain zero or more metadata mapping pecifications. Mappings exist in order to assist in the case that more than one metadata set specifications are used in a DOP definition. Using mappings, one can decrease the amount of duplication required to fill-in values to the "equivalent" fields shared between two metadata sets.
For example, the following snippet defines a mapping between the dc:creator and dc:publisher fields.
<mappings> <mapping id="creatorToPublisher" from="DC.dc:creator" to="DC.dc:publisher"/> </mappings>
Digital Content
Digital content related attribute specifications can be defined as follows.
<!ELEMENT digitalContent (stream+)>
<!ELEMENT stream (label*, description*, mime*)>
<!ATTLIST stream
id CDATA #REQUIRED
type (stored|referenced) "stored"
>
<!ELEMENT mime (conversion*)>
<!ATTLIST mime
type CDATA #REQUIRED
>
<!ELEMENT conversion EMPTY>
<!ATTLIST conversion
converter CDATA #REQUIRED
hint CDATA #REQUIRED
target CDATA #REQUIRED
mime CDATA #REQUIRED
>
<!ELEMENT batchImports (batchImport+)>
<!ELEMENT batchImport (label*, description*)>
<!ATTLIST batchImport
id CDATA #REQUIRED
sourceStream CDATA #REQUIRED
targetDop CDATA #REQUIRED
targetStream CDATA #REQUIRED
>
Stream
In terms of digital content, a DOP may specify zero or more streams (oftenly termed files for simplicity). For example, the above Painting DOP defines three streams: hq, web and thumb.
Each stream attribute specification is comprised of an identifier and optional multi-lingual labels and descriptions. A stream attribute may be defined as either "stored" or "referenced":
- stored streams will be stored in the underlying repository
- referenced streams are not stored in underlying storage -- only the reference to their actual location is stored.
A stream specification is also used to specify the allowed formats of digital content, expressed in terms of MIME types. For each supported MIME type declaration zero or more stream conversions may be also specified, as in the following example:
<stream id="hq">
<mime type="image/tiff">
<conversion
target="web"
mime="image/jpeg"
converter="Java class name"
hint="conversion hint"/>
<conversion
target="thumb"
mime="image/jpeg"
converter="Java class name"
hint="conversion hint"/>
</mime>
</stream>
Suppose that this stream specification refers to the hq stream of a Page.
A stream converter for converting between image formats will be available in a next release of the DOPs Modules. Feel free to contribute your own.
Batch Import
A DOP may also define zero or more batch import specifications. Such a specification is used to hold information regarding the generation of instances from an "archived" form of a stream. For example, it can be used to represent a batch import of Page digital objects originating from a "zip file" attached to a Book object.
Consider that Books, instead of containing no digital content, they are defined to contain a zip stream:
<stream id="zip">
<mime type="application/zip"/>
</stream>
Moreover, Books are also defined to contain a batch import, as follows:
<batchImports>
<batchImport id="zip2pages" sourceStream="zip" targetDOP="page" targetStream="hq"/>
</batchImports>
In this scenario, zip files containing the hiqh quality images of book's pages are attached to Book instances. By triggering the batch import procedure, one can generate the Page instances from this zip file and when each hiqh quality image is set to its respective hq Page stream, the aforementioned stream conversions can be used to automatically generate the web and thumb images.
Currently, you have to utilize the batch import information on your own. Since batch import procedures highly depend on the deployment context of the DL, no default batch import procedure is provided with DOPs Core. Feel free to contribute your own batch import procedure implementations to the DOPs Modules.
Relations
Relation attribute specifications can be defined as follows.
<!ELEMENT relations (structuralRelationContext|relationContext)+>
<!ELEMENT structuralRelationContext (label*, description*, child+)>
<!ELEMENT child EMPTY>
<!ATTLIST child
dop CDATA #REQUIRED
>
<!ELEMENT relationContext (label*, description*, target+)>
<!ATTLIST relationContext
id CDATA #REQUIRED
>
<!ELEMENT target EMPTY>
<!ATTLIST target
dop CDATA #REQUIRED
>
Relation Context
Relation context attribute specifications are used to define the relationships in which the instances of this DOP are allowed to participate. Structural relation contexts are special-purpose contexts used to express parent/child relationships between instances of DOPs. For example, the Book DOP defined above, defines a structural relation context in which only Page instances are allowed.
Relation contexts can be used to model any type of relationships. Consider for example that Books should contain references to Paintings. A relation context can be defined in the Book DOP to model this reference relationhsip between Book and Painting instances as follows:
<relations>
<structuralRelationContext>
<child dop="dl.books.page"/>
</structuralRelationContext>
<relationContext id="reference2paintings">
<target dop="dl.paintings.painting"/>
</relationContext>
</relations>
Finally, if there is a requirement for a more fine-grained definition of this reference relationship between Books and Paintings, one can define the aforementioned reference2paintings relation context in the Page DOP. This would allow a book's page to reference a painting directly.
Behavior
Behavior specifications are defined as follows.
<!ELEMENT behavior (scheme+)>
<!ELEMENT scheme (label*, description*, (element|elementSet)+)>
<!ATTLIST scheme
id CDATA #REQUIRED
>
<!ELEMENT element EMPTY>
<!ATTLIST element
id CDATA #REQUIRED
ref CDATA #REQUIRED
>
<!ELEMENT elementSet EMPTY>
<!ATTLIST elementSet
ref CDATA #REQUIRED
>
Behavior Schemes
A behavior scheme provides a subset of an object's attributes. This subset may contain any identifiable attribute of an object. For example, the shortView scheme of a Painting provides three of its DC metadata fields and the painting's thumbnail, while the detailView provides all the DC metadata fields along with the painting's web image. On the other hand, the shortView of the Book provides selected book's DC metadata fields and the thumbnail of its first page (structure[0]). Such reference capability is not currently available in DOPs Core 1.0 alpha -- it will be supported in a forthcoming DOPs Core release.
As you may notice, behavior schemes do not contain any actual executable code definitions. This is a design decision, since behavior schemes are to be "executed" in Behavior Execution Contexts.
Please, consult the Creating Collections Guide to read how these three DOPs (Painting, Book, Page) can be defined in the context of collections.