DOPs Overview

History and Motivation

The motivation of the DOPs framework originates from a digital library development project we have implemented in the University of Athens. The result, Pergamos, constitutes a "real-life" example of the usage of an older version of DOPs. Pergamos is an integrated web-based DL system used for cataloging, ingesting, hosting and publishing the heterogeneous and diverse material of the University's Libraries.

Since the initial version of DOPs operated atop the FEDORA repository, you can find more details about the origins and motivation of DOPs in the following presentations: Introducing Pergamos: A FEDORA based Digital Library System utilizing Digital Object Prototypes (European FEDORA User's Meeting, Copenhagen, September 2005) and Digital Object Prototypes and Fedora Content Models (FEDORA Content Model Workshop, Karlsruhe, May 2006).

A big thanks goes to all my University of Athens colleagues and especially to George Pyrounakis, whose effort and ideas had played a significant role in the first realization of DOPs.

Digital Objects

A digital object is a network accessible, globally identifiable unit of information which is used to represent artifacts and/or intellectual work in the field of Digital Libraries (DLs). Examples of digital objects include but are not limited to articles, books, photographs, paintings, archives, documents, artifacts etc. Conceptually, a digital object is comprised of:

• metadata, providing the descriptive, technical, administrative aspects of the artifact and/or intellectual work,

• digital content, holding the digital material (streams or files) that constitute the object,

• relationships, outlining the relationships among this object and others,

• behavior, providing the operations supported by this object.

Digital Object Prototypes

A DOP provides the definitions of a class and/or type of digital objects, comprised of a set of digital object attribute specifications. A digital object is treated as an instance of its DOP, automatically conforming to the DOP's specifications by containing the same set of attributes. As a result, all digital objects that belong to the same class and/or type (all instances of a prototype):

• contain similar metadata and digital content
• participate in the same relationships
• expose uniform behavior

From a technical point of view, the DOPs framework is a domain-specific realization of the notions of types and classes, tailored to the needs of digital object management and manipulation. Individual objects are guaranteed to conform to the structure and behavior definition entailed in their prototype automatically, releasing DL users¹ from having to make each individual object conform to its specification manually.

DOPs supply high-level DL services with an effective means to manage and manipulate diverse and heterogeneous digital objects. In particular, DOPs enable services to handle the structural and behavioral variations of digital objects in a uniform manner, without resorting to custom developments for resolving individual object peculiarities and idiosyncrasies.

Architecture

Architecture Annotated

Features at a glance

• The framework supports prototypes that represent user-defined types and/or classes of digital objects. The DOPs framework will then force individual objects to conform to their prototype automatically.

• Collections / sub-collections are explicitly supported by the framework. Users of the framework are able to define their own collections / sub-collections hierarchies and each collection node in the hierarchy can contain different prototypes.

• The DOPs framework is independent of the underlying digital object store. Digital object instances conform to their prototypes regardless of the underlying storage encoding or format used to represent stored digital objects.

• Digital object behavior is defined once and in one place. All behavior is defined in the prototype, and it is dynamically attached to individual objects / instances of the prototype by the DOPs framework during instantiation.

• Type-specific digital object behavior can be composed in various DL service execution contexts. The DOPs framework makes no assumptions about the "service machinery" (service provision environments) supported by the DL system and allows one to execute digital object behavior in any service execution contexts supported by the DL system at hand: web services, web-based UIs, etc.

• The framework supports DOP inheritance, fostering reuse of existing DOP definitions while yielding type-polymorphic instances at runtime.

Example

For example, consider a DL comprised of Books and Paintings collections:

• Paintings are realized in terms of 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, on the other hand, do not contain any digital content but hold book's DC metadata and links to Pages.

• In turn, a Page contains no descriptive metadata except from its identifier and relation. A Page also contains three versions of the page's digital image, as in Paintings.

Such a model of Books and Paintings is not universal, as it has been generated by a DL designer to meet the requirements of a specific DL development and deployment context. For more details, please consult the Guide to Creating DOPs and the Guide to Creating Collections.

As shown in the figure above, Books, Pages and Paintings are comprised of different structure and behavior and participate in different relationships. This diversity is inherent in the objects and does not depend on the format we use for storing them. For example, DL services need not be aware of the low-level syntactic details involved in storing the attributes of a Book. In contrast, such services should focus on providing a higher level, user-oriented view of the attributes that constitute a Book, including its title, author, table of contents and its pages, while at the same time be in position to handle and manipulate these attributes effectively, in the proper level of abstraction.

DOPs supply high-level DL services with type-consistent abstractions of stored digital objects (the digital object instances), allowing Books, Pages and Paintings to behave as such automatically. Thus, given a definition of a digital object class and/or type, the DOPs framework provide abstractions over stored digital objects that are effective both in terms of semantics and manipulation capabilities, allowing DL service implementations to achieve more functionality with less effort and code development.

Behavior of Digital Objects

DLs are essentially used to manage and manipulate digital material. DL operations can be broadly grouped into the following two categories:

• Type-inherent behavior: operations that depend on the type of the object at hand. Roughly, type-inherent behavior refers to functionality that makes sense when applied on one type of object but not on another.

• DL-inherent behavior: general-purpose operations that depend on the overall functionality supported by a DL and can be applied to any type of digital material.

In terms of behavior, DOPs express both DL-inherent and type-inherent behavior in a manner that allows them to be effectively composed. DOPs use Behavior Execution Contexts for encapsulating behavior composition in various service execution contexts and use type-inherent Behavior Schemes for giving access to the object's data in such contexts.

Example

The above figure illustrates the use of behavior schemes and execution contexts for composing the behavior of Painting-typed objects:

• The "getDCMetadata" scheme yields the two --limited in number for brevity-- DC fields of the Painting object.
• The "shortView" scheme generates a combination of some DC fields with the object's thumbnail image.
• The "detailView" scheme provides a combination of all DC elements with the object's Web quality image.

In order to execute behavior on objects, high-level services apply the appropriate behavior scheme in the behavior execution context of their choice. For example, the OAI-PMH service evaluates the "getDCMetadata" scheme in the OAI-PMH context and uses the result to generate the OAI-PMH response. The OAI-PMH execution context "knows" how to handle the metadata provided by the "getDCMetadata" scheme, i.e., it encodes such metatada in an appropriate manner. On the other hand, browsing and object display services apply the "shortView" and "detailView" behavior schemes in the HTML behavior execution context. The latter "knows" how to generate HTML representations of an object's attributes and it is used by the browsing and object display services to construct Painting short and detailed object views respectively.

Extensibility & Adaptiveness

By separating behavior composition concerns, DOPs advance modularity. The use of behavior schemes releases DL services from being conscious on which attributes constitute each type of material --only objects themselves hold the knowledge about their constituent elements. By directing all object-specific operations via its behavior schemes, services are abstracted from structural and storage-specific object details, as the acquisition of appropriate attributes is transparently performed by the instance. The use of behavior execution contexts bridges type-inherent and DL-inherent behavior effectively. Behavior execution contexts encapsulate the service environments in which behavior schemes --and hence, the attributes they provide-- are composed.

The use of behavior schemes and behavior execution contexts advances extensibility and adaptiveness:

• When the DL is augmented with a new service, the service implementation can reuse existing schemes and/or contexts. For example, a search service can reuse the "shortView" behavior scheme and the HTML behavior execution context for displaying the search results to the user. A metadata service may reuse the "getDCMetadata" scheme and HTML execution context to provide metadata user display in HTML format. A print service may use the "detailView" scheme in a newly created PDF behavior execution context to supply users with printable PDF representations of digital objects.

• When a new class of objects joins the DL, changes to be made in existing contexts and/or services are kept to a minimum. If a new class complies with existing behavior schemes, no change is required at all. For example, although Books and Paintings have different structure, books expose a superset of Paintings behavior schemes. To have thus Books be compatible with Paintings in terms of behavior composition, service implementations require no change: all three required behavior schemes ("getDCMetadata", "shortView" and "detailView") are also available in Books and provide a book's DC metadata, short and detail views.

DOP Inheritance

We introduce DOP inheritance to foster reuse of local and/or remote DOP definitions, while offering a means to generate digital object instances that have multiple types. The latter can assist in supplying services with guarantees about the existence of behavior schemes in the objects such services manage at runtime. Put in other terms, DOP inheritance can be used to generate type-compatible digital object instances from incompatible digital object classes.