DOP Inheritance

This page provides a technical description of DOP inheritance.

Terminology - Digital Object Prototypes, Classes and Types

The term “digital object prototype” helps us identify our specific notation and mechanism, while we use more general terms such as “digital object class” and/or “digital object type” to refer to the concepts realized by such a mechanism. More specifically, a DOP definition provides an abstract representation of a “prototypical” digital object, providing the specifications of its enclosing elements (metadata sets and fields, streams), its supported relationships and its behavior schemes. In practical terms, a DOP defines a hierarchical namespace, which is cloned upon instantiation to generate a runtime artifact called a digital object instance. Although the term “prototype instance” is not valid in neither object-based nor class-based OO programming languages, we use the term in the digital object domain since the generation of a runtime artifact involves two steps:

clone the DOP’s namespace and issue appropriate structures (represented in the DOPs API through the MetadataSet, MetadataField, RelationContext, BehaviorScheme, etc Java classes) to reflect the DOP's specifications at runtime. For example, a <field .../> XML specification will be represented at runtime through a MetadataField Java object, which will comply with the field's definitions automatically.
Given that the actual digital object information originates from the underlying storage artifact, a newly created digital object instance is “empty” and contains no digital object information: the names it defines are not yet bound to any values. The latter are loaded from the storage artifact after instantiation for efficiency reasons using the DOStorage mechanism. This interaction with the underlying digital object store is performed "behind the scenes" by the DOPs runtime, yielding digital object instances that "know" how to assemble/disassemble their internal information in a transparent manner.

As a result, the developer is supplied with a runtime artifact that abides to its DOP's definitions and also "knows" how to stage the underlying stored object's information at runtime in a transparent manner. The runtime artifact is said to be an instance of its DOP, as we use the term "DOP" to refer to a digital object class and/or type definition. In programming languages, a class differs from a type as follows: types define the properties we can reason about a group of objects, while classes constitute implementations of types that are also used as generators of objects. In the DOPs framework, a DOP definition can act both as a class (the generator of objects that offers the "implementation" these objects should share, expressed in terms of metadata, streams and relationships) and a type (offering the interface to be shared by a group of objects, expressed in terms of behavior schemes).

Inheritance in the digital object domain

Inheritance is a mechanism that helps us realize the following three features.

Subclassing

Subclassing is the ability to share behavior and representation. The primary goal of subclassing is reuse, where a subclass inherits part of the implementation from its superclass.

Subtyping

Subtyping is the ability to substitute an object with another; an instance of a subtype can stand in for an instance of its supertype. Subtyping is also called interface inheritance, referring to the relationship between the interfaces of two types. In the general case, a subtype inherits the operations of its supertype, without necessarily inheriting its implementation; a subtype may implement the interface defined by its supertype in a different manner.

Specialization

Specialization is the ability to describe one kind of object as a special kind of another with the help of the is-a relationship.

In the digital object domain, subclassing will enable a new class of digital material (a DOP definition) to reuse the definitions of its ancestor --i.e., by inheriting its metadata definitions, its digital content specifications and so forth. To this end, subclassing is of value to the DOP designer, since new DOPs (new classes of digital objects) can be defined by extending and reusing existing ones.

Subtyping is vital to the DL service implementor, since, in programming terms, she has to know which digital object instances are of the same type (expose similar sets of behavior schemes) in order to be able to treat them uniformly at runtime.

Finally, specialization is valuable for understanding the logical dependencies between diverse kinds of objects and therefore, specialization is important to both the DOP designer and the DL service implementor.

Implementation of DOP Inheritance

With DOP inheritance we support all aforementioned features. More specifically, we support multiple inheritance in DOPs, where a new DOP can be derived from many existing ones. We deem single inheritance to be too restrictive for allowing users to express type-polymorphism effectively. In particular, single inheritance would impose the introduction of additional constructs to allow for the effective expression of polymorphism, such as "abstract classes" or "interfaces". For this reason, the only notion we support is that of the "digital object prototype", which can be used in conjunction with multiple inheritance to effectively express subclassing, subtyping and type-polymorphism and, finally, generalization/specialization.

We illustrate the capabilities of DOP inheritance through revisiting the paintings and books example.

Paintings and Books Example Revisited

Evidently, DL services must be given guarantees regarding the behavior schemes they rely upon. In our paintings and books example, the two object types are supplied with a common set of behavior schemes in a "manual" fashion, since the DOP designer has supplied them intentionally with a same set of behavior schemes in their DOP definition, namely "shortView", "detailView" and "getDCMetadata". Making incompatible objects share a compatible set of behavior, as we have discussed in the Overview, is rather effective as it will allow DL services to treat both painting and book digital object instances uniformly at runtime. However, what we lack is ability to express the fact that these objects are of compatible types in a more fine-grained manner. To resolve this, we use DOP inheritance.

The next figure depicts the new definition of painting, book and page objects, generated by the virtue of DOP inheritance.

This new layout provides guarantees to DL services about an object’s type and its supported set of behavior schemes. It also highlights the polymorphic capabilities offered by DOP-based inheritance. For example, book objects now are polymorphic and have multiple types. As such, they can be treated differently in different contexts: they can behave as DCMetadata-typed objects being able to respond to "getDCMetadata" messages, as ObjectViews-typed objects responding to "shortView" and "detailView" messages, and, ultimately, as book-typed objects in any service provision context that can also exploit their toc (table of contents) behavior scheme. Finally, this new arrangement provides a more clear view of the logical dependencies of these objects, through their "is-a" relationships.

The next figures show the new inheritance-based XML DOP definitions of the painting, book and page objects, along with the new DOPs (ImageContent, ObjectViews and DCMetadata) issued to model such objects in a more effective manner.

The ImageContent DOP

<dop id="ImageContent">
    <label lang="en">ImageContent</label>
    <description lang="en">
        ImageContent is used to represent digital objects that
        hold 3 different forms of a digital image.
        It can be viewed as a definition of an "abstract class"
        of digital objects.
    </label>
    <digitalContent>
        <stream id="hq">
            <label lang="en">High Quality Image</label>
            <description lang="en">
                The Hiqh Quality Image is used for representing
                the original image --i.e, digitized in high resolution--
                to be held for preservation purposes.
            </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 representing a web-quality version of
                the original high quality image which can be used for web display.
            </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 representing the thumbnail version
                of the original high quality image.
            </description>
            <mime type="image/jpg"/>
            <mime type="image/jpeg"/>
        </stream>
    </digitalContent>  
</dop>

The DCMetadata DOP

<dop id="DCMetadata">
    <label lang="en">A DCMetadata Object</label>
    <description lang="en">
        A DOP definition that represents a DC metadata record.
    </description>
    <metadata>
        <set id="DC">
            <label lang="en">DC Metadata</label>
            <!--
                The metadata fields definitions enclosed in this
                object are targeted to a general-purpose usage,
                suited to documenting a variety of objects. Some DC
                fields are missing, as they are meant to be "added" by this
                DOP's descendants based on their particular needs.
            -->
            <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">Creator</label>
                </field>
                <field id="dc:description" isBigText="true">
                    <label lang="en">Description</label>
                </field>
            </fields>
        </set>
    </metadata>
    <behavior>
        <scheme id="getDCMetadata">
            <label lang="en">The object's DC metadata.</label>
            <description lang="en">
                Provides all the fields of the object's
                DC metadata set.
            </description>
            <elementSet ref="DC.*"/>
        </scheme>    
    </behavior>
</dop>

The ObjectViews DOP

<dop id="ObjectViews">
    <label lang="en">ObjectViews</label>
    <description lang="en">
        This DOP provides only "empty" definitions of two
        behavior schemes, resembling an "interface/type" definition.
        It is up to its descendants to provide implementations of
        these behavior schemes based on their internal structure.
    </description>
    <behavior>
        <scheme id="shortView"/>
        <scheme id="detailView"/>
    </behavior>
</dop>

The Painting DOP

<dop id="painting">
    <label lang="en">Painting DOP</label>
    <description lang="en">
        This DOP defines paintings as descendants of the DCMetadata,
        ObjectViews and ImageContent DOPs.
    </description>
    <inherits dop="DCMetadata"/>
    <inherits dop="ObjectViews"/>
    <inherits dops="ImageContent"/>
    <!-- 
    This DOP contains no metadata and no digital content specifications.
    It inherits both from DCMetadata and ImageContent respectively.
    --> 
    <behavior>
        <!--
        This DOP inherits the getDCMetadata behavior scheme
        of the DCMetadata. It also provides an implementation
        of the inherited shortView and detailView behavior schemes
        tailored to "painting" objects.
        -->
        <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>

The Book DOP

<dop id="book">
    <label lang="en">Book DOP</label>
    <description lang="en">
        This DOP defines books as descendants of the DCMetadata
        and ObjectViews DOPs.
    </description>
    <inherits dop="DCMetadata"/>
    <inherits dop="ObjectViews"/>
    <metadata>
        <!--
        This DOP overrides the inherited DCMetadata's DC set
        to add new fields for books.
        -->
        <set id="DC">
            <label lang="en">DC Metadata</label>
            <!-- inherit all DCMetadata's fields -->
            <elementSet ref="DCMetadata.DC.*"/>
            <!-- 
            override the dc:creator field to make it repeatable
            and, thus, support muliple creators (authors).
            -->
            <field id="dc:creator" isMandatory="true" isRepeatable="true">
                <label lang="en">Author(s)</label>
            </field>
            <!-- add the dc:publisher field -->
            <field id="publisher" isMandatory="true">
                <label lang="en">Publisher</label>
            </field>
        </set>
    </metadata>
    <relations>
        <relationContext id="structure">
            <child dop="dl.books.page"/>
        </relationContext>
    </relations>
    <behavior>
        <!--
        This DOP overrides the inherited getDCMetadata behavior
        scheme to include the new fields' definitions.
        It also provides an implementation of the inherited
        shortView and detailView behavior schemes tailored to
        books.
        Finally, it defines the book's table of contents behavior
        scheme.
        -->
        <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>

The Page DOP

<dop id="page">
    <label lang="en">Book's Page DOP</label>
    <description lang="en">
        This DOP defines pages as descendants of the ImageContent and ObjectViews
        DOPs.
    </description>
    <inherits dop="ImageContent"/>
    <inherits dop="ObjectViews"/>
    <digitalContent>
        <!-- 
            This DOP overrides the inherited hq stream specification
            to supply pages with support of TIFF high quality images.
            All other digital content attributes are inherited in 
            an "as-is" fashion.
        -->
        <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>
    </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>

Navigation

Action