After studying formal systems, we have been working in the design of Madame, a hypermedia framework, basically inspired by the Dexter Model. The purpose of this framework is to provide basic hypermedia functionality to be usefully adapted to different environments.
At the moment, the validity of Madame is being tested in different projects, by using it in different application areas in collaboration with specialists from each selected area. Each project has aims at specifying and implementing one application with built- in Hypermedia Functionality (HF). The chosen application areas are
In this contribution, we present our idea about HF definition and integration, based on our experience in the a), b) and c) type projects. Next, we describe how HF is integrated in the three projects using Madame; we finally discuss the interest of Madame use in these integrations.
When HF integration is part of the initial premises of the application design, we consider this approach as an intra-application approach (cases a) and b)). Otherwise, when we want to add the hypermedia paradigm to existing applications, without modifying its design/philosophy/implementation, we consider this approach as an extra-application approach (case c)).
On the other hand, with the intra-application approach, the HF integration implementation will result in an intra- or extra-application, but with the extra- application approach, the implementation will always result in an extra-application.
From our experience, the task of providing an application with HF consists in identifying/defining application/domain elements (we consider as an application/domain element every object, property, task, concept, abstraction, ... from the application or from the domain of the application) and relating them to hyperobjects (links, nodes, specifiers, anchors, components, navigators,...). We consider this task as the assignment of a hypermedia metaphor to an application/domain. In our opinion this constitutes the basis for the HF integration methodology to be followed.
The identification/definition of the elements to relate requires both application/domain knowledge and hypermedia knowledge. Actually, the selection of the hyperobject to relate with the element depends on the suitability of the hypermedia characteristics/services belonging to the hyperobject, with respect to the image that the designer wants the element to be provided with. For example, in electronic encyclopaediae, the node metaphor for a concept could be suitable when consulting a concept, and the anchor metaphor could also be suitable when consulting a semantic net where the concept appears. On the other hand, the link metaphor doesn't seem suitable for any kind of representation we want for an encyclopaedic concept.
So, to facilitate HF integration, it is necessary -1- to provide the designer and/or user with hyperobjects of relevant characteristics/services and -2- to provide mechanisms to relate the hyperobjects with the application/domain elements they represent.
As regards -1-, it is clear that today there is no consensus about the most common hyperobjects and their characteristics/services, and we do not pretend to reach it here. Nevertheless, this way of integrating HF requires to have the possibility for the designer/user to create specialised hyperobjects that represent application/domain elements correctly. If the functionality is not adaptable and extensible, it will be difficult to use.
As concerns -2-, the relation between hyperobjects and elements is maintained thanks to reference systems and code. Reference systems allow the identification/definition of the elements and their association with hyperobjects, whereas the code allows to invoke characteristics/services of the hyperobjects and permits to echo changes over the elements, when working on hyperobjects with editing capabilities.
Hence, implementation of one application with integrated HF will be easier when using a tool that is suited to -1- and -2-, in the same way as the implementation of one application with real-time capabilities will be easier when using a real-time developing tool.
So, Madame consists of five different levels, each one responsible for a hypermedia functionality: the Hyperbase (HB), the Information Storage Level (ISL), the Presenter Level (PL), the Graphic Run-Time Level (GRTL) and the Hypermedia Level (HL).
The Hyperbase stores hyperspace topological information by means of components (nodes and links), anchors and specifiers as described in the Dexter's Storage Layer. The Information Storage Level stores the definition of the information contained in the components and may serve as an interface between Madame and the data of other applications. The Hypermedia Level provides navigation control functionality, the Presenter Level specifies the different ways in which the components may be presented during hyperspace traversal. Lastly, the Graphic Run-Time Level implements the different kind of presentations.
The Hyperbase and the Information Storage Levels supply structured data storage functionality; the former stores the hyperspace and the latter stores the information. The Presenter Level is in charge of presenting information and anchors; it consults the previous storage levels and requests the Graphic Run-Time Level instances to carry out the presentation. Through navigators, the Hypermedia Level is responsible for navigation, consults the Hyperbase to know about the components to be presented and manages creation (and also deletion) of presenters.
At the moment a prototype of Madame has been implemented on ADAM (Aberdeen DAta Model) an experimental OODBMS written in Prolog. This platform is very useful to rapid prototype and to improve the functional consistency of the different levels.
This case is typically an intra-application approach that results in an intra-application implementation. The design is basically hypermedia, therefore the application/domain elements and the hyperobjects generally constitute a unique design unit.
About Madame, ISL allows node content definition, HB allows application structural node definition and storage, and HL implements navigation and target identification techniques selected by the user, including navigation tools like history-track. In this project, the Madame functional levels have been the design base for the application (intra-application approach), which already includes HF in the first part of the development [Lopisteguy, 96].
This project is a typical situation of the extra-application approach with extra- application implementation. It is necessary to identify potentially linkable application/domain elements and interfaces presenting them, to define hyperobjects modelling those elements. Concerning information, the definition and management of anchors is particularly important to allow its integration, into the interface corresponding to the information it referred to, in a homogeneous way.
When using Madame [Filgueira, 95], most of the functionality from the GRTL is filled by application interfaces. So, it is necessary to adapt the application interface for anchor presentation management, and to communicate to the PL the user interactions with anchors. Then, the PL only has to invoke the corresponding application of the hyperobject-node to be presented. The ISL models potentially linkable application/domain elements, including integrity mechanisms between hyperobject contents and elements, the HB maintains all information about anchors and links, and the HL implements navigation control, with the navigator invoking applications through PL presenters. In this project, Madame is used as a link server and the integrated applications have to be extended for anchor definition and management.
In this case, we have an intra-application approach, because the design of HyperTutor has been based on the hypermedia paradigm, but the implementation is basically an extra-application. As each component preserves its own functionality, the Tutor Component does not manipulate or have any knowledge about hyperobjects.
Identified elements in the Tutor Component are divided into three groups: first, pedagogical concepts and relations that constitute the semantic network that models the domain to teach; second, tests that allow the Tutor Component to evaluate student learning; and, finally, the learner's learning process. From the semantic network of pedagogical concepts and relations we define the hyperspace of nodes and links along with additional sub-networks of nodes and links to document every concept. For every test a node is defined and for the solution and corresponding explanations, other nodes and specific links to relate them are added. Finally, the learner's learning process has associated a tutored navigation strategy.
In general, the relation between hyperobjects and the application elements are based on a reference mechanism as well as on computation, in order to get adaptation of the contents of the nodes (in more or less detail), of the hyperspace (nodes not always accessible) and of the evaluation of the learner (conditioned by previous navigation).
In Madame, both ISL as HB are specialized in reflecting the different and necessary hyperobjects as specific nodes for the tests or nodes with variable content to implement different detail levels. Presentation aspects do not change in terms of functionality, only for the exercises, with which user interactions are not only anchor selections; there are answers that need to be communicated to the tutor, via HL. The HL, on the other hand, has to be specialized to allow the relation between student navigation and his learning process within the tutor. For this reason, HL informs the tutor about learner navigation, and then the tutor diagnoses the corresponding visibility horizon. In this project, Madame is used as the base of the Hypermedia Component, implementing the HyperTutor interface.
We have also shown that 2 stages for HF integration have to be distinguished: approach (design of applications) and implementation (development). Therefore our HF integration methodology is based on the three following parts:
From our point of view, implementing an application integrating HF will be easier and easier if using a tool that allows us to define/specialize hyperobjects services and maintain element-hyperobject relationship. However it is still difficult to get good applications with HF today, as all the more it requires specialists in Software Engineering and HCI. But the objective of providing HF to every kind of applications is very ambitious. We certainly are aware conscious of the difficulties linked to such a wide objective but we are optimistic as to the outcome.
[Garg, 88] Garg P.K., "Abstraction mechanisms in Hypertext", Communications of the ACM, Vol.31 Num.7, July 1988.
[Halasz, 94] Halasz F., Schwarz M., "The Dexter Hypertext Reference Model", Communications of the ACM, Vol. 37, No. 2, February 1994.
[Lange, 90] Lange D.B., "A Formal Model of Hypertext", Proceedings of the Hypertext Standardization Workshop, January 1990.
[Lopisteguy, 96] Lopisteguy P., Losada B., Aizpurua J.M., "Etude d'une Structure Generale et d'une Interface de Consultation Hypermedia Pour Encyclopedies Electroniques", UPV/EHU/LSI/TR1-96, January 1996.
[Perez, 95] Perez T.A., Lopisteguy P., Gutierrez J., Usandizaga I., "HyperTutor: From Hypermedia to Intelligent Adaptive Hypermedia", Proceedings of EDMEDIA'95-AACE, Charlottesville - USA, August 1995.
[Usandizaga, 95] Usandizaga I., Lopisteguy P., Perez A., "Madame: An Object- Oriented Hypermedia Prototype", Proceedings of BIWIT'95, San Sebastian - Spain, July 1995.