By realization we refer to the task of creating from a design plan specifications for concrete media objects, and layouts of media objects. As mentioned above, the structure of the Realization Layer shares similarities with the Design Layer. It consists of a Media Realization component, and a Layout Realization component (cf. Fig. 8). Once again, the Media Realization component, (cf. Fig. 9) can be regarded as the location to plug in subcomponents for media/mode-specific realization, i.e., dedicated modules for producing 2D- and 3D graphics, natural language utterances, animation, video, music etc. according to design plans.
The Dispatching Component has been included to represent the task of dispatching media realization commands to the relevant modules, and vice versa, to collect and pass on the results of the single realization modules. It is important to note that there is not necessarily a 1:1 relationship of media design and realization components in an IMMPS. For example, an actual design component may rely on several realization modules (using them alternatively, or even in parallel), in order to convey design plans.
It is beyond the scope of the current RM to describe particular realization
subcomponents.
The only suggestion made here is, for realization subcomponents, to
distinguish whether the transformation of realization commands to
media objects is handled as a retrieval
task, or a generation task. In case of retrieval, the commands
serve as descriptors which have to be matched
against descriptors of available media objects. At this point,
however, we stop and refer to work on multimedia retrieval and
multimedia databases for a
more detailed treatment of the retrieval task ([9]).
In a generative approach, media realization commands
trigger and constrain the employed mechanisms for generating
media objects.
The result of the Realization Layer is a specification of dispalyable media objects together with layout information. It entails all the information required to ``run'' the presentation properly. To represent this information, one could use a specification language as proposed in [10], or rely on an object oriented approach for describing multimedia objects such as MHEG [11], or the more general PREMO [4] framework. It should be noted that the output of the Realization Layer cannot be said to be the complete internal representation of a presentation. Rather, it's only one piece of it, since the Realization Layer has only a restricted view of the presentation process and may be asked to achieve goals which are less complex than the overall one. On the other hand, there is a clear distinction between the media objects as such and their presentation (or display). This distinction is reflected in the RM by separating the Realization Layer from a Presentation Display Layer. Moreover, it might be the case that presentation generation (as described by the first four layers of the RM) is completely separated from Presentation Display (e.g., at different instances of time, and running on different unconnected machines). For example, consider the automated generation of a multimedia presentation which will be distributed on a CD-ROM.