The Digital Object

A digital object represents the union of an asset, its metadata, and any operations supported by the object. Relevant APIs are grouped into interfaces, allowing digital objects deployed to the framework to support multiple stream and metadata access APIs.

The Warwick Framework container supports the mapping of metadata vocabularies to a single storage mechanism, which could be an EJB, a database, or a WebDAV container. The mapping for an object is defined when the digital object is deployed, much like an EJBs persistence mapping can be established during deployment.

The digital object, as the combined representation of an asset and its associated metadata, is the foundational object for media components and business applications. Digital objects are transportable, meaning that multiple systems, repositories, and platforms can be involved in any operation involving a digital object. Services can be hosted anywhere on the network to manipulate the metadata, asset, or both, for a particular digital object. Scarce resources such as hardware CODECs can be managed and represented as services that accept digital objects. Web Services (specifically, SOAP-based services), can be supported through the Digital Item Declaration of MPEG-21, an XML representation of a digital object.

A Solution Architecture

The logical model for a solution breaks down into four layers: business, application, component, and storage. Each layer tackles different problems, has different solutions, and effects different types of users. A rich-media platform defines a common model within each layer that allows for portability across implementations. Integrations between the layers allow for plug-and-play implementations of the architecture.

The foundation of a rich-media platform is the storage layer. Providing an abstraction to the digital assets is the key to developing rich media-based applications and services. Defining this layer has the same importance as defining a common language and API for accessing traditional relational-database systems. The storage layer is composed of the asset, the metadata about the asset, and the structure to store this information. The storage layer has to provide expected features such as insert, update, delete and query.

The component layer, also referred to as the repository layer, helps define access to the storage layer and allows functionality to be added that is not typical of a business developer and not typical of a storage system. Such functionality includes face recognition, sound to text, text to sound, watermarking, encoding, and decoding.

The list of operations cannot be predetermined, hence a layer to add new features must be provided. The repository layer provides two of the basic input/output pipelines needed, including meta and asset. The meta pipeline allows the ingestion of assets and the extraction of metadata. When digital assets are retrieved from the storage system, the metadata pipeline allows information to be pushed back into the stream. The asset pipeline allows the transformation of the digital asset, using operations like watermarking or encoding. For example, an image-based program might get an image as a GIF when it is encoded by the underlying storage system as a JPEG file.

The application layer provides ties into the modern business platforms, such as J2EE. Current distributed architectures include Enterprise JavaBeans (EJBs). A subset of EJBs, called Entity EJBs, are a well-known mechanism for representing information stored in a traditional relational-storage system or object-oriented storage system. Unfortunately, they are not well-suited for representing a digital asset. Current architectures do not provide proper support for digital rights management, transformation requests, metadata extraction, digital ingestion, or referenced resources.

The business layer helps unite the common business services and the rich-media services. This layer is most influenced by the MPEG-21 standards. The business layer utilizes existing technologies to help integrate services and define the ecosystem by uniting third-party providers of rich-media services with business processes. By providing the proper rich-media services, the cost of integrating rich-media applications and assets, which can be located throughout an organization, is reduced.

Figure 3 outlines the architecture for a rich-media framework. It is important to note that each of the service layers are required to bring together both low-level storage and translation capabilities with high-level programming and user features. Furthermore, these capabilities are not available off-the-shelf today with traditional environments.

New architectures, such as the one proposed here, are required to create a truly open-software platform that understands the structural details of rich-media content and provides a straightforward, standards-based interface for application development.

Mining for Riches:A technical look at rich media platforms
The Evolution of Rich Media
Application Development