ESTÁNDARES Y ESPECIFICACIONES EN E-LEARNING

2.2.1. ¿Qué es un estándar y para qué sirve?

El diccionario de la Real Academia de la Lengua dice que un estándar es lo “que

sirve como tipo, modelo, norma, patrón o referencia”. En el campo técnico la
estandarización es el proceso por el cuál se establecen unas normas comúnmente
aceptadas que permiten la cooperación de diferentes empresas o instituciones sin
menoscabar su posibilidad de competir. Un estándar proporciona ventajas no sólo
a las empresas, si no también al usuario, ya que así no ve limitada su capacidad
de elección a un determinado proveedor, si no a todos aquellos que cumplen un
estándar determinado y que, por tanto, crean productos que son compatibles.

Un ejemplo es el de la electricidad casera, que en España y toda Europa es de

230 voltios y 50 hertzios de modo que un dispositivo eléctrico comprado en
cualquier país debería funcionar en otro. No obstante, esto no es tan sencillo ya
que las tomas de corriente o enchufes son físicamente diferentes entre los países
europeos, de modo que, probablemente, necesitaremos un sencillo adaptador
para que realmente funcione. Aún así el problema es menor que si intentamos
usar el dispositivo en EEUU, donde hará falta, además de un adaptador para el
enchufe, un transformador ya que su estándar de corriente eléctrica es de 125
voltios.

Existen dos tipos de estándares los oficiales o “de jure” y los “de facto”. Los
estándares oficiales son aquellos que han sido aprobados y sancionados por un
organismo oficial de estandarización, ya sea nacional (e.g. Asociación Española
de Normalización, AENOR en España) o internacional (e.g. Intenational Standards
Office). Estos estándares en algunos casos son de obligado cumplimiento como,
por ejemplo, que todas las páginas web oficiales deben cumplir un determinado
nivel de accesibilidad para discapacitados. Los estándares de facto son aquellos
que se usan por voluntad propia o conveniencia y tienen una amplia aceptación,
aunque no hayan sido sancionados por un organismo de estandarización. El caso
más conocido en Internet son las recomendaciones realizadas por el World Wide
Web Consortium (W3C), que crea las normas probablemente mas utilizadas en
Internet como, por ejemplo, el lenguaje HTML (y que en muchos casos después de
publicadas pasan a ser reconocidas como estándares formales).

2.2.2. Ventajas aportadas por los estándares en e-learning

En e-learning, una de las principales funciones de los estándares es servir como

facilitadores de la durabilidad y de la reutilización en el tiempo de los contenidos y
de la interoperabilidad, es decir, facilitar el intercambio de los contenidos entre
diversas plataformas y sistemas. Hay que evitar caer en el error de ver el estándar
como un limitador de la iniciativa o creatividad personal. En muchos casos, cuando
los educadores oyen la palabra estándar suelen tener una reacción adversa, ya
que tienden a considerar que es una norma de obligado cumplimiento que
coartará su creatividad respecto a la creación de nuevos cursos, o su forma
habitual de planificar una acción formativa o una clase. Otra circunstancia es
considerar que su uso es sólo en educación a distancia y que no son útiles para
otros planteamientos educativos. Esto no es cierto, ya que la existencia de
contenidos educativos reutilizables puede ser de gran ayuda para simplificar el
trabajo de los docentes, aunque lo utilicen en educación presencial o en un
formato mixto presencial-web (llamado blended learning o b-learning).

Existen multitud de ventajas asociadas a la utilización generalizada de estándares

de e-learning para todas las partes implicadas en el proceso de aprendizaje. Entre
ellas cabe mencionar las siguientes (Sun 2002):

 Desde el punto de vista del de los clientes o consumidores tanto

institucionales como individuales, los estándares evitan quedarse atrapado
por las tecnologías propietarias. Los costes se reducen al sustituir los
desarrollos propios por tecnología “plug and play” de modo que, por
ejemplo, una institución pueda cambiar de LMS sin tener que empezar
desde el principio perdiendo toda o gran parte de la información que ya
tenía en su LMS anterior.

 Desde el punto de vista de los vendedores de aplicaciones, la existencia de

métodos estandarizados de comunicación entre sistemas simplifica la
integración de diferentes productos. Esto redunda en una reducción de los
costes de desarrollo e incrementa el mercado potencial para las
aplicaciones.

 Desde el punto de vista de los productores de contenidos educativos, los

estándares permiten que el formato de producción sea único y pueda ser
utilizado en cualquier plataforma de distribución. Más aún, un mercado más
amplio para los contenidos educativos permite a los creadores realizar
inversiones en producción de contenidos, aumentando la oferta y la calidad
de éstos, incluso en áreas altamente especializadas. Además la existencia
de estándares facilita su labor, al tener acceso a almacenes de contenidos
reutilizables, y les permite la creación de contenidos modulares de más fácil
mantenimiento y actualización

 Desde el punto de vista de los alumnos, los estándares implican mayor

posibilidad de elección del producto educativo. Además implican que los
resultados de su aprendizaje (créditos o certificados) tengan mayor
portabilidad.

En otros trabajos se destacan las ventajas y propiedades beneficiosas que se

obtienen con la aplicación de los estándares (Masie 2003).

 Interoperabilidad. Que se pueda intercambiar y mezclar contenido de

múltiples fuentes y se pueda usar directamente en distintos sistemas. Que
 sistemas diferentes puedan comunicarse, intercambiar información e
interactuar de forma transparente.

 Reusabilidad. Que el contenido pueda ser agrupado, desagrupado y

reutilizado de forma rápida y sencilla. Que los objetos de contenido puedan
ensamblarse y utilizarse en un contexto distinto a aquél para el que fueron
inicialmente diseñados.

 Gestionabilidad. Que el sistema pueda obtener y trazar la información

adecuada sobre el usuario y el contenido.

 Accesibilidad. Que un usuario pueda acceder el contenido apropiado en el

momento justo y en el dispositivo correcto.

 Durabilidad. Que los consumidores no queden atrapados en una

tecnología propietaria de una determinada empresa. Que no haya que
hacer una inversión significativa para lograr la reutilización o la
interoperabilidad.

 Escalabilidad. Que las tecnologías puedan configurarse para aumentar la

funcionalidad de modo que se pueda dar servicio a más usuarios
respondiendo a las necesidades de la institución, y que esto no exija un
esfuerzo económico desproporcionado.

2.2.3. Organismos e instituciones que participan en los procesos de

estandarización en e-learning

Tener una idea clara del proceso de estandarización para las tecnologías e-
learning es una tarea compleja, debido al relativamente poco tiempo que se lleva
realizando el proceso y a la profusión de grupos, instituciones y consorcios que
trabajan en el tema. No obstante el escenario está mejorando, ya que cada vez
más se llegan a acuerdos de colaboración entre distintas iniciativas. Por tanto se
está cada vez más cerca de una estandarización real y que tenga un impacto
efectivo en la industria.

A continuación pasamos a presentar brevemente algunas de las iniciativas mas

importantes o que están teniendo una mayor repercusión.

Aviation Industry CBT Committee (AICC).

Este comité internacional para la enseñanza y entrenamiento utilizando

ordenadores en el campo de la industria de la aviación fue creado en 1998 para
estandarizar los productos de formación que se usan en aviación. La aviación es
un campo donde, desde el principio, las simulaciones y el software educativo han
tenido una gran importancia. Su objetivo es crear aplicaciones educativas que
sean eficientes, que tengan un coste razonable y que sean mantenibles a lo largo
del tiempo.
AICC publica recomendaciones en muchos aspectos del e-learning (incluido el
hardware), pero quizás la que ha tenido mayor impacto ha sido la recomendación
para interoperabilidad CMI (Computer-Managed Instruction). Es una especificación
sobre cómo crear contenido que se pueda comunicar con el mayor número de
sistemas LMS

Advanced Distributed Learning (ADL)

En Noviembre de 1997 el Departamento de Defensa de EE.UU. y la oficina de

Ciencia y Tecnología de la Casa Blanca lanzaron la iniciativa Advanced Distributed
Learning (ADL 2002). El propósito de ADL es desarrollar el e-learning para
asegurar el acceso a materiales educativos y de alta calidad que puedan ser
adaptados a las necesidades individuales y que se puedan distribuir de forma
sencilla. ADL surge como respuesta a las necesidades de uno de los mayores
consumidores de software del mundo, y forma parte del esfuerzo que el gobierno
norteamericano viene realizando con el objetivo de conseguir una enseñanza de
calidad, en el que también están implicados los departamentos de Educación y
Trabajo.

Figura 2.2.3.a. Colaboración entre los principales organismos de estandarización

(adaptado de CEN/ISSS LTO)

ADL se ha centrado desde un principio en el aprendizaje sobre la Web. Su trabajo

ha acompañado al de otras instituciones, para buscar puntos críticos del
aprendizaje sobre la Web en los que sería recomendable especificar interfaces
consensuadas. El ADL ha sido una de las organizaciones más activas en el
esfuerzo de la estandarización de las tecnologías de aprendizaje, en colaboración
con otras iniciativas principalmente IEEE, IMS y AICC. Su principal resultado es un
conjunto de especificaciones que, bajo la denominación Shareable Content Object
Reference Model(SCORM) (ADL SCORM, 2002, 2006) propone un modelo de
agregación de contenidos (Content Aggregation Model, CAM), un entorno de
tiempo de ejecución (Run-Time Environment, RTE) y la secuenciación y
navegación (Sequencing and Navigation, SN) de los contenidos. Actualmente
SCORM es la norma que está teniendo un mayor impacto en la industria, ya que
es la que se ha implementado en un mayor número de sistemas.

IMS Global Consortium

IMS Global Learning Consortium es un grupo independiente, sin ánimo de lucro

que inició su labor en 1997 impulsado por el NLII (National Learning Infrastructure
Initiative) que es una organización apoyada por Educase. Auque inicialmente
surgió como una iniciativa en EEUU, ahora en IMS participan instituciones
educativas de todo el mundo (desde universidades a pequeñas empresas de
formación), fabricantes, y vendedores de aplicaciones software para la educación.

Actualmente es el principal promotor y desarrollador de especificaciones abiertas

orientadas a la enseñanza electrónica. Su objetivo es que, a partir de estas
especificaciones, se consiga la interoperabilidad de aplicaciones y servicios en la
enseñanza electrónica para que los autores de contenidos y de entornos puedan
trabajar conjuntamente.

IMS tiene muchas especificaciones (actualmente tiene 16 especificaciones) ya que

cada una de ellas está enfocada en una necesidad distinta del proceso de
enseñanza. Hay especificaciones que se refieren a metadatos de los objetos
educativos, al formato de empaquetamiento y distribución de los cursos, a la
información del usuario, a la secuenciación de contenidos educativos, o incluso al
diseño de la actividad educativa en su conjunto.

European Committee for Standardization/Information Society

Standardization System (CEN/ISSS)

El comité europeo de normalización (Comité Europeen de Normalisation, CEN)

alberga un subcomité de sistemas de estandarización de la sociedad de la
información (Information Society Standardization System, ISSS), en el que está el
grupo de trabajo de tecnologías de aprendizaje (Learning Technologies Workshop,
CEN/ISSS/LT). Su principal objetivo es contribuir al éxito de la sociedad de la
información en Europa para, en colaboración con otras instituciones que crean
estándares o especificaciones, proporcionar un conjunto de servicios y productos
integrados y que presten una especial atención a la diversidad cultural europea.

Como resultado de su trabajo publican los acuerdos a los que se ha llegado en el

grupo de trabajo, por ejemplo, sobre internacionalización de los metadatos de los
objetos educativos, o sobre cómo expresar las competencias de los estudiantes.
También cabe destacar el observatorio de estándares en tecnologías de e-
learning, que recoge información sobre las principales iniciativas, organismos e
instituciones que realizan trabajos en este campo. Su página web está accesible
en http://www.cen-ltso.net/.

International Standards Organisation (ISO/IEC JTC1 SC36) y Asociación

Española de Normalización (AENOR)
 La organización internacional de estándares (International Standards Organisation,
ISO) es una red de institutos de normalización de más de 140 paises que trabaja
en colaboración con los gobiernos, empresas y organizaciones de usuarios. El
subcomité 36 de la ISO fue creado en 1999 (ISO/IEC JTC1
SC36 http://jtc1sc36.org/) con el objetivo de cubrir todos los aspectos relacionados
con la estandarización en el campo de las tecnologías de aprendizaje. Este comité
es conjunto de ISO con International Electrotechnical Commission.

En España, la institución española que participa en ISO es la Asociación Española

de Normalización AENOR que ha creado el subcomité técnico CTN71/SC36
“Tecnologías de la información para el aprendizaje”. Su misión es la
“Normalización de aplicaciones, productos, servicios y especificaciones
relacionados con las tecnologías educativas, formativas o de aprendizaje a nivel
individual, de organización o de grupo, con el fin de habilitar la interoperabilidad y
la reutilización de herramientas y recursos”. Actualmente tiene muy avanzado un
perfil de aplicación de LOM al caso español, que se pretende aprobar y publicar a
lo largo de 2007.

Institute for Electrical and Electronic Engineers Learning Technology

Standards Committee (IEEE LTSC)

El comité de estandarización de las tecnologías aplicadas al aprendizaje, Learning

Technologies Standarization Committee, perteneciente al Institute of Electrical and
Electronic Engineers (IEEE), cubre prácticamente todos los aspectos del
aprendizaje basado en ordenador. Su misión principal es desarrollar estándares
técnicos, prácticas recomendadas y guías para componentes software,
herramientas, tecnologías y métodos de diseño que faciliten el desarrollo,
implantación, mantenimiento e interoperabilidad de implementación de sistemas
educativos.

LTSC está organizado en subcomités que se encargan de áreas de trabajo

determinadas como la definición de la arquitectura de sistemas de e-learning o la
definición de metadatos para objetos educativos. En estos momentos el área de
mayor impacto es la relacionada con los metadatos de los recursos educativos, ya
que el estándar Learning Object Metadata (estándar IEEE 1484.12.1 – 2002) es el
estándar oficial que más se está utilizando actualmente en e-learning.

Alliance of Remote Instructional Distribution Networks for Europe (ARIADNE)

Es una fundación que surge a raíz de dos proyectos con financiación de la Unión Europea y que
está compuesta por miembros de la industria y de las instituciones educativas. La misión básica
de ARIADNE es permitir la mejora de la calidad del e-learning mediante el desarrollo de
herramientas y metodologías que permitan la compartición y reutilización de objetos de
aprendizaje.

Están desarrollando guías y recomendaciones para la aplicación de estándares, siendo muy

activos en aspectos como la indexación multilingüe y los almacenes o repositorios de objetos de
aprendizaje. Además han colaborado activamente en la elaboración del estándar LOM.

2.2.5. Dublin Core Metadata Initiative

Dublin Core es un foro abierto dedicado al desarrollo de estandares de metadatos de propósito

general enfocado principalmente a la localización y catalogación de recursos. Es una iniciativa
que tiene una amplia aceptación en otros campos, como los sistemas de información. En Agosto
de 1999 el Comité Asesor de Dublin Core (Dublin Core Advisory Committee, DCAC) creó el grupo
de trabajo sobre educación cuyo objetivo es el de desarrollar una propuesta que simplifique el uso
de metadatos de Dublin Core en la descripción de recursos educativos. El resultado principal ha
sido el Dublin Core Metadata Element Set (DCMES) que contiene 15 elementos y que puede ser
refinado para añadir una mayor riqueza a la descripción.

2.3. ESTANDARIZACIÓN: ASPECTOS Y PROCESOS

El éxito de un estándar radica en su nivel de aceptación, por lo que un grupo de estandarización

debe ser un organismo que se encargue de recopilar requisitos de múltiples fuentes y elabore con
ellos una especificación consensuada. La obtención de un estándar formal se consigue como
resultado de los esfuerzos combinados de numerosos organismos y consorcios que se agrupan
de acuerdo a tres niveles de trabajo (Figura 2.3.a):

 Nivel de especificación. En este primer paso del proceso, se trabaja en la elaboración de

recomendaciones basadas en el análisis de las necesidades de los propios participantes.
El objetivo es proponer la especificación elaborada a la comunidad e-learning, de modo
que se pueda experimentar, corregir y actualizar en función de las nuevas necesidades
detectadas.

Nivel de validación. En esta fase del proceso, se desarrollan nuevos productos que
incorporan las especificaciones elaboradas en el paso anterior, y se inician programas
piloto con el fin de valorar la efectividad y aplicabilidad de la especificación. Así mismo, se
crean modelos de referencia que muestran cómo las distintas especificaciones y
estándares pueden ensamblarse para integrar un sistema e-learning completo.

 Nivel de estandarización. Es el paso final de la elaboración. Las especificaciones que ya

han sido validadas, son retomadas por los organismos oficiales de estandarización, que se
encargan de realizar un último refinamiento, consolidación, clarificación de los requisitos
que satisfacen. Habitualmente también hay un proceso de acreditación para los productos
que cumplen un determinado estándar. Es importante distinguir entre la especificación (que
es un proceso de trabajo en evolución) y el estándar acreditado (que es mucho más
estable y, por tanto, menos propenso a cambios).

Figura 2.3.a Proceso de desarrollo de estándares (adaptado de Masie 2003)

Como todo el proceso de e-learning es muy complejo, implicando muchas herramientas y actores,
nos centramos inicialmente en la interoperabilidad de los cursos. Esta interoperabilidad consiste
en poder reutilizar de manera global los cursos o contenidos educativos entre distintos sistemas
de gestión de cursos o LMS. Por tanto son necesarios consensos sobre diversas características
relativas a estos contenidos educativos. Nosotros para simplificar y sistematizar el análisis hemos
identificado 8 capas sobre las que es necesario establecer estándares para lograr la total
interoperabilidad (Figura 2.3.b). En estas capas hemos destacado las iniciativas de
estandarización, especificación o formatos que nos parecen más prometedoras o tienen
actualmente una mayor aceptación:

Figura 2.3.b Esquema representativo de las capas y las iniciativas más relevantes
para llegar a la interoperabilidad de contenidos en e-learning
 La capa más baja hace referencia a aspectos puramente tecnológicos para
las que ya existen estándares aceptados. TCP/IP y HTTP son los
protocolos estándar de intercambio de información en Internet.

 La segunda capa trata de los formatos en los que se crean los contenidos
educativos. En este punto existe una gran variedad, de modo que en
general se acepta cualquier formato de contenido web que sea capaz de
visualizar un navegador (incluso si para ello necesita algún complemento o
plug-in). La realidad es que no existe aún un consenso claro sobre qué
lenguaje o formato utilizar. XML y HTML son los principales candidatos
actuales pero hay muchos sistemas que utilizan contenidos PDF por su
portabilidad y calidad de impresión, o Macromedia Flash por su capacidad
de animación o interacción.

 La tercera capa selecciona los mecanismos que se utilizarán para

representar los metadatos asocidos con los contenidos educativos. Los
metadatos son la información complementaria que se añade sobre los
objetos educativos y que describen distintos aspectos sobre su contenido,
sus objetivos didácticos, y facilitan los procesos de búsqueda, selección y
recuperación. XML es la tecnología más frecuente para crear los
metadatos, siendo considerada ya un estándar de facto para esta capa.
Entre las características que han convertido a XML en la tecnología más
utilizada, vale la pena destacar: la validación automática de documentos, la
separación entre contenido y procesamiento, y la independencia de
 herramientas o plataformas concretas. No obstante, con el desarrollo de la
web semántica, hay iniciativas para hacer dicha descripción utilizando RDF,
ya que estas nuevas tecnologías facilitan el desarrollo de aplicaciones
informáticas que traten e interpreten de manera automática dicha
metainformación.

 En la cuarta capa, los esquemas de metadatos, se determina qué

información es relevante para los objetivos del modelo, se agrupa de
acuerdo a una serie de categorías, que por lo general tienen carácter
jerárquico, y por último, se adjunta al objeto como metadatos
(implementados habitualmente con XML). El principal estándar ya aprobado
de IEEE es el esquema de metadatos LOM (Learning Object Metadata) que
se ocupa de estos aspectos.

 Las capas quinta y sexta hacen referencia a la necesidad de estructurar los

objetos en unidades superiores de contenido (los cursos) y asegurar su
portabilidad a través de la red en forma de fichero, aportando toda la
información para que sea posible su reconstrucción exacta en el sistema
destinatario. La séptima capa busca la homogeneidad en la estructuración
de los perfiles de aquellos implicados en el proceso de enseñanza y en la
forma de utilizar didácticamente los recursos educativos. Por último, la capa
de nivel superior aborda los aspectos de adecuación lingüística, cultural y
social a distintos contextos. Esta última capa tiene un gran nivel de
dificultad, y todavía no hay trabajos significativos al respecto.

Respecto a los propios sistemas de gestión del aprendizaje, los estándares

proporcionan un modelo arquitectónico coherente, en el cuál se pueden integrar
distintas soluciones o programas y se pueden realizar evoluciones y
actualizaciones de forma controlada y además se proporciona un mercado abierto
en el que los usuarios pueden elegir el LMS deseado o incluso cambiarlo con un
mínimo riesgo y coste.

2.4. OBJETOS DE APRENDIZAJE

Analicemos, por tanto, con más detalle el elemento central en la nueva forma de
desarrollar los cursos que es el objeto de aprendizaje. Vamos a analizar que se
entiende por objeto de aprendizaje.

La definición más citada en la literatura es la de IEEE, propuesta en uno de los

pocos estándares relacionados con e-learning que han sido aprobados. Este es
LOM, en el que se define un objeto de aprendizaje como “cualquier entidad, digital
o no digital, que puede ser utilizada, para el aprendizaje, la educación o el
entrenamiento”.Esta es una definición excesivamente genérica y que ha hecho
que se proporcionen otras definiciones mas específicas como la de Wiley (2000):
“cualquier recurso digital que pueda ser reutilizado como soporte para el
aprendizaje”. Wiley también matiza que se usa para designar material educativo
diseñado y creado en pequeñas unidades con el propósito de maximizar el
número de situaciones educativas en las que se puede utilizar dicho recurso. Esta
idea está directamente recogida en la definición proporcionada por Polsani (2003)
que lo define como “unidad didáctica de contenido, autocontenida e independiente,
predispuesta para su reutilización en múltiples contextos instruccionales”.

Figura 2.4.a. Esquema del proceso de e-learning utilizando objetos de aprendizaje

(Adaptado de Eduworks)

En realidad IEEE actualmente ha redefinido ligeramente el concepto de objeto de

aprendizaje como cualquier entidad digital o no digital que puede ser usada,
reutilizada o referenciada durante un proceso de aprendizaje apoyado por la
tecnología. Ahora le da más importancia al soporte tecnológico, entre los que
destacan los LMS, y además se proporcionan como posibles ejemplos de objetos
de aprendizaje contenidos multimedia, contenido instruccional, objetivos de
aprendizaje o programas instruccionales.

El objetivo es que los cursos se puedan crear por agregación de estos objetos de
aprendizaje (Figura 2.4.a). El conjunto de especificaciones y estándares de e-
learnign pretenden facilitar todos los procesos asociados para que se puedan
hacer de forma eficiente y sistemática. Con este propósito se trata de normar
aspectos como la descripción (mediante metadatos) de los objetos de aprendizaje,
de modo que puedan ser gestionados, indexados y clasificados de forma eficiente;
su almacenamiento en catálogos o bases de datos (que habitualmente se
denominan mediante el anglicismo repositorios) o la descripción de un curso
completo. Los estándares por tanto facilitan fundamentalmente la reutilización y la
interoperabilidad, ya que permiten el intercambio directo de objetos de aprendizaje
y de cursos completos entre distintos sistemas de enseñanza electrónica (Figura
2.4.b). Por otro lado, los objetos de aprendizaje no presuponen ningún tipo de
filosofía educativa determinada, y aunque se han utilizado mayormente siguiendo
un enfoque instruccional, también se pueden utilizar en sistemas que utilicen otros
paradigmas (e.g. constructivista). Tampoco implica que se puedan utilizar
únicamente en educación a distancia ya que simplifican procesos como la
reutilización y la integración de contenidos de modo que pueden ayudar a los
profesores en otros modos de educación (e.g. semipresencial o apoyo a la
docencia presencial).

Figura 2.4.b Curso de sobre Photoshop proporcionado por ADL/SCORM

(http://www.adlnet.org/downloads/62.cfm) para probar la reutilización de
contenidos. Se puede importar directamente en cualquier sistema que sea
compatible con IMS o con SCORM. En este caso se ha importado en el sistema
<e-Aula> desarrollado por el grupo de e-learning de la Faculta de Informática, de
la Universidad Complutense de Madrid.

No obstante aunque los OA suponen un gran avance hacia la sistematización del

desarrollo de cursos existen, diversos problemas no totalmente resueltos. Por
ejemplo hay una falta de consenso sobre la definición concreta y la descripción de
los objetos de aprendizaje, así como sobre su tamaño (granularidad). De hecho,
muchos de los almacenes de recursos educativos no siguen ningún estándar y
presentan contenidos muy diversos (páginas de contenido, fotos, cursos, libros
electrónicos, etc). También es necesaria más experiencia en el aspecto de
reutilizar dichos OA, ya que su combinación no es tan directa como cabría desear,
ni actualmente existen herramientas que simplifiquen dicho proceso sin necesidad
de tener un profundo conocimiento, ni tecnológico, ni de los estándares.

2.5. PERFILES DE APLICACIÓN

Ningún estándar puede cubrir todas y cada una de las necesidades que la gran
diversidad de aplicaciones y contextos educativos exigen. Más bien ahora se
considera que estas especificaciones son un marco general de interoperabilidad
que proporcionan un margen de adaptación a las necesidades concretas de cada
dominio o aplicación.

Un perfil de aplicación (en inglés application profile) es una colección de

estándares, especificaciones y guías de buenas prácticas que se combinan,
adaptan y particularizan para su mejor aplicación en una determinada comunidad
o en un determinado dominio. Inicialmente esto podría parecer contradictorio con
el concepto de estandarización, pero no es así, ya que en muchos casos hay
aspectos muy concretos que, por generalidad, el estándar deja sin fijar y que
dificultan su implementación o aplicación final. Por ejemplo, el perfil puede fijar qué
campos de la descripción mediante metadatos tendrán que estar siempre
presentes, aunque en el estándar sean opcionales, o proporcionar un vocabulario
controlado para rellenar un campo descriptivo cuando en el estándar no se prefijan
valores para dicho campo. En otros casos, se puede considerar que el estándar es
demasiado amplio y que limitar dicha amplitud puede simplificar la aplicación
efectiva en un determinado campo. Por ejemplo, el perfil de aplicación CanCore
utiliza sólo un subconjunto de los metadatos definidos en LOM para la descripción
de objetos de aprendizaje.

De hecho la importancia de los perfiles de aplicación ha hecho que IMS publique

una nueva especificación denominada Application Profile Guidelines, en la que se
describe que es lo que IMS entiende por perfil de aplicación, los beneficios que se
obtienen y los pasos para realizarlo. Esta especificación refleja la experiencia
previa obtenida por los usuarios en el desarrollo de otros perfiles, y da consejos
sobre como realizar el proceso.

2.6. LIMITACIONES DE LOS ESTÁNDARES

Los estándares no cubren todos los aspectos de los sistemas de e-learning.

Aunque es cierto que ayudan en gran manera a la interoperabilidad, integración y
reutilización de información hay otros muchos aspectos que no están
contemplados en los estándares. Idealmente si hubiera estándares para todos los
procesos e informaciones incluidas en un sistema de e-learning, sería posible
cambiar de un LMS a otro diferente pero que estuviera desarrollado de acuerdo al
mismo conjunto de estándares, sin perder información y sin tener que hacer una
gran inversión.

Lamentablemente esta situación todavía no se ha alcanzado. Aspectos como la

interoperabilidad de contenidos, la búsqueda, localización y reutilización de
objetos de aprendizaje o la importación o exportación de evaluaciones ya
comienzan a estar maduros, de modo que hay herramientas de autoría y LMS que
lo soportan. Sin embargo hay muchos otros aspectos que también son muy
importantes en la enseñanza on-line, y que no están suficientemente resueltos.
Por ejemplo, hay cursos donde las contribuciones más valiosas se encuentran, no
tanto en los contenidos iniciales, como en las aportaciones realizadas por los
propios estudiantes en los foros de discusión. En un cambio de plataforma, esos
contenidos se perderían o no serian fáciles de integrar en el nuevo LMS.

En general los estándares no dan hoy en día una adecuada respuesta a aspectos
que cada vez son más importantes en e-learning, como son los sistemas de
colaboración o cooperación entre usuarios. Los LMS actuales incorporan nuevas
herramientas, como por ejemplo sistemas de edición colaborativa como
los wikis(1), que se gestionan con sus propios formatos, y sin que de momento
aparezcan claramente en el objetivo de ningún organismo de estandarización. Hay
otros autores que son más críticos con los estándares porque dicen que este es
un enfoque demasiado centralizado que va contra el espíritu de Internet, y que no
tiene en cuenta el desarrollo no regulado de información que está teniendo gran
éxito en la red, como son los cuadernos de bitácora (blogs) o la sindicación de
noticias mediante RSS o Atom.

ESPECIFICACIONES Y ESTÁNDARES MÁS UTILIZADOS EN E-

LEARNING

Como se ha mostrado en el capítulo anterior hay un gran número de iniciativas de

estandarización de modo que no es muy realista tratar de hacer una descripción
completa de todas ellas en este trabajo. Además existen relaciones entre las
especificaciones realizadas por diferentes grupos que a veces se solapan, y otras
son simplemente adaptaciones o perfiles de aplicación para adaptarse a un campo
o uso específico.

Nosotros consideramos que actualmente IMS (Global Learning Consortium, Inc)

es el principal promotor y desarrollador de especificaciones abiertas, y que cubren
más aspectos de la enseñanza electrónica. Este trabajo, conjuntamente con el
desarrollado por ADL en su modelo de referencia SCORM, y por IEEE LTSC con
su propuesta de metadatos para objetos de aprendizaje, son los que están
teniendo una mayor repercusión en e-learning. De hecho es especialmente
interesante analizar las propuestas de IMS, ya que su amplio número de
colaboraciones con otras entidades, y especialmente con IEEE LTSC, hace muy
previsible que sus especificaciones sean la base para nuevos estándares (e.g.
definición de competencias).

Es importante volver a destacar que la estandarización no tiene importancia

únicamente en educación que utilice la web como único medio de distribución, ya
que está influyendo en otros tipos de educación. Por ejemplo los contenidos
desarrollados para clases presenciales se están empaquetando como cursos para
simplificar su distribución y reutilización. En el otro sentido, contenidos
desarrollados para cursos en línea se están reutilizando en clases presenciales, ya
que es más sencillo su localización y uso.

Por tanto, en este capítulo pasamos a hacer una breve descripción de estas
especificaciones de modo que el lector pueda tener una idea de conjunto del
proceso de estandarización. Las especificaciones mas utilizadas hoy en día se
desarrollaran con más detalle en capítulos posteriores.

3.1. ESPECIFICACIONES DE IMS

El objetivo de IMS de definir especificaciones que hagan posible la

interoperabilidad de aplicaciones y servicios de enseñanza distribuida, se ha
concretado, a día de hoy, en más de 15 especificaciones principales.

3.1.1. Estructura de las especificaciones de IMS

Normalmente cada una de ellas se encuentra detallada al menos en tres

documentos:

1. Guía de Implementación y consejos. En él se incluyen: la forma de uso de

la especificación, ejemplos, la relación con otras especificaciones, y
cualquier tipo de información complementaria que pueda servir de ayuda.
Normalmente es el documento que se recomienda leer primero para
entender los conceptos generales con los que se trata.

2.

3. Modelo de Información. Documento que describe de manera formal, los

datos así como su estructuración, detallando cada uno de los elementos
considerados en la especificación. El modelo que se propone en este
documento es independiente del formato físico en el que finalmente se
representa la información.

4.

5. Documento de Enlace. Documento que ofrece la forma de representar la

estructura de datos de la especificación, generalmente, en XML.
Adicionalmente se proporciona el esquema documental XML que nos
permite comprobar la validez de la estructura de un documento que
hayamos creado, respecto a la especificación a la que está asociado.
IMS tiene muchas especificaciones ya que cada una de ellas está enfocada en
una necesidad distinta del proceso de enseñanza. A continuación vamos a
describir con más detalle algunas de las más relevantes.

3.1.2. IMS Content Packaging

El objetivo de esta especificación es permitir la distribución de contenidos

reutilizables e intercambiables, es decir, describe el modo en el que se debe
empaquetar el contenido educativo para que pueda ser procesado por otro
sistema LMS diferente. Ofrece una forma de empaquetar (en un archivo
comprimido tipo .zip) los contenidos educativos tales como cursos individuales,
conjuntos de cursos, o cualquier tipo de recurso necesario en el proceso educativo
(por ejemplo, evaluaciones o exámenes). Al distribuir una serie de contenidos
empaquetados según el Content Packaging de IMS, existe un documento
fundamental que es el Manifiesto. Dicho documento es un fichero XML en el que
se describe la estructura de los contenidos incluidos en el paquete (Figura
3.1.2.a). Dicha descripción se realiza a dos niveles diferentes:

 Por un lado, se describe cada uno de los Recursos del paquete. En una
primera aproximación se puede hacer una relación casi directa entre un
Recurso y un fichero con contenidos visualizables (e.g. un Objeto de
Aprendizaje) como pueden ser ficheros HTML, animaciones en Flash, etc.
En realidad, en cada Recurso se puede incluir información sobre los
ficheros que componen dicho Recurso, el tipo de los mismos (que puede
ser uno de los tipos ya definidos por el estándar o una extensión de los
propuestos) y, opcionalmente, metadatos con información adicional sobre
dicho Recurso.

 Por otro lado, en el Manifiesto se describe como están organizados dichos

Recursos, es decir, como se estructura el contenido del paquete. Esto se
implementa mediante las Organizaciones. Una organización es una vista (o
recorrido) de una posible ordenación jerárquica (actualmente en forma de
árbol) de los Recursosde un paquete. El estándar permite que un Manifiesto
contenga distintas organizaciones sobre los Recursosdel paquete, dando
así lugar a distintas vistas o “cursos” a partir de los mismos contenidos. El
elemento básico de estructuración que se usa al definir las organizaciones
son los Ítems. A cada Ítem se le puede asociar un Recurso, de modo que el
árbol de Ítems es, efectivamente, una estructuración de los Recursos del
paquete.

Figura 3.1.2.a Esquema de un manifiesto.

En resumen, el Manifiesto es un fichero XML que describe y organiza los
contenidos de un paquete, añadiendo información adicional en forma de
metadatos que pueden ser procesados y aprovechados en tareas de catalogación
de contenidos (Figura 3.1.2.b).

Figura 3.1.2.b Manifiesto XML en formato IMS (simplificado) de un curso de

programación del Campus Virtual de la Universidad Complutense creado con el
LMS WebCT en el que los objetos de aprendizaje son archivos en formato PDF.
Finalmente, para la distribución e intercambio efectivo de los cursos, lo que se
crea es un Archivo de Intercambio de Paquetes (Package Interchange File, o
simplemente PIF). El “PIF” es un archivo que alberga en su interior el manifiesto y
los recursos que se referencian en dicho manifiesto. Por tanto, podemos decir que
es un paquete comprimido y con un formato de intercambio en formato .zip (Figura
3.1.2.c ). La funcionalidad de exportación a PIF o de importación de un PIF se
encuentra en muchos de los LMS tanto comerciales (e.g. WebCT) como de
software libre (v.g. Moodle, .LRN, Dokeos, Claroline).

Figura 3.1.2.c Fichero comprimido con el manifiesto y la carpeta de contenidos del

curso de programación

IMS Question & Test Interoperability Specification

Esta especificación contempla una estructura básica que describe la forma de

representar preguntas individuales o ítems (assesment item) y gestionar
evaluaciones o exámenes completos (assessment). Su objetivo es conseguir que
tanto las evaluaciones cómo los resultados sean intercambiables entre los
diferentes LMS. Así, podemos disponer de almacenes de preguntas y bases de
datos con los resultados obtenidos por los alumnos a los que cualquier sistema de
enseñanza electrónica podrá acceder.

Con este propósito se plantea y se documenta un formato de contenido para

almacenar las preguntas o ítems independientemente del sistema o herramienta
de autoría utilizada para crearlas. Esto permite, por ejemplo, el uso de las mismas
preguntas en diversos LMS o en sistemas de evaluación electrónica, o la
integración en un único LMS de preguntas o exámenes desarrollados con distintas
herramientas. Por otro lado se propone un sistema coherente para que los
sistemas puedan informar de cuál es el resultado de una evaluación.

Figura 3.1.3.a Editor de preguntas QTI (version 1.2) desarrollado en el proyecto

<e-Aula> en la Universidad Complutense de Madrid. En este caso se ha definido
una pregunta de respuesta múltiple y con 2 respuestas correctas y además se ha
determinado que en cada presentación de las respuestas se “barajen” para que no
representen siempre en el mismo orden

Un item incluye la pregunta que se presenta al usuario y puede incluir otra

información necesaria para el procesamiento de la respuesta o puntuación,
retroalimentación instantánea o consejos para su realización, y otros mecanismos
para mejorar el examen y/o la evaluación (Figura 3.1.3.a). QTI trata de ser
pedagógicamente neutral y proporciona un gran conjunto de preguntas que
habitualmente se utilizan en las evaluaciones, tales como elección
verdadero/falso, elección múltiple con respuesta única, elección múltiple con
varias respuestas válidas, rellenar campos en blanco, ordenar objetos, relacionar
objetos, etc. Además permite definir nuevos tipos de preguntas si fuera necesario.
Las preguntas se agrupan en secciones, que a su vez se agrupan para formar una
evaluación o examen. Una evaluación, examen o test es una colección de
secciones que agrupan items y que además contiene información sobre cómo
secuenciar los ítems (presentación secuencial o se “barajan” las preguntas antes
de presentarlas) y como combinar sus evaluaciones individuales para obtener la
evaluación final. Esto permite, por ejemplo, definir cuál es el número de preguntas
que se deben responder correctamente para que el examen se considere
aprobado.

En la especificación de QTI se ha producido un gran cambio entre la versión

anterior la 1.2 y la versión final 2.0, ya que en ésta última se ha tratado de
sistematizar más los exámenes, evitando muchas de las dificultades de
interpretación y tecnológicas que existían en la versión anterior. Por ejemplo, la
versión 2.0 se ha centrado en simplificar el aspecto más conflictivo en las
especificaciones anteriores, que es el concepto de item o pregunta individual,
dejando inalterados aspectos como la agrupación de preguntas en secciones o
exámenes, que estaban claramente definidas en la versión 1.2.

Mientras que en versiones anteriores se centraba principalmente en cómo se

presentaba finalmente la pregunta, ahora se definen los posibles tipo de
interacciones por parte del usuario (e.g. seleccionar uno o más elementos de una
lista, crear asociaciones entre elementos de dos listas, introducir texto, seleccionar
un trozo de texto de un texto mas largo, etc). Además de todas las interacciones
contempladas, introduce un tipo de interacción propio para poder extender el
modelo y crear nuevas formas de interacción para poder introducir nuevos tipo de
preguntas. También tiene plantillas de preguntas para crear preguntas similares,
pero en las que hay partes variables que se seleccionan aleatoriamente entre un
conjunto de valores predefinidos. Otra de las novedades que introduce son los
ítems adaptativos, que permite su corrección adaptativa en función de una
secuencia de intentos. Esto permite, por ejemplo, que el alumno pueda alterar su
respuesta debido a la realimentación, o que se le planteen preguntas adicionales
en función de su respuesta actual.

Figura 3.1.3.b Aplicación Comprueba de la Universidad Complutense de Madrid.

En este caso se presenta una pregunta para la asignatura dibujo técnico.
QTI permite la construcción de almacenes o repositorios de preguntas que sean
directamente utilizables en distintos sistemas (e incluso para crear exámenes tipo
test que los alumnos realicen por escrito). Esto puede ser muy útil cuando se
generalice la representación mediante QTI de los repositorios de libre acceso
existentes. Por ejemplo, en la Universidad Complutense se dispone de una
aplicación dedicada, llamada Comprueba (Figura 3.1.3.b ), que tiene un extenso
conjunto de preguntas de distintas materias para que alumnos de enseñanzas
medias preparen su prueba de acceso a la universidad (accesible
en http://alamo.sim.ucm.es/comprueba/intro.htm ). La generalización de este tipo
de almacenes y su libre disposición en formato compatible con otras plataformas
puede simplificar mucho la creación de evaluaciones y exámenes por parte de los
docentes. Además de LMS comerciales que soportan el formato y la importación
de preguntas, también hay LMS de software libre que soportan dicho formato y
que permiten incluso exportar las evaluaciones del sistema en formato QTI (v.g.
Claroline, Moodle).

3.1.4. IMS Learning Design

Esta especificación ha sido el resultado de la integración dentro de IMS de la

especificación Educational Modeling Language (lenguaje de modelado
educacional) (Koper 2001), desarrollada inicialmente en la Universidad Abierta de
Holanda. Se ocupa de describir y codificar el diseño pedagógico, es decir las
metodologías educativas implícitas en un proceso de enseñanza, de forma que
sean procesables por un LMS. En este caso se utiliza un nuevo concepto,
la unidad de aprendizaje (UdA), ya que se considera que lo importante no son
tanto los objetos de aprendizaje por sí mismos, si no las actividades en las que se
encuentran implicados.
El elemento clave de una Unidad de Aprendizaje es la actividad o tarea, que se
concibe como uno o más actores (e.g. alumnos, profesores) que trabajan para
lograr un cierto objetivo educativo en un determinado entorno. El entorno contiene
los recursos y los servicios necesarios para realizar la actividad propuesta. El
principio subyacente es que los alumnos aprenden realizando actividades en un
entorno, en el cual los objetos de aprendizaje son recursos que permiten o facilitan
la tarea. La visión es más amplia que la de los objetos de aprendizaje básicos, ya
que se contempla el uso de herramientas o de procesos, como la comunicación
entre alumnos o entre alumnos y profesores. De hecho el rol o papel de un alumno
podría cambiar en un determinado momento, por ejemplo, para supervisar el
trabajo realizado por otros alumnos. La unidad de aprendizaje es la nueva unidad
mínima de intercambio entre sistemas, ya que se considera que si se descompone
en sus elementos básicos se pierde el diseño pedagógico que permite alcanzar el
resultado deseado.

3.1.5. IMS Learner Information Package Specification

Especificación que nos indica qué información se almacena referente a un alumno

(o grupo de alumnos) o incluso a un productor de contenido educativo, y cómo
debe almacenarse. El objetivo de esta especificación es definir una estructura que
permita el intercambio de paquetes con información relativa a cualquiera de los
implicados en el sistema de enseñanza.

La existencia de formatos consensuados para la definición de expedientes de

alumnos permite su exportación entre sistemas educativos heterogéneos. Es
necesario decidir qué información debe incluirse en el expediente y el formato para
representarla. Dentro de los estándares para perfiles y expedientes debe
contemplarse tanto la información estática (no depende de la interacción con el
sistema, v.g.. datos personales) como la dinámica (aquella que se genera o se
modifica a medida que el alumno avanza en su proceso de aprendizaje, ej.
calificaciones). LIP incluye la información de otra especificación sobre información
de alumnos denominada Personal and Private Information (PAPI) de IEEE, y que
en la actualidad está siendo revisada por ISO considerando la posibilidad de pasar
a ser estándar oficial. Esta especificación está complementada por otra
denominada Accessibility for LIP. que define nuevas estructuras de datos para
poder especificar preferencias de accesibilidad que tengan en cuenta las
características del alumno (v.g. alumnos con discapacidades) de modo que el LMS
se pueda adaptar a dichas características (v.g. modificando la presentación en
forma sonora si tiene dificultades visuales).

Otras especificaciones de IMS

Hay otras especificaciones de IMS que describiremos de modo más breve:

 Definición e intercambio de vocabulario. IMS VDEX (Vocabulary

Definition and Exchange) define una gramática para el intercambio de listas
de valores o vocabularios, que puedan ser procesables automáticamente y
 entendibles por las personas. Permite por ejemplo definir valores para ser
utilizados en IEEE LOM, IMS LIP o en ADL/SCORM.

 Secuenciación de los contenidos educativos. La especificación Simple

Sequencing (IMS SS 2002) se ocupa de la definición de mecanismos que
permitan la secuenciación de los recursos educativos dentro de cualquier
sistema e-learning que lo implemente. El objetivo es poder definir, por
ejemplo, el orden en el que se presentan los objetos de aprendizaje o las
reglas para seleccionar un objeto de aprendizaje entre varios posibles en
función del comportamiento o de las respuestas del alumno.

 Interoperabilidad entre repositorios digitales. La especificación Digital

Repositories tiene como objetivo la elaboración de recomendaciones que
permitan la interoperabilidad entre diferentes repositorios digitales. El
propósito es poder acceder a cualquier almacén de recursos educativos
para obtener dichos recursos sin necesidad de conocer cuál es la
organización o estructura de dicho almacén. En esta recuperación, los
metadatos son el elemento principal para la identificación de los recursos.

 Descripción de sistemas basados en competencias. La especificación

Reusable Competencies Definition tiene como objetivo definir una
nomenclatura estándar para etiquetar las distintas componentes de un
sistema de competencias. Estas competencias pueden formar parte de los
prerrequisitos o de los objetivos educativos de una actividad formativa.
Además debe permitir el intercambio de datos con sistemas de gestión
académica o de recursos humanos. Esta especificación está siendo
utilizada por IEEE LTSC para crear un estándar formal sobre especificación
de competencias.

 El modelo de información empresarial. IMS Enterprise Information Model

define modelos de datos que permiten la integración y el intercambio de
datos de los LMS con los otros sistemas de gestión de una empresa o
centro educativo como, por ejemplo, la gestión de estudiantes o la
administración general.Servicios de empresa. La especificación Enterprise
Services es la definición de cómo los sistemas gestionan el intercambio de
información que describe personas, grupos y membresías en el contexto
del aprendizaje desde el punto de vista organizativo y no educativo, como
en el caso de IMS LIP.

 Portfolio. El portfolio electrónico o e-portfolio es una colección de

documentos en formato electrónico que dan idea de las habilidades,
formación y desarrollo profesional de una persona. El concepto en el que se
basa es el mismo que cuando se quiere juzgar la calidad de un fotógrafo y
se le pide que enseñe sus trabajos previos. Esta especificación se ha
creado para hacer que los portfolios electrónicos se puedan intercambiar
entre distintas instituciones y sistemas. El objetivo es lograr que se pueda
hacer un mejor seguimiento de las competencias de un alumno, que se
 mejore su impresión del proceso educativo y su desarrollo personal incluso
en formación continua o no reglada. Esto debería simplificar el intercambio
de portfolios entre las instituciones educativas y los centros de trabajo.

 Estado persistente y compartible. La especificación Shareable State

Persistence describe una extensión a los entornos de ejecución (e.g.
SCORM) que permite el almacenamiento y el acceso compartido a la
información de estado entre los objetos de contenido. Trata de solucionar el
problema de que un contenido pueda almacenar información de estado en
el entorno de ejecución para que pueda ser recuperada posteriormente por
ese contenido o por otro. Esta característica es crucial para la ejecución de
contenido altamente interactivo como, por ejemplo, las simulaciones y hasta
ahora se estaba realizando con métodos y formatos propietarios,
dificultando la estandarización completa de los sistemas.

 Interoperabilidad de listas de recursos. La especificación Resource List

Interoperability (RLI) detalla como intercambiar metadatos estructurados
entre sistema que almacenan y proporcionan recursos con el propósito de
crear listas de recursos y aquellos sistemas que recogen y organizan estas
listas de recursos con un propósito educativo o de entrenamiento. Un
ejemplo típico citado en la especificación como lista de recursos es una lista
de trabajos o artículos para que lean los estudiantes durante un curso.

 Metadatos de acceso para todos. La especificación AccessForAll Meta-

data pretende posibilitar la identificación de recursos que coincidan con las
preferencias o necesidades de los usuarios. Las necesidades o
preferencias deberían declararse utilizando IMS Accesibility for LIP. Estas
preferencias incluyen la necesidad de utilizar presentaciones alternativas de
los recursos, métodos alternativos para controlar recursos, recursos
alternativos a los predeterminados y mejoras o necesidades de ayuda que
tenga el usuario. Esta especificación proporciona un lenguaje común para
identificar y describir los recursos primarios o por defecto, y las alternativas
equivalentes para dicho recurso.

3.2. IEEE LEARNING OBJECT METADATA / IMS LEARNING RESOURCE

METADATA SPECIFICATION (VERSIÓN 1.3 PUBLIC DRAFT)

Los metadatos proporcionan descripciones, propiedades e información sobre los

objetos de aprendizaje que permiten caracterizarlos, de forma que se simplifica su
uso y gestión. De forma coloquial, lo que se busca mediante esta información
complementaria es poder saber cuál es el contenido y el propósito de un OA sin
tener que acceder a dicho contenido. Por tanto, los metadatos aportan información
orientada a hacer más eficiente la búsqueda y utilización de los recursos. Los
metadatos se pueden aplicar tanto a OA concretos como a cursos completos o a
partes del curso (como se puede ver en el esquema del manifiesto de la (Figura
3.1.2.a).
Actualmente LOM (IEEE Learning Object Meta-Data) es el estándar de e-learning
formalmente aprobado que goza de mayor aceptación (estándar IEEE 1484.12.1 –
2002), y que ha sido adoptado en la especificación de IMS Learning Resorce
Metadata. De hecho LOM se basa en los esfuerzos previos hechos para la
descripción de recursos educativos en los proyectos ARIADNE, IMS y Dublin Core.

El objetivo de LOM es la creación de descripciones estructuradas de recursos

educativos. Su modelo de datos especifica qué aspectos de un objeto de
aprendizaje deberían ser descritos y qué vocabularios se pueden utilizar en dicha
descripción.

Esta es una descripción jerárquica con nueve apartados principales que agrupan
el resto de campos. A continuación describimos cada una de estas categorías:

 General. Aquí se describe el objeto educativo. Incluye campos como

identificador del OA, título, descripción, etc.

 Lifecycle. Almacena un histórico del objeto y su estado actual. Detalla

quiénes han interactuado con este objeto desde que fue creado, y el tipo de
interacción que han realizado.

 Meta- Metadata. Agrupa información sobre los metadatos. Esto puede

parecer redundante a primera vista pero resulta muy interesante tener
información como quién ha contribuido a la creación de los metadatos y el
tipo de contribución que ha realizado.

 Technical. Incluye la información técnica del recurso de aprendizaje, tal

como tamaño, ubicación, o formato en el que se encuentra. Además, en
este elemento se almacenan los posibles requisitos técnicos necesarios
para poder usar el objeto al que se refieren los metadatos.

 Educational. En este elemento se encuentran las diferentes características

pedagógicas del objeto. Típicamente se incluyen campos como tipo de
recurso – ejercicio, diagrama, figura -, nivel de interactividad entre el
usuario y el objeto –alta, media, baja-, o el contexto de uso del recurso –
universidad, enseñanza primaria, doctorado-, entre otros.

 Rights. Se incluyen los detalles sobre la propiedad intelectual del recurso.

También se detallan las condiciones de utilización y el precio en caso de
tenerlo.

 Relation. Explica el tipo de relación que tiene el recurso de aprendizaje con

otros OA. Posee un par nombre-valor en el que detalla el nombre del OA
relacionado y el tipo de relación –es parte de, está basado en, etc -.
  Annotation. Incluye comentarios sobre la utilización del LO, además de su
autor y la fecha de creación.

 Cassification. Nos informa si el OA pertenece a algún tema en concreto. Por

ejemplo, es aquí dónde se almacenaría que un OA se refiere a Física o a
Historia. Permite tanto detalle cómo se quiera mediante anidamiento de
temas.

El modelo de datos especifica también qué elementos de la descripción pueden

repetirse (e.g. Classification). Además, hay unos campos en los que el tipo de
contenido es libre, es decir se puede poner cualquier cadena de texto (para la cuál
se puede especificar además el idioma) y hay otros campos en los que se dispone
de un conjunto de valores concretos entre los que se puede elegir (es decir, se
tiene un vocabulario controlado -Figura 3.2.a, Figura 3.2.b).

Figura 3.2.b asignación del valor alto (“high”) al campo nivel de interactividad de la
categoría educacional utilizando el editor Reload

Como hemos mencionado antes existe otra especificación anterior cuyo nivel de
aceptación es también muy amplio: el Dublin Core. Nacida con el objetivo de
describir recursos de carácter genérico en la Web, también ha sido adoptado por
la comunidad educativa con el fin de adjuntar información complementaria a los
recursos educativos. En este caso, y frete a los más de 70 campos de LOM, los 15
metadatos básicos de Dublín Core para un recurso educativos son: título, autor,
tema o palabras clave, descripción, editor, otros colaboradores, fecha, tipo de
recurso, formato, identificador, fuente, idioma, relación con otros recursos,
cobertura, y derechos. En el documento del propio estándar LOM se incluye un
apéndice comparando ambas especificaciones.

3.3. ADL/SCORM

ADL surge como respuesta a las necesidades principalmente del Departamento de

Defensa de EE.UU, que es uno de los mayores consumidores de software del
mundo y forma parte del esfuerzo que el gobierno norteamericano viene
realizando con el objetivo de conseguir una enseñanza de calidad.

ADL se ha centrado desde un principio en el aprendizaje sobre la Web.

Actualmente es el modelo más utilizado en la industria y que cuenta con mayor
cantidad de herramientas que lo soportan. Es un perfil de aplicación, ya que
combina muchas especificaciones (IMS, AICC, IEEE) y las particulariza para un
caso concreto. Las especificaciones, por su generalidad, dejan sin fijar aspectos
que son necesarios para facilitar la implementación final, y SCORM trata de ser
más preciso para lograr una mayor compatibilidad. En concreto SCORM se
sustenta sobre las siguientes especificaciones:

 IEEE Data Model For Content Object Communication

 IEEE ECMAScript Application Programming Interface for Content to

Runtime Services Communication

 IEEE Learning Object Metadata (LOM)

 IEEE Extensible Markup Language (XML) Schema Binding for Learning

Object Metadata Data Model

 IMS Content Packaging

 IMS Simple Sequencing.

Bajo la denominación SCORM (Sharable Courseware Object Reference Model)

propone un entorno de ejecución, un modelo de metadatos y un modelo de la
estructura de los cursos (modelo de agregación de contenidos). En su versión
2004 este modelo ha pasado a incluir también la secuenciación y navegación
(Sequencing and Navigation SN) de los contenidos. Esta secuenciación define
como se aplica y extiende IMS Simple Sequencing para un sistema SCORM.
SCORM define un modelo software que describe el modelo de agregación de
contenidos, las interrelaciones establecidas entre las componentes de los cursos,
los modelos de datos y los protocolos de comunicación, de manera que los
“objetos” definidos en un LMS puedan compartirse entre diferentes LMS.

Los elementos más característicos del modelo son:

 Modelo de Agregación de Contenido (Content Aggregation Model, CAM)
En este modelo se definen los cursos y se distinguen los objetos de
aprendizaje compartibles (Sharable Courseware Object, SCO), curso o
componente de un curso que cumple con los requisitos de interoperabilidad,
durabilidad y que dispone de la información suficiente para poder ser
reutilizado y accesible. Un SCO es la mínima unidad intercambiable entre
sistemas compatibles con SCORM, y consiste en un objeto de aprendizaje
que incluye un módulo software que le permite comunicarse con el entorno
de ejecución proporcionado por el LMS. Además se identifican los recursos
básicos (assets) que son elementos básicos, como ficheros de texto, audio,
video, etc. Estos recursos básicos se agrupan en los SCOs.

 Entorno de ejecución (Runtime Environment, RTE). Propone un entorno

estándar en el que se puede presentar un objeto de aprendizaje (en este
caso un SCO) que es capaz de intercambiar datos con el LMS. El LMS se
encarga de enviar los contenidos al alumno y el contenido intercambia la
información sobre el alumno y el seguimiento de su interacción con el curso
al LMS.

 Secuenciación y navegación (Sequencing and Navigation SN). Es la

información que permite complementar el diseño del curso, añadiendo
información sobre como se van a presentar dichos contenidos al usuario.
Esta presentación no tiene por qué ser siempre la misma, ya que puede
depender de las respuestas o comportamiento de los alumnos.

 LMS Y UTILIDADES COMPATIBLES CON LAS ESPECIFICACIONES Y

LOS ESTÁNDARES

 Algunos de los problemas identificados para la generalización de los estándares

educativos han sido, por un lado, que algunos LMS han tardado en ser
compatibles con las especificaciones, y, por otro, la necesidad de que los
educadores tengan bastante conocimiento técnico para su uso efectivo. No
obstante, estos problemas están en vías de solución, ya que cada vez aparecen
nuevas versiones de los LMS, tanto comerciales como de software libre, que
soportan el uso de algunas especificaciones y, por lo menos, la importación o la
exportación de cursos completos empaquetados según IMS o SCORM. Además
esto está unido también al desarrollo de nuevas herramientas que permiten la
creación de objetos de aprendizaje y de cursos completos, así como su anotación
con metadatos, sin necesidad de ser un experto en los estándares educativos.
 Aunque ya hemos mencionado previamente algunos LMS y herramientas, en este
epígrafe, y sin el propósito de ser exhaustivos, citaremos algunos de los mas
relevantes. En cuanto a LMS comerciales cabe mencionar WebCT Vista
(http://www.webct.com) y Blackboard (http://www.blackboard.com) como dos de los
más utilizados (actualmente están en proceso de fusión para crear una única
plataforma). En cuanto a LMS de software abierto destacan Moodle
 (http://www.moodle.com), .LRN (http://www.dotlrn.org), Claroline
(http://www.claroline.net), Dokeos (http://www.dokeos.com) y, últimamente, LAMS
ya que incluye soporte para el desarrollo de unidades de aprendizaje –aunque no
es compatible con IMS Learning Design- (http://www.lamsinternational.com).

Respecto a herramientas concretas, probablemente las que mayor repercusión

están teniendo son las desarrolladas en el proyecto Reload
(http://www.reload.ac.uk), que incluyen un editor de metadatos que permite
diferentes perfiles de aplicación, un creador de cursos empaquetados (con IMS o
con SCORM), un editor de IMS Learning Design y visualizadores (players) para
que se pueda ver el resultado obtenido con las herramientas. Hay herramientas
que soportan IMS QTI fundamentalmente comerciales como QuestionMark
(http://www.questionmark.com) o CanvasLearning
(http://www.canvaslearning.com). También hay muchos proyectos de software libre
que proporcionan soporte a los estándares, como por ejemplo, el sistema de
ejecución CopperCore para IMS Learning Design, desarrollado por los principales
creadores de la especificación.
 Además hay proyectos como SAKAI (http://www.sakaiproject.org) u Open
Kowledge Inititiative (http://web.mit.edu/oki/) que tienen herramientas y propuestas
de arquitectura para sistemas LMS muy versátiles y en continuo desarrollo. Otros
sitios web para encontrar información sobre las últimas herramientas compatibles
con los estándares son Academia ADL Co-lab (http://www.academiccolab.org) y los
sitios web de ADL (www.adlnet.org) e IMS (http://www.imsglobal.org).
 Además dos sitios de referencia para mantenerse al día de las continuas
evoluciones de los estándares son Centre for Educational Technology
Interoperability Standards (www.cetis.ac.uk) y el Learning Technolgy Standards
Observatory (www.cen-ltso.net) del Centro Europeo para la Normalización.

 3.5. COMPARTICIÓN DE RECURSOS EDUCATIVOS Y REPOSITORIO

DE OBJETOS DE APRENDIZAJE
 Otro elemento importante para el éxito de los objetos de aprendizaje es la
existencia de materiales educativos de calidad y fácilmente reutilizables por los
educadores. Aquí hay muchos aspectos a considerar, que van desde los aspectos
más técnicos, como el formato de dichos materiales, su granularidad o su
localización, a aspectos más legales, como su uso libre (incluso con modificación
posterior) o si están protegidos por derechos de propiedad intelectual.

 Figura 3.5.a Página principal de la iniciativa OpenCourseWare del MIT

 

 Iniciativas como la realizada por el Instituto de Tecnología de Massachussets

denominada MIT-OCW Open CourseWare Initiative (http://ocw.mit.edu) por la cuál
se compromete a hacer disponible todos sus contenidos de cursos universitarios
de forma gratuita en Internet, está creando una nueva tendencia (Figura 3.5.a). De
hecho hay otras universidades que lo están comenzando a hacer como, por
ejemplo, la Open University del Reino Unido (http://oci.open.ac.uk/). Incluso
algunos de los contenidos del MIT también están disponibles en español, ya que
hay un acuerdo con el portal Universia para la traducción y distribución de dichos
cursos (http://mit.ocw.universia.net). Como el MIT está implicado también en
iniciativas de estandarización, existe el compromiso de que todos estos contenidos
sean acordes a estándares en un futuro. Recientemente está iniciativa está siendo
secundada por mas universidades alguna de las cuáles pretende incluso distribuir
no sólo los contenidos, si no también las propias clases grabadas en video.
 Por otro lado, en los contenidos está pasando algo similar a lo que ya se ha
mostrado como muy eficaz en el desarrollo de aplicaciones, que es el la idea de
software libre. Se han desarrollado tipos de licencias similares para contenidos
que permite el libre uso e incluso modificación de los contenidos, y de la que el
más claro exponente es la licencia Creative Commons
(http://creativecommons.org). Por ejemplo, los contenidos del MIT-OCW se
distribuyen utilizando esta licencia.
 Otro de los elementos clave son los almacenes de objetos de aprendizaje, o
repositorios, con los que se pretende disponer de grandes bases de datos de
recursos educativos directamente utilizables y en muchos casos compatibles con
los estándares (o por lo menos descritos mediante ellos). Hay muchos proyectos e
iniciativas, que a su vez son muy diversas en cuanto a contenidos. En el proyecto
de universidad virtual promovido por la UNESCO
 (http://www.unesco.org/iiep/virtualuniversity/) se puede encontrar descritas muchas
iniciativas de compartición de información. Entre ellas podemos destacar Merlot
(http://www.merlot.org), Ariadne (http://www.ariadne-eu.org), EdNA Online
(http://www.edna.edu.au) o SMETE (http://www.smete.org). En las páginas de ADL
Academic Co-Lab se puede encontrar una base de datos que analiza más de
cuarenta iniciativas y las describe utilizando 32 propiedades o características
(http://projects.aadlcolab.org/repository-directory/).
 El creciente interés de estos aspectos ha hecho que una de las iniciativas actuales
de SCORM sea proponer una arquitectura para la federación de almacenes de
objetos de aprendizaje llamada CORDRA (Content Object Repository Discovery
and Registration/Resolution Architecture) que simplifique y resuelva la búsqueda y
obtención de objetos de aprendizaje preexistentes.
 Por toda la información anterior podría parecer que la estandarización, y en
general el e-learning, sólo está teniendo repercusión en disciplinas más técnicas,
generalmente de nivel universitario o profesional, y que los contenidos sólo están
en inglés. Aunque es cierto que hay más información disponible en esas áreas, y
que el inglés es la lengua predominante en los recursos (como por otro lado
también lo es en el conjunto de información que contiene Internet), existen
ejemplos significativos de contenidos y experiencias no técnicas en español. Por
ejemplo, a partir de la página web de las Jornadas del Campus Virtual de la
Universidad Complutense de Madrid (campusvirtual.ucm.es), se puede comprobar
cómo WebCT se está utilizando para mejorar la docencia en campos como el
derecho, la lingüística o las propias ciencias de la educación. Por otro lado, en el
propio Centro Nacional de Información y Comunicación Educativa (CNICE) del
Ministerio de Educación y Ciencia, promotor de esta publicación, se proporciona
un gran conjunto de materiales educativos para la formación básica y para la
formación secundaria. En este momento, el CNICE está estudiando cómo utilizar
los estándares (e.g. LOM) para mejorar la indexación, búsqueda y reutilización de
dichos recursos.
 Existe también una lista de distribución sobre e-learning soportada por RedIris en
la que participan varios cientos de personas interesadas en el tema, no sólo de
España si no también de Latinoamérica, (la dirección de la lista es
elearning@listserv.rediris.es pero previamente hay que suscribirse) por lo que es
un recurso adecuado para saber lo que está sucediendo en este campo, sobre
todo desde el punto de vista de la aplicación real.

En lo referente a la aplicación industrial hay dos asociaciones representativas de

las principales empresas dedicadas al e-learning en España que son AEFOL
(www.aefol.com) y IMS CONTENT PACKAGING

4.1. INTRODUCCIÓN
La recolección y el empaquetado de los contenidos educativos en formato digital es un
requisito básico para muchos de los procesos involucrados en el despliegue, gestión,
distribución y agregación de dichos contenidos. La especificación Content Packaging de
IMS (de ahora en adelante, IMS CP) define un formato digital estándar para representar
dichos paquetes de contenidos educativos (ver IMS CP 2001-2004).

De esta forma, IMS CP es una especificación básica para facilitar

la interoperabilidad entre los sistemas de e-learning, ya que dichos sistemas pueden
intercambiar materiales empaquetados de acuerdo a IMS CP: un sistema que soporta IMS
CP (por ejemplo, una herramienta de autor, un sistema de gestión del aprendizaje, una
biblioteca digital de recursos educativos, etc.) será capaz de abrir los paquetes IMS,
independientemente de la forma y el lugar en los que dichos paquetes hayan sido
producidos.

En este capítulo se detalla la especificación IMS CP. Para ello, se comienza planteando
un caso de estudio sencillo que será utilizado a lo largo del mismo para ilustrar los
distintos aspectos introducidos. Seguidamente se comenta la estructura de los paquetes
IMS CP desde un punto de vista conceptual. Para finalizar, se analiza cómo dicha
estructura se describe en XML.

4.2. UN CASO DE ESTUDIO

El Profesor Eméritus ha desarrollado un curso informatizado sobre Introducción a la
Geometría. Para ello ha producido y seleccionado los materiales que se detallan en la
Figura 4.2.a:

Figura 4.2.a . Materiales para el curso sobre la introducción a la geometría [Árbol de

directorios con los contenidos del curso en distintas carpetas y una representación de dos
recursos externos accesibles a través de Internet]

 Un tutorial. Dicho tutorial consta de cuatro archivos HTML: pres.html, con la

presentación del tutorial, intro.html, con una introducción, conten.html, con el
contenido, y res.html, con un resumen. Desde conten.html se refieren dos
imágenes: fig1.jpg y fig2.jpg. Todos estos archivos se encuentran en la subcarperta
tutorial.
  Un par de ejercicios. Cada ejercicio está contenido en un archivo HTML (ej1.html y
ej2.html). Desde ej1.html se refiere, así mismo, a las imágenes fig1.jpg y fig2.jpg.
Este material está colocado en la subcarpeta ejercicios.

Así mismo, el Profesor Eméritus ha localizado un par de sitios web dedicados a la

Geometría, que considera relevantes como complemento al curso. Las direcciones web
de estos sitios son http://www.geoworld.org/y
http://www.amigosdelageometria.tv/default/index.htm.
Es importante notar que, desde el punto de vista de IMS CP, no es preciso entrar en los
detalles de los contenidos reales de este curso. De hecho, IMS CP servirá
fundamentalmente para describir la agrupación lógica y la estructura de estos contenidos,
tal y como se detalla en el resto de este capítulo.

4.3. VISIÓN CONCEPTUAL DE IMS CP

El principal concepto introducido en IMS CP es el de paquete IMS. Un paquete IMS define
explícitamente la estructura de un conjunto de archivos con contenidos educativos
interrelacionados. Dicha estructura sigue el patrón genérico expuesto en la Figura 4.3.a.
De esta forma:

Figura 4.3.a . Esquema de la estructura de un paquete IMS

 El paquete puede involucrar archivos internos y archivos externos. Los archivos

internos son archivos digitales que forman parte del paquete, y pueden estar
físicamente organizados en carpetas. Los archivos externos son elementos que no
forman parte del paquete, pero que se refieren desde el mismo utilizando una URL
 (una dirección estándar de Internet). En el caso de estudio, ejemplos de archivos
internos son los archivos HTML y JPG asociados con el tutorial y con los
ejercicios. Los dos sitios web citados son ejemplos de archivos externos.

 Los archivos internos pueden agruparse en recursos internos. En dichas

agrupaciones siempre se distingue un archivo primario. El resto de los archivos
son archivos secundarios.

 Los archivos externos están asociados con recursos externos.

 Los recursos pueden, a su vez, organizarse siguiendo un determinado convenio a

efectos de su presentación, dando lugar, por tanto, a distintas organizaciones. La
presencia de organizaciones en un paquete es opcional. Así mismo, un paquete
puede incluir más de una organización, en cuyo caso deberá distinguir una
como organización por defecto. IMS CP introduce un mecanismo simple de
descripción de organizaciones que se detallará a continuación, aunque dicho
mecanismo puede especializarse y adaptarse a cada escenario de aplicación. Por
ejemplo, IMS Learning Design (ver IMS LD 2003) puede considerarse, desde la
óptica de IMS CP, un lenguaje muy sofisticado de descripción de organizaciones
de recursos educativos en un paquete.

 Por último, un paquete puede contener a su vez varios subpaquetes, lo que ofrece
un mecanismo de agregación de paquetes para dar lugar a paquetes más
complejos, así como un mecanismo de desagregación de un cuerpo de contenidos
educativos interrelacionados en subconjuntos de contenidos autónomos

 APEL (www.apel.es).

Es importante notar que los paquetes IMS son meros organizadores de los materiales
educativos. La naturaleza exacta del paquete depende enteramente de los criterios y
estrategias pedagógicas del instructor que lo diseña. Así por ejemplo, en la Figura 4.3.b y
en la Figura 4.3.c se esquematizan dos posibles paquetes IMS para el caso de estudio,
cada uno de los cuáles proporciona una estructuración alternativa de los materiales
educativos distinguidos por el mismo:

Figura 4.3.b . Un empaquetado de los materiales del caso de estudio

  El paquete de la Figura 4.3.b representa un agrupamiento uninivel de los
materiales. De esta forma, este paquete no incluye subpaquetes. Cada archivo
HTML, junto con las imágenes referidas por el mismo, constituyen un recurso
interno. Obsérvese que, de esta manera, los recursos permiten agrupar archivos
interrelacionados que, como los archivos HTML y los elementos por ellos referidos,
forman, como un todo, elementos de información significativos. Así mismo, hay un
par de recursos externos, uno para cada uno de los sitios web. Por último, el
paquete incluye cinco organizaciones diferentes.

Figura 4.3.c . Una segunda alternativa de empaquetado para los materiales del caso de
estudio, en la que se sitúan los ejercicios en un subpaquete
  El paquete de la Figura 4.3.c agrupa los ejercicios en un subpaquete. Dicho
subpaquete presenta la misma estructura que un paquete global. Este hecho
revela la percepción de los ejercicios como un cuerpo de materiales
autocontenidos, que posiblemente puedan ser reutilizados en otros contextos.
Tanto el paquete global como el subpaquete incluyen dos organizaciones distintas.

Obsérvese que en estos paquetes no se detalla la naturaleza de las organizaciones. A

continuación se describirán dichas organizaciones en términos del modelo por defecto
considerado en la propia especificación IMS CP.

4.3.1. Organizaciones en IMS CP

IMS CP introduce un mecanismo sencillo y por defecto que permite organizar los recursos
de un paquete de manera jerárquica. Efectivamente:

 Una organización en IMS CP es una secuencia de ítems (elementos). Dichos

ítems pueden ser simples o compuestos.

 Los ítems compuestos tienen asociadas, a su vez, secuencias de otros ítems

(simples o compuestos).

 Tanto los ítems simples como compuestos pueden referir, opcionalmente, recursos
de su paquete o de los subpaquetes, así como dichos subpaquetes como un todo

Dicha organización supone una presentación pasiva de los contenidos del paquete. La
forma de explotar dicha presentación dependerá, en última instancia, de la plataforma de
e-learning que reciba el paquete. Por ejemplo, un sistema de gestión de aprendizaje
puede utilizar la organización de un paquete para generar un índice visual de sus
contenidos, que facilite la navegación por los mismos. Para facilitar éste, y otro tipo de
usos, IMS CP permite indicar la visibilidad o no visibilidad de un ítem. De esta forma, será
posible identificar en una organización ciertos ítems como no visibles.
A continuación se muestran las organizaciones introducidas en el primer paquete de
ejemplo. Dichas organizaciones incluyen:

Figura 4.3.1.a .Una organización plana .

 Una organización plana de los recursos del paquete (Figura 4.3.1.a). Se introduce
un ítem por cada recurso, de tal forma que la organización en sí es una secuencia
ordenada de dichos ítems.

Figura 4.3.1.b . Una organización con estructura

  Una organización en la que el tutorial se presenta de manera más estructurada,
introduciendo un ítem compuesto que refiere la presentación, y que tiene como
hijos ítems simples que refieren a cada uno de los recursos elementales del
tutorial (introducción, contenidos y resumen) -Figura 4.3.1.b. La presentación del
resto de los recursos continúa siendo plana.

 Una organización que estructura también los ejercicios y los sitios web mediante la
introducción de ítems compuestos (Figura 4.3.1.c). Nótese que dichos ítems no
hacen referencia a ningún recurso. Efectivamente, las organizaciones en IMS CP
permiten utilizar ítems que no tienen contenido asociado, con un carácter
puramente organizativo.

 Dos organizaciones que muestran vistas parciales de los recursos del paquete
(Figura 4.3.1.d): una vista del tutorial y los ejercicios, y otra vista que involucra a
los sitios web. Este ejemplo pone de manifiesto que una organización no tiene
porque referir a todos los recursos del paquete, sino que puede involucrar
únicamente a un subconjunto de los mismos.

Metadatos

Los metadatos son un componente esencial de cualquier material educativo

informatizado con mínimas aspiraciones de permitir su descubrimiento y
reutilización por terceros. Tal y como se indica en el capítulo dedicado a este tema,
dichos metadatos son información adicional que se añade a los contenidos y que
describen distintas características semánticas de los mismos. Por ejemplo, si se
desea indicar quién es el autor de un paquete, quién ha sido el último revisor de
un determinado recurso, cómo se clasifica dicho recurso en una taxonomía de
recursos educativos, etc., será necesario asociar metatados apropiados con los
distintos elementos estructurales del paquete. IMS CP contempla dicha necesidad,
y permite asociar metadatos con los siguientes componentes:

 Con la totalidad del paquete en sí.

 Con cada una de las organizaciones.

 Con cada ítem

 Con cada recurso

  Con cada archivo integrado en un recurso

Para ello, la especificación permite utilizar cualquier convenio de descripción de

metadatos, aunque recomienda el uso de la especificación Learning Object
Metadata (LOM) para tal fin. Dicha especificación se describe con detalle en este
mismo informe, en el capítulo dedicado a metadatos.

4.3.4. Archivos de Intercambio de Paquetes

El concepto de paquete introducido por IMS es un concepto lógico. De esta forma,

dicho concepto puede realizarse de muy distintas maneras. Por ejemplo, un
paquete puede involucrar archivos almacenados en un disco duro o en un CD,
recursos en una biblioteca digital, etc. No obstante, cuando los paquetes se
intercambian entre sistemas, la especificación recomienda que todos los archivos
internos, junto con la descripción de la estructura del paquete (descripción que se
detallará en el próximo apartado), se almacenen en un único archivo comprimido
denominado archivo de intercambio de paquetes (o archivo PIF, del
inglés Package Interchange File). Para realizar la compresión puede utilizarse
cualquier formato de compresión actual (por ejemplo, .jar, .cab, .rar, etc.), aunque
la especificación recomienda utilizar el formato .zip para tal fin.

De esta forma, la distribución habitual de un paquete IMS es como un archivo .zip,

que pude abrirse con cualquier herramienta de compresión/decompresión
estándar (tipo WinZip y similares).

4.4. DESCRIPCIÓN XML DE LA ESTRUCTURA DE LOS PAQUETES

IMS CP aplica XML para definir un lenguaje de marcado específico que permite
describir la estructura de los paquetes. Los documentos marcados con dicho
lenguaje se denominan manifiestos. De esta forma, si se abre un PIF, siempre se
encontrará en su raíz un archivo XML denominado imsmanifest.xml, que describe
la estructura del paquete: sus recursos, sus organizaciones, sus sub-paquetes, y
los metadatos asociados con los distintos componentes. En este apartado se
describen los distintos tipos de elementos (las etiquetas) introducidos por dicho
lenguaje, y se ejemplifica su uso con el caso de estudio. Los manifiestos
completos de los paquetes ejemplo se listan en un apéndice.

4.4.1. El elemento manifest.

El elemento manifest es el elemento raíz de los manifiestos. La Figura 4.4.1.a

esquematiza la estructura gramatical del mismo. El elemento incluye los siguientes
atributos:
Figura 4.4.1.a . Estructura gramatical del elemento manifest

 identifier. Un atributo obligatorio que identifica al manifiesto, mediante un

identificador que es único en el contexto del mismo.

 version. Atributo opcional que identifica la versión del manifiesto. Es útil

para distinguir entre manifiestos que tienen asociado el mismo identificador.

 xml:base. Atributo opcional que proporciona una ruta inicial para los
archivos con el contenido.

Así mismo, el elemento puede contener los siguientes elementos en su contenido

(en este orden):

 Opcionalmente, una ocurrencia del elemento metadata, que describe los

metadatos globales del paquete.

 Una única ocurrencia del elemento organizations, que describe las

organizaciones.

 Una única ocurrencia del elemento resources, que describe los recursos del
paquete.

 Cero o más ocurrencias del elemento manifest, cada una de las cuáles
describirán la estructura de los distintos subpaquetes.

Figura 4.4.1.b . Estructura de alto nivel del manifiesto para el primer paquete
ejemplo.
En la Figura 4.4.1.b se muestra el fragmento de manifiesto que refleja la estructura
de alto nivel del primer paquete de ejemplo. Obsérvese que, aparte de los
atributos específicos introducidos para el elemento manifest, en el elemento
manifest raíz aparecen también otros atributos estándar de XML, que asocian con
el documento los esquemasnecesarios para validar estructuralmente el mismo
(todos estos esquemas deberán residir, junto con el manifiesto, en la raíz del
correspondiente PIF). Aunque el significado de estos atributos es de carácter
marcadamente técnico, se detalla a continuación por completitud:

 Un esquema XML es una descripción de las reglas gramaticales que tiene

que seguir un determinado lenguaje XML (ver XML Schema 2004). En
concreto, existe un esquema para el lenguaje de descripción de manifiestos
en IMS CP. También existe un esquema para el lenguaje de descripción de
metadatos LOM.

 En un mismo documento XML puede combinarse marcado que se ajusta a

múltiples esquemas. Para permitir, entre otras cosas, determinar
unívocamente el esquema que debe utilizarse en cada momento, XML
permite situar el marcado en distintos espacios de nombres (ver XML
Names 2006). Dichos espacios de nombres tienen asociados
identificadores únicos (normalmente se utilizan identificadores con formato
de direcciones web), y se declaran usualmente en el elemento raíz del
documento, utilizando el atributo predefinido xmlns. De esta forma:

o Es posible indicar un espacio de nombres por defecto para el

marcado del documento dando directamente un valor para xmlns. En
el ejemplo, dicho espacio de nombres por defecto es

http://www.imsglobal.org/xsd/imscp_v1p1.
 o El marcado que no se encuentre en el espacio de nombres por
defecto deberá distinguirse con un prefijo. Para ello, el resto de los
espacios de nombres deben introducirse como xmlns:prefijo. Por
ejemplo,

xmlns:lom="http://www.imsglobal.org/xsd/imsmd_v1p2"
indica que para introducir marcado que esté en el espacio de
nombres
http://www.imsglobal.org/xsd/imsmd_v1p2
deberá utilizarse el prefijo lom (por ejemplo, <lom:classification>…
<lom:classification>).

 Para indicar las reglas gramaticales que rigen en cada espacio de nombres,
es necesario asociar esquemas con espacios de nombres. Para ello se
utiliza el atributo schemaLocation, que se encuentra, a su vez, en el espacio
de nombres

http://www.w3.org/2001/XMLSchema-instance
espacio de nombres que, en el ejemplo, se asocia con el prefijo xsi. De esta
forma, mediante
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1
imscp_v1p1.xsd"
se está indicando que las reglas gramaticales del marcado utilizado en el
espacio de nombres
http://www.imsglobal.org/xsd/imscp_v1p1
(el espacio de nombres por defecto, en este documento) vienen dadas por
el esquema XML que se encuentra en el archivo imscp_v1p1.xsd. Este
archivo, como todos los esquemas que se refieran desde el manifiesto,
debe colocarse en la raíz del paquete. Utilizando un mecanismo análogo se
identifica imsmd_v1p2p2.xsd como el archivo que contiene el esquema
para el espacio de nombres asociado con el prefijo lom (este esquema
norma la descripción de los metadatos LOM).

El elemento metadata

Este elemento permite encerrar la descripción de los metadatos. Podrá aparecer,

por tanto, en todos aquellos lugares del manifiesto donde sea lícito incluir
metadatos. La estructura de este elemento se detalla en la Figura 4.4.2.a. De esta
forma, el elemento puede incluir los siguientes elementos, y en el orden indicado:

Figura 4.4.2.a . Estructura gramatical del elemento metadata

  Elemento schema. Un elemento opcional cuyo contenido proporciona una
descripción textual del esquema que norma la estructura gramatical de la
descripción de los metadatos. Si no se indica, se toma IMS Content como
su contenido por defecto.

 Elemento schemaversion. Elemento opcional que describe textualmente la

versión del esquema utilizado. Si no se indica, se toma 1.1 por defecto.

 Un elemento obligado que indica la descripción de los metadatos en sí. El

nombre y la estructura de dicho elemento dependerá del esquema de
metadatos utilizado.

Figura 4.4.2.b . Ejemplo muy simple de metadatos globales

Es importante indicar que los elementos schema y schemaversion tienen

únicamente un papel documentador, y, en ningún caso, normativo. La introducción
de metadatos se lleva a cabo directamente, utilizando vocabulario del espacio de
nombres apropiado. La Figura 4.4.2.b detalla un ejemplo muy simple de
descripción de metadatos globales para el manifiesto ejemplo. En este caso, el
esquema de metadatos utilizado es LOM, y, por tanto, la descripción de los
metadatos seguirá la normativa del esquema XML para LOM. Todos los elementos
prefijados con LOM son elementos definidos en dicho esquema. El significado de
los mismos se detalla en el capítulo sobre metadatos.
4.4.3. Descripción de recursos

El elemento resources permite describir los recursos de un paquete. Cada recurso

en sí se describe mediante un elemento de tipo resource. En la Figura 4.4.3.a se
esboza la estructura gramatical de estos elementos.

Figura 4.4.3.a . Estructura gramatical de los elementos resources y resource

El elemento resources puede tener un atributo opcional xml:base que indica un

posicionamiento relativo en la estructura de carpetas del paquete, y contiene una
secuencia (posiblemente vacía) de elementos resource. Por su parte, los
elementos resource tienen asociados los siguientes atributos:

Figura 4.4.3.b . Estructura gramatical de los elementos file y dependency

 Atributo obligatorio identifier, identificando unívocamente el recurso en el

contexto del paquete.

 Atributo obligatorio type, identificando el tipo de contenido que representa el

recurso. La especificación introduce el tipo webcontent para indicar
contenido que puede servirse y visualizarse en un navegador web. Así
 mismo, en IMS CP USE (2001) se definen un conjunto de términos que
pueden utilizarse para especificar tipos de contenido adicionales.

 Atributo opcional xml:base indicando un posicionamiento relativo del

recurso.

 Atributo opcional href, refieriendo el archivo principal del recurso, en caso

de recursos internos, o bien localizando el recurso externo, mediante una
URL (dirección web) absoluta, en el caso de recursos externos.

Figura 4.4.3.c . Descripción de recursos

Estos elementos resource contienen los siguientes:

 Opcionalmente, un elemento metadata conteniendo metadatos acerca del

recurso.

 Una secuencia (posiblemente vacía) de elementos file indicando los

archivos del recurso.

 Una secuencia (posiblemente vacía) de elementos dependency indicando

las dependencias con otros recursos.

Figura 4.4.3.d .Ejemplo de descripción de las dependencias entre recursos.

La Figura 4.4.3.b esquematiza la estructura gramatical de los elementos file y
dependency. Los elementos file incluyen una referencia al archivo en sí mediante
un atributo href. Así mismo, pueden contener, opcionalmente, un elemento de
metadatos. Por su parte, los elementos dependency incluyen un atributo
identifierref, que sirve para referir el identificador del recurso con el que se
establece la dependencia.

La Figura 4.4.3.c ejemplifica la descripción de recursos. Por simplicidad, no se han

incluido metadatos en dicha descripción. Por su parte la Figura 4.4.3.d ejemplifica
el uso de dependencias entre recursos. La descripción se corresponde con el
ejemplo de dependencia expuesto anteriormente.

Posicionamiento en la estructura de carpetas del paquete

Los atributos xml:base permiten definir rutas relativas dentro de la estructura de

carpetas que permiten abreviar la referencias a nivel de los elementos file. Este
mecanismo sigue la especificación XML Base descrita en XML Base (2001). En la
Figura 4.4.4.a se muestra un ejemplo de uso de esta característica. Mediante
xml:base se especifica que todos los archivos del recurso se encuentran en la
capeta tutorial. Esto permite abreviar las referencias a dichos archivos. Dicha
carpeta puede haberse, así mismo, posicionado utilizando atributos xml:base en
los elementos resources y manifest antecesores. El punto de partida inicial es la
raíz del paquete.

Figura 4.4.4.a . Ejemplo de uso del atributo xml:base

4.4.5. Descripción de organizaciones

La descripción de las organizaciones de un paquete se encierra en el interior de

un elemento de tipo organizations. Este es un elemento obligatorio, aún para
aquellos paquetes que no incluyen ninguna organización (en este caso, deberá
incluirse un elemento vacío: <organizations/>). Tal y como se ha indicado, IMS CP
incluye un mecanismo por defecto de descripción de organizaciones. Cada
organización que sigue dicho mecanismo se describe, a su vez, mediante un
elemento organization. La Figura 4.4.5.a. esboza la estructura gramatical de estos
elementos.

El elemento organizations puede incluir un atributo opcional default, que refiere a

la organización por defecto. Así mismo, puede incluir una secuencia opcional de
elementos organization, así como una secuencia de otros elementos, no prefijados
a priori en la especificación IMS CP, que proporcionan otras formas de describir
organizaciones. Por su parte, cada elemento organization puede tener asociados
los siguientes atributos:

 Obligatoriamente, un atributo identifier que identifica unívocamente la

organización en el contexto del paquete.

 Opcionalmente, un atributo structure que identifica el tipo de estructura

utilizada para expresar la organización. Su valor por defecto es hierarchical,
que se corresponde con la visión arborescente de los recursos y
subpaquetes contemplada en la presentación conceptual de la
especificación

Figura 4.4.5.a. Estructura gramatical de los elementos organizations y

organization
Así mismo, los elementos organization contienen:

 Opcionalmente, un elemento title, que proporciona un título descriptivo de la

organización.

 Una secuencia de cero o más elementos item.

 Opcionalmente, un elemento metadata con los metadatos de la

organización.

La Figura 4.4.5.b. muestra la estructura gramatical de los elementos item, que

permiten describir los distintos ítems en una organización. Dichos elementos
tienen asociados los siguientes atributos:

 Un identificador obligatorio: identifier.

 Una referencia opcional a un recurso o a un subpaquete: identifierref

Figura 4.4.5.b . Estructura gramatical de item

Figura 4.4.5.c .Organizaciones globales del manifiesto de la Figura 4.4.1.b

Por su parte, item puede contener los siguientes elementos:

 Un título opcional: title.

  Una secuencia (posiblemente vacía) de ítems. Esto permite representar
ítems compuestos.

 Un elemento opcional describiendo los metadatos asociados.

 Opcionalmente, un atributo booleano isvisible, que determina si el ítem es o

no visible. Sus posibles valores son true y false. Su valor por defecto es true
(es decir, por defecto es visible)

 Opcionalmente, los parámetros requeridos para ejecutar el recurso referido:

parameters. Este atributo tiene sentido, por ejemplo, cuando el recurso es
un programa ejecutable, que necesita ciertos parámetros para ser lanzado

La Figura 4.4.5.c muestra las organizaciones globales del manifiesto de ejemplo.

Al igual que en los ejemplos anteriores, por simplicidad no se incluyen metadatos.

4.4.6. Extensibilidad

El lenguaje de marcado para manifiestos de IMS CP posee diversos puntos de

extensibilidad, que permiten introducir marcado para perfiles de aplicación
específicos. Tal y como ya se ha indicado anteriormente, es posible utilizar
distintos esquemas de metadatos, así como añadir otros mecanismos de
descripción de organizaciones. Igualmente, también es posible añadir nuevos
elementos hijos de manifest. Cada nueva extensión tendrá asociada un espacio de
nombres, así como un esquema XML que regulará la estructura de dicho espacio
de nombres.

5. LEARNING OBJECT METADATA (LOM)

5.1. INTRODUCCIÓN

Los metadatos son información añadida a los materiales digitales que facilitan su
clasificación y posterior recuperación. La especificación de metadatos adecuados
para los materiales educativos es indispensable a fin de añadir valor a los mismos,
en el sentido de facilitar su reutilización. Efectivamente, los materiales
enriquecidos convenientemente con metadatos podrán almacenarse en bibliotecas
digitales de contenidos educativos (por ejemplo, repositorios de objetos de
aprendizaje). Estas bibliotecas soportarán, entonces, consultas significativas que
permitirán la recuperación de aquellos materiales almacenados que cubran una
determinada necesidad pedagógica. De hecho, las ideas básicas subyacentes al
uso de metadatos han sido utilizadas durante siglos por los expertos en
documentación en la organización de ingentes archivos documentales y
bibliotecas. La signatura asociada a un libro en una biblioteca es un buen ejemplo
de metadato, que facilita su búsqueda y su recuperación por parte de un
bibliotecario.
La utilidad de un esquema de metadatos radica en su acepción por una
comunidad suficientemente amplia de productores y consumidores de material
educativo. Efectivamente, si dos comunidades utilizan esquemas de metadatos
distintos, difícilmente los materiales producidos podrán coexistir en un mismo
repositorio, a menos que se haya encontrado previamente un consenso que
permita homogeneizar los metadatos utilizados por ambas comunidades (por
ejemplo, transformándolos a un esquema común). Es por ello que, desde la
comunidad de e-learning, se han realizado distintos esfuerzos para estandarizar
los esquemas de metadatos que deben ser utilizados en la producción de
contenidos educativos. El esfuerzo más prometedor ha desembocado en el
estándar IEEE LOM (del inglés, Learning Object Metadata) (ver IEEE LOM 2002),
estándar que también ha sido adoptado, en una versión preliminar, como una
especificación de descripción de metadatos por IMS (ver IMS META 2001). Así
mismo, a fin de evitar las pequeñas diferencias existentes entre versiones LOM,
recientemente IMS ha propuesto una forma de migración automática entre
versiones (ver IMS META 2006).

Este capítulo se centrará principalmente en la adopción de IMS del estándar IEEE

LOM. Se comenzará introduciendo un caso de estudio sencillo que se utilizará a lo
largo de todo el capítulo para ilustrar la especificación. Seguidamente, se
describirá la especificación desde un punto de vista conceptual. A continuación, se
analizará la forma de representar metadatos LOM en XML. Después se describirá
brevemente el concepto de perfil de aplicación LOM, y se revisarán brevemente
dos perfiles de aplicación: CanCore, adoptado en el sistema educativo de Canada,
y la especificación emergente LOM-ES, actualmente en curso de realización, y
que supondrá un perfil LOM orientado a su uso en el sistema educativo español.
Para finalizar, se analizarán brevemente otras propuestas de metadatos, tales
como Dublin Core.

5.2. UN CASO DE ESTUDIO

En este capítulo se utilizará como caso de estudio la anotación con metadatos de

la imagen mostrada en la Figura 5.2.a. Se trata de una imagen que ilustra el
gráfico de la función de densidad de probabilidad Normal, o campana de Gauss.

Figura 4.5.2.a . Recurso educativo del caso de estudio

 5.3. UNA VISIÓN CONCEPTUAL DE LA ADOPCIÓN DE IMS DE LOM

Los metadatos en la adopción IMS del estándar LOM están agrupados

en categorías de metadatos. Más concretamente, LOM distingue 9 categorías de
metadatos diferentes (Figura 4.2.a):

Figura 4.5.2.a. Categorías de metadatos LOM

 Categoría general. Los metadatos en esta categoría representan información

general sobre el material educativo que describe el mismo como un todo.

 Categoría lifecycle (ciclo de vida). Esta categoría agrupa metadatos referidos a la

historia y estado actual del proceso de producción y mantenimiento del material
educativo por parte de los autores.

 Categoría metametadata (meta-metadatos). Esta categoría agrupa información

relativa a los metadatos en sí (de ahí su nombre).
  Categoría technical (técnica). Categoría que agrupa metadatos relativos a las
características y requisitos técnicos del material en sí.

 Categoría educational (educativa). Categoría que agrupa metadatos relativos a los

usos educativos del material.

 Categoría rights (derechos). Categoría que agrupa metadatos relativos a los

derechos de propiedad e intelectuales del material.

 Categoría relation (relación). Categoría de metadatos utilizados para establecer

relaciones entre el material y otros materiales.

 Categoría annotation (anotación). Anotaciones y comentarios sobre el material

educativo.

 Categoría classification (clasificación). Metadatos para la clasificación del material

en taxonomías.

A continuación se describen con más detalle cada una de estas categorías. Debe
tenerse en cuenta, no obstante, que la adopción de IMS del estándar se llevó a
cabo sobre un borrador del mismo. Aunque dicho borrador estaba ya en un estado
bastante avanzado, existen algunas discrepancias mínimas entre el estándar LOM
final publicado por IEEE (ver IEEE LOM 2002) y la adopción IMS (ver IMS META
2001). La última contribución de IMS al campo de los metadatos (ver IMS META
2006) persigue, precisamente, la automatización de la migración entre versiones,
como ya se ha indicado anteriormente.

5.3.1. La Categoría General

La categoría general agrupa 9 tipos de metadatos distintos (Figura 4.3.1.a):

Figura 5.3.1.a. Metadatos en la categoría general

 identifier (identificador). Identificador descriptivo del material educativo. Su valor

debe identificar unívocamente el material en su contexto educativo.
  title (título). Nombre descriptivo del material educativo.

 catalogentry (entrada en catálogo). Entrada en un determinado catálogo. El valor

para este metadato debe ser un par formado por un nombre de catálogo, así como
por el nombre de la entrada en dicho catálogo. Este metadato puede especificarse
para seleccionar el recurso cuando éste se encuentra indexado en un catálogo
externo (2).

 language (idioma). El idioma primario utilizado en el material para comunicarse

con los potenciales consumidores del mismo.

 description (descripción). Texto describiendo el contenido del material.

 keyword (palabra clave). Colección de frases que representan palabras clave

sobre el material.

 coverage (cobertura). Eventos temporales, culturales o geográficos asociados con

el material.

 structure (estructura). La estructura interna del material. LOM define el siguiente

vocabulario controlado para describir la
estructura: collection (colección), mixed (mixta), linear (lineal), hierachical (jerárqui
ca), networked (en
red), branched (ramificada), parceled (compartimentada), atomic (atómica). No
obstante, los autores pueden utilizar sus propios vocabularios, adaptados a sus
necesidades pedagógicas particulares.

 aggregationlevel (nivel de agregación). Define la granularidad del material. LOM

define el siguiente vocabulario controlado para definir dicha granularidad

Tabla 5.3.1.a. Metadatos en la categoría general para el caso de estudio.

Categoría: general

Metadato Valor

identifier Fig00089

title Función de densidad de probabilidad Normal

catalogentry  Fig00089 en catálogo Imágenes

language ES

description Gráfico de la función de densidad de probabilidad de una normal.

keyword  Probabilidad

 estadística

 función de densidad

 normal

 campana de gauss

coverage 1823

structure atomic (vocabulario LOM)

aggregationlevel 1 (vocabulario LOM)

o 1. Representa el nivel más pequeño de agregación (el aplicable a material

aparentemente indivisible, como una imagen, un archivo PDF, etc.).

o 2. Colección de materiales atómicos (por ejemplo, un archivo HTML junto

con las imágenes referidas desde el mismo).

o 3. Una colección de dos o más materiales de nivel 2 (por ejemplo, una web
formada por múltiples documenttos HTML).

o 4. El nivel mayor de granularidad (por ejemplo, un conjunto de cursos que

conducen a la obtención de un grado).

No obstante, al igual que con el metadato structure, los autores pueden utilizar
cualquier otro convenio, incluyendo cualquier otro vocabulario.

Tal y como se muestra en la Figura 4.3.1.a, un mismo material puede tener

asociados múltiples metadatos catalogentry, así como múltiples description,
keyword, coverage, e incluso language (éste será el caso de materiales con
soporte para múltiples idiomas). El resto de los metadatos deben especificarse, a
lo sumo, una vez para cada material.

La Figura 4.3.1.b muestra un ejemplo de asignación de metadatos en esta

categoría para el caso de estudio. Como puede observarse en el ejemplo, dicha
asignación consiste únicamente en proporcionar valores para los distintos
metadatos considerados. La asignación en sí podrá, posteriormente, codificarse
utilizando la representación XML para LOM, tal y como se detalla más adelante en
este capítulo. Así mismo, y aunque con motivos ilustrativos se indican valores para
todos los metadatos, dicha condición no es, en absoluto, necesaria (por ejemplo,
en este caso el valor para coverage, la fecha en la que Gauss publicó el tratado en
el que introducía la función normal, es un poco forzado). No obstante, sí es
recomendable la especificación de metadatos en todos aquellos casos en los que
tenga sentido.

La Categoría Lifecycle.

La categoría lifecycle (Figura 5.3.2.a) incluye los siguientes 3 tipos de metadatos:

 version. La edición o versión del material.

 status. El estado de producción del material. LOM propone el siguiente

vocabulario para este metadato (aunque puede utilizarse cualquier
otro): draft (borrador), final, revised (revisado), unavailable (no disponible).

 contribute (contribución). Introduce información acerca de un contribuyente

a la producción del material. De esta forma, un mismo material puede tener
asociados múltiples contribuyentes. La información de cada contribuyente
puede incluir las siguientes características (aunque no es necesario que
incluya todas)

Figura 5.3.2.a . Metadatos en la categoría lifecycle

o El papel del contribuyente en el proceso de producción. LOM

propone el siguiente vocabulario controlado para este
metadato: autor, publisher (publicador), unknown (desconocido), initi
 ator (iniciador), terminator (finalizador), validator (validador), editor (e
ditor), graphical designer (diseñador gráfico), technical
implementer (implementador técnico), content provider (proveedor de
contenidos), technical validator (validador técnico), educational
validator (validador pedagógico), script writer (escritor de
guiones), instructional designer (diseñador pedagógico).

o La identidad del contribuyente. Tiene sentido especificar varias

identidades para el mismo contribuyente (por ejemplo, en el caso en
que éste tenga varias afiliaciones).

o La fecha de la contribución.

La Tabla 5.3.2.a ilustra un ejemplo de asignación de estos metadatos en el caso

de estudio. Obsérvese que se supone que el material está en su versión 3.0, en un
estado de producción final, y se distinguen dos contibuyentes a su producción: uno
encargado de proporcionar el contenido en sí, y otro encargado de validar su
adecuación pedagógica.

Tabla 5.3.2.a .Metadatos en la categoría lifecycle para el caso de estudio.

Categoría: lifecycle

Metadato Valor

version 3.0

status final

contribute Primer contribuyente

 Papel: content provider

 Identidad: Francisco Eméritus

 Fecha: 20/04/2008

Segundo contribuyente

 Papel: educational validator

  Identidad: Pedro Censor

 Fecha: 24/04/2008

5.3.3. La Categoría Metametadata

La Figura 5.3.3.a esquematiza los metadatos englobados en la categoría

metametadata. Es interesante notar que aparecen de nuevo elementos ya
contemplados en las anteriores categorías, aunque esta vez su significado es
diferente, y se refieren a la producción de los metadatos en sí como recurso
digital, y no a la producción del material educativo que se está anotando.
Efectivamente, en esta categoría se contemplan los siguientes metadatos:

 identifier. Identificador del conjunto de metatados para el recurso. Este

identificador puede utilizarse para seleccionar el conjunto de metadatos,
cuando éste se encuentra almacenado externamente.

 catalogentry. Un catálogo y una entrada en dicho catálogo en el que el

conjunto de metadatos para el recurso reside. Esto permite seleccionar los
metadatos de un catálogo externo.

Figura 5.3.3.a . Metadatos en la categoría metametadata

 contribute. Contribuyente a la elaboración de estos metadatos.Para cada

contribuyente es posible especificar, al igual que en la categoría lifecycle,
el rol, la identidad y la fecha. LOM proporciona un vocabulario controlado
para el rol, que, en este caso, puede ser: creator (creador)
y validator (validador).

 metadatascheme (esquema de metadatos). Esquema de metadatos

utilizado (por ejemplo, LOMv1.0). Obsérvese que es posible haber usado
 más de un esquema (por ejemplo, en el caso de que se haya realizado una
especilización o perfil de aplicación de uno ya existente).

 language. El idioma por defecto utilizado para proporcionar los metadatos.

Tabla 5.3.3.a . Metadatos en la categoría metametadata para el caso de estudio.

Categoría: metametadata

Metadato Valor

contribute Primer contribuyente

 Papel: creator

 Identidad: Lula Hacker

 Fecha: 30/05/2008

Segundo contribuyente

 Papel: validator

 Identidad: Mike Hammer

 Fecha: 1/06/2008

metadataschema LOMv1.0

language ES

La Tabla 5.3.3.a muestra un ejemplo de meta-metadatos para el caso de estudio.

Aquí se está afirmando, por ejemplo, que Lula Hacker es la creadora de los
metadatos de este recurso, mientras que Mike Hammer ha validado los mismos.

5.3.4. La Categoría Technical

La Figura 5.3.4.a muestra los distintos metadatos contemplados por la categoría

technical:
  format (formato). Formato del material. Dado que el material no tiene
porque ser atómico, es posible que integre múltiples formatos (por ejemplo,
una página web puede integrar un documento HTML con un conjunto de
imágenes JPG), por lo que un mismo material puede exhibir múltiples
metadatos format. Una manera adecuada de describir los formatos es
mediante su denominación MIME (ver MIME 1996).

 size (tamaño). Tamaño en bytes del material.

 location (localización). Forma de localizar al material (por ejemplo, una

URL, o una descripción textual acerca de cómo llevar a cabo dicha
localización).

 requirement (requisito). Plataforma informática necesaria para utilizar este

material. Dicha plataforma puede describirse en términos de las siguientes
características:

Figura 5.3.4.a .Metadatos en la categoría technical

Tipo de la plataform. LOM propone el siguiente vocabulario para el

tipo: browser (navegador), operating system (sistema operativo).

Nombre de la plataforma. LOM propone el siguiente vocabulario: (i) en caso de

que el tipo sea operating system: PC-DOS, MS-Windows, MacOS, Unix, Multi-OS,
None; (ii) en caso de que el tipo sea browser: Any (cualquiera), Netscape
Communicator, Microsoft Internet Explorer, Opera, Amaya

 Versión mínima requerida.

 Versión máxima requerida.

 instalationremarks (indicaciones de instalación). Notas de instalación para

el recurso.
  otherplatformrequeriments (otros requisitos de plataforma). Otros
requisitos software y hardware.

 duration (duración). Duración (únicamente para material para el que tenga

sentido una duración en su reproducción, como, por ejemplo, un video o
una presentación Flash)

Tabla 5.3.4.a . Metadatos en la categoría technical para el caso de estudio.

Categoría: technical

Metadato Valor

format image/jpeg

size 512456

location ftp://imgserver.com/images/math/gauss.jpg

requirement  Tipo: Browser

 Nombre: Any

instalationremarks Basta disponer de un visualizador de imágenes JPG como

añadido al navegador

otherplatformsrequirements Opcionalmente, cualquier otro tipo de visualizador

La Tabla 5.3.4.a muestra un ejemplo de metadatos en la categoría technical para

el caso de estudio. De nuevo se exagera un poco el ejemplo, a fin de ilustrar el
cometido de los metadatos en esta categoría.

La Categoría Educational

Los metadatos contemplados por la categoría educational se resumen en la Figura

5.3.5.a:
Figura 5.3.5.a . Metadatos en la categoría educational

 interactivitytype (tipo de interacción). Tipo de interacción soportado por el

material. LOM propone el siguiente vocabulario para caracterizar este tipo
de interacción: active (para los contenidos interactivos), expositive (para los
contenidos pasivos), mixed (para contenidos que comparten ambas
características), undefined (para contenidos para los que no procede
especificar el tipo de interacción).

 learningresourcetype (tipo de recurso educativo). Especifica el tipo de

material (por ejemplo, ejercicio, figura, etc.). Un mismo material puede tener
distintos tipos asociados. LOM propone el siguiente vocabulario para
caracterizar el tipo de
material: exercise (ejercicio), simulation (simulación), questionnarie (cuestio
nario), diagram (diagrama), figure (figura), graph (gráfico), index (índice), sli
de (diapositiva), table (tabla), narrative text (texto
narrativo), exam (examen), experiment (experimento), ProblemStatement (e
nunciado de problema), SelfAssessment (autoevaluación).

 interactivitylevel (nivel de interacción). Especifica el nivel de interacción del

material. LOM propone el siguiente vocabulario controlado para especificar
dicho nivel: very low (muy
bajo), low (bajo), medium (medio), high (alto), very high (muy alto).

 semanticdensity (densidad semántica). Una medida subjetiva de la utilidad

educativa del material en comparación con su tamaño y/o duración. LOM
propone usar para expresar este nivel el mismo vocabulario controlado que
para interactivitylevel.

 intendeduserrole (papel jugado por el supuesto usuario). Determina el papel

del usuario final del material. LOM propone el siguiente vocabulario para
describir dicho
papel: teacher (maestro), author (autor), learner (aprendiz), manager (gesto
r).
  context (contexto). El entorno educativo típico en el que se usará el
material. LOM propone el siguiente vocabulario: primary
education (educación primaria), secondary education (educación
secundaria), higher education (educación superior), university first
cycle (primer ciclo universitario), university second cycle (segundo ciclo
universitario), university postgrade (postgrado), technical school first
cycle (primer ciclo de escuela técnica), technical school second
cycle (segundo ciclo de escuela técnica), professional formation (formación
profesional), continuous formation (formación continua), vocational
training (formación vocacional).

 typicalagerange (segmento de edad típico). Rango de edades típico de los

usuarios a los que va dirigido el material.

 difficulty (dificultad). Grado de dificultad del material. LOM propone el

siguiente vocabulario para caracterizar dicho grado: very easy (muy
fácil), easy (fácil), medium (medio), difficult (difícil), very difficult (muy difícil).

 typicallearningtime (tiempo típico de aprendizaje). Tiempo de aprendizaje

típico asociado con el material.

 description (descripción). Comentarios sobre el uso del material desde un

punto de vista pedagógico.

 language (idioma). Idioma del usuario final.

Tabla 5.3.5.a . Metadatos en la categoría educational para el caso de estudio.

Categoría: educational

Metadato Valor

interactivitytype expositive

learningresourcetype figure

interactivitylevel very low

semanticdensity high
intendeduserrole learner

context higher education

typicalagerange 16-20

difficulty Médium

typicallearningtime 30 minutos

description Entendimiento cualitativo de los principales parámetros de la normal

univariante.

language ES

La Tabla 5.3.5.a muestra un ejemplo de metadatos en la categoría educational

para el caso de estudio.

5.3.6. La Categoría Rights.

La Figura 5.3.6.a introduce los metadatos considerados en la categoría rights:

Figura 5.3.6.a . Metadatos en la categoría rights

Tabla 5.3.6.a. Metadatos en la categoría rights para el caso de estudio.

 Categoría: rights

Metadato Valor

cost no

copyrightandotherrestrictions no

description Este recurso no está sujeto a derechos de

autor alguno, porque las matemáticas son
patrimonio universal de la humanidad.

 cost (coste). Establece si el recurso es o no de pago. LOM propone como

vocabulario controlado para este metadato el sigiente: yes, no.

 copyrightandotherrestrictions (derechos de copia y otras restricciones).

Establece si el recurso está o no sujeto a derechos de copia y otras
restricciones. LOM propone como vocabulario controlado para este
metadato, de nuevo, yes y no.

 description (descripción). Comentarios sobre las condiciones y derechos de

uso de este recurso

La Tabla 5.3.6.a muestra un ejemplo de metadatos en la categoría rights para el

caso de estudio.

5.3.7. La Categoría Relation.

La categoría relation considera metadatos referidos a la relación entre el material y

otros materiales. Un mismo material puede mantener múltiples relaciones con
otros materiales. Cada una de estas relaciones exhibe las siguientes
características:

 La clase de la relación. LOM propone el siguiente vocabulario controlado

para caracterizar dicha clase: isPartOf (el material es parte de otro más
complejo), hasPart (el material tiene a otro como parte
integrante), isVersionOf(el material es una versión de otro), hasVersion (el
material tiene a otro como una versión), isFormatOf (el material es la
descripción de un formato de otro material), hasFormat (el material tiene a
 otro como formato), references (el material refiere al
otro), isReferencedBy (el material está referido por el otro), isBasedOn (el
material está basado en otro), isBasisFor (el material es la base de
otro), requires (el material requiere la presencia de otro), isRequiredBy (el
material es requerido por otro).

 La caracterización del otro material con el que se establece la relación.

Dicha caracterización puede darse en términos de:

 El identificador único del otro material.

 La descripción del otro material.

 Una entrada en un catálogo para el otro material

Tabla 5.3.7.a . Algunas relaciones del material del caso de estudio con otros.

Relación Recurso

isPartOf Identificador: doc098765

Descripción: Manual sobre variables
aleatorias unidimensionales

isRequiredBy Identificador: doc098765

Descripción: Manual sobre variables
aleatorias unidimensionales

isReferencedBy e08765 en catálogo manuales

Descripción: Manual sobre reconocimiento
estadístico de patrones

A modo de ejemplo, en la Tabla 5.3.7.a se muestran algunas relaciones entre el

material del caso de estudio y otros materiales. Las relaciones se toman del
vocabulario controlado propuesto por LOM.

La Categoría Annotation.

Los materiales pueden tener asociados mútiples anotaciones. Dichas anotaciones

pueden caracterizarse por:
  El anotador que realiza la anotación.

 La fecha de la anotación.

 El texto en sí de la anotación

Tabla 5.3.8.a . Algunas anotaciones del material del caso de estudio.

Anotador Fecha Texto

Franciscus 25/10/2008 Considero la combinación de la expresión formal y la

Emeritus representación gráfica muy adecuada para transmitir el concepto
de normalidad.

Bacus Floyd 25/11/2008 El énfasis de la franja de normalidad es apropiado, aunque

deberían resaltarse los puntos de inflexión.

La Tabla 5.3.8.a muestra algunas anotaciones para el material del caso de estudio.

5.3.9. La Categoría Classification.

LOM permite someter a los materiales a múltiples clasificaciones. Cada

clasificación puede tener asociada la siguiente información:

 El propósito de la clasificación. LOM propone el siguiente vocabulario

controlado de
propósitos: discipline(disciplina), idea, prerequisite, educational
objective (objetivo educativo), accesibility restrictions (restricciones de
acceso), educational level (nivel educativo), skill level (nivel de
destreza), security level (nivel de seguridad).

 Una serie de rutas en distintas taxonomías.

 Una descripción textual del material relativa al propósito de clasificación

establecido.

 Un conjunto de palabras clave relativas al propósito de clasificación

establecido.

Tabla 5.3.9.a . Algunas clasificaciones del material del caso de estudio.

Propósito Rutas Descripción Palabras clave

discipline Materia obligatoria en

estadística

discipline  matemáticas

 estadística

 probabilidad

educational informática->primer ciclo->

level estadística en carreras

educational Nodo 455 en carreras

level

La Tabla 5.3.9.a muestra algunas posibles clasificaciones para el material del caso
de estudio.

5.4. REPRESENTACIÓN DE METADATOS LOM EN XML

Los metadatos LOM pueden codificarse en múltiples formatos (por ejemplo, XML,
o RDF -ver RDF 2004). De estos, la codificación en XML es especialmente
interesante, ya que permite el uso combinado de la especificación con otras, como
por ejemplo IMS CP. En este apartado se describe la codificación en XML de LOM.
Comienza describiéndose la estructura general de la codificación. A continuación
se describe la codificación de cada una de las categorías.

5.4.1. Estructura general

La Figura 5.4.1.a muestra la estructura gramatical general de la codificación de

metadatos LOM en XML. De esta forma, se introducen elementos para cada una
de las categorías Obsérvese que la presencia de todos los elementos es opcional.
De esta forma, si no existen metadatos para una categoría dada, no es preciso
especificar el elemento para dicha categoría. No obstante, el orden de aparición
de los elementos debe ser el indicado.
Figura 5.4.1.a . Estructura gramatical de alto nivel para la codificación XML de
metadatos LOM

Figura 5.4.1.b . Aspecto general de la codificación XML de los metadatos del caso
de estudio

La Figura 5.4.1.b esquematiza el aspecto general de la codificación XML de los

metadatos del caso de estudio. El prefijo lom: se asume asociado con el espacio
de nombres para el esquema de dicha codificación, siguiendo los mecanismos
explicados en el capítulo sobre IMS CP. Nótese que, dado que en este ejemplo se
han especificado metadatos para todas las categorías, en la codificación XML
aparecen todos los elementos indicados. No obstante, en casos de aplicación más
realistas esto no tiene porque ser necesariamente cierto.

5.4.2. Codificación de la Categoría General

La Figura 5.4.2.a muestra la estructura gramatical de la codificación de los

metadatos en la categoría general. Las principales características de dicha
estructura son:

 Siempre que es preciso introducir una descripción textual, dicha descripción

se introduce mediante un elemento langstring. Dicho elemento puede tener
asociado un atributo xml:lang (este atributo no se indica en el esquema por
simplicidad), que especifica el idioma del texto. De hecho, siempre es
posible utilizar múltiples langstring alternativos para una misma descripción,
introduciendo textos en distintos idiomas (dichos elementos deben diferir en
el valor del atributo xml:lang).

 En el caso de metadatos que, como structure y aggregationlevel, admiten

vocabularios controlados, mediante source debe introducirse la
denominación del vocabulario, y mediante value el término. Este patrón se
repite recurrentemente en la codificación de otros muchos metadatos, tal y
como se examinará más adelante.

 En catalogentry se sigue un esquema de codificación específico de

entradas en catálogos, que también se adopta para otros metadatos en
LOM. Mediante catalog se identifica el nombre del catálogo, y mediante
entry la descripción de la entrada.

Figura 5.4.2.a . Estructura gramatical para la codificación de la categoría general

Figura 5.4.2.b . Codificación de los metadatos de la categoría general del caso de
estudio
En la Figura 5.4.2.b se indica la codificación de los metadatos de la categoría
general para el caso de estudio. Obsérvese que, una vez que se han decidido los
valores de los metadatos (se ha pensando en la Figura 4.3.1.b), la codificación en
XML es una tarea rutinaria, que, de hecho, puede llevarse a cabo con ayuda de
una herramienta apropiada. Como comentario técnico, obsérvese que se omite el
valor del atributo xml:lang en todos los langstring, excepto en el de value en
structure. Efectivamente, el valor del metadato language ya especifica que, por
defecto, los textos estarán en español. El texto tomado del vocabulario controlado
de LOM correspondiente es una excepción.
Codificación de la Categoría Lifecycle

La Figura 5.4.3.a esboza la gramática de la codificación de los metadatos en la

categoría lifecycle:

Figura 5.4.3.a . Estructura gramatical para la codificación XML de metadatos en la

categoría lifecycle

 El metadato version se especifica directamente mediante una descripción

textual, siguiendo el patrón general de la codificación (uso de elementos
langstring).

 El metadato status se especifica utilizando un término de un vocabulario

controlado. Para ello se sigue el patrón habitual (elementos source y value).

 Se introducen elementos para marcar las diferentes características de

contribute:

 El papel jugado por el contribuyente se marca mediante role, que debe

tomar su valor de un vocabulario (de ahí el uso de source y value para
describir su contenido).

 Las identidades se marcan mediante centity, y se describen usando el

formato vcard, marcado con un elemento vcard. El formato vcard (ver
VCARD 1996) es un formato estándar usado para intercambio de
información personal. Es un texto que comienza con begin:vcard y termina
con end:vcard. En su interior hay líneas de la forma clave:texto. Claves
típicas son n (nombre, abreviatura de name en inglés), fn (apellidos,
 abreviatura de family name en inglés), tel;type=tipo (teléfono, con tipo el
tipo de teléfono: home, mobile, etc), adr (dirección), etc.

 Las fechas de contribución se marcan con date. Mediante datetime se

proporciona la fecha en sí, y mediante description una descripción textual.

Figura 5.4.3.b . Codificación de los metadatos lifecycle del caso de estudio

La Figura 5.4.3.b ilustra la codificación en XML de los metadatos correspondientes
con el ciclo de vida para el caso de estudio.

5.4.4. Codificación de la Categoría Metametadata

La estructura gramatical de la categoría metametadata se esboza en la Figura
5.4.4.a. Como puede observarse, esta estructura no introduce criterios de
codificación nuevos. De hecho, la estructura del elemento catalogentry es análoga
a la utilizada en el contexto de la categoría general, mientras que la estructura de
la categoría contribute es la misma que la del correspondiente elemento de la
categoría lyfecycle. La Figura 5.4.4.b ejemplifica la codificación de los meta-
metadatos para el ejemplo.

Figura 5.4.4.a . Estructura gramatical para la codificación de metadatos en la

categoría metametadata

Es interesante hacer énfasis en el empleo de los elementos identifier y

catalogentry para seleccionar metadatos almacenados externamente.
Efectivamente, supóngase que todos los metadatos para el material del caso de
estudio se encuentran almacenados en el catálogo mismetadatos, y en la entrada
Fig00089. Entonces, será posible substituir toda la descripción por la que se
muestra en la Figura 5.4.4.c. Básicamente, lo que dice dicha descripción es “los
metadatos pueden encontrarse en el catálogo mismetadatos, en la entrada
Fig00089”. El mecanismo permite mantener repositorios centralizados de
metadatos para materiales educativos, y referirlos desde todos aquellos contextos
que sea necesario. Es posible utilizar también el elemento identifier para tal
propósito, o ambos elementos combinados, como se sugiere en la Figura 5.4.4.c.
En sistemas reales, esta información puede ser generada automáticamente por el
sistema de gestión de metadatos.

Figura 5.4.4.b . Codificación de los meta-metadatos del caso de estudio

Figura 5.4.4.c . Ejemplo de cómo referir una descripción de metadatos externa

Codificación de la Categoría Technical

La Figura 5.4.5.a esquematiza la estructura gramatical para la codificación de los

metadatos en la categoría technical.

Figura 5.4.5.a . Estructura gramatical para la codificación de metadatos en la

categoría technical
Obsérvese que los requisitos de plataforma se codifican en términos de un
elemento type (para el tipo de plataforma), un elemento name (para el nombre de
la plataforma), un elemento minimunversion (versión mínima) y un último elemento
maximumversion (versión máxima). Así mismo, la duración se codifica mediante
un elemento datetime (en caso de que se especifique fecha y hora) y otro
description (en caso de que se proporcione una descripción textual).

Figura 5.4.5.b . Codificación de los metadatos technical del ejemplo

En la Figura 5.4.5.b se muestra la codificación de los metadatos technical en el

ejemplo.

5.4.6. Codificación de la Categoría Educational

Las reglas gramaticales para la codificación de los metadatos en la categoría

educational se detallan en la Figura 5.4.6.a.

Figura 5.4.6.a . Estructura gramatical para la codificación de metadatos en la

categoría educational
La codificación de los metadatos que admiten vocabularios controlados
(interactivitytype, learningresourcetype, etc.) sigue el patrón habitual, al igual que
aquellos que implican una descripción textual (typicalagerange y description). Por
su parte, typicallearningtime sigue el patrón ya utilizado de proporcionar una
descripción en términos de fecha y hora junto con una descripción textual. Para
finalizar, language permite marcar directamente el código de idioma.

Figura 5.4.6.b . Codificación de los metadatos educational del ejemplo

La Figura 5.4.6.b muestra la codificación de los metadatos en la categoría
educational para el caso de estudio.

Codificación de la Categoría Rights

Las reglas gramaticales para la codificación de los metadatos en la categoría

rights se detallan en la Figura 5.4.7.a. Dicha codificación no ofrece ninguna
característica novedosa, más allá de los patrones de codificación ya aparecidos en
las anteriores categorías, referentes a la introducción de valores en vocabularios
controlados.

Figura 5.4.7.a . Codificación XML de los metadatos en la categoría rights

Figura 5.4.7.b .Codificación de los metadatos rights del ejemplo

La Figura 5.4.7.b ejemplifica la codificación de los metadatos rights para el

ejemplo.

5.4.8. Codificación de relaciones

La estructura gramatical para la codificación XML de las relaciones con otros

recursos se detalla en la Figura 5.4.8.a.

Figura 5.4.8.a . Codificación XML de los metadatos relation

Figura 5.4.8.b . Codificación de las relaciones del material ejemplo con otro
material
El tipo de la relación se codifica mediante el elemento kind, que se ajusta al patrón
habitual de uso de vocabularios controlados. Por su parte, el recurso con el que se
establece la relación se especifica mediante el elemento resource. Mediante
identifier puede referirse el identificador del recurso, mientras que mediante
catalogentry a la entrada que ocupa dicho recurso en un catálogo determinado.
Mediante description es posible describir textualmente el recurso relacionado.

La Figura 5.4.8.b muestra la codificación de las relaciones del material del caso de
estudio con otro material.

5.4.9. Codificación de anotaciones

Las anotaciones LOM se codifican en XML siguiendo el patrón gramatical de la

Figura 5.4.9.a.

Figura 5.4.9.a . Codificación de las anotaciones

Figura 5.4.9.b . Codificación de anotaciones en el ejemplo

El autor de la anotación puede introducirse mediante un elemento person, y
describirse con un elemento vcard, que identificará al autor usando el
formato vcard. La fecha se codifica con un elemento date, cuya estructura es la
habitual (anotación temporal y/o descripción del evento temporal). Por último, el
texto de la anotación en sí se codifica mediante un elemento description.
La Figura 5.4.9.b muestra la codificación de las anotaciones en el caso de estudio.

5.4.10 Codificación de clasificaciones

La Figura 5.4.10.a muestra la sintaxis que regula la codificación de las

clasificaciones en XML. Nótese que esta sintaxis soporta el amplio rango de
criterios de clasificación contemplado por LOM. Efectivamente:

Figura 5.4.10.a . Codificación de las clasificaciones

  Mediante el elemento purpose puede introducirse el propósito de la
clasificación. Esto permite llevar a cabo, tal y como propugna LOM, la
clasificación de un mismo material con distintos propósitos.

 El resto de los elementos permiten codificar la clasificación en sí:

Figura 5.4.10.b . Codificación de una clasificación por descripción textual

 El elemento description permite clasificar el material de forma narrativa,

mediante un texto libre en lenguaje natural. La Figura 5.4.10.b muestra la
codificación de este tipo de clasificación en el caso de estudio.

Figura 5.4.10.c . Codificación de una clasificación por palabras clave

Los elementos keyword permiten establecer una clasificación basada en palabras
clave. En la Figura 5.4.10.c se ilustra este criterio con el caso de estudio.

Figura 5.4.10.d . Codificación de una clasificación por situación directa en una

taxonomía.

Los elementos taxonpath permiten clasificar el material en taxonomías externas.

La taxonomía en sí puede identificarse mediante source. El elemento taxom
permite situar el material en un nodo de la taxonomía. Para ello pueden usarse los
siguientes criterios: (i) Situación directa. Este criterio sirve para taxonomías cuyos
nodos estén identificados unívocamente. Mediante el elemento id puede referirse
al identificador. La Figura 5.4.10.d ilustra este estilo de codificación. (ii) Situación
mediante ruta. Se lista explícitamente la ruta utilizando entry para nombrar la
categoría raíz, y, de nuevo, un elemento taxon para nombrar el resto de la ruta. La
Figura 5.4.10.e ilustra este estilo de codificación.
Figura 5.4.10.e . Codificación de una clasificación por situación mediante ruta

PERFILES DE APLICACIÓN LOM

LOM puede especializarse para cubrir mejor las necesidades de un determinado

contexto educativo (por ejemplo, de un determinado sistema educativo). El
resultado se denomina perfil de aplicación LOM. La ventaja de disponer de un
perfil de aplicación es su mayor adecuación a un determinado contexto. No
obstante, la creación de perfiles de aplicación específicos dificulta la
interoperabilidad de aplicaciones fuera de los contextos a los que están dirigidos,
ya que dichas aplicaciones externas no estarán obligadas a entender las
particularidades del perfil de aplicación.

La introducción de un perfil de aplicación puede valerse de distintos mecanismos:

 Es posible elegir únicamente un subconjunto de los metadatos

contemplados.

 Es posible refinar la estructura de algunos metadatos.

 Es posible introducir nuevas categorías de metadatos, y nuevos metadatos

en las categorías existentes. Esta estrategia se plasma directamente a nivel
 de la codificación en XML mediante la incorporación de nuevos espacios de
nombres para los nuevos metadatos, así como la caracterización de la
estructura gramatical de dichos espacios de nombres utilizando esquemas.

 Es posible precisar y particularizar el uso y el papel de los metadatos

existentes. Para ello puede, por ejemplo, introducirse nuevos vocabularios
controlados que capturen mejor las peculiaridades del contexto educativo
particular.

Un perfil de aplicación LOM bastante difundido es CanCore, desarrollado en el

contexto del sistema educativo canadiense. Por su parte, en España se está
actualmente formulando un perfil de aplicación específico denominado LOM-ES. A
continuación se revisa brevemente las principales características de dichos
perfiles de aplicación.

5.5.1. CanCore

El perfil de aplicación CanCore (ver CanCore 2004) se ha creado eligiendo un

subconjunto de los metadatos LOM, así como precisando el significado de estos
metadatos a un nivel de granularidad muy fina.

Los metadatos considerados por CanCore son:

 Todos los metadatos de la categoría general, excepto coverage y structure.

 Todos los metadatos de la categoría lifecycle, excepto status.

 Todos los metadatos de la categoría metametadata.

 Todos los metadatos de technical, excepto requirement e

installationremarks.

 Todos los metadatos de educational, excepto semanticdensity, difficulty y la

característica description de typicallearningtime.

 Todos los metadatos de rights.

 Todas las características de relation, excepto description.

 Todas las características de classification, excepto description

Así mismo, CanCore realiza un examen mucho más pormenorizado y sistemático

del uso de todos los metadatos que la especificación original de LOM.

5.5.2. LOM-ES
El perfil de aplicación LOM-ES se encuentra actualmente en curso de realización,
en el seno del Subcomité 36 de la Asociación Española de Normalización y
Certificación (AENOR) (ver LOM-ES 2006). En dicho perfil se están introduciendo,
entre otras, las siguientes características:

 Cambio de característica de opcionalidad por obligatoriedad para muchos

metadatos (por ejemplo, identifier –en el sentido de la versión final de
LOM-, title, language y description en general son obligatorios en el perfil).

 Establecimiento de nuevos vocabularios controlados para distintos

metadatos (muchos traducción al español de los propuestos por LOM).

5.6. OTROS ESQUEMAS DE METADATOS. DUBLIN CORE

Aunque en la actualidad LOM y sus ramificaciones constituyen el cuerpo de

metadatos para materiales educativos con mayor reconocimiento y dedicación de
esfuerzo en la comunidad de e-learning internacional, también existen otras
propuestas de metadatos. De éstas, quizá la más conocida sea Dublin Core (ver
Dublin Core 2004).

Tabla 5.6.a . Metadatos contemplados por Dublin Core.

Metadatos relativos al contenido

Coverage, Description, Type, Relation, Source, Subject,Title,Audience

metadatos relativos a los derechos de uso

Contributor, Creator, Publisher,Rights

metadatos relativos a la implementación

Date, Format, Identifier, Language

La principal ventaja de Dublin Core frente a LOM es su mayor sencillez. No

obstante, dicha sencillez se deriva, también, de su menor nivel de detalle.
Efectivamente, LOM es mucho más exhaustivo que Dublin Core (por
ejemplo, Dublin Core no introduce metadatos específicos para caracterizar los
propósitos educatinales de los contenidos). No obstante, en contextos donde no
se demande excesiva flexibilidad semántica a la hora de catalogar los
materiales, Dublin Core puede resultar una opción interesante. La Tabla 5.6.a lista
los principales tipos de metadatos contemplados por Dublin Core. La Figura 5.6.a
presenta un ejemplo de codificación XML de este tipo de metadatos. Dado
que Dublin Core propugna una organización más plana de los metadatos, la
codificación es también más sencilla.

Figura 5.6.a . Ejemplo de codificación XML de algunos metadatos Dublin Core

6. IMS QUESTION & TEST INTEROPERABILITY SPECIFICATION

6.1. INTRODUCCIÓN

Los exámenes son utilizados ampliamente como herramienta para evaluar si un

alumno ha asimilado los conceptos que le han sido presentados y como
herramienta de autoevaluación para el alumno, de manera que éste pueda
reforzar aquella parte de la materia para la que no tenga un dominio suficiente. En
este sentido, el uso de herramientas informáticas ha supuesto un avance. Un gran
número de tipos de preguntas pueden ser corregidas de manera automática
mediante el uso de este tipo de herramientas, de manera que un profesor puede
crear una batería de preguntas que el sistema informático puede utilizar para
preparar exámenes y corregirlos automáticamente.

De hecho, en la actualidad, gran parte de las plataformas de aprendizaje incluyen

con menor o mayor funcionalidad una herramienta para la creación, gestión y
realización de exámenes en línea. Sin embargo, acorde con la idea que se ha
venido transmitiendo en este informe, el esfuerzo realizado por el instructor en la
elaboración de preguntas y exámenes puede llegar a perderse si es necesario
cambiar de plataforma de aprendizaje.

Asimismo, ya que la creación de dichos exámenes requiere invertir cierto esfuerzo,

sería deseable tener la posibilidad de compartir este esfuerzo permitiendo el
intercambio de exámenes completos, o poder crear repositorios de preguntas. Así
mismo, estas preguntas deberían estar clasificadas por materias y por dificultades
para simplificar su localización y reutilización en la formulación de nuevos
exámenes.

Como ya se ha mencionado previamente, la especificación IMS Question and Test

Interoperability (IMS QTI) permite crear preguntas individuales y evaluaciones
completas. El objetivo principal de esta especificación es permitir el intercambio de
preguntas, evaluaciones y resultados entre distintas herramientas. Con este
propósito IMS QTI plantea un modelo en el que se definen los componentes
principales que intervienen en el proceso de evaluación y, adicionalmente a este
modelo, se proporciona un formato de contenido para almacenar las preguntas de
manera independientemente del sistema o herramienta de autoría utilizada para
crearlas.

Este formato, basado en XML, hace uso de estándares ampliamente utilizados en

el ámbito empresarial y técnico, permitiendo el uso de las mismas preguntas entre
diversos sistemas de gestión de aprendizaje o LMS, entre sistemas de evaluación
electrónica independientes y la integración en un único LMS de preguntas y
exámenes desarrollados con distintas herramientas. Por otro lado se propone un
sistema coherente para que los sistemas puedan informar de cual es el resultado
de una evaluación.

IMS QTI permite la construcción de almacenes o repositorios de preguntas que

sean directamente utilizables en distintos sistemas LMS (e incluso para crear e
imprimir exámenes tipo test que los alumnos realicen por escrito). Esto puede ser
muy útil cuando se generalice la representación mediante QTI de los repositorios
de libre acceso existentes. Por ejemplo, como ya hemos comentado previamente,
en la Universidad Complutense se dispone de una aplicación dedicada llamada
Comprueba (3) (figura 6.1.a) que tiene un extenso conjunto de preguntas de
distintas materias para que alumnos de enseñanzas medias preparen su prueba
de acceso a la universidad.

La generalización de este tipo de almacenes y su libre disposición en formato

compatible con otras plataformas puede simplificar mucho la tarea de los
docentes, especialmente dada la situación actual en la que diversos LMS
comerciales o libres dan algún tipo de soporte a este formato.

Figura 6.1.a . Aplicación Comprueba de la Universidad Complutense de Madrid.

En este caso se presenta una pregunta para la asignatura dibujo técnico
En el ámbito hispano, muy centrado en los exámenes de desarrollo de conceptos,
puede parecer que este tipo de exámenes basados en tests son una forma
excesivamente simplista de realizar evaluaciones pero la aceptación en la
industria y sobre todo en el mundo anglosajón de este tipo de pruebas es muy
grande. De hecho es mediante pruebas, principalmente de tipo test y con
corrección automática, con lo que se otorgan calificaciones para saber el nivel de
inglés de los alumnos que quieren cursar estudios en universidades americanas o
con los que se puede obtener acreditaciones profesionales respaldadas por
empresas en el campo informático.

6.2. HISTORIA DE IMS QTI

IMS QTI es una de las especificaciones en las que el consorcio IMS trabajó más
tempranamente (los primeros trabajos se realizaron en 1999). Sin embargo, el
potencial de la especificación IMS QTI no se ha explotado completamente debido
en parte a su complejidad y a la escasa existencia de herramientas informáticas
que pusieran en práctica (habitualmente de manera parcial) la especificación. En
la historia de IMS QTI hay 3 versiones de la misma que han tenido una gran
repercusión: IMS QTI versión 1.2, IMS QTI versión 2.0 y finalmente IMS QTI
versión 2.1.

IMS QTI versión 1.2 (aparece en 2002) es la última versión finalizada

completamente en la que se abarcan tanto preguntas individuales como exámenes
completos. Una vez publicada la especificación, surgieron diversos problemas a la
hora de implementarla. Aunque se publicó una suplemento (IMS QTI 1.2.1), parte
de los problemas que habían surgido requerían de grandes cambios de manera
que dichas modificaciones provocarían que se perdiera la compatibilidad con las
versiones anteriores. Además, algunas otras partes de la especificación
necesitaban clarificarse o extenderse para resolver los problemas que habían
surgido durante su puesta en práctica.

Desde la aparición de IMS QTI 1.2 y con el desarrollo de nuevas especificaciones

como el IMS Content Packaging, IMS Simple Sequencing y IMS Learning Design
surgió la necesidad de hacer compatible la especificación IMS QTI a las nuevas
iniciativas. Así apareció la versión 2.0 (2005) de la especificación donde se
comenzó con la armonización con las otras especificaciones y el comienzo de la
resolución de los problemas de la antigua especificación. Sin embargo, para
simplificar el proceso de adopción y permitir un trabajo razonable, esta
especificación ser concentró sólo en las preguntas individuales y no actualiza
aquellas partes que tienen que ver con la composición de dichas preguntas, es
decir, la creación de exámenes completos.

Mientras que las versiones anteriores de la especificación se centraban

principalmente en cómo se presentaba finalmente la pregunta, ahora se definen
los posibles tipo de interacciones por parte del usuario (e.g. seleccionar uno o más
elementos de una lista, crear asociaciones entre elementos de dos listas,
introducir texto, seleccionar un trozo de texto de un texto mas largo, etc). Además
de todas las interacciones contempladas introduce un tipo de interacción propio
para poder extender el modelo y crear nuevas formas de interacción para poder
introducir nuevos tipo de preguntas. Es decir QTI no es modelo completo y cerrado
si no que permite que si una empresa lo considera oportuno pueda extenderlo y
ampliarlao (eso sí esos nuevos tipo de preguntas creados por ampliación no
serían reconocidos necesariamente por otro sistema QTI).

También tiene plantillas de preguntas para crear familias de preguntas similares

pero en la que hay partes variables que se seleccionan de manera aleatoria entre
un conjunto de valores predefinidos.

Otra de las novedades que introduce son las preguntas adaptativas que permiten
al alumno realizar varios intentos sobre dicha pregunta. Esto permite, por ejemplo,
que el alumno pueda alterar su respuesta debido a la realimentación, por ejemplo,
la presentación de alguna pista en caso de que la respuesta sea incorrecta o
parcialmente incorrecta, o que se le planteen preguntas adicionales en función de
su respuesta actual.

IMS QTI versión 2.1 (aparece en 2006) está actualmente en proceso de evolución
en modo borrador sobre el que la comunidad, tanto educativa como técnica, puede
opinar. El objetivo de esta nueva versión es seguir con el proceso de simplificación
y evolución de la especificación, esta vez dando soporte a los exámenes
completos y al intercambio de los resultados de los mismos. Además también se
incluye información para clarificar la compatibilidad y el uso de IMS QTI con
algunas otras de las especificaciones ya existentes.

6.3. CONCEPTOS BÁSICOS DE IMS QTI V 2.X

Como se ha mencionado en la sección 6.2, la versión 2 de la especificación
intenta simplificar su uso tanto desde el punto de visa técnico como desde el punto
de vista del usuario de dicha especificación. Para ello, se han definido de manera
completamente independiente tres conceptos:

Las preguntas. Las preguntas individuales podrán ser utilizadas como un recurso
educativo independiente, por ejemplo, como un recurso más dentro de un paquete
IMS.

Los exámenes. Los exámenes son agrupaciones de preguntas que permitirán

resumir las evaluaciones conseguidas en las preguntas individuales en una única
evaluación del examen.

Resultados de los exámenes. La interacción de los alumnos con las preguntas

individuales y con los exámenes generarán diferentes registros de información que
puede ser recolectada para su posterior estudio.

6.4. LAS PREGUNTAS

Las preguntas individuales (assessmentItem) en QTI son auto-contenidas, es

decir, incluyen toda la información necesaria para su presentación al alumno y su
corrección automática. Toda la información relativa a la presentación ha sido
agrupada en el cuerpo (itemBody) de las preguntas. En la presentación de la
pregunta están involucrados dos aspectos:

El enunciado de la pregunta. Obviamente, la pregunta debe contener el enunciado

de la misma y, de manera adicional, puede contener material explicativo
complementario que permita al docente indicar el contexto en el que se realiza la
pregunta. En la especificación IMS QTI v 2.X, los contenidos que podemos utilizar
dentro del cuerpo de la pregunta siguen el estándar XHTML, es decir, contenido
web y además es posible utilizar el estándar MathML para la representación de
ecuaciones matemáticas.

La construcción de la respuesta. De manera adicional al enunciado de la pregunta,

debemos dotar al alumno del equivalente del lápiz y papel para poder construir la
respuesta. En el caso de IMS QTI v 2 se ha introducido el concepto de interacción
(interaction). Dependiendo del tipo la herramienta informática generará una
presentación acorde.

Figura 6.4.a . Estructura de un assessmentItem (pregunta) y su proceso de

evaluación
Adicionalmente a la definición de la presentación de las preguntas y junto a la
definición de la interacción se llevará a cabo para recolectar las respuestas, es
necesario especificar cómo corregir la pregunta. El funcionamiento de la
corrección es simple y directo (figura 6.4.a.). Cuando un alumno tiene que
responder a una pregunta, la herramienta presentará la pregunta y la interacción al
alumno. Como resultado de esta interacción obtendremos una representación de
la respuesta del alumno (figura 6.4.a, 1). Estas respuestas servirán como
información de entrada para el proceso de corrección (figura 6.4.a, 2), generando
finalmente una evaluación (figura 6.4.a, 3).

IMS QTI proporciona un arsenal de herramientas que nos permiten crear métodos
de evaluación con alto nivel de personalización, incluyendo la posibilidad de forzar
una determinada presentación. Sin embargo esto lleva a que el creador de la
pregunta necesite conocer en detalle la especificación IMS QTI e incluso tener
conocimientos de programación.

Para simplificar tanto la tarea de autoría como la creación de herramientas que

pongan en práctica IMS QTI se han definido un conjunto de plantillas de
corrección en la que se han tenido en cuenta los casos típicos de corrección.

Finalmente, también es posible que cuando creemos una pregunta no indiquemos

como corregirla automáticamente, en este caso, es necesaria la intervención
externa (e.g. del profesor) para llevar a cabo la corrección de la misma, es decir,
para crear la evaluación de la pregunta. Habitualmente sólo necesitamos indicar
cuales de las opciones son correctas.

INTERACCIONES

En el caso de IMS QTI no está contemplado el concepto de tipo de pregunta,

existiendo en su lugar el concepto de interacción. Las interacciones permiten al
profesor especificar las herramientas que tendrá el alumno disponible para poder
construir la respuesta.

Al igual que existen múltiples tipos de pregunta, también existen múltiples tipos de
interacción. A continuación se describirán los tipos de interacciones posibles que
pueden utilizarse dentro de una pregunta.

Hay que remarcar que existen dos grupos de interacciones, las interacciones en
línea y las interacciones en bloque. Las interacciones en línea son un tipo de
interacción que pueden incluirse en medio del enunciado de la pregunta. Por otra
parte las interacciones de tipo bloque están pensadas para ser presentadas de
manera independiente al enunciado de la pregunta.

Para ejemplificar las posibles interacciones que se nos ofrecen y debido a la falta
de herramientas que proporcionen un soporte completo a la especificación,
haremos uso de los ejemplos que se nos ofrecen en la propia especificación.

6.5.1. Interacciones simples

Las interacciones simples con aquellas interacciones en las que la corrección de

las mismas se realiza en base a la selección de una opción o varias opciones
disponibles. Las interacciones que pertenecen a esta categoría son:

choiceInteraction. Esta interacción muestra al alumno un conjunto de posibles

opciones. El alumno podrá seleccionar una o varias posibles opciones como
respuesta. Es posible indicar que el conjunto de posibles opciones sea barajado
entre distintos intentos del alumno.

orderInteraction. En esta interacción el objetivo del alumno es reordenar el

conjunto de soluciones proporcionada. Además, es posible un número mínimo y
un número máximo de opciones que conforman la solución, de manera que se
realizaría una selección sobre las opciones disponibles y posteriormente se
realizaría una ordenación de los elementos de dicha selección.

associateInteraction. Esta interacción presenta al alumno un conjunto de

opciones y permite crear asociaciones por parejas entre dichas opciones. Es
posible indicar el número mínimo y máximo de asociaciones que deben crearse
como parte de la respuesta. Además, también es posible indicar el número mínimo
y máximo de veces que una de las opciones puede aparecer dentro de una
asociación.
matchInteraction. Esta interacción presenta al alumno dos conjuntos de opciones
y le permite crear pares de asociaciones entre ellas. Al igual que en la interacción
anterior es posible indicar el número mínimo y máximo de asociaciones posibles o
el número mínimo y máximo de apariciones de una de las opciones en las
asociaciones creadas.

gapMatchInteraction. Esta interacción permite definir un conjunto de huecos

dentro del enunciado de la pregunta a mostrar al alumno. Además se permitirá al
alumno asociar a cada uno de los huecos una de las posibles opciones de
respuesta. Hay que destacar que las opciones posibles son compartidas por todos
los huecos. Como posibles respuestas es posible utilizar texto o también es
posible utilizar imágenes. Además es posible restringir el número mínimo y
máximo de veces que es utilizada cada una de las posibles opciones del conjunto
de respuestas.

Figura 6.5.1.a. Ejemplo de choiceInteraction. Captura tomada mediente la

herramienta <e-QTI> en desarrollo en la Universidad Complutense de Madrid

Figura 6.5.1.b. Ejemplo de ordeInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide
Figura 6.5.1.c. Ejemplo de associateInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide

Figura 6.5.1.d. Ejemplo de matchInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide
Figura 6.5.1.e. Ejemplo de gapMatchInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide.

Interacciones de texto

En esta categoría se encuentran las interacciones en las que la respuesta que

construirá el alumno puede ser una única palabra, una frase corta o un párrafo de
texto completo. Estas interacciones permiten que durante el proceso de corrección
se tenga en cuenta la respuesta en forma de texto que ha construido el alumno.
Las interacciones que pertenecen a esta categoría son:

 inlineChoiceInteraction (interacción en línea). Esta interacción está

pensada para definir un hueco donde se permitirá al alumno escoger entre
un conjunto de opciones, donde cada una de estas opciones una palabra o
frase corta. A diferencia de gapMatchInteraction, esta interacción está
ideada para que cada uno de los huecos pueda tener un conjunto de
opciones independiente. Es posible definir que las respuestas sean
barajadas entre distintos intentos del alumno.

 textEntryInteraction (interacción en línea). Al igual que la interacción

anterior, esta interacción tiene como objetivo crear un hueco donde se
 permitirá teclear una palabra o frase corta para poder construir la respuesta.
Cuando se define una pregunta con esta interacción es posible especificar
la longitud del texto que se espera que el alumno introduzca.

 extendedTextInteraction. Esta interacción está pensada para que el

alumno construya como respuesta un párrafo de texto. Es posible indicar el
número mínimo y máximo de líneas de texto esperadas, junto con la
longitud máxima de cada una de ellas.

 hottextInteraction. El objetivo de esta interacción es que el alumno

seleccione partes de texto que estarán resaltadas en el enunciado de la
pregunta. Es posible indicar el número mínimo y máximo de elecciones que
debe realizar el alumno, siendo 0, el valor mínimo, y 1, el valor máximo, de
selecciones por defecto.

Figura 6.5.2.a. Ejemplo de inlineChoiceInteraction. Fuente: IMS QTI v 2.1

Implementation Guide.

Figura 6.5.2.b. Ejemplo de textEntryInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide

Figura 6.5.2.c. Ejemplo de extendedTextInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide
Figura 6.5.2.d. Ejemplo de hottextInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide

Interacciones gráficas

Las interacciones gráficas tienen como elemento principal una imagen que se
utilizará como fondo del enunciado y sobre la que se realizarán todas las acciones
permitidas en las interacciones para que el alumno construya la respuesta. Las
interacciones que pertenecen a esta categoría son:

 hotspotInteraction. El objetivo de esta interacción es presentar al alumno

un conjunto de “puntos calientes” (hotspot) sobre una imagen utilizada
como fondo del enunciado. El alumno deberá seleccionar uno o varios de
 estos puntos calientes para construir la respuesta. Es posible especificar el
número mínimo y máximo de selecciones que debe realizar el alumno,
siendo 0, el valor mínimo, y 1, el valor máximo, de selecciones por defecto.

 selectPointInteraction. El objetivo de esta interacción es que el alumno

seleccione uno o varios puntos de una imagen utilizada como fondo del
enunciado. Al contrario que en la interacción anterior, no se le presentará al
alumno ninguna zona resaltada.

 graphicOrderInteraction. Esta interacción mostrará un conjunto de puntos

calientes sobre una imagen que será utilizada como fondo del enunciado. El
objetivo es que el alumno realice una ordenación de estos puntos calientes.
Al igual que la interacción orderInteraction, es posible definir el número
mínimo y máximo de opciones que formarán parte de la respuesta, de
manera que el alumno primero seleccionará las opciones y posteriormente
realizará la ordenación de las mismas.

 graphicAssociateInteraction. Esta interacción mostrará un conjunto de

zonas seleccionables o puntos calientes sobre una imagen que será
utilizada como fondo del enunciado. El objetivo de la interacción es permitir
al alumno la creación de pares de asociación entre los puntos calientes. Es
posible indicar el número máximo de asociaciones que el alumno puede
crear. Asimismo también es posible indicar el número mínimo y máximo de
cada uno de los puntos calientes dentro de las asociaciones creadas.

 graphicGapMatchInteraction. Esta interacción mostrará un conjunto de

puntos calientes sobre una imagen que será utilizada como fondo del
enunciado, además se proporcionará al alumno un conjunto de opciones. El
objetivo es que el alumno construya parejas entre los puntos calientes y las
opciones que le son proporcionadas. Hay que destacar que el conjunto de
opciones disponibles es compartido por todos los puntos calientes.
Asimismo, es posible definir el número mínimo y máximo de veces que
puede aparecer una de las opciones en una de la parejas creadas por el
alumno.

 positionObjectInteraction. En esta interacción el alumno colocará una

imagen le será proporcionada sobre alguna zona de otra imagen será
utilizada como fondo del enunciado. Esta interacción es similar a la
interacción selectPointInteraction, ya que tienen como objetivo seleccionar
puntos de la imagen que se utiliza como fondo, en el caso de la
interacción positionObjectInteraction esta posición seleccionada se marcará
con la imagen que se le proporciona al alumno. Es posible definir el número
mínimo y máximo de posibles selecciones que puede realizar el alumno.

Figura 6.5.3.a. Ejemplo de hotspotInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide.
Figura 6.5.3.b. Ejemplo de selectPointInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide.

Figura 6.5.3.c. Ejemplo de graphicOrderInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide.
Figura 6.5.3.d. Ejemplo de graphicAssociateInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide.
Figura 6.5.3.e. Ejemplo de graphicGapMatchInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide
Otros tipos de interacciones

En esta categoría se encuentran interacciones relativamente avanzadas. Las

interacciones que pertenecen a esta categoría son:

 sliderInteraction. Esta interacción muestra al alumno una barra deslizante

que permitirá al alumno seleccionar la respuesta correcta.

 mediaInteraction. Esta interacción está pensada para ser utilizada de

manera conjunta con alguna otra interacción. El objetivo de esta interacción
es permitir controlar el número de veces que un alumno visualiza un
material multimedia, de esta manera es posible incluir esta interacción con
un video como enunciado, e incluir alguna otra interacción que realmente
realice una pregunta acerca del enunciado. El número de veces que el
alumno visualice el vídeo puede utilizarse para cambiar la interacción o
simplemente puede ser utilizada para posteriormente realizar un estudio
estadístico acerca del número de veces que es necesario visualizar el vídeo
para poder responder a la pregunta.

 drawingInteraction. Esta interacción tiene como objetivo permitir al alumno

pintar sobre una imagen proporcionada en el enunciado. El resultado de la
pregunta será la propia imagen modificada.

 uploadInteraction. Esta interacción tiene como objetivo permitir al alumno

crear una respuesta a partir de un fichero que será enviado a la herramienta
desde el ordenador del alumno.

 customInteraction. Esta interacción tiene como objetivo servir como base

para la creación de interacciones particulares de cada herramienta que no
se puedan encuadrar a ninguna de las interacciones descritas
anteriormente.

Figura 6.5.4.a. Ejemplo de sliderInteraction.

Fuente: IMS QTI v 2.1 Implementation Guide
6.6 LOS EXÁMENES EN IMS QTI V 2.1

Un examen para IMS QTI es simplemente un grupo de preguntas. Durante el

proceso de creación podemos estructurar el examen en distintas partes (testPart).
Por ejemplo, si hemos impartido un módulo de un curso en el cual se discuten
distintos temas, podemos crear un examen en el que se crean distintas partes por
cada uno de esos temas. Asimismo, estas partes pueden dividirse en distintas
secciones (sections) que representan diferentes secciones dentro de una parte del
examen. Tanto las partes como las secciones de un examen pueden contener
materiales que serán presentados a los alumnos durante la realización de dicha
parte o sección.

El objetivo de las partes del examen es doble:

 Desde el punto del alumno, cuando realice el examen se le presentarán

cada una de las partes en las que está dividido el examen en el orden en el
que aparecen en la definición del examen.

 Desde el punto de vista del creador del examen, el uso de distintas partes
permite configurar distintas partes del examen, por ejemplo, indicando
alguna limitación en el tiempo que puede emplear un alumno en una parte o
sección (para mayor detalle consultar la sección 6.8.3).

Además de la estructuración, un objetivo adicional es la generación de una única

evaluación, es decir, de una nota que agrupe todas las evaluaciones individuales
de las preguntas, ponderándolas con algún factor si fuera necesario. Para ello,
durante la creación del examen se puede definir como ha de realizarse la
agrupación de las evaluaciones individuales.

Finalmente hay que destacar que desde el punto de vista de QTI la creación de un
examen se realiza de manera completamente independiente de las preguntas de
las que está compuesto. Al intercambiar un examen entre la herramienta de
autoría y la herramienta que interpreta la descripción del examen, este intercambio
se realiza creando un paquete de intercambio definido mediante el uso de la
especificación IMS Content Packaging (ver el capítulo dedicado a describir esta
especificación).

Figura 6.6.a. Estructura de un examen (assessmentTest) completo.

Figura 6.6.b. Vista del módulo de edición de exámenes de la herramienta <e-QTI>
.7. RESULTADOS Y ESTADÍSTICAS

Además de permitirse el intercambio de la definición de las preguntas y de los

exámenes, IMS QTI también permite el intercambio entre distintas herramientas
de un informe en el que se incluyen los resultados que ha obtenido un alumno
cuando ha realizado un examen concreto o cuando ha respondido a una o varias
preguntas aisladas.

Dentro del informe se puede incluir la siguiente información:

 Identificación del alumno. Se incluye la información necesaria para

identificar al alumno, esta información se encuentra codificada utilizando la
especificación IMS Learning Information Profile.

 Identificación del examen y/o preguntas. Se incluye la información

necesaria para identificar que herramienta ha generado el informe, además
de la información necesaria para identificar los exámenes y las preguntas a
las que hace referencia este informe.

 Informe acerca de las preguntas individuales realizadas por el

alumno. Esta información incluye las respuestas que ha creado el alumno a
partir de las interacciones, la información relativa a las respuestas
 correctas, si se ésta encuentra disponible, y finalmente la información
generada tras la corrección de las respuestas proporcionadas por los
alumnos.

 Información acerca de los exámenes. Esta información incluye el

resultado de la agregación de las evaluaciones de las preguntas
individuales.

Además de la información específica para un alumno, examen y preguntas

particulares, también es posible realizar el intercambio de información estadística
acerca de los resultados obtenidos por los alumnos en exámenes y preguntas. La
información que se intercambia incluye información como el número de muestras a
partir de las que se ha generado la información estadística, la media aritmética, la
varianza o a desviación típica.

Además también es posible intercambiar los resultados de la aplicación de otros

cálculos estadísticos habituales o incluso la aplicación de cálculos estadísticos
adaptados a nuestras propias necesidades.

Para simplificar su intercambio se hace uso de la especificación IMS Vocabulary

Definition Exchange para poder describir, tanto para las herramientas software,
cómo para los actores humanos, los algoritmos estadísticos.

6.8. CONCEPTOS AVANZADOS

Además de las posibilidades vistas hasta ahora la especificación IMS QTI permite
que podamos crear preguntas y exámenes utilizando funcionalidades avanzadas,
las cuales requieren tanto un mayor conocimiento de la propia especificación
como un mayor esfuerzo desde el punto de vista técnico. Debido a estos requisitos
es posible que alguna de las características no estén disponibles en todos las
herramientas de gestión de evaluaciones que sean compatibles con QTI.

A continuación se describen las características avanzadas más relevantes.

6.8.1. Intentos y sesiones de interacción

El proceso de interacción típico de alumno con una pregunta, denominado intento,

consta de tres pasos:

Primero. Se presenta al alumno el enunciado de la pregunta, incluyendo algún

contenido adicional que especifique el contexto de la pregunta.

Segundo. El alumno construye la respuesta utilizando las herramientas

proporcionadas por la interacción que el profesor ha elegido para la pregunta.

Tercero. El alumno envía la respuesta para que esta sea corregida.

Habitualmente, sólo se lleva a cabo un intento por pregunta, sin embargo, en la
especificación se ha tenido en cuenta la posibilidad de que un alumno realice
varios intentos sobre la misma pregunta, denominándose a este conjunto de
intentos como sesión de interacción. Además también está contemplado que un
alumno pueda suspender el intento, es decir que el alumno puede construir
parcialmente la respuesta pero sin enviar la respuesta para su corrección. De esta
manera, el alumno puede pasar a otra pregunta del examen y posteriormente
puede volver a la pregunta suspendida y terminar el intento.

Los intentos son importantes ya que dentro del proceso de corrección se va

permitir la posibilidad de presentar nueva información al alumno entre intentos
haciendo uso del mecanismo de realimentación. Asimismo, es posible modificar
incluso la propia pregunta, por ejemplo, al fallar los dos primeros intentos podría
darse un tercer intento final en el cual el enunciado de la pregunta y la interacción
a utilizar para construir la pregunta fueran distintas a la original.

6.8.2. Preguntas dinámicas: realimentación, preguntas adaptativas y

preguntas compuestas

Cuando diseñamos una pregunta podemos hacerlo teniendo en mente que un

alumno pueda interactuar varias veces con dicha pregunta. La idea es que durante
el proceso de creación de la pregunta vamos a poder añadir contenidos e
interacciones adicionales que en el primer intento del alumno van a estar ocultas
pero que en intentos sucesivos pueden aparecer según las respuestas del alumno
y los resultados del proceso de corrección posterior.

Al tipo de preguntas donde el proceso de corrección y el contenido de la pregunta

se modifica dependiendo de cada intento del alumno son denominadas preguntas
adaptativas.

El mecanismo de realimentación puede ser utilizado en numerosas situaciones,

algunas de ellas son:

Cuando un alumno ha fallado una pregunta, podemos mostrarle un mensaje

indicando que ha fallado la pregunta, o podemos incluir alguna pista para que el
alumno pueda responder correctamente a la pregunta.

Tras finalizar el último intento de la pregunta, podemos mostrar un mensaje al

alumno informándole de cual era la respuesta correcta.

En el último intento de una pregunta, podemos hacer que aparezca una nueva
interacción en la que se permita al alumno construir una respuesta de manera más
simple, de forma que el resultado final de la pregunta será la evaluación de esta
nueva interacción.
Algunas interacciones como, por ejemplo, la interacción choiceInteraction en la
que se describe cada una de las posibles respuestas de la pregunta, podemos
modificar dicha descripción. Además tras el proceso de corrección se puede
mostrar un mensaje indicando que dicha opción es incorrecta, de manera que el
mensaje se mantendrá durante los restantes intentos del alumno.

La figura 6.8.2.a muestra un ejemplo de pregunta acerca de la geografía española.

Esta pregunta hace uso de la interacción hotspotInteraction, definiendo un
conjunto de puntos calientes para cada una de las provincias de la comunidad de
Castilla La Mancha. En el primer intento sólo se muestra el mapa de España, el
enunciado de las pregunta y finalmente se marcan los puntos calientes. En el
ejemplo, el alumno selecciona en el primer intento la provincia de Cuenca. Cuando
el alumno finaliza el intento, es decir, cuando envía la respuesta se corrige y se
descubre que el alumno ha fallado. En el siguiente intento del que dispone el
alumno, se le vuelve a mostrar la misma interacción y enunciado, pero esta vez se
le muestra un mensaje adicional informando que la opción seleccionada es
incorrecta. Hay que destacar que en este caso debe estar seleccionado el punto
caliente que había seleccionado inicialmente el alumno.

Fig. 6.8.2.a . Ejemplo de pregunta con un hotspotInteraction con retroalimentación.

(a) Presentación de la pregunta en el primer intento. (b) Presentación de la
pregunta en el segundo intento. La respuesta seleccionada se presenta de nuevo
junto al mensaje de retroalimentación [La imagen (a) incluye el mapa de España
mostrando puntos calientes para cada una de las provincias de Castilla la Mancha.
El enunciado de la pregunta es: ¿Cuál de las provincias destacadas es Toledo?.
La imagen (b) incluye el mapa de España mostrando puntos calientes para cada
una de las provincias de Castilla la Mancha, esta vez, con la provincia de Cuenca
seleccionada. Además de volverse a mostrar la pregunta, se muestra un mensaje
indicando al alumno que ha seleccionado la provincia de Cuenca, exhortando al
alumno para que intente de nuevo].
El uso de varias interacciones dentro de una pregunta, no está restringido sólo a
las preguntas adaptativas. En el proceso de creación de una pregunta en la que el
alumno no tenga varios intentos posibles, también es posible hacer uso de varias
interacciones independiente dentro de la definición de la misma pregunta, de
forma que las interacciones son evaluadas de manera independiente. Este tipo de
preguntas son denominadas preguntas compuestas.
Por ejemplo, el profesor puede utilizar esta característica para definir alguna
pregunta adicional que utilice el mismo enunciado, por ejemplo, para poder
asignar una puntación extra. Debemos resaltar que cada una de estas
interacciones se corregirá de manera independiente.

Exámenes dinámicos

De manera adicional a la creación de preguntas dinámicas, es posible definir

exámenes dinámicos. Cuando se diseña un examen, existen dos posibilidades
para crear exámenes dinámicos dependiendo de si el examen se modifica antes
de que el alumno intente responder a alguna de las preguntas que lo componen o
bien la modificación del examen que se realizará durante la propia realización del
examen.La modificación de un examen puede llevarse a cabo de manera previa a
la realización del examen, donde en este caso el examen actúa como plantilla. El
resultado final es que las secciones del examen se ven afectadas dependiendo del
resultado de la aplicación de un conjunto de reglas. Estas reglas estarán definidas
en las secciones del examen y afectaraán a las otras secciones y preguntas que
puede contener una sección. La idea es que dentro de las secciones se ordenarán
de manera aleatoria las secciones y preguntas contenidas, siendo posible
seleccionar un número de ellas posteriormente a la reordenación de las mismas.

Por ejemplo, en la figura 6.8.3.a podemos observar la estructura de una parte de

un examen en el momento de la autoría (figura 6.8.3.a, 1). Posteriormente (figura
6.8.3.a, 2) se seleccionan las dos primeras secciones de una parte del examen,
donde también podemos observar como en la sección S4 las dos preguntas han
sido reordenadas.

Figura 6.8.3.a . Ejemplo de examen dinámico. (1) Estructura original de una de las
partes del examen. (2) Estructura de la parte del examen tras aplicar las reglas de
selección y ordenación
Asimismo, los exámenes que se modifican dinámicamente durante la realización
del examen son denominados exámenes adaptativos. El alumno atravesará las
partes del examen dependiendo de los resultados de la corrección de las
preguntas. Por ejemplo, se puede crear un examen con dos partes, de manera
que si no se obtiene una puntuación mínima en una parte del examen no se puede
avanzar a la siguiente parte del mismo.

6.8.4. Bancos de preguntas

En las versiones anteriores de IMS QTI se definía con una notación específica el
formato de intercambio de los bancos de preguntas. Sin embargo, en la versión 2
de la especificación se ha tenido en cuenta el uso de otras especificaciones y la
metodología utilizada para el intercambio de información realizada en el resto de
especificaciones de IMS.
Por ello, para realizar el intercambio de bancos de preguntas, simplemente es
necesario crear cada una de las preguntas de manera individual y posteriormente
utilizar la especificación IMS Content Packaging para intercambiar cada una de las
preguntas como un recurso independiente dentro de la definición del paquete IMS.

Figura 6.8.4.a. Paquete de intercambio compatible con la especificación IMS

Content Packaging. El archivo imsmanifest.xml hará referencia a otros archivos
que estarán dentro del paquete y que contendrán la definición de la pregunta

6.9. RELACIÓN CON OTRAS ESPECIFICACIONES

Parte de los objetivos de la versión 2 de QTI es hacer uso de las especificaciones

existentes para evitar solapamientos en las funcionalidades que ofrecen.

Algunas de las especificaciones y estándares que están relacionados con QTI son:

 IMS Metadata, IEEE LOM. Al igual que el resto de contenidos educativos, es

necesario la inclusión de metainformación que permita clasificar los contenidos. En
el caso de las preguntas y exámenes la metainformación es muy útil a la hora de
almacenar las preguntas dentro de los bancos de preguntas, de manera que
podríamos clasificar las preguntas según materias y dificultades, facilitando la
búsqueda dentro de dichos repositorios y la posible generación automática de
exámenes.

 IMS Learning Information Package. Como resultado de la realización del

examen se genera información relativa al expediente académico del alumno,
 además dentro de IMS QTI hace falta de alguna manera hacer referencia al
alumno que ha realizado el examen.

 IMS Learning Design. Como se menciona en el capítulo dedicado a esta

especificación, IMS Learning Design en el nivel B de la especificación hace uso de
las condiciones para poder modificar la Unidad de Aprendizaje dependiendo de la
evaluación de estas condiciones. Las condiciones incluyen la consulta de
propiedades que han sido definidas por el creador de la Unidad de Aprendizaje
para almacenar información según interactúe el alumno con la Unidad de
Aprendizaje. Una posible actividad en una Unidad de Aprendizaje puede ser la
realización de un examen, donde la puntuación de este examen será almacenada
en alguna propiedad de la Unidad de Aprendizaje, de manera que el cambio de
esta propiedad afecta a las condiciones y por tanto condicionará la puesta en
práctica de otras actividades.

 IMS Simple Sequencing, SCORM. Al igual que con IMS Learning Design, tanto
en IMS Simple Sequencing como en el caso particular del perfil de aplicación
SCORM, existe un conjunto de propiedades que condicionan como se
secuenciarán los Objetos de Aprendizaje. Al igual que en el caso de IMS Learning
Design, podemos condicionar que se le presente al alumno uno o varios Objetos
de Aprendizaje dependiendo de la nota que haya obtenido en el examen

6.10 HERRAMIENTAS RELACIONADAS

Existen diversas herramientas que proporcionan soporte en mayor o menor

medida a la especificación IMS QTI en sus diferentes versiones. Las herramientas
pueden ser divididas en tres categorías:

 Herramientas de Autoría. Herramientas que permitirán crear exámenes y

finalmente salvarlos en el formato IMS QTI.

 LMS. En este caso los LMS incluirán una herramienta de gestión de evaluaciones
en línea donde la herramienta permitirá importar y/o exportar las preguntas y
exámenes en formato IMS QTI.

 Reproductores y motores de ejecución. Los reproductores interpretarán

preguntas y exámenes compatibles con IMS QTI y permitirán realizar el examen.
Los motores de ejecución, proporcionan infraestructura y componentes varios para
la creación de herramientas de evaluación en línea, en este caso compatibles con
IMS QTI.

Algunas herramientas de autoría son:

Respondus (http://www.respondus.com)
QuestionMark’s Perception (http://www.questionmark.com)
Assesst Designer (http://www.xdlsoft.com/ad/)

Algunos LMS que proporcionan soporte para IMS QTI:

Dokeos (http://www.dokeos.com/)
Claroline (http://www.claroline.net)
SAKAI (http://www.sakaiproject.org)
.LRN (http://www.openacs.org)
OLAT (http://www.olat.org)
WebCT (http://www.webct.com)

Sistemas que permiten la visualización y ejecución de QTI:

<e-QTI> (http://www.e-ucm.es/projects/eQTI)
Q-Player (http://www.e-teach.ch/qplayer/)
APIS (http://apis.sourceforge.net/)
R2Q2 (http://www.r2q2.ecs.soton.ac.uk/)
MathQTI (http://mqat.sourceforge.net/)

ADL SCORM

7.1. INTRODUCCIÓN

Como se ha indicado en la visión general de los estándares ante la variedad de

propuestas de especificación provenientes de distintas organizaciones y los
posibles problemas derivados de la falta de coordinación entre estos grupos, en
Noviembre de 1997 el Departamento de Defensa de los Estados Unidos de
América y la Oficina de Políticas de Ciencia y Tecnología de la Casa Blanca
(White House Office of Science and Technology Policy, OSTP) lanzaron la
iniciativa Advanced Distributed Learning (ADL) con el objetivo de impulsar y liderar
los diversos esfuerzos orientados al empleo de las Tecnologías de la Información y
la Comunicación para la modernización del aprendizaje. Los objetivos principales
eran estimular el mercado del software educativo y fomentar la creación de
contenidos interoperables.

La visión de ADL era que las especificaciones (muchas de ellas descritas en este
informe) tenían la madurez suficiente pero faltaba un impulso que condujese a su
adopción masiva. Así, en lugar de proponer un nuevo estándar para competir con
especificaciones propuestas por otras organizaciones, ADL ha tratado de aunar las
ideas de las distintas especificaciones en un único modelo de referencia,
permitiendo así que los distintos grupos interesados tuviesen un objetivo claro y
bien definido.

Aunque ADL ha participado directa o indirectamente en diversos proyectos

relacionados con la mejora de los procesos de aprendizaje (incluyendo
videojuegos educativos, simulaciones, tutores inteligentes, etc.), la principal
aportación de ADL es SCORM (Modelo de Referencia para Objetos de Contenido
Compartibles, del inglés Sharable Content Object Reference Model) (ADL SCORM
2002, 2006), que especifica cómo se deben definir los objetos de aprendizaje, sus
metadatos, su empaquetamiento y su distribución. También se especifican los
mecanismos para secuenciar estos objetos y formar así cursos con estructuras
que pueden tener forma lineal o definir caminos educativos complejos. Todos
estos conceptos se definen empleando especificaciones previamente existentes.

SCORM ha tenido y tiene un gran impacto en el campo del aprendizaje a través de

Internet dado que tanto la industria como el mundo académico han reconocido el
liderazgo de ADL como entidad de referencia a la hora de valorar la calidad de los
procesos de aprendizaje. En la actualidad la compatibilidad con SCORM es el
principal punto de encuentro entre todas las organizaciones implicadas en el
campo del aprendizaje asistido por computadora. Ningún estándar ni ninguna
especificación aparecen mencionados tan a menudo como las siglas SCORM ni
en el campo académico ni en la industria. Trascendiendo incluso su gran utilidad
como estándar, el peso de ADL ha convertido a SCORM en un requisito
prácticamente indispensable de cara a la comercialización de un nuevo producto
de enseñanza.

7.2. LA ESPECIFICACIÓN SCORM

Según la visión de ADL, la presencia de las distintas especificaciones propuestas

por diversos grupos no resultaba suficiente para garantizar los siguientes objetivos
fundamentales identificados cuando la iniciativa fue lanzada:

 Poder trasladar cursos de un LMS a otro

 Reutilizar piezas de contenido en distintos cursos

 Secuenciar estos contenidos reutilizables con soporte para ramificaciones,

planes alternativos u otras estrategias de aprendizaje adaptables

 Realizar búsquedas en bibliotecas de contenido o repositorios a través de

distintos LMS

En particular, ADL se basó en la afirmación de que, aunque existiesen

especificaciones cubriendo estos aspectos de la interoperabilidad, en la práctica
esto no era posible por falta de implantación de las especificaciones en algunos
casos y por conflictos entre especificaciones en otros casos.

Así, desde su posición de liderazgo debida al respaldo de la Administración

Norteamericana, ADL propuso el modelo SCORM con el objetivo de establecer un
marco común para el aprendizaje asistido por computadora y basado en la red
Internet. Este marco común provee un conjunto de guías, especificaciones y
estándares basados en las especificaciones previamente existentes en el campo
propuestas por distintas organizaciones. En la actualidad, ADL sigue trabajando
con estas organizaciones colaborando en la evolución de los estándares y en la
mejora y el crecimiento de SCORM.
7.2.1. Objetivos

La definición del modelo SCORM, así como su evolución y las distintas decisiones
de diseño tomadas durante el proceso de especificación, se basan en 6 principios
esenciales ya descritos en temas anteriores y que en la visión de la Iniciativa ADL
se enuncian como:

 Accesibilidad: Definida como la posibilidad de localizar y acceder a

componentes instruccionales desde una ubicación remota y su envío a
otras muchas localizaciones.

 Adaptabilidad: Definida como la posibilidad de adaptar la enseñanza a

distintas necesidades individuales u organizacionales.

 Asequibilidad: Definida como la posibilidad de aumentar la eficiencia y la

productividad reduciendo el tiempo y el coste invertidos en la enseñanza.

 Durabilidad: Definida como la posibilidad de resistir la evolución de la

tecnología y futuros cambios sin incurrir en rediseños, reconfiguraciones o
recodificaciones excesivamente costosas.

 Interoperabilidad: Definida como la posibilidad de tomar componentes

instruccionales desarrollados en una ubicación determinada y empleando
unas herramientas y plataformas determinadas para su posterior aplicación
en otra ubicación y otro conjunto de herramientas y plataformas.

 Reusabilidad: Definida como la flexibilidad para incorporar componentes

instruccionales en múltiples contextos y aplicaciones

La aplicación de estos principios más o menos abstractos a la enseñanza a través

de Internet resulta en la definición de las habilidades que se intentan garantizar
mediante la implementación de SCORM:

Un LMS debería ser capaz de ejecutar contenido creado empleando herramientas

de distintos vendedores. Así mismo, un LMS debería ser capaz de intercambiar
información con este contenido para poder llevar a cabo su adaptación y evaluar el
camino a seguir en función de los resultados obtenidos con ese contenido.

Distintos LMS desarrollados por distintos vendedores deberían ser capaces de

ejecutar el mismo contenido y de intercambiar información con el mismo.

Distintos LMS desarrollados por distintos vendedores deberían ser capaces de

acceder a distintos repositorios de contenido ejecutable y ejecutar ese contenido.

En la concepción de SCORM se ha tenido además en cuenta el hecho de que los

LMS son una población heterogénea, con distintas capacidades, implementados
con tecnologías diversas y con distintos objetivos comerciales. Por ello, la
especificación de SCORM se centra en definir las interfaces entre el contenido
instruccional y el LMS que los gestiona y ejecuta, dejando abierta la
implementación así como las distintas facilidades adicionales ofrecidas por LMS
como pueden ser foros de discusión, facilidades de comunicación o emisión de
certificados. Esto permite equilibrar la necesidad de mecanismos de
interoperabilidad con la libertad de innovar para obtener una ventaja competitiva.

7.2.2. La organización de SCORM

La especificación de SCORM se centra en 3 aspectos y para cada uno de ellos se

publica un documento técnico distinto estableciendo los detalles de dichos
aspectos.

Figura 7.2.2.a : La biblioteca SCORM (Fuente: SCORM 2004 3rd Edition)

Éstos son los documentos técnicos que forman la especificación SCORM:

 Modelo de Agregación de Contenido (Content Aggregation Model, CAM):

Este manual describe los distintos tipos de objetos de contenido permitidos
dentro de la especificación y detalla los mecanismos que se deben seguir
para su empaquetamiento, descubrimiento en repositorios y su distribución
e interoperabilidad entre distintos LMS

 Entorno de Tiempo de Ejecución (Run-Time Environment, RTE): El requisito

de adaptabilidad e intercambio de datos entre el contenido y el LMS da
lugar a contenidos educativos más complejos de lo habitual y es necesario
estandarizar el proceso de ejecución de estos contenidos para garantizar la
interoperabilidad entre distintos LMS. Por ello, este manual define el
proceso de ejecución y los mecanismos de comunicación que tanto el LMS
como el propio contenido deben emplear.
  Secuenciamiento y Navegación (Sequencing and Navigation, SN): Este
manual define los mecanismos para que los LMS puedan concatenar las
actividades educativas de modo consistente. El manual recoge los eventos
que pueden ser generados por los alumnos o por el sistema y que deben
ser procesados por el LMS para decidir cual es el recurso educativo que
debe ser servido a continuación. También se recoge el modelo de datos
para generar y procesar estos eventos

7.2.3. SCORM y otros estándares

Como ya se ha mencionado, SCORM no consiste en una especificación que

compita con las ya existentes en el campo. Al contrario, SCORM agrupa diversas
especificaciones de diversos organismos y colabora con dichos organismos en la
evolución de estas especificaciones. En particular SCORM integra las siguientes
especificaciones de grupos como IMS Global Consortium, ARIADNE, AICC o
IEEE-LTSC:

 IEEE Learning Object Meta-data 1484.12 (IEEE LOM 2002): Empleado en

el Modelo de Agregación de Contenido para definir los Metadatos de los
objetos de contenido.

 IEEE ECMAScript API for Content to Runtime Services Communication

1484.11.2 (IEEE EACRSC 2003): Empleado por el Entorno de Tiempo de
Ejecución para definir el mecanismo de comunicación entre el contenido y
el LMS

 IEEE Data Model for Content Object Communication 1484.11.1 (IEEE

DMCOC 2002): Empleado por el Entorno de Tiempo de Ejecución para
definir el modelo de datos empleado en la comunicación entre el contenido
y el LMS

 AICC/Web-Based CMI Guidelines (AICC WBCMIG 1998): Empleado para

definir la estructura del contenido en el Modelo de Agregación de
Contenido.

 IMS Content Packaging (IMS CP): Empleado en el Modelo de Agregación

de Contenido para agrupar objetos de contenido.

 IMS Simple Sequencing (IMS SS): Empleado para el secuenciamiento de

actividades en un curso.
7.3. MODELO DE AGREGACIÓN DE CONTENIDO

El Modelo de Agregación de Contenido de SCORM representa el punto de partida

a la hora de crear paquetes de contenido que pueden ser divididos en partes
interoperables. Para ello se concibe un proceso en el diseñan e implementan
procesos educativos mediante la creación y agregación de recursos simples
formando recursos educativos complejos que a su vez se organizan en una
determinada secuencia. El Modelo de Agregación de Contenido especifica los
requisitos en los que se apoya este proceso definiendo:

 Un Modelo de Contenido: Nomenclatura de los elementos que componen

un proceso educativo.

 Un Modelo de Empaquetamiento: Definición de cómo representar la

estructura del contenido y como agregar distintos recursos educativos para
su transporte entre distintos entornos

 Metadatos: Un mecanismo para la descripción del contenido generado que

permita realizar búsquedas y catalogaciones de este contenido

 Secuenciamiento: Un modelo basado en reglas que describe el orden en

que deben ejecutarse los distintos recursos educativos.

Las siguientes secciones se centran en mostrar los conceptos principales en cada

uno de estos apartados. Allí donde corresponda, se empleará una versión
modificada del curso de Introducción a la Geometría planteado en el capítulo
sobre IMS Content Packaging para ilustrar los conceptos presentados.

En este caso, el curso es un poco más complejo e incluye los siguientes

elementos de contenido tal y como se muestran en la Figura 7.3.a:

Un tutorial. Dicho tutorial consta de cuatro archivos HTML: principal.html, con la

presentación del tutorial, intro.html, con una introducción, conten.html, con el
contenido, y res.html, con un resumen. Desde conten.html se refieren dos
imágenes: fig0.1.jpg y fig0.2.jpg.

Dos temas de contenido más detallado. Cada tema está formado por un fichero
HTML (Tema1.html y Tema2.html) y una imágen de apoyo (Fig1.1.jpg y Fig2.1.jpg).

Dos posibles ejercicios de evaluación de complejidades distintas. Cada ejercicio

consta de un archivo XML que sigue la especificación IMS QTI (ver el capítulo
dedicado a esta especificación): ej1.xml y ej2.xml. Este material está colocado en
la subcarpeta ejercicios. El segundo ejercicio es más complicado que el primero.
Figura 7.3.a : Los ficheros que forman el curso de Introducción a la Geometría

El profesor está preocupado por aquellos alumnos que apenas revisan el material
del curso e intentan directamente resolver los ejercicios para superar el curso
cuanto antes. Para evitar esto, el autor quiere introducir dos restricciones:

 Es imprescindible leer, por lo menos, el tutorial. Hasta que el alumno no ha

leído las cuatro secciones del tutorial, no es posible acceder a los temas ni
a los ejercicios.

 Si el alumno no ha consultado debidamente todos los contenidos del curso,

se le presentará el segundo ejercicio (más complicado) en lugar del primer
ejercicio.

7.3.1. Definiciones en el modelo de contenido

Recursos

El elemento más sencillo en el Modelo de Contenido definido por SCORM sería

un recurso (del inglés, Asset). En esencia, el recurso es el elemento básico de
construcción con el que representamos el contenido. Ejemplos habituales
de recursos serían un documento HTML, un fichero de sonido, un vídeo o una
imagen.

Figura 7.3.1.a: Recursos simples y Recursos Compuestos en el caso de estudio

Así, en el caso de estudio los ficheros HTML con el contenido, las imágenes y los
ejercicios de evaluación serían definidos como recursos en el ámbito de la
especificación SCORM.

Habitualmente los recursos se combinan para formar recursos más complejos,

como es el caso de un documento HTML que incluye una o varias imágenes.
Estos recursos compuestos reciben el mismo tratamiento conceptual que los
recursos simples.

En el caso de estudio, la unión del fichero conten.html y los ficheros Fig0.1.jpg y

Fig0.2.jpg formarían un recurso compuesto. Así mismo las uniones entre los
ficheros HTML de los dos temas y sus respectivas imágenes son también recursos
compuestos.

Objeto de Contenido Compartible

La mera agrupación de ficheros en recursos simples y compuestos es interesante

desde el punto de vista de la interoperabilidad, pero no representa ningún avance
en cuanto a la complejidad del proceso de aprendizaje planteado.

En particular, no permite atender las restricciones propuestas en el caso de

estudio de controlar el acceso a todos los recursos, el tiempo empleado en
resolver los ejercicios o el poder escoger entre los dos ejercicios de evaluación.

Por ello, Objetos de Contenido Compartible (Sharable Content Object, SCO)

representan el núcleo de la especificación SCORM y se definen como una
colección de uno o más recursos que representa un elemento educativo indivisible
y que emplea el Entorno de Tiempo de Ejecución de SCORM para comunicarse
con un LMS. Esto es, a la noción de recurso (simple o compuesto) se le añade la
capacidad de comunicarse con el LMS para que éste pueda tomar decisiones en
función de cómo interactúa el alumno con el contenido. Este procedimiento de
comunicación se describe con más detalle más adelante en este capítulo.

La noción de indivisibilidad supone además que un SCO es el mínimo nivel de

granularidad que recibe un seguimiento individual por parte de un LMS. Esto es,
desde el punto de vista del LMS los SCOs nunca están compuestos de otros
elementos menores, sino que se tratan como entidades atómicas.

Paralelamente, los SCOs se conciben como la unidad interoperable habitual, es

decir, un SCO se identifica con la noción de Objeto de Aprendizaje Interoperable
tal y como se definía en el capítulo introductorio sobre conceptos, y en (Wiley
2000). Por tanto, para permitir aplicar los principios del Modelo de Objetos
Educativos, los SCOs deben concebirse como unidades relativamente pequeñas y
autocontenidas, aunque la especificación no cuantifica el tamaño preciso que
éstos deben tener debido a que el equilibrio entre tamaño y cohesión dependerá
de las necesidades de cada caso concreto.

En nuestro caso de estudio, el autor quiere comprobar si el alumno ha accedido a

cada parte del curso cuánto tiempo empleó para estudiar el tutorial y cada unos de
los temas. Concibiendo cada tema y sus imágenes asociadas como un objeto
educativo el autor emplearía una herramienta de autoría compatible con SCORM
para generar un SCO a partir de estos ficheros. Cada SCO resultante sería un
conjunto formado por el fichero HTML, sus figuras de apoyo y un módulo que
monitoriza el tiempo que el alumno pasa estudiando el tema correspondiente y
que se comunica con el LMS para notificarle la información relevante. El contenido
ya no son piezas pasivas que el alumno lee, sino objetos activos de gran
complejidad.
En cuanto a la noción de indivisibilidad, el tutorial está concebido como una unidad
indivisible (los distintos ficheros HTML que lo componen carecen de sentido por
separado), por lo que todos los ficheros HTML que lo conforman así como las
imágenes de apoyo se agruparían en un único SCO.

Paralelamente, la herramienta de creación de contenidos debe permitir al autor

crear SCOs a partir de los ejercicios de evaluación, incluyendo en el SCO el
mecanismo para comunicarle al LMS el resultado del ejercicio.

Figura 7.3.1.b: SCOs correspondientes al caso de estudio

Cabe destacar que la especificación SCORM no detalla como se deben

implementar tecnológicamente estos objetos inteligentes, limitándose a especificar
un mecanismo de comunicación independiente de la tecnología. Esto deja a los
distintos fabricantes de herramientas la libertad de escoger cómo implementar
estas cuestiones y además permite que el autor no tenga que preocuparse de
estos detalles. Simplemente deberá emplear una herramienta certificada por
SCORM (ver sección 7.5) e indicar qué información desea que el SCO le transmita
al LMS.

Actividades, organizaciones y agregaciones de contenido

En SCORM el término actividad representa un elemento de aprendizaje

significativo a la hora de estructurar y secuenciar el aprendizaje. Una actividad
habitualmente estará asociada con un SCO o con un recurso (simple o
compuesto) y puede incluir además diversas sub-actividades. Los árboles de
actividades y sub-actividades se agrupan en conjuntos
denominados organizaciones, que definen como las actividades se agrupan y
relacionan entre sí.

Figura 7.3.1.c: Actividades, organizaciones y agregaciones de contenido (Fuente:

SCORM 2004 3rd Edition)

A un conjunto de organizaciones unido a todos los recursos físicos (ficheros)

referenciados por las distintas actividades se le denomina agregación de
contenido.

Figura 7.3.1.3.b: Actividades, organizaciones y agregaciones de contenido

(Fuente: SCORM 2004 3rd Edition)
Nuestro ejemplo incluye dos actividades principales (estudiar el contenido y
realizar el ejercicio correspondiente). Como se observa en la Figura 7.3.1.3.b,
estas actividades se dividen en 5 sub-actividades correspondientes a los SCOs
que forman este curso (Tutorial, Tema 1, Tema 2, Ejercicio 1 y Ejercicio 2).

7.3.2. Empaquetamiento de contenidos

Para el empaquetamiento de contenidos SCORM opta por adoptar (y

particularizar) la especificación IMS Content Packaging. Esta especificación,
descrita con más detalle en el capítulo especialmente deciada a la misma de este
documento, indica el formato en el que deben agruparse las colecciones de
ficheros con material educativo y, fundamentalmente, detalla la sintaxis de un
fichero en el que se describen y estructuran los contenidos de un determinado
paquete de contenido. A este fichero se le denomina manifiesto del paquete y
suele incluir metadatos, información de secuenciamiento y otras indicaciones que
convierten a una determinada agrupación de contenidos en un curso estructurado.

Como también se mencionaba en el capítulo sobre IMS Content Packaging, la

especificación no es estricta y permite la particularización de la sintaxis del
manifiesto para adaptar la especificación a distintos entornos y satisfacer las
necesidades de las distintas organizaciones. Estas particularizaciones se
denominan Perfiles de Aplicación (del inglés, Application Profiles)

La especificación SCORM define dos perfiles de aplicación sobre IMS Content

Packaging para atender dos tipos de mecanismo de interoperabilidad: Los
Paquetes de Contenido formados por Recursos (Resource Content Package) y los
Paquetes de Contenido formados por Agregaciones de Contenido (Content
Aggregation Content Package).El primer perfil de aplicación (Paquetes de
Contenido formados por Recursos) se emplea para empaquetar conjuntos de
recursos y SCOs sin tener que especificar una organización o un contexto de
aprendizaje. Este tipo de empaquetamiento de los contenidos educativos ofrece
un medio común para el intercambio simple de recursos y es el mecanismo
recomendado por SCORM para la interoperabilidad de contenido (que no cursos)
entre distintos entornos de aprendizaje. Al no definirse ningún tipo de estructura,
los paquetes creados mediante este perfil de aplicación son transportables entre
sistemas pero carecen de estructura y por tanto no son paquetes diseñados para
ser consultados por los alumnos. En términos sencillos, estos paquetes son meras
colecciones de recursos educativos sin diseño instruccional ninguno.

En cambio, el perfil de aplicación de Paquetes de Contenido formados por

Agregaciones de Contenido se emplea para agrupar los distintos contenidos
educativos (recursos o SCOs) y la descripción de la estructura de estos
contenidos.

Con este perfil de aplicación se generan paquetes que representan cursos

completos, módulos, lecciones, etc. El principal objetivo de uno de estos paquetes
es ser navegado por un alumno a través de un LMS.

7.3.3. Metadatos

Aunque con carácter opcional, desde SCORM se promueve el empleo de

metadatos para describir el contenido y su aplicación a distintos niveles de
granularidad (recursos, SCOs, agregaciones de contenido, paquetes de contenido,
etc.). El modelo de metadatos sugerido por SCORM es el definido por el IEEE en
su estándar 1484.12.1-2002 para Metadatos de Objetos de Aprendizaje (en
inglés, Learning Object Metadata, LOM) en su sintaxis basada en XML y descrita
en el estándar IEEE 1484.12.3 Standard for Extensible Markup Language Binding
for Learning Object Metadata Data Model.

A pesar de que este modelo de metadatos se describe en la propia especificación

de SCORM, en ella se aclara que el uso de metadatos es opcional (aunque
recomendado) y que es posible incluso la adopción de otro modelo de metadatos.
En su versión 2004, la especificación recomienda que cada organización analice
su modelo de negocio y sus casos de uso y decida que tipo de política de
metadatos debe adoptar. En cualquier caso, y pese a esta libertad, el modelo IEEE
LOM para la descripción de metadatos se ha convertido en el estándar de facto en
el campo y de ahí la recomendación explícita realizada en la especificación.

Según las necesidades identificadas por cada organización, se pueden aplicar

metadatos a distintos niveles de granularidad según la jerarquía definida en el
Modelo de Agregación de Contenido de SCORM.
  Recursos simples: Aunque sólo consistan en un fichero, en ocasiones estos
ficheros tienen valor educativo por sí mismos, por lo que podrían ir
acompañados de metadatos. En el caso de estudio, las figuras podrían ir
acompañadas de metadatos que las describen.

 Recursos compuestos: Estos conjuntos de recursos simples suelen tener

un significado mayor que la suma de sus partes, por lo que podrían ir
acompañados de metadatos de un nivel más elevado.

 SCOs: Como unidad fundamental de aprendizaje y núcleo de la

especificación SCORM, se recomienda encarecidamente la aplicación de
metadatos a estos elementos. Todos los SCOs del caso de estudio
deberían ir acompañados de metadatos describiendo sus características y
su contenido.

 Actividades: Las actividades suelen asociarse con SCOs y recursos, pero

ocasionalmente son más complejas por lo que se emplean metadatos para
describir sus objetivos educativos más allá de los metadatos de sus
recursos o SCOs asociados.

 Agregaciones de contenido: Los conjuntos de actividades (unidos a los

recursos y SCOs asociados) tienen sentido como recorridos de aprendizaje
completos, por lo que podrían ir acompañados de metadatos describiendo
la experiencia de aprendizaje.

Paquetes de Contenido: Independientemente del perfil de aplicación, los paquetes

de contenido son la unidad fundamental de interoperabilidad y distribución, por lo
que se recomienda encarecidamente la inclusión de metadatos que permitan el
descubrimiento y catalogación de estos paquetes.

Cabe señalar también que el propio modelo de metadatos especificado en IEEE

LOM incluye mecanismos de extensión y adaptación de los campos de metadatos
para aquellos entornos en los que el estándar resulte insuficiente o inadecuado. La
especificación SCORM acepta esta flexibilidad permitiendo el empleo de este
mecanismo de extensión al aplicar metadatos a los distintos elementos de la
especificación.

7.3.4. Información de secuenciamiento

La gestión del secuenciamiento de las actividades no forma parte del ámbito del
modelo de datos y, de hecho, la especificación SCORM incluye una sección
completa dedicada al secuenciamiento de las actividades en la que se describen
distintas metodologías de secuenciamiento y se detallan los aspectos técnicos de
dichas metodologías.
Pese a ello, los paquetes que siguen el perfil de aplicación de Paquetes de
Contenido formados por Agregaciones de Contenido pueden incluir en su
manifiesto información adicional recomendando un determinado secuenciamiento
de las actividades descritas en el paquete. Esta información será interpretada por
el LMS en el contexto de su mecanismo de secuenciamiento.

Los mecanismos de secuenciamiento en SCORM se basan en la

especificación IMS Simple Sequencing (IMS SS), la cual define los métodos para
representar el flujo de una experiencia de aprendizaje de un modo consistente.
Esta especificación, aunque rica y compleja, recibe la denominación simple debido
a que está orientada a soportar únicamente los patrones de secuenciamiento más
habituales en procesos de aprendizaje individualizado.

La parte dedicada a secuenciamiento de la especificación SCORM (SCORM

Sequencing and Navigation Book) describe como se aplica IMS Simple
Sequencing y especifica los comportamientos y funcionalidades que un LMS
compatible con SCORM debe implementar para procesar la información de
secuenciamiento leída de los paquetes en tiempo de ejecución.

La idea básica detrás de IMS Simple Sequencing es asociar a cada elemento de

un paquete SCORM una serie de reglas que gestionan si el alumno puede
acceder al elemento correspondiente o no. Estas reglas se indican mediante una
sintaxis XML que se incluye en el manifiesto del paquete de contenido (ver el
capítulo sobre IMS CP) al aplicar el perfil de aplicación de SCORM a IMS Content
Packaging.

Así, la especificación SCORM soporta los requisitos planteados en el caso de

estudio. Tanto los temas de contenido como los dos ejercicios están cubiertos por
reglas que especifican que si no se ha completado el tutorial, no es posible
acceder a los mismos.
Además, el ejercicio 1 tiene asociada una regla que especifica que sólo es visible
si el alumno ha leído también los temas 1 y 2, mientras que, por el contrario, el
ejercicio 2 tiene asociada una regla que especifica que sólo es visible si el alumno
no ha leído los mencionados temas. En la práctica, esto significa que una vez que
se termina de leer el tutorial, los dos temas de contenido y el ejercicio 2 (la versión
más difícil del examen) son directamente accesibles. Si el alumno lee
detalladamente los temas de contenido, el ejercicio 2 es sustituido por el ejercicio
1.

En cualquier caso, para que este sistema de reglas funcione, es necesario que el
LMS pueda saber si el alumno ha accedido a todas las partes del contenido para
poder controlar la activación de las reglas. El LMS adquiere este conocimiento
gracias a la posibilidad de comunicarse con los SCOs, tal y como se describe en el
siguiente apartado.

.4. EL ENTORNO DE TIEMPO DE EJECUCIÓN

En SCORM, el Entorno de Tiempo de Ejecución (del inglés, Run-Time
Environment o RTE) engloba la parte de la especificación relativa al lanzamiento y
ejecución de los objetos de contenido, la comunicación entre el contenido y el LMS
y la gestión de la información intercambiada en dicha comunicación.

El proceso de ejecución de cualquier tipo de contenido se inicia en el sistema de

secuenciamiento, el cual decide cual es el identificador de la pieza de contenido
que se debe mostrar al alumno. El LMS localiza la URL del contenido que se debe
mostrar a continuación y los transmite al navegador del alumno para su visionado.

Como se mencionaba en la descripción del Modelo de Agregación de Contenidos,

en SCORM se distinguen dos tipos de material educativo: Los SCOs (objetos de
contenido compartibles) y los recursos (Assets), consistiendo los primeros en
contenido activo con el que se puede interactuar y los segundos en documentos
pasivos que simplemente se muestran al alumno. Si el elemento que se debe
mostrar a continuación consiste en un recurso pasivo, la especificación
simplemente exige que el contenido sea transmitido al navegador del alumno
empleando el protocolo HTTP. Por otro lado, dado que los SCOs se definen como
elementos activos que se comunican con un LMS pero sin perder las capacidades
de interoperabilidad, la especificación debe detallar los mencionados procesos de
ejecución del contenido, el mecanismo de comunicación y la gestión de la
información intercambiada.

Ciertamente, el proceso de lanzamiento y ejecución debe estar estandarizado ya

que el SCO, al ser lanzado, debe establecer un canal de comunicación con un
LMS desconocido a priori. Esta comunicación se establece a través de un
elemento enviado junto con el SCO al navegador del alumno. Este elemento
consiste en una implementación de la API definida en el estándar IEEE 1484.11.2
y su provisión es responsabilidad del LMS, siendo el SCO completamente
independiente del mecanismo de comunicación.

La primera responsabilidad del SCO es buscar este elemento de comunicación en

una ubicación predeterminada (en el propio navegador del alumno) y, en caso de
encontrarlo, emplearlo para comunicarse con el LMS. Esta comunicación es
posible dado que el SCO y el LMS, pese a ser independientes, ambos conocen la
API disponible para la comunicación y la información que intercambian se envía
ciñéndose a un Modelo de Datos predeterminado por el estándar IEEE 1484.11.1.

El SCO seguirá comunicándose con el LMS hasta que algún evento dispare el
mecanismo de Secuenciamiento y el SCO sea sustituido por algún otro elemento
de contenido. Este evento puede ser una interacción intencionada del alumno
(solicita la visión del siguiente recurso o indica que ha terminado de trabajar con el
SCO actual), una indicación del propio SCO (por ejemplo, indicándole al LMS que
se ha llegado al final del contenido) o una decisión del propio LMS (por ejemplo,
detectando que se ha superado el tiempo máximo permitido para superar una
prueba o una pérdida de la conexión con el contenido).
SCORM define también el significado de los datos intercambiados y como deben
ser almacenados, procesados y utilizados por el LMS. En el caso de estudio los
distintos SCOs le comunicarán al LMS distintas informaciones relevantes. Los
SCOs de contenido le comunicarán al LMS si el alumno ha accedido a los mismos
y si ha llegado hasta el final del contenido para que el LMS pueda bloquear y
desbloquear los elementos correspondientes. Por su parte, los ejercicios deberán
comunicarle al LMS la nota obtenida por el alumno al realizarlos.

Figura 7.4.a: Esquema de la comunicación entre un SCO y un LMS. Los

elementos del SCO y del LMS pueden haber sido desarrollados por
organizaciones distintas empleando tecnologías distintas

7.5. COMPATIBILIDAD CON SCORM

La compatibilidad con SCORM se ha convertido en uno de los requisitos
habituales en la creación de un LMS o en las herramientas de autoría de
contenido educativo.

Para poder ser declarado conforme a la especificación SCORM un LMS debe

interpretar correctamente los paquetes de contenido, debe ser capaz de
establecer los mecanismos de comunicación apropiados con los objetos de
contenido y debe ser capaz de tratar los datos recibidos desde el contenido y de
emplearlos a la hora de secuenciar el proceso de aprendizaje.

Por su parte, que un paquete de contenido sea conforme a la especificación

SCORM significa que se distribuye según el Modelo de Agregación de Contenidos,
que se incluye información para la secuenciación del contenido y que sus SCOs
son capaces de buscar la implementación del mecanismo de comunicación y de
emplearlo de una manera consistente con las especificaciones correspondientes.
SCORM distribuye un paquete con los programas e instrucciones necesarios para
que una organización verifique si su LMS o sus paquetes de contenido se adaptan
a la especificación SCORM. Si se superan estas pruebas, la organización puede
afirmar que su producto es conforme a la especificación SCORM.

Por otro lado, existen centros oficiales de certificación que trabajan conjuntamente
con ADL. Cualquier organización puede acudir a estos centros para solicitar una
evaluación oficial de la compatibilidad de su LMS o de sus paquetes de contenido.
Cuando un producto supera las pruebas correspondientes en uno de estos
centros, se le puede denominar producto certificado SCORM.

Desde un punto de vista técnico, no existen diferencias entre un

producto conforme a la especificación SCORM y un producto certificado SCORM.
La principal diferencia reside en la confianza que pueda inspirar una organización
que ha realizado de manera interna las pruebas de compatibilidad frente al hecho
de que haya sido un centro de certificación independiente el responsable de
dichas pruebas.

Para más información sobre los procesos de certificación,

consúltese http://www.adlnet.gov/scorm/certified/index.cfm?
event=main.information

8. IMS LEARNING DESIGN

8.1 INTRODUCCIÓN

Las distintas especificaciones presentadas en este informe se centran en el

estudio de un modelo de aprendizaje en el que un alumno individual accede a un
contenido, interactúa con éste y, con la mediación del LMS, evalúa los
conocimientos adquiridos. Representan una tendencia ampliamente generalizada
en el campo del aprendizaje a través de Internet centrada en un tipo de enseñanza
muy particular y muy influida por la tecnología subyacente (i.e. acceso a
documentos HTML empleando un navegador). Así, las actividades de aprendizaje
que el alumno realiza suelen poder traducirse en “lee este fragmento de
contenido” o “realiza este ejercicio de evaluación con preguntas de respuesta
múltiple”.

En cambio, desde el campo de la pedagogía se promueven una serie de modelos

de aprendizaje en los que se dejan de lado los procesos en los que el alumno
trabaja en solitario consumiendo material educativo. Partiendo de la base
pedagógica de que el aprendizaje es más sencillo y efectivo cuando el alumno se
involucra en el proceso (Cordova y Lepper 1996), conceptos como el aprendizaje
en grupo, el aprendizaje colaborativo, la interacción con el entorno e incluso la
participación activa de instructores y otros individuos de apoyo son cada vez más
reconocidos como un modelo interesante tanto a nivel educativo (jardín infantil,
enseñanza primaria y secundaria) como a nivel corporativo (Wenger 1998).

Aunque ninguna de estas ideas supone una revolución desde el punto de vista
pedagógico (pues son ideas ya estudiadas y desarrolladas), el campo del
aprendizaje a través de Internet ha tardado en acercarse masivamente a estos
conceptos puesto que resultan excesivamente costosos de implementar en
comparación con el modelo de un alumno consumiendo contenidos en solitario.

Más allá de lo complicado que pueda resultar introducir modelos pedagógicos

complejos en la enseñanza a través de Internet, su interoperabilidad resulta aún
más problemática debido a la riqueza del campo a tratar. Para poder introducir
diseños pedagógicos complejos (habitualmente denominados también diseños
instruccionales) que involucren simultáneamente a distintos usuarios con distintos
roles de un modo que además sea interoperable, resulta necesario desarrollar
especificaciones que formalicen de manera precisa los elementos básicos de
estos diseños para así poder trasladarlos de un sistema a otro sin pérdida de
información.

A diferencia del resto de las especificaciones expuestas en este informe que se

centran en la interoperabilidad de contenidos educativos, el propósito de IMS
Learning Design es precisamente facilitar la interoperabilidad de diseños
instruccionales. Algunos de los requisitos de diseño de la especificación más
relevantes son los siguientes:

 Permitir la descripción, formalización e implementación de distintas

aproximaciones educativas y distintos procesos de aprendizaje.

 Permitir la implementación de Unidades de Aprendizaje consistentes en

actividades heterogéneas.

 Permitir el descubrimiento y la interoperabilidad de estas Unidades de

Aprendizaje.
  Aprovechar las especificaciones y estándares ya existentes en los casos en
que sea posible.

 Permitir la inclusión en las actividades de múltiples participantes ejerciendo

distintos roles para dar soporte a experiencias de aprendizaje en grupo y
colaborativas/competitivas.

8.2. ESPECIFICACIÓN DE DISEÑOS INSTRUCCIONALES

Para satisfacer estos requisitos, es necesario estudiar cuales son los elementos
esenciales de estos procesos educativos complejos creados por especialistas en
pedagogía. Una vez encontrados estos elementos, se construye sobre ellos una
formalización para permitir el intercambio y la interoperabilidad.

Puesto que estos diseños no son conocidos a priori, las definiciones deben ser
suficientemente abstractas para así poder ser empleadas en múltiples escenarios
educativos. La abstracción sobre la que se construye la especificación IMS
Learning Design es la formada por actividades de aprendizaje y flujos de
aprendizaje.

La participación en un foro de discusión, un experimento de laboratorio, realizar un

examen o actuar de moderador en un debate son posibles actividades de
aprendizaje, es decir, es un concepto amplio que cubre cualquier actividad en la
que un participante se puede involucrar durante un proceso de aprendizaje.

Por su parte, un flujo de aprendizaje es un planteamiento de un número de

actividades que deben realizarse en un determinado orden, con unos
determinados participantes y, habitualmente, con varios caminos posibles en
función de los resultados obtenidos por los distintos participantes.

8.3. DEFINICIÓN DE DISEÑOS INSTRUCCIONALES EMPLEANDO IMS

LEARNING DESIGN

La especificación IMS Learning Design (IMS LD) formaliza los conceptos definidos
en la sección anterior. Para ello, la especificación parte del lenguaje Educational
Modelling Language (Lenguaje de Modelado Educativo) desarrollado
originalmente en la Open University of the Netherlands (La Universidad Abierta de
Holanda) a partir de la identificación de los principios fundamentales de distintas
aproximaciones pedagógicas y de la búsqueda de un equilibrio entre genericidad y
expresividad pedagógica (Koper y Manderveld 2004).

El resultado es un lenguaje pedagógicamente neutro, lo que permite que los

sistemas de aprendizaje compatibles con IMS Learning Design no necesiten
soportar explícitamente un número de aproximaciones pedagógicas. En su lugar,
el sistema sólo necesita ser capaz de interpretar los diseños instruccionales, de
lanzar las distintas actividades en los momentos precisos para los distintos roles y
coordinar el flujo de ejecución general.

Los diseños instruccionales se definen empleando el lenguaje formalizado en la

especificación IMS Learning Design, pero el diseño de un curso en sí no es un
recurso con el que se pueda aprender, pues las actividades a menudo requieren
contenido que debe ser distribuido junto con el diseño. Dentro de la familia de
especificaciones de IMS, se propone que los diseños instruccionales se
distribuyan junto con sus contenidos asociados en forma de paquete siguiendo la
especificación IMS Content Packaging. A estos paquetes que aúnan diseño y
contenido se les denomina Unidades de Aprendizaje. A continuación se describen
los elementos básicos que conforman una Unidad de Aprendizaje:

 Actores: Los actores en una Unidad de Aprendizaje son las distintas

personas o entidades involucradas en un proceso de aprendizaje.

 Roles: Los roles definen las responsabilidades que los distintos actores
tendrán en distintas etapas del proceso de aprendizaje. Un mismo actor
puede actuar bajo distintos roles en distintos momentos del proceso de
aprendizaje. Por ejemplo, la misma persona puede ejercer en un momento
dado de alumno principiante y más delante de mentor de otros alumnos
principiantes.

 Actividades: Una actividad es un proceso educativo atómico que sucede en

un determinado entorno (dentro o fuera del contexto del LMS) y que puede
tener asociados uno o varios elementos de contenido que se distribuyen
como parte de la Unidad de Aprendizaje.

 Estructuras de Actividades: Las actividades se pueden agrupar en

estructuras de actividades, lo que permite referenciar un conjunto de
actividades atómicas como una sola entidad. Similarmente, las estructuras
de actividades se pueden agrupar en estructuras mayores, dando lugar a
estructuras complejas formadas por otras estructuras anidadas.

 Papeles (role-part): Un papel es la asociación entre un rol y una estructura

de actividades más o menos compleja. Así, un papel tendría la forma “El
actor X realiza la estructura de actividades Y”.

 Actos: Un acto es un conjunto de papeles que se lanzan simultáneamente

(aunque las actividades de los distintos papeles pueden estar secuenciadas
internamente de múltiples maneras).

 Obras: Una obra es una sucesión de actos y representa la mayor unidad de

agrupación en IMS Learning Design. Las obras completas se identifican con
diseños instruccionales completos.
Ilustramos la relación entre estos distintos conceptos mediante un ejemplo.
Queremos representar un diseño instruccional en el que el alumno comienza
estudiando dos lecciones (Lecciones 1 y 2) en ese orden y a su ritmo. Después de
completar la segunda lección, el alumno debe realizar dos ejercicios prácticos
(Ejercicios A y B) en el orden que prefiera. Una vez realizados los ejercicios, el
alumno se somete a un examen que es corregido por el instructor. Si el alumno
aprueba, el proceso acaba. En caso contrario, el alumno debe volver a comenzar
las lecciones. Este proceso se ilustra en la Figura 7.2.2.a que emplea la notación
estándar para diagramas de actividades del Lenguaje Unificado de Modelado.

En términos de IMS Learning Design, cada uno de los procesos (lecciones,

ejercicios, examen y proceso de evaluación) es una actividad atómica. Los dos
ejercicios, que pueden realizarse en cualquier orden, son una estructura de
actividades no ordenada. Esta estructura se engloba a su vez en una estructura
mayor, ordenada y consistente en la Lección-1, la Lección-2, la estructura que
contiene ambos ejercicios y el examen. A su vez, los dos roles definidos
corresponden al alumno y al evaluador.

El ciclo completo consta de una única obra que a su vez contiene un solo acto.
Este acto (y por tanto la obra) termina cuando se supera el examen y contiene dos
papeles. El primer papel relaciona al alumno con la estructura de actividades B y
el segundo papel relaciona al evaluador con la actividad evaluación.

Figura 8.3.a: Ejemplo de Unidad de Aprendizaje con un diseño instruccional muy

sencillo.
8.4. LOS NIVELES DE ESPECIFICACIÓN EN IMS LEARNING DESIGN

La especificación IMS Learning Design plantea un lenguaje potente aunque es

considerado por la comunidad académica como excesivamente complejo de
emplear y, sobre todo, de implementar en un LMS.

Para facilitar su adopción progresiva, la especificación propone tres niveles de

detalle a los que denomina simplemente A, B y C. De este modo, el primer nivel es
bastante sencillo de implementar y permite crear diseños instruccionales sencillos.
Un LMS que implemente solamente el nivel A no puede considerarse
completamente compatible con la especificación IMS Learning Design, pero si
puede considerarse compatible con el Nivel A de la especificación. Los Niveles B y
C añaden funcionalidad y potencia, construyendo siempre sobre el nivel anterior.
Esto permite a las organizaciones adoptar IMS Learning Design incrementalmente
y, si las necesidades de la organización no requieren de la adopción completa de
la especificación, se puede optar por una adopción parcial llegando sólo al nivel
que fuese necesario.

Las siguientes secciones describen la funcionalidad especificada en cada uno de

los niveles de IMS Learning Design.

8.4.1. IMS Learning Design - Nivel A

El Nivel A de la especificación se centra en superar el modelo de un único usuario

(un alumno trabajando en solitario) reflejado en el resto de las especificaciones de
IMS. En este primer nivel de la especificación se incluyen los conceptos básicos
expuestos en la sección anterior, esto es, las obras, divididas en actos en las que
distintos actoresinterpretan distintos roles.

La noción de estructuras de actividades, que es la esencia de la definición de los

caminos de aprendizaje con ramificaciones, también aparece en el Nivel A. Con
esta información es posible crear Unidades de Aprendizaje en las que se define un
proceso colaborativo en el que participan varios actores (tanto alumnos como
instructores u otros miembros de apoyo) y se define un secuenciamiento complejo
de las actividades en el que en algunos casos se le da importancia al orden y en
otros no. Lo que no se incluye en el Nivel A es la posibilidad de modificar y
consultar valores, con lo que los flujos de aprendizaje son fijos y el resultado de
las distintas actividades no puede afectar al resto.

Aún así, una implementación que sólo soporte el Nivel A podría soportar un
modelo en el que aparezcan distintos tipos de participantes que realizan distintas
actividades en un determinado orden. Por tanto, este nivel ya presenta una
aportación sobre el modelo dirigido a un único tipo de usuario y abre la puerta a
diseños instruccionales basados en los principios del aprendizaje colaborativo.

Por otro lado, dado que otra posible interpretación de los roles es la de distintos
perfiles de alumnos, el Nivel A de IMS Learning Design soportaría modelos
educativos en los que distintos tipos de alumno recorren distintos caminos al
realizar un determinado curso.

Pese a ello, un sistema que implemente el Nivel A no podría ejecutar el ejemplo

planteado en esta sección, pues la presencia de roles, actividades y un orden de
las actividades no implica la posibilidad de que el resultado de una determinada
actividad afecte al resto del proceso de aprendizaje. En el ejemplo planteado, la
actividad de evaluación del exámen no puede afectar al flujo del curso como se
indicaba en la descripción del mismo.

8.4.2. IMS Learning Design – Nivel B

Las dos aportaciones fundamentales del Nivel B de la especificación IMS Learning

Design son las propiedades y las condiciones.
Las propiedades son pares atributo-valor que parten de un estado inicial y se
modifican a lo largo del proceso de ejecución de la Unidad de Aprendizaje. Un
ejemplo de propiedad en el ejemplo de la sección anterior sería examen-
superado con un valor inicial de falso. Durante la actividad de evaluación del
examen es posible que este valor se convierta en verdadero o que se quede en su
estado inicial.

En cuanto a las condiciones, éstas son consultas que se realizan sobre el valor de
las propiedades en un momento determinado. Así, para llegar al estado final del
ejemplo de la sección anterior, es necesario que la propiedad examen-
superado tome el valor verdadero. Si tras la actividad de evaluación del examen el
valor siguiese siendo falso, el alumno deberá recorrer el camino de aprendizaje de
nuevo.

Así, el Nivel B aporta la posibilidad de que el resultado de una actividad genere un

cambio en alguna de las propiedades. Por su parte, el resto de actividades pueden
estar condicionadas a un cierto valor de las propiedades. En la práctica esto
significa que el resultado de unas actividades puede tener un impacto real en el
resto del proceso de aprendizaje, cambiando el camino a seguir o incluso
modificando el propio contenido de alguna actividad.

Adicionalmente, las propiedades pueden ser también externas, esto es, no son
modificadas por la propia Unidad de Aprendizaje sino que son definidas por el
propio LMS. Esto significa que en el Nivel B de la especificación también se
pueden crear Unidades de Aprendizaje que se comportan de manera distinta en
función de las exigencias del propio LMS. Un ejemplo común sería que el LMS
emplee este mecanismo para quitar del proceso de aprendizaje aquellas
actividades inadecuadas para el perfil de los alumnos o que simplemente
requieran servicios no implementados por el entorno de aprendizaje (como, por
ejemplo, un foro de discusión).

8.4.3. IMS Learning Design – Nivel C

La adición de propiedades y condiciones en el Nivel B de la especificación permite

la creación de Unidades de Aprendizaje cuyo recorrido cambia durante la propia
ejecución. Pero estos cambios son síncronos, es decir, las actividades se ejecutan
en un determinado orden y esperan a que la actividad anterior termine antes de
comenzar su ejecución.

El Nivel C de la especificación introduce un mecanismo de notificación o de envío

de mensajes entre las distintas actividades. Esto significa que una actividad puede
estar ejecutándose en unas determinadas condiciones y en un momento no
predecible recibir un mensaje desde otra actividad o desde el propio LMS que
afecte a la ejecución de la actividad inicial.

Esto permite soportar flujos de aprendizaje modificables en tiempo real mediante

eventos. Los flujos pre-definidos se sustituyen por actividades que se disparan,
modifican o interrumpen a medida que cambia el estado de la Unidad de
Aprendizaje.

Dado que en estos procesos de aprendizaje normalmente hay varios individuos, el

camino que se seguirá y el orden de ejecución de las actividades ya no es
predecible, pues es alterado por la acción de los distintos roles.

Las aplicaciones del Nivel C pueden ser algo tan sencillo como que en el momento
de la ejecución de la actividad de evaluación del examen el alumno reciba un
email, pero existen posibles aplicaciones mucho más sofisticadas que permiten
incluso realizar simulaciones multi-usuario en las que el entorno cambia
continuamente en función de las acciones de cada actor.

8.5. AUTORÍA DE CONTENIDOS EN IMS LEARNING DESIGN

Dado lo complejo del tema a tratar, la especificación IMS Learning Design resulta
muy complicada para un autor de contenidos. Se emplea un lenguaje XML muy
verboso y con muchas referencias cruzadas lo cual hace que resulte poco
asequible su uso directo por parte de un autor de contenidos que carezca de una
gran experiencia y fluidez en el uso de tecnologías XML.

Por esto, aunque la existencia de herramientas de autoría para las distintas

especificaciones de IMS es habitual y ayuda enormemente al autor, en el caso de
IMS Learning Design esto todavía no está tan desarrollado. Primero la
especificación es lo suficientemente compleja como para que sea prácticamente
indispensable recurrir a este tipo de herramientas pero además todavía se tiene
una limitada experiencia con ellas de modo que no dejan de ser unos formularios,
mas o menos sofisticados, para editar el XML subyacente. En nuestra opinión es
necesario que se desarrollen nuevas herramientas, por ejemplo, que permitan
hacer un diseño más visual que pueda ser entendido sin tener tanto conocimiento
de los detalles de la especificación. Esta falta de herramientas está dificultando la
adopción de LD, entre otros motivos, porque es todavía muy completo reutilizar
diseños realizados por otros autores adaptándolos a nuevas necesidades.

Una de las herramientas más utilizadas es el editor RELOAD (4). El proyecto

RELOAD ofrece herramientas de autoría para distintas especificaciones de IMS,
entre las cuales destaca el editor de IMS Learning Design por haber sido uno de
los primeros en llegar al mercado y su naturaleza de código abierto (opensource).

Figura 8.5..a: El editor de IMS Learnign Design de Reload.

El propio proyecto RELOAD también distribuye un reproductor de IMS Learning
Design capaz de ejecutar Unidades de Aprendizaje que sigan la especificación en
cualquiera de sus tres niveles.

Similarmente, CopperAuthor y CopperCore (5) implementan respectivamente un

editor y un reproductor de IMS Learning Design, soportando también los tres
niveles y con el factor adicional de haber sido desarrollado por la propia Open
Univeristy of the Netherlands (creadores del lenguaje EML original y participantes
activos en el grupo de trabajo responsable de IMS Learning Design) en conjunción
con la Open University of the United Kingdom. Ambos programas son también de
código abierto.

Figura 8.5.b: El editor de IMS Learnign Design CopperAuthor.

Como se ha mencionado previamente, las mayoría de las herramientas de autoría
para IMS Learning Design más relevantes desafortunadamente están todavía muy
ligadas a la sintaxis XML de la especificación por lo que, aunque facilitan el
trabajo, no evitan la necesidad de tener que familiarizarse con los detalles técnicos
de la especificación. Esto es un hecho conocido en el entorno académico y
comercial y se está invirtiendo un gran esfuerzo en facilitar los procesos de autoría
sin perder potencia expresiva.

4. http://www.reload.ac.uk/ldeditor.html

5. http://coppercore.sourceforge.net/