4.2 Sistemas de representación hipermedia

El Diccionario de la Real Academia de la Lengua Española define hipertexto ³ como “texto que contiene elementos a partir de los cuales se puede acceder a otra información”. Intentaremos dar un modelo sencillo de hipertexto a través de esta definición. Supongamos que cada texto está contenido en una única página (de mayor o menor tamaño) y, si nos alejamos lo suficiente, podremos ver la página en su totalidad. Cada vez que seleccionamos un ancla, origen de un hiperenlace, accedemos a otra página, que también vemos en su totalidad. Si hacemos una navegación por distintas páginas, y cada vez que accedemos a una página distinta la mantenemos visible, tendremos, al final, un conjunto de páginas en la pantalla del ordenador. Si ahora marcamos con una flecha cada salto que dimos desde la página origen hasta llegar a la última página, tendremos un conjunto de páginas relacionadas mediante estas flechas; es decir, hemos obtenido una imagen que desde un punto de vista informático se puede modelar como un grafo dirigido que representa al hipertexto. Pues bien, la Máquina Abstracta de Hipertexto (MAH) (Campbell, 1988) caracteriza aplicaciones hipermedia a través de dichos grafos dirigidos.

El mayor problema de esta aproximación es que no es capaz de caracterizar navegaciones más avanzadas, donde sea posible visualizar en la misma ventana, o área de la pantalla, más de una página de contenidos, como por ejemplo sucede con los marcos o frames de HTML. Una ampliación al modelo de grafos la proporciona Tompa con su Modelo de Hipergrafos (Tompa, 1989) donde existe la posibilidad de tener varios nodos del grafo activos al mismo tiempo. El mayor inconveniente de este nuevo modelo es que el manejo del hipergrafo no está totalmente definido por la propia estructura de nodos y enlaces (como en la máquina abstracta de hipertexto), sino que recae en una serie de funciones de bajo nivel que programa la respuesta del hipergrafo a la selección de un ancla. Otra extensión posible a la máquina abstracta de hipertexto es utilizar una red de Petri para caracterizar hipertextos, como hace el Modelo Trellis (Stotts, 1989). La mayor ventaja de esta aproximación es que la semántica de navegación de la aplicación queda caracterizada por la red de Petri. El problema de esta caracterización es que lleva a diseños poco escalables y fuerza la interpretación de la navegación en la red de Petri, en vez de en el propio hipertexto.

Frente a la filosofía de los anteriores modelos, el Modelo Dexter (Halasz, 1994) presenta un punto de vista diferente. Ahora se intenta proporcionar una caracterización de muy alto nivel de las aplicaciones hipermedia, de tal forma que se proporciona un modelo de referencia con el que comparar otros modelos hipermedia concretos. Así, el modelo Dexter identifica tres grandes niveles dentro de toda aplicación hipermedia: el primer nivel es el de Composición Interna, formado por todos los contenidos que aparecen en una aplicación hipermedia, esto es, textos, imágenes y sonidos; el segundo nivel es el de Almacenamiento, o formado por el grafo resultante de añadir anclas a los elementos del nivel de composición interna y definir enlaces entre dichas anclas; finalmente, el tercer nivel es el de Ejecución, que representa a la propia aplicación hipermedia tras añadir especificaciones de presentación al nivel de almacenamiento. Todos los modelos hipermedia consideran el nivel de composición interna, ya que todos presentan contenidos al usuario. La capa de almacenamiento también está presente de manera más o menos explícita (mediante un grafo en la MAH, o mediante una red de Petri en el modelo Trellis). Finalmente, la capa de ejecución puede quedar recogida mediante especificaciones de presentación implícitas en la propia representación de la capa de almacenamiento (como en la MAH) o mediante especificaciones explícitas añadidas a dicha capa (como en el modelo de hipergrafos). Aunque fundamental para comprender la naturaleza de las aplicaciones hipermedia, el modelo Dexter mantiene un nivel de abstracción demasiado alto para ser utilizado como modelo de diseño.

El Modelo Ámsterdam (Hardman, 1994) representa un claro ejemplo de modelo creado según las directrices del modelo Dexter. Evolución del modelo multimedia CMIF (Hardman, 1994), el modelo Ámsterdam amplía las capacidades del modelo Dexter incluyendo un soporte explícito para las relaciones de sincronización y de contexto. Las relaciones de sincronización son fundamentales para presentaciones hipermedia con un alto contenido multimedia. Las relaciones de contexto definen el comportamiento de los elementos que tienen que ser presentados simultáneamente al usuario. A nuestro entender, Ámsterdam es el mejor modelo para representar aplicaciones hipermedia con fuertes relaciones de sincronización entre sus contenidos. El inconveniente es que las descripciones que utiliza para modelar la aplicación son demasiado específicas, dificultando implementaciones ajenas al sistema hipermedia que soporta al modelo.

Hasta ahora nos hemos preocupado por caracterizar aplicaciones hipermedia cuyos contenidos no presentaban a priori ninguna estructura reseñable pero, en la actualidad, existen multitud de contenidos que se organizan según el Modelo Relacional (Codd, 1970). Este modelo es el de mayor uso en el dominio de las bases de datos, dando lugar a las Bases de Datos Relacionales. Pudiera plantearse entonces la posibilidad de proporcionar un acceso hipertextual a las bases de datos relacionales. Modelos como RMDM (Relationship Management Data Model) (Isakowitz, 1995) o HDM (Hypertext Design Model) (Garzotto, 1993) utilizan las claves extranjeras que se encuentran definidas en las tablas relacionales para generar un grafo con los contenidos, obteniendo así caracterizaciones similares a la propuesta por la MAH. La principal diferencia entre RMDM y HDM es que este último permite definir entidades con mayor estructura que las entidades relacionales. Aunque ideales para proporcionar un acceso hipertextual a una base de datos relacional, en ambos casos el mayor problema que presentan estos modelos es la dificultad para describir estructuras de presentación avanzadas, así como su uso exclusivo sobre contenidos relacionales.

Un problema que no aborda ninguno de estos modelos de manera explícita es la respuesta a los eventos que pueden producirse en una aplicación hipermedia, más allá de la selección de un ancla. Modelos como Labyrinth (Díaz, 2001) o metodologías como OOHDM (Object-Oriented Hypermedia Design Meted) (Schwabe, 1996) se preocupan de caracterizar esta situación. La principal diferencia entre Labyrinth y OOHDM es que Labyrinth es un modelo clásico, mientras que OOHDM es una metodología que, a través de ocho diagramas, se preocupa de caracterizar el diseño de las aplicaciones hipermedia. La mayor ventaja de estos SRH es su capacidad para modelar aplicaciones hipermedia dinámicas (por ej. los contenidos y/o los enlaces entre estos se generan durante la navegación por la aplicación), y el mayor inconveniente es la dificultad para definir la semántica de navegación.

El modelo Pipe (Navarro, 2002) es un modelo que intenta compaginar las ventajas de modelos con semántica de navegación implícita (como la MAH o Trellis) junto con la posibilidad de caracterizar aplicaciones hipermedia dinámicas (como OOHDM o Labyrinth). Con este fin, Pipe organiza los contenidos mediante un Grafo de Contenidos. La interfaz gráfica de usuario queda caracterizada por el Esquema Navegacional. Ambos elementos, especificados de manera independiente, se relacionan a través de las Funciones de Canalización, que asignan contenidos a los elementos de la interfaz de usuario y canalizan (o interpretan) los enlaces de contenidos hasta el nivel de la interfaz de usuario. Finalmente, el modelo incluye una Semántica de Navegación capaz de caracterizar la respuesta del sistema hipermedia ante la selección de un enlace. La mayor ventaja de Pipe es su capacidad para caracterizar aplicaciones dinámicas, y para caracterizar, de forma independiente, los contenidos y la interfaz de usuario. El mayor inconveniente es su falta de capacidad para caracterizar eventos dinámicos más allá de la selección de un ancla.

Aunque existen otros SRH, en este capítulo hemos visto una selección bastante representativa. Como hemos podido comprobar, todos los SRH presentan ventajas e inconvenientes y por tanto, no podemos recomendar uno de ellos y desechar los demás. Cada uno es adecuado para una familia de aplicaciones hipermedia y, por ello, debe ser utilizado el que mejor se adecue a las necesidades de una aplicación concreta.

Notas

Índice general I Índice artículo I Siguiente