Uso de estándares aplicados a Tic en educación

Uso de estándares aplicados a Tic
en educación
Baltasar Fernández Manjón, Pablo Moreno Ger, José Luis Sierra Rodríguez, Iván
Martínez Ortíz
1
1. INTRODUCCIÓN
2. CONCEPTOS BÁSICOS
2.1. Uso de las tic en educación: contexto y participantes
2.2. Estándares y especificaciones en e -learning
2.2.1. ¿Qué es un estándar y para qué sirve?
2.2.2.Ventajas aportadas por los estándares en e -learning
2.2.3.Organismos e Instituciones que participan en los procesos de
estandarizaci ón en e -learning
2.2.4. Alliance of Remote Instructional Distribution Networks For
Europe (ariadne)
2.2.5. Dublin Core Metadata Initiative
2.3. Estandarización: aspectos y proceso
2.4. Objetos de aprendizaje
2.5. Perfiles de aplicación
2.6. Limitaciones de los estándares
3. ESPECIFICACIONES Y ESTÁNDARES MÁS UTILIZADOS EN E-LEARNING
3.1. Especificaciones de Ims
3.1.1. Estructura de las especificaciones de Ims
3.1.2. Ims Content Packaging
3.1.3. Ims Question & Test Interoperability Specification
3.1.4. Ims Learning Design
3.1.5. Ims Learner Information Package Specification
3.1.6. Otras Especificaciones de Ims
3.2. Ieee Learning Object Metadata / Ims Learning Resource Metadata
Specification (versión 1.3 public draft)
3.3. Adl/Scorm
3.4. lms y utilidades compatibles con las especificaciones y los
estándares
3.5. Compartición de recursos educativos y repositorios de objetos de
aprendizaje
4. IMS CONTENT PACKAGING
4.1. Introducción
4.2. Un caso de estudio
4.3. Visión conceptual de Ims CP
4.3.1. Organizaciones en Ims CP
4.3.2. Dependencias entre recursos
4.3.3. Metadatos
4.3.4. Archivos de intercambio de paquetes
4.4. Descripción xml de la estructura de los paquetes
2
4.4.1. El elemento manifest
4.4.2. El elemento metadata
4.4.3. Descripción de recursos
4.4.4. Posicionamiento en la estructura de carpetas del paquete
4.4.5. Descripción de organizaciones
4.4.6. Extensibilidad
4.5. Apéndice: ejemplo de manifiestos
4.5.1. Manifiesto para el paquete con organización plana
4.5.2. Manifiesto para el paquete con subpaquete incluido
5. LEARNING OBJECT METADATA (LOM)
5.1. Introducción
5.2. Un caso de estudio
5.3. Una visión conceptual de la adopción de Ims de lom
5.3.1. La categoría general
5.3.2. La categoría Lifecycle
5.3.3. La categoría metametadata
5.3.4. La categoría Technical
5.3.5. La categoría Educational
5.3.6. La categoría Rights
5.3.7. La categoría Relation
5.3.8. La categoría Annotation
5.3.9. La categoría Classification
5.4. Representación de metadatos lOM en Xml
5.4.1. Estructura general
5.4.2. Codificación de la categoría general
5.4.3. Codificación de la categoría Lifecycle
5.4.4. Codificación de la categoría metametadata
5.4.5. Codificación de la categoría Technical
5.4.6. Codificación de la categoría Educational
5.4.7. Codificación de la Categoría Rights
5.4.8. Codificación de Relaciones
5.4.9. Codificación de Anotaciones
5.4.10. Codificación de Clasificaciones
5.5. Perfiles de aplicación IOM
5.5.1. Cancore
5.5.2. lOM-ES
5.6. Otros esquemas de metadatos. Dublín Core.
5.7. Apéndice: ejemplo completo de metadatos Ims lom codificados en
xml
3
6. IMS QUESTION & TEST INTEROPERABILITY SPECIFICATION
6.1. Introducción
6.2. Historia de Ims Qti
6.3. Conceptos B ásicos de Ims Qti v 2.x
6.4. Las preguntas
6.5. Interacciones
6.5.1. Interacciones simples
6.5.2. Interacciones de texto
6.5.3. Interacciones gráficas
6.5.4. Otras tipos de interacciones
6.6. Los exámenes en Ims QTI V 2.1
6.7. Resultados y estadísticas
6.8. Conceptos avanzados
6.8.1. Intentos y sesiones de interacción
6.8.2. Preguntas dinámicas: realimentación, preguntas adaptativas
y preguntas compuestas
6.8.3. Exáme nes dinámicos
6.8.4. Bancos de preguntas
6.9. Relación con otras especificaciones
6.10. Herramientas relacionadas
7. ADL SCORM
7.1. Introducción
7.2. La especificación SCORM
7.2.1. Objetivos
7.2.2. La organización de SCORM
7.2.3. SCORM y otros estándares
7.3. Modelo de agregación de contenido
7.3.1. Definiciones en el modelo de contenido
7.3.2. Empaquetamiento de contenidos
7.3.3. Metadatos
7.3.4. Información de secuenciamiento
7.4. El entorno de tiempo de ejecución
7.5. Compatibilidad con SCORM
8. IMS LEARNING DESIGN
4
8.1 Introducción
8.2. Especificación de Diseños Instruccionales
8.3. Definición de Diseños Instruccionales empleando IMS Learning
Design
8.4. Los niveles de especificación en IMS Learning Design
8.4.1. Ims Learning Design - Nivel A
8.4.2. Ims Learning Design – Nivel B
8.4.3. Ims Learning Design – Nivel C
8.5. Autoría de contenidos en Ims Learning Design
9. SISTEMAS DE GESTION DEL APRENDIZAJE: MOODLE
9.1. Introducción a Moodle
9.1.1. Características generales
9.2. Guía visual a las herramientas disponibles
9.2.1. Cursos
9.2.2. Tareas
9.2.3. Chat
9.2.4. Consultas
9.2.5. Foros de discusión
9.2.6. Exámenes
9.2.7. Glosario
9.2.8. Encuestas
9.2.9. Wiki
9.3. Soporte de estándares educativos en moodle
9.3.1. Ejemplo de intercambio de módulos de cursos entre webct y
moodle
9.3.2. Ims Qti en Moodle
9.3.3. Actividades SCORM
10. BIBLIOGRAFÍA
5
1. INTRODUCCIÓN
La presente publicación surge como fruto del análisis de los estándares y
especificaciones que se aplican en la enseñanza que utiliza como ayuda y soporte las
Tecnologías de la Información y la Comunicación (TIC). Habitualmente a este tipo de
enseñanza que utiliza Internet como medio de comunicación se le denomina por
diversos términos como teleformación, formación en línea, formación virtual, o
simplemente con el término inglés e-learning. No obstante, hay que destacar que esta
utilización de las TIC para la educación y aprendizaje que englobamos bajo el término
e-learning, no necesariamente implica una modalidad de formación a distancia, ya que
su uso es mas amplio, siendo frecuente su empleo como apoyo a clases presenciales
o incluso un modelo mixto de clases semipresenciales (lo que se ha denominado
blended learning o b-learning). Por otro lado, estos estándares están teniendo también
mucha influencia en cómo se diseñan los cursos y en cómo se organizan los
contenidos educativos en la red, ya que ahora muchos sistemas y almacenes de
recursos educativos usan el modelo de objetos de aprendizaje u objetos digitales
reutilizables para los contenidos que pueden ser utilizados en distintos contextos.
Este documento se basa, además de en la revisión bibliográfica de los propios
estándares, en la experiencia en investigación, implementación y desarrollo que han
adquirido los autores en su trabajo como miembros del grupo de investigación en elearning de la Facultad de Informática de la Universidad Complutense de Madrid. El
propósito principal es presentar una visión general sobre los estándares que han
surgido en el mundo del e-learning y que son aplicables a distintos enfoques y
contextos educativos. Se presentarán sus fundamentos y sus aplicaciones de la
manera más simple posible, pero tratando de no perder el rigor, de modo que pueda
ser comprensible y útil para los educadores.
La amplitud, diversidad y continua evolución de este campo hace que un estudio de
este tipo no pueda ser exhaustivo, es decir, que cubra todas las iniciativas existentes,
así que se ha tenido que limitar su contenido para que únicamente considere aquellas
iniciativas que son más utilizadas actualmente, o que consideramos que son más
prometedoras.
Aún restringiendo el número de propuestas en e-learning a aquéllas que son, o bien
estándares publicados (e.g. IEEE LOM), o bien que tienen una mayor aceptación
comercial e implantación industrial (e.g. ADL SCORM), o bien que son el conjunto de
especificaciones más completas (e.g. IMS), la amplitud de estas propuestas hace que
su presentación tenga que ser parcial en algunos aspectos. A día de hoy los
estándares más maduros son aquellos que abordan aspectos relativos a los
contenidos, cómo se empaquetan los cursos, cómo se describen tanto los cursos
como los propios elementos que componen dichos cursos (e.g. objetos de
aprendizaje) y cómo se describen las evaluaciones o exámenes de modo que puedan
ser intercambiables entre sistemas. Por otro lado, aunque el enfoque actual está muy
centrado en contenidos, nos ha parecido relevante presentar la especificación que va
un paso más allá en la concepción completa del proceso educativo y permite su
descripción formal. Esta es la especificación de diseño de aprendizaje (e.g. IMS
Learning Design) que es muy prometedora, pero que actualmente no está
suficientemente aceptada, ni dispone de un conjunto de herramientas asociado que
permita su aplicación real.
Hay algunos aspectos que no están cubiertos de forma extensa en este trabajo. Son
fundamentalmente temas relacionados, o bien con la especificación y arquitectura de
6
los sistemas de e-learning, o bien con los aspectos de información respecto a los
alumnos. En la parte de sistemas de e-learning, aunque prácticamente todas las
aplicaciones ofrecen funcionalidades parecidas, todavía no existe un amplio consenso
sobre un único modelo conceptual, y es además un tema muy técnico que interesa
principalmente a los informáticos encargados del desarrollo de estos sistemas. Sí es
importante hacer notar que hay dos tendencias interesantes: una es el desarrollo de
sistemas de código abierto que empiezan a poder competir con aplicaciones
comerciales (e.g. Moodle, Sakai, .LRN), y otra es que se tiende hacia sistemas
orientados a servicios. Los sistemas orientados a servicios permiten ofrecer servicios
que sean accedidos por otros sistemas de forma sencilla, lo que simplifica en gran
manera la integración de sistemas heterogéneos. El tema de la información de los
usuarios y su estandarización, aunque es muy importante, plantea problemas de muy
diversa índole, desde legales (debido a que la Ley de Protección de Datos Personales
en Europa y España es más estricta que en otros países) a culturales o de madurez de
las propias especificaciones. A pesar de que se está tratando de buscar una forma de
expresar la información personal, su historial dentro del sistema (incluyendo su porfolio
de trabajos realizados) y las preferencias de los usuarios es un tema complejo en el
que sigue habiendo competencia comercial y falta de suficiente consenso. Este tema
podría comenzar a cambiar si, como parece, sigue adelante y tiene éxito el intento de
estandarizar una forma de definición de competencias y capacidades de los
estudiantes.
La organización de este trabajo está pensada para diferentes públicos. El lector que
está interesado sólo en tener una visión general de los estándares de e-learning podrá
adquirirla mediante la lectura de los dos primeros capítulos. Un lector que ya tenga un
cierto conocimiento de las ideas, fundamentos, proceso de e-learning y cómo se ven
afectados por la estandarización, pero quiera profundizar en aspectos más técnicos de
todos o alguno de los estándares abordados, podrá obtenerlo mediante la lectura de
los capítulos posteriores al segundo. Aunque estos capítulos son más técnicos, hasta
donde ha sido posible se ha tratado de hacerlos legibles y de poner ejemplos
simplificados siempre intentando no pasar el límite en el que se pierda el rigor técnico.
Este campo tiene, además, la particularidad de su juventud y cambio continúo. Como
continuamente surgen, o bien nuevas especificaciones, o bien correcciones o
añadiduras a las existentes, la bibliografía existente queda rápidamente superada por
la realidad. Esto hace que gran parte de las referencias que aparecen en este trabajo
sean páginas web de las instituciones implicadas en la estandarización, publicaciones
electrónicas o documentos que están disponibles en Internet.
7
2. CONCEPTOS BÁSICOS
2.1. Uso de las tic en educación: contexto y participantes
Aunque los ordenadores se han empleado en tareas educativas prácticamente desde
su aparición a mediados del siglo XX, ha sido a partir de la generalización de Internet
como medio de comunicación cuando se ha producido una revolución que está
teniendo un impacto real en la educación. Hoy en día Internet ha cambiado la forma de
trabajo, de comunicación, e incluso de relación, en la sociedad y por tanto también en
el mundo educativo. Por ejemplo, cuando se encarga un trabajo de revisión
bibliográfica a un alumno, éste no sólo dispone de los libros de referencia o
publicaciones sugeridas por el profesor, sino que de forma cada vez más habitual
realiza búsquedas de documentos en Internet, consulta páginas o foros especializados
sobre el tema donde comenta el trabajo con otras personas a las que muchas veces
no conoce o, en el peor de los casos, trata de encontrar dicho trabajo previamente
hecho por otra persona en la red. Por tanto, se están dando nuevas situaciones en la
educación que no son habituales, ya que modifican el rol de los participantes en el
proceso y especialmente de los profesores y de los alumnos. Y esto no sólo pasa en
educación a distancia, ya que cada vez más se utilizan estos medios informáticos
como un complemento a las clases presenciales. A continuación se presentan los
principales actores del proceso y como se relacionan entre sí (Figura 2.1.a).
Figura 2.1.a. Principales participantes en el proceso de la enseñanza en Internet
Proveedor de
contenidos
Administrador
Cursos
LMS
Profesor o tutor
Alumno
Los principales participantes en el proceso de enseñanza mediante la web son: los
profesores o tutores, los alumnos, los proveedores de contenido y los administradores.
Los profesores o tutores son los encargados de supervisar el proceso de enseñanza.
Contrariamente a lo que muchas personas consideran, la enseñanza utilizando nuevas
tecnologías no pretende sustituir a los profesores, aunque sí cambia su papel principal
ya que pasa a ser más un dinamizador y un supervisor que un “transmisor” de
8
conocimiento. Los alumnos son los participantes centrales en e-learning, ya que
dependiendo de su rendimiento o satisfacción, se podrá evaluar el éxito de la
enseñanza. Esta enseñanza necesita que el alumno tenga un papel activo y desarrolle
mayores capacidades de autoaprendizaje, ya que la comunicación con el profesor y
los compañeros es más limitada (si es que ésta última existe). Los proveedores de
contenidos educativos son responsables de la tarea de crear y diseñar el contenido, y
de alguna manera del proceso de instrucción, de tal forma que se consigan objetivos
educativos pretendidos. Finalmente, los administradores del sistema se ocupan de
gestionar los elementos de los catálogos de cursos, los horarios, los recursos,
sesiones de aprendizaje, tutores, equipos disponibles, así como de los aspectos de
seguridad y económicos. Por supuesto, los roles de los participantes en el proceso no
tienen por qué estar claramente separados y, por ejemplo, en las universidades
españolas es muy habitual que el profesor, además de dinamizador y tutor del curso,
sea también el principal proveedor de contenidos para dicho curso.
El elemento central de la comunicación en e-learning es el sistema de gestión del
aprendizaje (en inglés, Learning Management System, LMS), un sistema basado en la
web que permite el acceso a contenidos, la gestión de los recursos y la comunicación
entre todos los actores implicados en el proceso (alumnos, profesores,
administradores, etc). La plataforma LMS permite gestionar los accesos, la actividad y
permisos de los usuarios (e.g. inscripción, control de qué contenidos son accedidos,
notas de evaluaciones, generación de informes y estadísticas de uso, etc) y
proporciona distintas herramientas de comunicación, tanto síncronas (e.g. chat o
conversaciones, videoconferencia, tutorías en tiempo real, etc) como asíncronas (e.g.
tablones de anuncios, foros de discusión, etc). Además, puede existir un sistema
especializado para la gestión de contenidos educativos (en inglés, Learning Content
Management System , LCMS), que es un sistema multiusuario donde los creadores de
contenidos pueden crear, almacenar, gestionar y presentar contenidos digitales
almacenados en un repositorio centralizado. Mientras un LMS se encarga de todos los
procesos que rodean al aprendizaje en sí (está asociado al rol de profesor y de
alumno), un LCMS gestiona el proceso de creación de los contenidos (está asociado al
rol del creador). No obstante la diferencia entre LCMS y LMS no es tan clara, ya que la
mayoría de los sistemas de gestión de contenidos proporciona también un sistema de
gestión del aprendizaje haciendo que cada vez mas esta frontera sea más difusa.
En cualquier caso, cabe destacar que el uso de Internet no presenta únicamente
ventajas, sino que también tiene inconvenientes, debido a que es un sistema abierto,
diverso y heterogéneo, en el que surgen problemas que se deben abordar para poder
lograr soluciones eficaces y eficientes. Algunos de estos problemas se deben a la
heterogeneidad de plataformas o herramientas (e.g. distintos tipos de ordenadores con
distintos sistemas operativos, distintos LMS) o a aspectos como la comunicación entre
los distintos sistemas.
En este nuevo escenario siguen identificándose problemas clásicos de la informática
educativa, tales como son el alto coste de desarrollo de cursos para estos sistemas, o
la baja posibilidad de reutilización/adaptación de contenidos o aplicaciones cuando
cambia algún factor, como, por ejemplo, la plataforma o el contexto educativo. El
proceso de creación de aplicaciones y contenidos educativos de calidad es una labor
ardua que requiere la colaboración de expertos en diversos temas (v.g. contenidos,
tecnología, didáctica). Hasta ahora, ha sido habitual que contenidos educativos
excelentes desarrollados con enorme coste para una tecnología concreta se han
perdido cuando se ha cambiado de plataforma o se ha producido un cambio
9
tecnológico (por ejemplo, la evolución desde el vídeo disco interactivo al CD-ROM y,
posteriormente, a Internet).
Para paliar este problema, todos los agentes implicados en e-learning tratan de
sistematizar la creación de materiales educativos de calidad que puedan ser
actualizados, reutilizados y mantenidos a lo largo del tiempo. De estas necesidades
básicas surge un nuevo modelo para el diseño de los cursos denominado modelo de
objetos de aprendizaje (OA), objetos educativos u objetos digitales educativos (en
inglés, Learning Objects). La idea subyacente a este modelo consiste, básicamente,
en diseñar los cursos como agregados de objetos de aprendizaje, que idealmente son
independientes, reutilizables y combinables a la manera de las piezas de un juego de
lego, o mejor dicho, de un mecano (ya que no todos son combinables con todos). Para
poder hacer realidad esta nueva forma de crear contenidos, y debido a la
heterogeneidad de plataformas educativas y de los sistemas de enseñanza en línea
(es decir de los LMS), es necesaria la existencia de recomendaciones y estándares
ampliamente aceptados que posibiliten la reutilización de los OA y su interoperabilidad
entre diferentes sistemas.
2.2. 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).
10
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.
11
§
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.
12
Figura 2.2.3.a. Colaboración entre los principales organismos de estandarización
(adaptado de CEN/ISSS LTO)
LTSC & JTC1/SC36 Colaboración cercana
LTSC
Actual
Futura
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.
13
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.cenltso.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
14
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.
2.2.4. 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 elearning 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 proceso
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.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
15
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.2.3.a Proceso de desarrollo de estándares (adaptado de Masie 2003)
AICC
IMS
ARIADNE
IEEE
ISO
CEN/ISS
Ideas
Necesidades
Especs
ADL
Pruebas
mercado
IEEE
Cuerpo
estándar
ESTANDAR
(“de facto”)
Tendencias
tecnicas
Implementaciones,
Modelos de referencia,
Especifiaciones Requisitos
Estandares
generales
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.2.5.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:
16
Figura 2.2.5.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
17
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”.
18
Figura 2.2.5.a. Esquema del proceso de e-learning utilizando objetos de aprendizaje
(Adaptado de Eduworks)
Libros y
manuales
Herramienta
de autoría
Internet
Material
prestado
LMS
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.b). 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
19
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
20
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
1
Más información sobre el concepto de wiki incluida precisamente en un sistema wiki:
http://es.wikipedia.org/wiki/Wiki
21
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.
3. 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:
§
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.
22
Normalmente es el documento que se recomienda leer primero para
entender los conceptos generales con los que se trata.
§
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.
§
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 Recursos de un paquete. El estándar permite que un Manifiesto
contenga distintas organizaciones sobre los Recursos del 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.
23
Figura 3.1.2.a Esquema de un manifiesto
Manifiesto
Metadatos
Organizaciones
Recursos
Submanifiestos
Ficheros físicos
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.
24
<?xml version="1.0" encoding="ISO-8859-1"?>
<manifest identifier="CMD_7540019_M" version="1.0"
xmlns="http://www.imsproject.org/content"
xmlns:webct="http://www.webct.com/IMS">
<metadata>
..............
</metadata>
<organizations>
<organization identifier="CMD_7540020">
<webct:properties identifierref="CMD_7540021"/>
<item identifier="CMD_7540022">
<title>Temas del curso (trasparencias en pdf)</title>
<item identifier="CMD_7540023" identifierref="CMD_7540024">
<title>Introducción a la programción orientada a objetos</title>
</item>
<item identifier="CMD_7540026" identifierref="CMD_7540027">
<title>Introducción a Java</title>
</item>
.............
</organization>
</organizations>
<resources>
<resource identifier="CMD_7540021" type="webctproperties">
<file href="CMD_7540019_M/data/properties_CMD_7540020.xml"/>
</resource>
<resource identifier="CMD_7540024" type="webcontent">
<file href="CMD_7540019_M/my_files/POO20042005/IntroduccionPOO.pdf"/>
</resource>
<resource identifier="CMD_7540027" type="webcontent">
<file href="CMD_7540019_M/my_files/POO2004-2005/introjava.pdf"/>
</resource>
..............
</resources>
</manifest>
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
25
3.1.3. 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 <eAula> 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.
26
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.
27
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
28
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).
3.1.6. 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 sistem a
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.
29
§
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)
30
? 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 (com o 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 -.
31
§
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.
Figura 3.2.a Editor de metadatos Reload
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.1.6.2.b).
Figura 3.1.6.2.b asignación del valor alto (“high”) al campo nivel de interactividad de la
categoría educacional utilizando el editor Reload
32
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
33
§
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.
34
3.4. 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.
35
3.5. Compartición de recursos educativos y repositorios 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.
36
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 APEL (www.apel.es).
37
4. 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
pres.html
cursogeometria
tutorial
intro.html
conten.html
res.html
Internet
fig1.jpg
fig2.jpg
PC
Prof. Emeritus
ej1.html
http://www.
geoworld.org/
ejercicios
ej2.html
fig1.jpg
http://www.amigosdelageometria.
tv/default/index.htm
fig2.jpg
§
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
38
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
Organizaciones
Recursos
Subpaquetes
Archivos
internos
Archivos
externos
§
El paquete puede involucrar archivos internos y archivos externos. Los archivos
internos son archivos digitales que forman parte del paquete, y pueden estar
39
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.
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
3.1.6b y en la
Figura 3.1.6c 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 3.1.6b. Un empaquetado de los materiales del caso de estudio
40
rpresen
ej1
rres
rcont
rintro
ej1.html
content.
intro.html
html
pres.html
tutorial
§
web1
ej2
web2
fig2.jpg
fig2.jpg res.html
ej2.html
fig1.jpg
ejercicios
fig1.jpg
El paquete de la Figura 3.1.6b 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 3.1.6c. Una segunda alternativa de empaquetado para los materiales del caso
de estudio, en la que se sitúan los ejercicios en un subpaquete
rpresen
rintro
rcont
rres
web1
web2
ej1
pres.html
intro.html
tutorial
content.
html
ej2
fig2.jpg res.html
fig1.jpg
ej1.html
fig2.jpg
fig1.jpg
ejercicios
§
El paquete de la
41
ej2.html
§
Figura 3.1.6c 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
presentación introducción contenido resumen
rpresen
§
§
rintro
rcont
ejercicio1
ej1
rres
ejercicio2
ej2
web1
web1
web2
web2
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.
42
Figura 4.3.1.b. Una organización con estructura
presentación
ejercicio1
introducción contenido
rpresen
§
rintro
rcont
ejercicio2
web1
web2
resumen
ej1
rres
ej2
web1
web2
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.
Figura 4.3.1.c. Una organización fuertemente estructurada
curso
introducción
rpresen
contenido
rintro
rcont
webs
ejercicios
presentación
resumen
ejercicio1
ej1
rres
43
ejercicio2
ej2
web1
web1
web2
web2
Figura 4.3.1.d. Dos organizaciones parciales
curso
introducción
rpresen
resumen
contenido
rintro
webs
ejercicios
presentación
rcont
ejercicio1
ej1
rres
ejercicio2
web1
ej2
web1
web2
web2
Con el fin de ejemplificar algunos aspectos más avanzados del mecanismo, se
esbozan a continuación las organizaciones globales introducidas en el segundo
paquete de ejemplo:
Figura 4.3.1.e. Organización global de los recursos del segundo paquete de ejemplo
curso
introducción
rpresen
resumen
contenido
rintro
rcont
ejercicio1
ejercicio2
web1
rres
web1
Recursos del
subpaquete
§
webs
ejercicios
presentación
ej1
web2
web2
ej2
El paquete incluye una organización global de todos sus recursos (incluidos los del
subpaquete) −Figura 4.3.1.e. Esta organización es análoga a la mostrada en la
44
Figura 4.3.1.c. Este ejemplo pone de manifiesto que un ítem puede hacer
referencia a cualquiera de los recursos de su propio paquete, o a cualquiera de los
recursos que se encuentran en los subpaquetes. El contrario no es, sin embargo
cierto, ya que no es posible hacer referencia a recursos que se encuentran en
paquetes contenedores. Esta restricción es muy importante para mantener el
carácter autocontenido de paquetes y subpaquetes.
Figura 4.3.1.f. Organización global en la que se refiere directamente al subpaquete
curso
ejercicios
presentación
introducción
rpresen
contenido
rintro
rcont
resumen
webs
web1
rres
web1
web2
web2
Subpaquete
§
§
La
Figura 4.3.1.f esquematiza una organización global alternativa, en la que no se
refieren directamente los recursos del subpaquete, sino que se refiere
directamente el subpaquete en sí. Dicha organización es, de esta forma, más
modular, ya que será posible reorganizar los recursos del subpaquete sin
comprometer la misma.
Las organizaciones locales del subpaquete no ilustran ningún concepto nuevo, por lo
que se omitirá su detalle.
4.3.2. Dependencias entre Recursos
IMS CP permite especificar recursos internos que incluyen los contenidos de otros
recursos internos. Si un recurso A incluye los contenidos de otro recurso B se dice que
A depende de B. El mecanismo de dependencias facilita el agrupamiento básico de los
contenidos cuando existen recursos que comparten dichos contenidos. En lugar de
duplicar el listado de archivos en cada recurso, basta introducir un recurso común, que
actúa como contenedor de los archivos compartidos, y establecer dependencias con
dicho recurso común.
45
Figura 4.3.2.a. Empaquetado alternativo al del primer paquete ejemplo
rpresen
pres.html
rintro
intro.html
rcont
content.html
ej2
ej1
rres
ej1html
res.html
tutorial
web1
web2
ej2.html
ejercicios
fig1.jpg
fig2.jpg
figuras
A modo de ejemplo, supóngase que en el caso de estudio las figuras de los ejercicios
son las mismas que las figuras del tutorial. En la
Figura 4.3.2.a se muestra una disposición alternativa de los archivos y los recursos a
la sugerida por el primer paquete ejemplo, en la que se evita duplicar físicamente los
correspondientes archivos. Para ello, los archivos se colocan físicamente en una
misma carpeta (figuras), y se hace que los recursos correspondientes refieran a dichos
archivos. Efectivamente, IMS CP permite que los recursos compartan archivos, a fin
de proporcionar agrupaciones pedagógicamente alternativas de los mismos. El uso de
46
dependencias entre recursos permite, no obstante, simplificar este esquema de
empaquetamiento. Para ello:
§
§
Se introduce un recurso contenedor común que refiere a ambas imágenes.
Se establecen dependencias de los recursos asociados con el contenido del
tutorial y con el ejercicio 1 con el nuevo recurso contenedor.
Figura 4.3.2.b. Simplificación del empaquetado de la
Figura 4.3.2.a
rpresen
rintro
pres.html
intro.html
rcont
content.html
ej1
rres
ej2
web1
web2
ej1html ej2.html
res.html
tutorial
fig1.jpg fig2.jpg
figuras
ejercicios
La Figura 4.3.2.b esquematiza esta solución. Obsérvese que incluso a este nivel
esquemático, puede apreciarse cómo el uso de dependencias simplifica la estructura
final resultante.
4.3.3. 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
47
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
48
identifier
atributo
opcional
Elemento
opcional
?
version
?
xml:base
0 .. 1
atributos
metadata
organizations
manifest
resources
0 .. ∞
manifest
0 o más
ocurrencias
§
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.
49
<manifest xmlns="http://www.imsglobal.org/xsd/imscp_v1p1 "
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance "
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1
imscp_v1p1.xsd"
xmlns:lom="http://www.imsglobal.org/xsd/imsmd_v1p2"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2
imsmd_v1p2p2.xsd "
identifier="gemetria2">
<metadata> ... </metadata>
<organizations> ... </organizations>
<resources> ... </resources>
<manifest identifier="ejercicios">
<metadata>...</metadata>
<organizations> ... </organizations>
<resources> ... </resources>
</manifest>
</manifest>
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
esquemas necesarios 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:
-
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.
-
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
50
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).
4.4.2. 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
0 .. 1
0 .. 1
schema
schemaversion
metadata
Un elemento
arbitrario
§
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.
51
Figura 4.4.2.b. Ejemplo muy simple de metadatos globales
<metadata>
<schema>LOM</schema>
<schemaversion>1.2.2</schemaversion>
<lom:lom>
<lom:general>
<lom:title>
<lom:langstring xml:lang="ES">
Curso introductorio a la geometría del plano
</lom:langstring>
</lom:title>
</lom:general>
</lom:lom>
</metadata>
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
identifier
type
? href
?
?
xml:base
xml:base
0 .. 1
resources
0 .. ∞
0 .. ∞
resource
0 .. ∞
metadata
file
dependency
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:
52
Figura 4.4.3.b. Estructura gramatical de los elementos file y dependency
href
identifierref
0 .. 1
file
metadata
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
<resources>
<resource identifier="rpresen" type="webcontent"
href="tutorial/presen.html">
<file href="tutorial/presen.html"/>
</resource>
<resource identifier="rintro" type="webcontent"
href="tutorial/intro.html">
<file href="tutorial/intro.html"/>
</resource>
<resource identifier="rcont" type="webcontent"
href="tutorial/content.html">
<file href="tutorial/content.html"/>
<file href="tutorial/fig1.jpg"/>
<file href="tutorial/fig2.jpg"/>
</resource>
<resource identifier="rres" type="webcontent"
href="tutorial/res.html">
<file href="tutorial/res.html"/>
</resource>
<resource identifier="web1" type="webcontent"
href="http://www.geoworld.org/"/>
<resource identifier="web2" type="webcontent"
href="http://www.amigosdelageometria.tv/default/index.htm"/>
</resources>
.
Estos elementos resource contienen los siguientes:
§
Opcionalmente, un elemento metadata conteniendo metadatos acerca del recurso.
53
§
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
<resources>
...
<resource identifier="rfigs" type="webcontent">
<file href="figuras/fig1.jpg"/>
<file href="figuras/fig2.jpg"/>
</resource>
<resource identifier="rcont" type="webcontent"
href="tutorial/content.html">
<file href="tutorial/content.html"/>
<dependency identifierref="rfigs"/>
</resource>
<resource identifier="ej1" type="webcontent"
href="tutorial/ej1.html">
<file href="tutorial/ej1.html"/>
<dependency identifierref="rfigs"/>
</resource>
...
</resources>
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.
4.4.4. 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
54
<resource identifier="rcont" type="webcontent"
xml:base="tutorial"
href ="content.html">
<file href="content.html"/>
<file href="fig1.jpg"/>
<file href="fig2.jpg"/>
</resource>
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
identifier
? structure
0 .. 1
?
title
default
0 .. ∞
organization
0 .. ∞
0 .. 1
organizations
0 .. ∞
item
metadata
Otro tipo de
organización
Así mismo, los elementos organization contienen:
55
§
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
identifier
?identifierref
?isvisible
0 .. 1
title
?parameters
item
0 .. ∞
0 .. 1
item
metadata
Figura 4.4.5.c.Organizaciones globales del manifiesto de la
Figura 4.4.1.b
56
<organizations default="org1">
<organization identifier="org1">
<item identifier="iorg1">
< title>Curso sobre geometría< /title>
< item identifier="iorg11" identifierref="rpresen ">
<title>Presentación</title>
<item identifier= "iorg111" identifierref="rintro">
<title >Introducción</title>
</item>
<item identifier= "iorg112" identifierref="rcont">
<title >Contenidos</title>
</item>
<item identifier= "iorg113" identifierref="rres ">
<title >Resumen< /title>
</item>
< /item>
< item identifier="iorg12">
<title>Ejercicios </title>
<item identifier= "iorg121" identifierref="ej1" >
<title >Ejercicio 1</title >
</item>
<item identifier= "iorg122" identifierref="ej2" >
<title >Ejercicio 2</title >
</item>
< /item>
< item identifier="iorg13">
<title>Webs</title>
<item identifier= "iorg131" identifierref="web1 " >
<title>Web "Geometry World"</title>
</item>
<item identifier ="iorg132" identifierref="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
< /item>
</item>
</organization >
<organization identifier= "org2">
<item identifier="iorg2 ">
<title>Curso sobre geometría</ title>
<item identifier="iorg21" identifierref ="rpresen" >
<title>Presentación </title>
<item identifier="iorg211" identifierref="rintro">
<title> Introducción</title >
</item>
<item identifier="iorg212" identifierref="rcont ">
<title> Contenidos </title>
</item>
<item identifier="iorg213" identifierref="rres" >
<title> Resumen</t itle>
</item>
</ item>
<item identifier="iorg22"
identifierref=" ejercicios"/>
<item identifier="iorg23">
<title>Webs</title>
<item identifier=" iorg231" identifierref="web1 " >
<title >Web "Geometry World"</title >
</item>
<item identifier=" iorg232" identifierref="web2 " >
<title >Web "Amigos de la geometría"</title>
</item>
</ item>
</item>
</organization>
</organizations>
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.
57
4.5. Apéndice: ejemplo de manifiestos
En este apéndice se incluye los manifiestos completos para los paquetes que se han
utilizado como ejemplo en este capítulo sobre IMS CP. Por simplicidad, en estos
manifiestos no se incluyen metadatos.
4.5.1. Manifiesto para el paquete con organización plana
<manifest xmlns="http://www.imsglobal.org/xsd/imscp_v1p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 imsmd_v1p2p2.xsd"
xmlns:lom="http://www.imsglobal.org/xsd/imsmd_v1p2"
identifier="gemetria2">
<organizations default="org1">
<organization identifier="org1">
<item identifier="iorg11" identifierref ="rpresen">
<title>Presentación</title>
</item>
<item identifier="iorg12" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg13" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg14" identifierref ="rres ">
<title>Resumen</title>
</item>
<item identifier="iorg15" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg16" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
<item identifier="iorg17" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg18" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</organization>
<organization identifier="org2">
<item identifier="iorg21" identifierref ="rpresen">
<title>Presentación</title>
<item identifier="iorg211" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg212" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg213" identifierref ="rres">
<title>Resumen</title>
</item>
</item>
<item identifier="iorg22" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg23" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
<item identifier="iorg24" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg25" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</organization>
<organization identifier="org3">
58
<item identifier="iorg3">
<title>Curso sobre geometría</title>
<item identifier="iorg31" identifierref ="rpresen">
<title>Presentación</title>
<item identifier="iorg311" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg312" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg313" identifierref ="rres">
<title>Resumen</title>
</item>
</item>
<item identifier="iorg32" identifierref ="ejercicios">
<item identifier="iorg321" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg322" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
</item>
<item identifier="iorg33">
<title>Webs</title>
<item identifier="iorg331" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg332" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</item>
</item>
</organization>
<organization identifier="org4">
<item identifier="iorg4">
<title>Curso sobre geometría</title>
<item identifier="iorg41" identifierref ="rpresen">
<title>Presentación</title>
<item identifier="iorg411" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg412" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg413" identifierref ="rres">
<title>Resumen</title>
</item>
</item>
<item identifier="iorg42" identifierref ="ejercicios">
<item identifier="iorg421" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg422" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
</item>
</item>
</organization>
<organization identifier="org5">
<item identifier="iorg5">
<title>Webs</title>
<item identifier="iorg51" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg52" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</item>
</organization>
</organizations>
<resources >
<resource identifier="rpresen" type="webcontent" href ="tutorial/presen.html">
59
<file href ="tutorial/presen.html"/>
</resource>
<resource identifier="rintro" type="webcontent" href ="tutorial/intro.html">
<file href ="tutorial/intro.html"/>
</resource>
<resource identifier="rcont" type="webcontent" href ="tutorial/content.html">
<file href ="tutorial/content.html"/>
<file href ="tutorial/fig1.jpg"/>
<file href ="tutorial/fig2.jpg"/>
</resource>
<resource identifier="rres " type="webcontent" href ="tutorial/res.html">
<file href ="tutorial/res.html"/>
</resource>
<resource identifier="web1" type="webcontent" href ="http://www.geoworld.org/"/>
<resource identifier="web2" type="webcontent"
href ="http://www.amigosdelageometria.tv/default/index.htm"/>
<resource identifier="ej1" type="webcontent" href ="ejercicios/ej1.html">
<file href ="ejercicios/ej1.html"/>
<file href ="ejercicios/fig1.jpg"/>
<file href ="ejercicios/fig2.jpg"/>
</resource>
<resource identifier="ej2" type="webcontent" href ="ejercicios/ej2.html">
<file href ="ejercicios/ej2.html"/>
</resource>
</resources >
</manifest>
4.5.2. Manifiesto para el paquete con subpaquete incluido
<manifest xmlns="http://www.imsglobal.org/xsd/imscp_v1p1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 imsmd_v1p2p2.xsd"
xmlns:lom="http://www.imsglobal.org/xsd/imsmd_v1p2"
identifier="gemetria2">
<organizations default="org1">
<organization identifier="org1">
<item identifier="iorg1">
<title>Curso sobre geometría</title>
<item identifier="iorg11" identifierref ="rpresen">
<title>Presentación</title>
<item identifier="iorg111" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg112" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg113" identifierref ="rres">
<title>Resumen</title>
</item>
</item>
<item identifier="iorg12">
<title>Ejercicios</title>
<item identifier="iorg121" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg122" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
</item>
<item identifier="iorg13">
<title>Webs</title>
<item identifier="iorg131" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg132" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</item>
</item>
60
</organization>
<organization identifier="org2">
<item identifier="iorg2">
<title>Curso sobre geometría</title>
<item identifier="iorg21" identifierref ="rpresen">
<title>Presentación</title>
<item identifier="iorg211" identifierref ="rintro">
<title>Introducción</title>
</item>
<item identifier="iorg212" identifierref ="rcont">
<title>Contenidos</title>
</item>
<item identifier="iorg213" identifierref ="rres">
<title>Resumen</title>
</item>
</item>
<item identifier="iorg22" identifierref ="ejercicios"/>
<item identifier="iorg13">
<title>Webs</title>
<item identifier="iorg131" identifierref ="web1" >
<title>Web "Geometry World"</title>
</item>
<item identifier="iorg132" identifierref ="web2" >
<title>Web "Amigos de la geometría"</title>
</item>
</item>
</item>
</organization>
</organizations>
<resources >
<resource identifier="rpresen" type="webcontent" href ="tutorial/presen.html">
<file href ="tutorial/presen.html"/>
</resource>
<resource identifier="rintro" type="webcontent" href ="tutorial/intro.html">
<file href ="tutorial/intro.html"/>
</resource>
<resource identifier="rcont" type="webcontent" href ="tutorial/content.html">
<file href ="tutorial/content.html"/>
<file href ="tutorial/fig1.jpg"/>
<file href ="tutorial/fig2.jpg"/>
</resource>
<resource identifier="rres " type="webcontent" href ="tutorial/res.html">
<file href ="tutorial/res.html"/>
</resource>
<resource identifier="web1" type="webcontent" href ="http://www.geoworld.org/"/>
<resource identifier="web2" type="webcontent"
href ="http://www.amigosdelageometria.tv/default/index.htm"/>
</resources >
<manifest identifier="ejercicios ">
<organizations >
<organization identifier="org3">
<item identifier="iorg31" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg32" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
</organization>
<organization identifier="org4">
<item identifier="iorg4">
<title>Ejercicios</title>
<item identifier="iorg41" identifierref ="ej1">
<title>Ejercicio 1</title>
</item>
<item identifier="iorg42" identifierref ="ej2">
<title>Ejercicio 2</title>
</item>
</item>
</organization>
</organizations >
<resources>
<resource identifier="ej1" type="webcontent" href ="ejercicios/ej1.html">
61
<file href ="ejercicios/ej1.html"/>
<file href ="ejercicios/fig1.jpg"/>
<file href ="ejercicios/fig2.jpg"/>
</resource>
<resource identifier="ej2" type="webcontent" href ="ejercicios/ej2.html">
<file href ="ejercicios/ej2.html"/>
</resource>
</resources>
</manifest>
</manifest>
62
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
63
Figura 4.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
Metadatos LOM
general
metametadata
lifecycle
relation
educational
rights
technical
classification
annotation
§
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.
64
§
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
general
0..1
0..1
identifier
0.. ∞
catalogentry
title
0.. ∞
0..∞
0..∞
0..1
coverage
description
language
0..∞
keyword
0..1
aggregationlevel
structure
§
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
65
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árquica), 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
title
catalogentry
language
description
keyword
Fig00089
Función de densidad de probabilidad Normal
Fig00089 en catálogo Imágenes
ES
Gráfico de la función de densidad de probabilidad de una normal.
Probabilidad
estadística
función de densidad
normal
campana de gauss
1823
atomic (vocabulario LOM)
1 (vocabulario LOM)
coverage
structure
aggregationlevel
-
1. Representa el nivel más pequeño de agregación (el aplicable a material
aparentemente indivisible, como una imagen, un archivo PDF, etc.).
-
2. Colección de materiales atómicos (por ejemplo, un archivo HTML junto con
las imágenes referidas desde el mismo).
-
3. Una colección de dos o más materiales de nivel 2 (por ejemplo, una web
formada por múltiples documenttos HTML).
2
En la versión final de LOM propuesta por IEEE, este metadato se ha fusionado con
identifier. De esta forma, identifier se concibe como una entrada en un catálogo.
66
-
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.
5.3.2. 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
lifecycle
0..1
0.. ∞
0..1
version
contribute
status
67
-
El papel del contribuyente en el proceso de producción. LOM propone el
siguiente vocabulario controlado para este metadato: autor, publisher
(publicador), unknown (desconocido), initiator (iniciador), terminator
(finalizador), validator (validador), editor (editor), 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).
-
La identidad del contribuyente. Tiene sentido especificar varias identidades
para el mismo contribuyente (por ejemplo, en el caso en que éste tenga varias
afiliaciones).
-
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
status
contribute
3.0
Final
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.
68
Figura 5.3.3.a. Metadatos en la categoría metametadata
metametadata
0..1
0.. ∞
identifier
0.. ∞
0.. ∞
contribute
catalogentry
0..1
language
metadatascheme
§
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
Contribuye
Primer contribuyente
Papel: creator
Identidad: Lula Hacker
Fecha: 30/05/2008
Segundo contribuyente
Papel: validator
Identidad: Mike Hammer
Fecha: 1/06/2008
LOMv1.0
ES
Metadataschema
Language
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
69
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
technical
0.. ∞
0.. 1
format
§
§
0.. ∞
0..1
location
size
§
0.. ∞
0..1
instalationremarks
otherplatformrequirements
0..1
duration
requirement
-
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, MultiOS, 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
Size
image/jpeg
512456
70
Location
Requirement
Instalationremarks
otherplatformsrequirements
ftp://imgserver.com/images/math/gauss.jpg
Tipo: Browser
Nombre: Any
Basta disponer de un visualizador de imágenes JPG como añadido al navegador
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.
5.3.5. 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
educational
0..1
0.. ∞
interactivitytype
0.. 1
0.. 1
interactivitylevel
learningsourcetype
0..∞
0..∞
typicalagerange
intendedenduserrole
semanticdensity
0..1
0..∞
context
difficulty
0..1
0..1
typicallearningtime
0..∞
language
description
.
§
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 (cuestionario),
diagram (diagrama), figure (figura), graph (gráfico), index (índice), slide
(diapositiva), table (tabla), narrative text (texto narrativo), exam (examen),
experiment (experimento), ProblemStatement (enunciado 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
71
dicho papel: teacher (maestro), author (autor), learner (aprendiz), manager
(gestor).
§
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
learningresourcetype
Interactivitylevel
Semanticdensity
Intendeduserrole
Context
Typicalagerange
Difficulty
Typicallearningtime
Description
Language
Expositive
Figure
very low
High
Learner
higher education
16-20
Médium
30 minutos
Entendimiento cualitativo de los principales parámetros de la normal univariante.
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
72
rights
0..1
0..1
cost
0.. 1
description
copyrightandotherrestrictions
Tabla 5.3.6.a. Metadatos en la categoría rights para el caso de estudio.
Metadato
Categoría: rights
Valor
Cost
copyrightandotherrestrictions
Description
No
No
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.
73
-
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
Identificador: doc098765
Descripción:
Manual
sobre
variables
aleatorias unidimensionales
e08765 en catálogo manuales
Descripción: Manual sobre reconocimiento
estadístico de patrones
isRequiredBy
isReferencedBy
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.
5.3.8. 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
Emeritus
Bacus Floyd
25/10/2008
Considero la combinación de la expresión formal y la representación gráfica muy
adecuada para transmitir el concepto de normalidad.
El énfasis de la franja de normalidad es apropiado, aunque deberían resaltarse los
puntos de inflexión.
25/11/2008
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.
74
§
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
discipline
Materia
obligatoria
estadística
Palabras
clave
en
discipline
-
educational
level
educational
level
matemáticas
estadística
probabilidad
informática->primer ciclo-> estadística en
carreras
Nodo 455 en carreras
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
75
lom
0..1
general
0..1
lifecycle
0..1
metametadata
0..1
technical
0..1
educational
0..1
rigths
0.. ∞
relation
0.. ∞
annotation
0.. ∞
classification
Figura 5.4.1.b. Aspecto general de la codificación XML de los metadatos del caso de
estudio
<lom:lom>
<lom:general>...</lom:general>
<lom:lifecycle>...</lom:lifecycle>
<lom:metametadata>...</lom:metametadata>
<lom:technical>...</lom:technical>
<lom:educational>...</lom:educational>
<lom:rights>...</lom:rights>
<lom:relation>...</lom:relation>
<lom:relation>...</lom:relation>
<lom:relation>...</lom:relation>
<lom:annotation>...</lom:annotation>
<lom:annotation>...</lom:annotation>
<lom:classification>...</lom:classification>
<lom:classification>...</lom:classification>
<lom:classification>...</lom:classification>
</lom:lom>
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
76
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
general
0..1
identifier
0..1
0.. ∞
title
0.. ∞
catalogentry
0.. ∞
language
langstring
catalog
entry
0.. ∞
description
0.. ∞
keyword
0.. ∞
langstring
0.. ∞
coverage
0.. ∞
langstring
0.. 1
structure
0.. ∞
aggregationlevel
langstring
langstring
source
value
0.. 1
0.. ∞
source
value
77
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
langstring
Figura 5.4.2.b. Codificación de los metadatos de la categoría general del caso de
estudio
<lom:general>
<lom:identifier>Fig00089</lom:identifier>
<lom:title>
<lom:langstring>Función de densidad de probabilidad Normal
</lom:langstring>
</lom:title>
<lom:catalogentry>
<lom:catalog>imágenes</lom:catalog>
<lom:entry>
<lom:langstring>Fig00089</lom:langstring>
</lom:entry>
</lom:catalogentry>
<lom:language>es</lom:language>
<lom:description>
<lom:langstring>Gráfico de la función de densidad
de probabilidad de una normal.</lom:langstring>
</lom:description>
<lom:keyword>
<lom:langstring>probabilidad</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>estadística</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>función de densidad</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>normal</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>campana de gauss</lom:langstring>
</lom:keyword>
<lom:coverage>
<lom:langstring>1823</lom:langstring>
</lom:coverage>
<lom:structure>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">atomic</lom:langstring>
</lom:value>
</lom:structure>
<lom:aggregationlevel>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>1</lom:langstring>
</lom:value>
</lom:aggregationlevel>
</lom:general>
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
78
especifica que, por defecto, los textos estarán en español. El texto tomado del
vocabulario controlado de LOM correspondiente es una excepción.
5.4.3. 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
lifecycle
0..1
0..1
version
0.. ∞
langstring
status
source
0.. ∞
langstring
value
0.. ∞
langstring
0.. ∞
contribute
role
source
value
0.. ∞
0..1
centity
date
0.. ∞
langstring
0.. ∞
langstring
vcard
0..1
0..1
datetime
description
0.. ∞
langstring
§
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.
79
Figura 5.4.3.b. Codificación de los metadatos lifecycle del caso de estudio
<lom:lifecycle>
<lom:version>
<lom:langstring>3.0</lom:langstring>
</lom:version>
<lom:status>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">final</lom:langstring>
</lom:value>
</lom:status>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">content provider</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Franciscus
fn:Emeritus
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>20/04/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:contribute>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">educational validator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Pedro
fn:Censor
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>24/04/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:contribute>
</lom:lifecycle>
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.
80
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
metametadata
0..1
identifier
0.. ∞
source
catalogentry
value
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
contribute
role
0.. ∞
centity
0..1
date
0.. ∞
langstring
value
0.. ∞
langstring
vcard
0..1
0..1
0.. ∞
source
datetime
description
0.. ∞
metadatascheme
0.. 1
language
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.
81
langstring
Figura 5.4.4.b. Codificación de los meta-metadatos del caso de estudio
<lom:metametadata>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">creator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Lula
fn:Hacker
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>30/05/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">creator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Mike
fn:Hammer
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>1/06/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:metadatascheme>LOMv1.0</lom:metadatascheme>
<lom:language>es</lom:language>
</lom:metametadata>
Figura 5.4.4.c. Ejemplo de cómo referir una descripción de metadatos externa
82
<lom:lom>
<lom:metametadata>
<lom:identifier>meta-fig00089</lom:identifier>
<lom:catalogentry>
<lom:catalog>mismetadatos</lom:catalog>
<lom:entry>
<lom:langstring>meta-fig00089</lom:langstring>
</lom:entry>
</lom:catalogentry>
</lom:metametadata>
</lom:lom>
5.4.5. 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
technical
0.. ∞
format
0.. 1
size
0.. ∞
location
0.. ∞
requirement
0.. 1
0.. 1
type
source
0.. ∞
langstring
value
0.. ∞
langstring
source
name
value
0.. 1
minimunversion
0.. 1
maximunversion
0.. ∞
0.. 1
0.. 1
otherplatformsrequirements
duration
0.. 1
langstring
0.. ∞
langstring
langstring
instalationremarks
0.. 1
0.. ∞
0.. ∞ langstring
datetime
0.. 1
description
0.. ∞
langstring
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).
83
Figura 5.4.5.b. Codificación de los metadatos technical del ejemplo
<lom:technical>
<lom:format>img/jpeg</lom:format>
<lom:size>512456</lom:size>
<lom:location>ftp://imgserver.com/images/math/gauss.jpg</lom:location>
<lom:requirement>
<lom:type>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">browser</lom:langstring>
</lom:value>
</lom:type>
<lom:name>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">any</lom:langstring>
</lom:value>
</lom:name>
</lom:requirement>
<lom:installationremarks>
<lom:langstring>Basta disponer de un visualizador de imágenes
JPG como añadido al navegador</lom:langstring>
</lom:installationremarks>
<lom:otherplatformrequirements>
<lom:langstring>Opcionalmente, cualquier otro tipo
de visualizador</lom:langstring>
</lom:otherplatformrequirements>
</lom:technical>
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
84
educational
0.. 1
0.. 1
0.. 1
0.. 1
0.. ∞
interactivitytype
source
0.. ∞
langstring
value
0.. ∞
langstring
0.. ∞
langstring
value
0.. ∞
langstring
source
0.. ∞
langstring
value
0.. ∞
langstring
source
0.. ∞
langstring
value
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
langstring
0.. ∞
langstring
source
0.. ∞
langstring
value
0.. ∞
langstring
source
learningresourcetype
interactivitylevel
semanticdensity
source
intendeduserrole
value
0.. ∞
source
context
value
0.. ∞
0.. 1
0.. 1
typicalagerange
0.. ∞
difficulty
typicallearningtime
0.. 1
langstring
datetime
0.. 1
description
0.. 1
0.. ∞
description
0.. ∞
0.. ∞ langstring
langstring
language
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
85
<lom:educational>
<lom:interactivitytype>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">expositive
</lom:langstring>
</lom:value>
</lom:interactivitytype>
<lom:learningresourcetype>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">figure
</lom:langstring>
</lom:value>
</lom:learningresourcetype>
<lom:interactivitylevel>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">very low
</lom:langstring>
</lom:value>
</lom:interactivitylevel>
<lom:semanticdensity>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">high
</lom:langstring>
</lom:value>
</lom:semanticdensity>
<lom:intendedenduserrole>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">
learner</lom:langstring>
</lom:value>
</lom:intendedenduserrole>
<lom:context>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">
higher education</lom:langstring>
</lom:value>
</lom:context>
<lom:typicalagerange>
<lom:langstring>16-20</lom:langstring>
</lom:typicalagerange>
<lom:difficulty>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">
medium</lom:langstring>
</lom:value>
</lom:difficulty>
<lom:typicallearningtime>
<lom:description>
<lom:langstring>30 minutos</lom:langstring>
</lom:description>
</lom:typicallearningtime>
<lom:description>
<lom:langstring>Entendimiento
cualitativo de los
principales parámetros de la normal
univariante.</lom:langstring>
</lom:description>
<lom:language>es</lom:language>
</lom:educational>
La Figura 5.4.6.b muestra la codificación de los metadatos en la categoría educational
para el caso de estudio.
5.4.7. 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
86
0..1
rights
source
cost
value
0.. ∞
langstring
0.. ∞
langstring
0..1
source
copyrightandotherrestrictions
value
0..1
description
0.. ∞
0.. ∞
langstring
0.. ∞
langstring
langstring
Figura 5.4.7.b.Codificación de los metadatos rights del ejemplo
<lom:rights>
<lom:cost>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">no</lom:langstring>
</lom:value>
</lom:cost>
<lom:copyrightandotherrestrictions>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">no</lom:langstring>
</lom:value>
</lom:copyrightandotherrestrictions>
<lom:description>
<lom:langstring>Este recurso no está sujeto a derechos
de autor alguno,porque las matemáticas son patrimonio
universal de la humanidad.</lom:langstring>
</lom:description>
</lom:rights>
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
relation
0..1
source
kind
value
0..1
0.. 1
resource
0.. ∞
langstring
0.. ∞
langstring
identifier
0.. ∞
0.. 1
langstring
description
0.. ∞
catalog
catalogentry
entry
87
0.. ∞
langstring
Figura 5.4.8.b. Codificación de las relaciones del material ejemplo con otro material
<lom:relation>
<lom:kind>
<lom:source>
<lom:langstring>LOMv1.0 </lom:langstring >
</lom:source >
<lom:value>
<lom:langstring xml:lang="en">isPartOf </lom:langstring>
</lom:value>
</lom:kind >
<lom:resource >
<lom:identifier >doc098765</lom:identifier>
<lom:description>
<lom:langstring >Manual sobre
variables aleatorias unidimensionales</lom:langstring>
</lom:description>
</lom:resource>
</lom:relation >
<lom:relation>
<lom:kind >
<lom:source>
<lom:langstring>LOMv1.0 </lom:langstring >
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">isRequiredBy </lom:langstring >
</lom:value>
</lom:kind>
<lom:resource>
<lom:identifier>doc098765</lom:identifier >
<lom:description >
<lom:langstring>Manual sobre variables aleatorias
unidimensionales</lom:langstring>
</lom:description>
</lom:resource>
</lom:relation >
<lom:relation>
<lom:kind >
<lom:source >
<lom:langstring >LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang ="en">isReferencedBy</lom:langstring>
</lom:value>
</lom:kind>
<lom:resource>
<lom:description >
<lom:langstring>Manual sobre reconocimiento estadístico
de patrones </lom:langstring >
</lom:description>
<lom:catalogentry>
<lom:catalog>manuales</lom:catalog>
<lom:entry>
<lom:langstring >e08765</lom:langstring>
</lom:entry>
</lom:catalogentry>
</lom:resource>
</lom:relation >
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
88
Figura 5.4.9.a.
Figura 5.4.9.a. Codificación de las anotaciones
annotation
0..1
vcard
person
0.. 1
0.. 1
date
datetime
0.. 1
description
0.. 1
description
0.. ∞
langstring
0.. ∞ langstring
Figura 5.4.9.b. Codificación de anotaciones en el ejemplo
<lom:annotation>
<lom:person>
<lom:vcard>
begin:vcard
n:Franciscus
fn:Emeritus
end:vcard
</lom:vcard>
</lom:person>
<lom:date>
<lom:datetime>25-10-2008</lom:datetime>
</lom:date>
<lom:description>
<lom:langstring>Considero la combinación de la expresión formal y
la representación gráfica muy adecuada para transmitir
el concepto de normalidad.</lom:langstring>
</lom:description>
</lom:annotation>
<lom:annotation>
<lom:person>
<lom:vcard>
begin:vcard
n:Bacus
fn:Floyd
end:vcard
</lom:vcard>
</lom:person>
<lom:date>
<lom:datetime>25-11-2008</lom:datetime>
</lom:date>
<lom:description>
<lom:langstring>El énfasis de la franja de normalidad es
apropiado,aunque deberían resaltarse los puntos de
inflexión.</lom:langstring>
</lom:description>
</lom:annotation>
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.
89
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
classification
0..1
purpose
0..∞
taxonpath
0..1
0..1
source
0.. ∞
langstring
value
0.. ∞
langstring
source
0.. ∞
langstring
0..1
taxom
0..1
id
entry
0.. ∞
langstring
0..1
0..1
description
0..∞
keyword
0.. ∞
0.. ∞
langstring
langstring
§
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
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:description>
<lom:langstring>Materia obligatoria en estadística</lom:langstring>
</lom:description>
</lom:classification>
-
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.
90
Figura 5.4.10.c. Codificación de una clasificación por palabras clave
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:keyword>
<lom:langstring>matemáticas</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>estadística</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>probabilidad</lom:langstring>
</lom:keyword>
</lom:classification>
-
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
</lom:classification>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:taxonpath>
<lom:source>
<lom:langstring>carreras</lom:langstring>
</lom:source>
<lom:taxon>
<lom:id>n455</lom:id>
</lom:taxon>
</lom:taxonpath>
</lom:classification>
-
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
91
-
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
</lom:classification>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:taxonpath>
<lom:source>
<lom:langstring>carreras</lom:langstring>
</lom:source>
<lom:taxon>
<lom:entry>
<lom:langstring>informática</lom:langstring>
</lom:entry>
<lom:taxon>
<lom:entry>
<lom:langstring>primer ciclo</lom:langstring>
</lom:entry>
<lom:taxon>
<lom:entry>
<lom:langstring>estadística</lom:langstring>
</lom:entry>
</lom:taxon>
</lom:taxon>
</lom:taxon>
</lom:taxonpath>
</lom:classification>
5.5. 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:
92
§
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:
93
-
-
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. DUBLÍN 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
<dc:title>
Normal
</dc:title>
<dc:description>
Función de densidad de probabilidad normal
</dc:description>
<dc:publisher>
CNICE
</dc:publisher>
<dc:identifier>
http://www.foo.org/default
</dc:identifier>
5.7. APÉNDICE: ejemplo completo de metadatos ims lom
codificados en XML
En este apéndice se incluye la codificación en XML completa de los metadatos para el
ejemplo utilizado a lo largo de todo este capítulo sobre metadatos.
94
<lom:lom>
<lom:general>
<lom:identifier>Fig00089</lom:identifier>
<lom:title>
<lom:langstring>Función de densidad de probabilidad Normal</lom:langstring>
</lom:title>
<lom:catalogentry>
<lom:catalog>imágenes</lom:catalog>
<lom:entry>
<lom:langstring>Fig00089</lom:langstring>
</lom:entry>
</lom:catalogentry>
<lom:language>es</lom:language>
<lom:description>
<lom:langstring>Gráfico de la función de densidad de probabilidad
de una normal.</lom:langstring>
</lom:description>
<lom:keyword>
<lom:langstring>probabilidad</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>estadística</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>función de densidad</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>normal</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>campana de gauss</lom:langstring>
</lom:keyword>
<lom:coverage>
<lom:langstring>1823</lom:langstring>
</lom:coverage>
<lom:structure>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">atomic</lom:langstring>
</lom:value>
</lom:structure>
<lom:aggregationlevel>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>1</lom:langstring>
</lom:value>
</lom:aggregationlevel>
</lom:general>
<lom:lifecycle>
<lom:version>
<lom:langstring>3.0</lom:langstring>
</lom:version>
<lom:status>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">final</lom:langstring>
</lom:value>
</lom:status>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">content provider</lom:langstring>
95
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Franciscus
fn:Emeritus
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>20/04/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">educational validator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Pedro
fn:Censor
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>24/04/2008</lom:datetime>
</lom:date>
</lom:contribute>
</lom:lifecycle>
<lom:metametadata>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">creator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Lula
fn:Hacker
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>30/05/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:contribute>
<lom:role>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">validator</lom:langstring>
</lom:value>
</lom:role>
<lom:centity>
<lom:vcard>
begin:vcard
n:Mike
fn:Hammer
96
end:vcard
</lom:vcard>
</lom:centity>
<lom:date>
<lom:datetime>1/06/2008</lom:datetime>
</lom:date>
</lom:contribute>
<lom:metadatascheme>LOMv1.0</lom:metadatascheme>
<lom:language>es</lom:language>
</lom:metametadata>
<lom:technical>
<lom:format>img/jpeg</lom:format>
<lom:size>512456</lom:size>
<lom:location>ftp://imgserver.com/images/math/gauss.jpg</lom:location>
<lom:requirement>
<lom:type>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">browser</lom:langstring>
</lom:value>
</lom:type>
<lom:name>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">any</lom:langstring>
</lom:value>
</lom:name>
</lom:requirement>
<lom:installationremarks>
<lom:langstring>Basta disponer de un visualizador de imágenes JPG
como añadido al navegador</lom:langstring>
</lom:installationremarks>
<lom:otherplatformrequirements>
<lom:langstring>Opcionalmente, cualquier otro tipo
de visualizador</lom:langstring>
</lom:otherplatformrequirements>
</lom:technical>
<lom:educational>
<lom:interactivitytype>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">expositive</lom:langstring>
</lom:value>
</lom:interactivitytype>
<lom:learningresourcetype>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">figure</lom:langstring>
</lom:value>
</lom:learningresourcetype>
<lom:interactivitylevel>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">very low </lom:langstring>
</lom:value>
</lom:interactivitylevel>
<lom:semanticdensity>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">high</lom:langstring>
97
</lom:value>
</lom:semanticdensity>
<lom:intendedenduserrole>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">learner</lom:langstring>
</lom:value>
</lom:intendedenduserrole>
<lom:context>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">higher education</lom:langstring>
</lom:value>
</lom:context>
<lom:typicalagerange>
<lom:langstring>16-20</lom:langstring>
</lom:typicalagerange>
<lom:difficulty>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">medium</lom:langstring>
</lom:value>
</lom:difficulty>
<lom:typicallearningtime>
<lom:description>
<lom:langstring>30 minutos</lom:langstring>
</lom:description>
</lom:typicallearningtime>
<lom:description>
<lom:langstring>Entendimiento cualitativo de los principales parámetros
de la normal univariante.</lom:langstring>
</lom:description>
<lom:language>es</lom:language>
</lom:educational>
<lom:rights>
<lom:cost>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">no</lom:langstring>
</lom:value>
</lom:cost>
<lom:copyrightandotherrestrictions >
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">no</lom:langstring>
</lom:value>
</lom:copyrightandotherrestrictions >
<lom:description>
<lom:langstring>Este recurso no está sujeto a derechos de autor alguno,
porque las matemáticas son patrimonio universal de
la humanidad.</lom:langstring>
</lom:description>
</lom:rights>
<lom:relation>
<lom:kind>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">isPartOf</lom:langstring>
</lom:value>
</lom:kind>
98
<lom:resource>
<lom:identifier>doc098765</lom:identifier>
<lom:description>
<lom:langstring>Manual sobre variables
aleatorias unidimensionales</lom:langstring>
</lom:description>
</lom:resource>
</lom:relation>
<lom:relation>
<lom:kind>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">isRequiredBy</lom:langstring>
</lom:value>
</lom:kind>
<lom:resource>
<lom:identifier>doc098765</lom:identifier>
<lom:description>
<lom:langstring>Manual sobre variables
aleatorias unidimensionales</lom:langstring>
</lom:description>
</lom:resource>
</lom:relation>
<lom:relation>
<lom:kind>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring xml:lang="en">isReferencedBy </lom:langstring>
</lom:value>
</lom:kind>
<lom:resource>
<lom:description>
<lom:langstring>Manual sobre reconocimiento
estadístico de patrones </lom:langstring>
</lom:description>
<lom:catalogentry>
<lom:catalog>manuales</lom:catalog>
<lom:entry>
<lom:langstring>e08765</lom:langstring>
</lom:entry>
</lom:catalogentry>
</lom:resource>
</lom:relation>
<lom:annotation>
<lom:person>
<lom:vcard>
begin:vcard
n:Franciscus
fn:Emeritus
end:vcard
</lom:vcard>
</lom:person>
<lom:date>
<lom:datetime>25-10-2008</lom:datetime>
</lom:date>
<lom:description>
<lom:langstring>Considero la combinación de la expresión formal y
la representación gráfica muy adecuada para transmitir
el concepto de normalidad.</lom:langstring>
</lom:description>
</lom:annotation>
<lom:annotation>
<lom:person>
<lom:vcard>
begin:vcard
n:Bacus
fn:Floyd
end:vcard
99
</lom:vcard>
</lom:person>
<lom:date>
<lom:datetime>25-11-2008</lom:datetime>
</lom:date>
<lom:description>
<lom:langstring>El énfasis de la franja de normalidad es apropiado,
aunque deberían resaltarse los puntos de
inflexión..</lom:langstring>
</lom:description>
</lom:annotation>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:description>
<lom:langstring>Materia obligatoria en estadística</lom:langstring>
</lom:description>
</lom:classification>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:keyword>
<lom:langstring>matemáticas</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>estadística</lom:langstring>
</lom:keyword>
<lom:keyword>
<lom:langstring>probabilidad</lom:langstring>
</lom:keyword>
</lom:classification>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:taxonpath>
<lom:source>
<lom:langstring>carreras</lom:langstring>
</lom:source>
<lom:taxon>
<lom:entry>
<lom:langstring>informática</lom:langstring>
</lom:entry>
<lom:taxon>
<lom:entry>
<lom:langstring>primer ciclo</lom:langstring>
</lom:entry>
<lom:taxon>
<lom:entry>
<lom:langstring>estadística</lom:langstring>
</lom:entry>
</lom:taxon>
</lom:taxon>
</lom:taxon>
</lom:taxonpath>
100
</lom:classification>
<lom:classification>
<lom:purpose>
<lom:source>
<lom:langstring>LOMv1.0</lom:langstring>
</lom:source>
<lom:value>
<lom:langstring>discipline</lom:langstring>
</lom:value>
</lom:purpose>
<lom:taxonpath>
<lom:source>
<lom:langstring>carreras</lom:langstring>
</lom:source>
<lom:taxon>
<lom:id>n455</lom:id>
</lom:taxon>
</lom:taxonpath>
</lom:classification>
</lom:lom>
101
6. IMS
QUESTION
SPECIFICATION
&
TEST
INTEROPERABILITY
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
102
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.
3
http://alamo.sim.ucm.es/comprueba/intro.htm
103
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.
104
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.
105
Figura 6.4.a. Estructura de un assessmentItem (pregunta) y su proceso de evaluación
ASSESSMENTITEM
(pregunta)
ITEMBODY
1
INTERACTION
(interacción)
Contenido
(XHTML, MathML)
RESPUESTAS
3
2
CORRECCIÓN
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.
6.5. 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.
106
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.
107
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
108
Figura 6.5.1.d. Ejemplo de matchInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide
Figura
6.5.1.e.
Ejemplo
Fuente: IMS QTI v 2.1 Implementation Guide.
109
de
gapMatchInteraction.
6.5.2. 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.
110
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
111
Figura 6.5.2.d. Ejemplo de hottextInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide
6.5.3. 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 a
l
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,
112
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
Fuente: IMS QTI v 2.1 Implementation Guide.
113
de
selectPointInteraction.
Figura
6.5.3.c.
Ejemplo
Fuente: IMS QTI v 2.1 Implementation Guide.
de
graphicOrderInteraction.
Figura 6.5.3.d. Ejemplo de graphicAssociateInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide.
114
Figura
6.5.3.e.
Ejemplo
de
Fuente: IMS QTI v 2.1 Implementation Guide
Figura 6.5.3.f. Ejemplo de positionObjectInteraction.
Fuente: IMS QTI v 2.1 Implementation Guide
115
graphicGapMatchInteraction.
6.5.4. Otras 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
116
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).
117
Figura 0.a. Estructura de un examen (assessmentTest) completo.
Paquete IMS
(IMS CP)
asessmentTest
(examen)
testPart
(partición)
testPart
(partición)
testPart
(partición)
section
P1
P2
section
P3
pregunta
pregunta
section
section
section
P4
P5
pregunta
pregunta
P6
P7
pregunta
pregunta
pregunta
Figura 0.b. Vista del módulo de edición de exámenes de la herramienta <e-QTI>
118
6.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.
119
§
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.
120
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
121
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
(a)
¿Cuál de las provincias destacadas es Toledo?
(b)
¿ Cuál de las provincias destacadas es Toledo?
¡Has seleccionado Cuenca!, inténtalo 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
122
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.
6.8.3. 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
123
(1)
testPart
S1
P1
S2
P2
S3
S4
P3
P6
S5
P4
P5
P7
(2)
testPart
S1
S2
P1
S4
P4
S5
P3
P5
P7
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.
124
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
Paquete IMS
(IMS Content Packaging)
manifiesto
(imsmanifest.xml)
recurso
pregunta
recurso
pregunta
recurso
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
125
§
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://eaula.sip.ucm.es/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/)
126
7. 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.
127
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
128
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)
129
É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 IEEELTSC:
§
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.
130
§
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.2.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.2.3.a: Los ficheros que forman el curso de Introducción a la Geometría
131
principal.html
cursogeometria
Tutorial
intro.html
conten.html
res.html
Fig0.1.jpg
Fig0.2.jpg
Tema1.html
Tema 1
Fig1.1.jpg
PC
Prof. Emeritus
Tema2.html
Tema 2
Fig2.1 .jpg
ej1.xml
ebasicos
ej2.xml
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.
132
Figura 7.3.1.a: Recursos simples y Recursos Compuestos en el caso de estudio
Recurso simple
principal.html
Recurso simple
intro.html
Recurso compuesto
Recurso compuesto
Recurso compuesto
Recurso simple
Recurso simple
Tema1.html
Recurso simple
Fig1.1.jpg
Ej1.xml
Recurso simple
FigA.1.jpg
Recurso simple
Recurso compuesto
Recurso compuesto
Recurso simple
Recurso simple
conten.html
Recurso simple
Tema2.html
Ej2.1.xml
Fig0.1.jpg
Recurso simple
Recurso simple
Recurso simple
Fig2.1.jpg
FigB.1.jpg
Fig0.2.jpg
Recurso simple
res.html
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
133
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
134
SCO – Tutorial
Modulo de
comunicación
principal.html
res.html
intro.html
Fig0.1.jpg
conten.html
Fig0.2.jpg
SCO – Tema 1
Modulo de
comunicación
SCO – Tema 2
Tema1.html
Fig1.1.jpg
SCO – Ejercicio 1
Modulo de
comunicación
Modulo de
comunicación
Tema2.html
Fig2.1.jpg
SCO – Ejercicio 2
Ej1.xml
FigA.1.jpg
Modulo de
comunicación
Ej2.xml
FigB.1.jpg
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 0) 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)
135
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 0.b: Actividades, organizaciones y agregaciones de contenido (Fuente: SCORM
2004 3rd Edition)
Introducción
a la Geometría
Estudiar el material
Tutorial
SCO – Tutorial
Tema 1
SCO – Tema 1
Tema 2
SCO – Tema 2
Evaluación
Ejercicio 1
SCO – Ejercicio 1
Ejercicio 2
SCO – Ejercicio 2
136
Nuestro ejemplo incluye dos actividades principales (estudiar el contenido y realizar el
ejercicio correspondiente). Como se observa en la Figura 0.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
137
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.
138
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.
139
7.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
140
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
Navegador Web
Interfaz de Usuario del LMS
Implementación
de la API
Sistema
receptor de
invocaciones a
funciones
SCO
Sistema
que invoca
funciones
de la API
Contenido
educativo
Sistema de
comunicación
Internet o Red de Área Local
LMS
Sistema de
comunicación
Funciones habituales
del LMS
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
141
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,
http://www.adlnet.gov/scorm/certified/index.cfm?event=main.information
142
consúltese
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
aproximaciones educativas y distintos procesos de aprendizaje.
§
Permitir la implementación de Unidades de Aprendizaje consistentes en
actividades heterogéneas.
143
de
distintas
§
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
144
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
145
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.
Alumno
Evaluador
Lección 1
Lección 2
Ejercicio A
Ejercicio B
Examen
Evaluación
del examen
[NO]
¿Aprobado?
[SÍ]
146
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 actores
interpretan 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
147
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.
148
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 des arrollen 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 RELOAD4. 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.4.3.a: El editor de IMS Learnign Design de Reload.
4
http://www.reload.ac.uk/ldeditor.html
149
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.
5
http://coppercore.sourceforge.net/
150
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.
151
9. SISTEMAS DE GESTION DEL APRENDIZAJE: MOODLE
Un Sistema de Gestión de Aprendizaje (Learning Management System, LMS), es una
herramienta informática, habitualmente de gran tamaño, que permite la gestión y
presentación de materiales educativos a estudiantes. El objetivo de estas herramientas
el permitir el aprendizaje en cualquier parte y en cualquier momento. La mayoría de
estas herramientas son herramientas web, es decir, herramientas que se usan a través
de Internet utilizando un navegador web.
Los LMS habitualmente proporcionan un conjunto de funcionalidades básicas como:
§
Gestión de Usuarios. Registro de profesores y alumnos, donde estos
habitualmente pueden personalizar una ficha con información adicional.
§
Gestión de cursos y grupos. Permite la creación y gestión de cursos y grupos
de trabajo, dentro de estos cursos se encontrarán los materiales educativos
que se presentarán finalmente a los alumnos.
§
Herramientas de Comunicación. Habitualmente se incluyen herramientas
dentro del sistema que permiten la comunicación entre los participantes del
curso, como por ejemplo foros, chats, etc.
§
Herramientas de evaluación. Habitualmente dentro del proceso educativo
necesitaremos aplicar algún tipo de metodología para evaluar el desempeño
del alumno en una materia. Algunas metodologías pueden ser la realización de
algún tipo de examen o la creación de trabajos. Los LMS incluirán herramientas
que faciliten la aplicación de estas metodologías, ya sea mediante la creación
de herramientas de gestión de exámenes en línea, o herramientas para la
gestión de entrega de tareas.
En la actualidad existen multitud de LMS disponibles para la comunidad educativa,
tanto comerciales (WebCT, BlackBoard, Desire2Learn, Learn eXact entre otros) como
de libre distribución (Moodle, Dokeos, Claroline, ILIAS, SAKAI, LAMS entre otros). La
diferencia entre estos sistemas, son el conjunto de herramientas que nos proporciona,
la fiabilidad de los mismos.
En esta sección describiremos la herramienta Moodle, siendo una de las herramientas
de libre distribución más robustas, fiables y por ello es ampliamente utilizada tanto por
la comunidad educativa como la comunidad investigadora.
9.1. Introducción a MOODLE
Moodle es un Sistema de Gestión de Cursos (Course Management System, CMS)
aunque también es conocido por otros nombres, como LMS o Entorno de Aprendizaje
Virtual (Virtual Learning Environment, VLE). Esta herramienta permite a los profesores
y educadores la creación de cursos en línea, aunque también puede ser utilizado
como herramienta de trabajo colaborativa. El objetivo es que el usuario sólo necesite
un navegador web en su ordenador y una conexión a Internet para interactuar con la
herramienta.
152
MOODLE es el acrónimo de Modular Object Oriented Dynamic Learning Environment
(Entorno de Aprendizaje Modular Orientado a Objetos). Las primeras etapas del
desarrollo de Moodle comenzaron en 1999, siendo el creador del sistema Martin
Dougiamas.
Moodle ha sido desarrollado como una herramienta de código abierto (opensource).
Esto significa que aunque Moodle tiene copyright, tenemos libertad para copiar, utilizar
y modificar Moodle siempre y cuando estemos de acuerdo a: proporcionar el código
fuente a otros; no modificar o eliminar la licencia original y el copyright y aplicar la
misma licencia a todo trabajo derivado.
Moodle está desarrollado sobre tecnologías de código abierto de amplia implantación,
lo que permite que pueda utilizarse en múltiples Sistemas Operativos, como Windows,
Linux, Mac OS X, etc.
El diseño y el desarrollo de Moodle está guiado por un filosofía particular de
aprendizaje, una manera de pensar que recibe el nombre de “pedagogía social
construccionista”. Esta filosofía está basada en 4 conceptos principales:
§
Constructivismo. La teoría constructivista, atribuida al filósofo Jean Piage,
sostiene que las personas construyen nuevos conocimientos de manera activa
al tiempo que interactúan con su entorno siguiendo un proceso de asimilación y
acomodación. Una persona asimilará un concepto cuando las experiencias
sean alineadas con respecto al conocimiento previo de la persona. Por otra
parte el proceso de acomodación, es el proceso en el cual la persona debe
acomodar los conocimientos previos a los nuevos conocimientos que ha
adquirido.
§
Construccionismo. El construccionismo afirma que el aprendizaje es más
efectivo cuando se construyen cosas. Por ejemplo, durante la lectura de este
informe, el lector puede tomar notas, aun cuando no vaya a utilizarlas
posteriormente, la construcción de estas notas permitirá una mejor asimilación
de los conceptos con sus propios conocimientos.
§
Construccionismo Social. Este concepto extiende las ideas anteriormente
descritas a un grupo social. Los individuos de este grupo social construye
artefactos para los otros individuos del grupo, creando de manera colaborativa
una pequeña cultura de artefactos compartidos con significados compartidos.
§
Conectado y Separado. Esta idea profundiza en las motivaciones de los
individuos dentro de una discusión. Una persona aplica el comportamiento
separado cuando intenta mantenerse “objetivo” y tiende a defender sus propias
ideas utilizando la lógica y encontrando puntos débiles en las ideas del
oponente. Una persona utiliza un comportamiento conectado cuando aplica
aproximación más empática que acepta subjetivamente, intentado escuchar y
realizar preguntas, en un esfuerzo de comprender el otro punto de vista. El
comportamiento construido está basado en que una persona es susceptible a
ambas aproximaciones descritas y es capaz de elegir cual de ellas es la
apropiada en la situación actual.
153
9.1.1. Características Generales
Como se ha mencionado, Moodle es un LMS. Algunas características interesantes
son:
§
§
Moodle puede ser ejecutado en Unix, Linux, Windows, Mac OS X, y en general
cualquier otro sistema que soporte la tecnología PHP (lo cual incluye a la
mayoría de proveedores web).
Moodle está diseñado de manera modular, permitiendo una gran flexibilidad
para añadir (y eliminar) funcionalidades en varios niveles.
§
Moodle puede ser actualizado de una versión en la siguiente, contiene un
sistema interno que permite la actualización del sistema manteniendo toda la
información que ha sido creada.
§
Moodle tiene hace énfasis en la seguridad de principio a fin. Moodle permite
definir distintos niveles de acceso a los cursos, por ejemplo teniendo varios
niveles de acceso para profesores
§
Moodle promociona la pedagogía construccionista social (en la que se
incluye la colaboración, el aprendizaje basado en actividades, reflexión crítica,
etc.).
§
Moodle es adecuado como herramienta de apoyo a la docencia tanto
presencial como completamente virtual.
§
Moodle tiene contiene una interfaz simple, ligera, eficiente, compatible con
multitud de navegadores web.
§
Moodle puede ser utilizado para impartir múltiples cursos, permitiendo que el
profesor que ha creado permita acceso al mismo a los alumnos, invitados, e
incluso a otros profesores.
9.2. Guía visual a las herramientas disponibles
En esta sección se proporcionará una introducción a las herramientas que tenemos
disponibles dentro de Moodle. Esta guía no pretende ser una guía exhaustiva para
todos los detalles de las mismas, sino que pretende proporcionar una guía visual para
las mismas.
9.2.1. Cursos
Los cursos forman parte que los conceptos principales dentro de Moodle. Un curso
puede considerarse como un sitio web donde estarán integrados los contenidos
educativos y numerosas herramientas que el profesor del curso considere oportunas.
El profesor además configurará el acceso que desea para su curso, podrá añadir
alumnos y otros profesores al curso, a partir de los usuarios que existen en el sistema
o permitir el registro manual de los alumnos dentro del curso.
Durante el proceso de creación de un curso (ver Figura 9.2.1.a) Se puede elegir el
formato que tendrá el curso. El formato del curso definirá la organización principal que
154
tendrá el sitio web del curso. Algunos de los formatos que tenemos disponibles dentro
del curso son:
§
Formato Semanal. Este tipo de curso, la estructura del sitio web del curso se
dispone entorno al trabajo semanal que debe realizar los alumnos dentro del
curso.
§
Formato por temas. En este tipo de curso, la estructura está organizada por
temas, estos temas pueden considerarse los módulos o lecciones a partir de
los cuales estará construido el curso completo.
Formato Social. En este formato de curso está organizado alrededor de un
foro principal de discusión.
§
Una vez que hemos creado el curso, podemos editar la estructura del sitio principal del
curso (ver Figura 9.2.1.b), donde el profesor puede adaptarlo según gustos
personales, permitiendo colocar en distintas posiciones las herramientas que desee
que los alumnos tengan disponibles.
Además de la definición de la estructura general del curso, dentro de los cursos
deberemos incluir los recursos educativos a utilizar y las actividades a realizar.
Existen diferentes módulos de actividades que podemos incluir dentro de un curso en
Moodle, entre ellos podemos destacar:
§
Comunicación y colaboración. Podemos incluir foros y chats para llevar a
cabo actividades conversacionales, junto a la posibilidad de realizar consultas
posteriormente para obtener realimentación de la actividad en grupo. Además
también tenemos disponible el uso de wiki, que permitirán realizar trabajos en
grupo.
§
Tareas y trabajos. El trabajo de los alumnos puede ser propuesto por los
profesores mediante la creación de tareas o mediante la creación de talleres.
También existe la posibilidad de crear exámenes online que serán
automáticamente evaluados.
§
Lecciones. Podemos crear módulos de contenidos se adapten a las
elecciones de los alumnos mediante el uso de lecciones o de actividades
SCORM. Además también existe la posibilidad de crear glosarios de
terminología de manera colaborativa.
Asimismo Moodle suporta un amplio espectro de recursos digitales que podemos
utilizar como recursos dentro de los cursos. Algunos de estos tipos de recursos son:
§
Páginas de Texto. Estas páginas pueden ser simples páginas de texto sin
ningún tipo de formato de estilo, aunque no muy atractivas, pueden ser
utilizadas para describir instrucciones a cerca de las tareas a llevar a cabo para
incluir otro tipo de información.
§
Páginas web. Mediante el uso de un editor en línea integrado dentro de
Moodle podemos crear páginas web más atractivas. Dentro de las páginas
web, podremos aplicar estilos a los contenidos e incluir contenidos multimedia
dentro de las mismas.
155
§
Contenidos online o multimedia. Dentro del curso podemos reutilizar otro
tipo de contenidos multimedia y de otro tipo de contenidos que están
disponibles a través de la web. Dentro de Moodle podemos hacer referencia
dentro de un curso a todo este tipo de contenidos.
§
Carpetas. Podemos simplemente permitir al alumno que navegue a través del
contenido que hayamos dejado disponible en alguna carpeta dentro de nuestro
curso.
§
IMS Content Packaging. Tenemos la posibilidad de poder incluir como
recursos dentro de Moodle de aquellos contenidos empaquetados utilizando el
formato IMS CP.
Figura 9.2.1.a. Pantalla de creación de un nuevo curso en Moodle. Durante este
proceso podemos elegir el formato que tendrá el curso.
Figura 9.2.1.b. Moodle durante el proceso de edición del curso. La estructura principal
a editar dependiendo del formato de curso que se haya elegido en la etapa de
creación del curso
156
9.2.2. Tareas
Las tareas permiten a los profesores evaluar tanto entregas de material electrónico,
como tareas creadas en papel o presentaciones de clase. Por ejemplo, el alumno
puede crear una página de texto utilizando Moodle o la actividad puede consistir en la
creación de algún trabajo en el ordenador del alumno y su posterior envío al profesor a
través de Moodle. También es posible asignar algún tipo de tarea que no esté
vinculada necesariamente al uso de los ordenadores, en este caso el resultado de la
tarea asignada será entregada al profesor de alguna manera para posteriormente ser
evaluada.
Figura 0.a. Ejemplo de Tarea de entrega online de un fichero. Una vez terminada la
tarea realizada el resultado que evaluará el profesor será el archivo creado y que será
entregado a través de la herramienta. Al crear la tarea podemos indicar una fecha de
entrega y una fecha límite de entrega. También podemos restringir el tamaño máximo
que puede tener el archivo que nos entregará el alumno. Adicionalmente podemos
controlar si permitimos al alumno que pueda entregar el archivo varias veces o no
157
Figura 0.b. (i) Ejemplo de Tarea de construcción de documento en línea. (ii) Dentro de
la propia herramienta se puede hacer uso de un editor para la creación del informe
para la tarea
158
(i)
(ii)
Figura 0.c. Tarea que no se realizará utilizando la herramienta online. En este caso
sólo se describirá la tarea a realizar
159
9.2.3. Chat
El módulo de Chat permite a los participantes tener una discusión en tiempo real via
web, permitiendo obtener los diferentes puntos de vista de cada uno de los alumnos
en un tema de discusión particular.
Figura 9.2.3.a. Chat web dentro de Moodle. Durante el proceso de creación de una
actividad de tipo Chat podemos planificar sesiones de Chat, por ejemplo, planificando
una sesión de Chat cada día a la misma hora. Además pueden almacenarse las
conversaciones llevadas a cabo a través del Chat de manera que pueden ser
posteriormente revisadas y analizadas
160
9.2.4. Consultas
Los profesores pueden proponer una pregunta y un conjunto de posibles respuestas.
Esto puede ser útil como una rápida encuesta para estimular la reflexión acerca de un
tema, permitiendo a la clase votar en una dirección para el curso, o recoger un
consenso de investigación.
Podemos especificar cuando estará disponible para los alumnos la encuesta y la fecha
tope para la realización de la misma. Además podemos configurar si deseamos que
los alumnos puedan visualizar o no los resultados de la encuesta, y en el caso
afirmativo en qué momento, justo después de contestar la consulta o cuando finalice la
fecha tope. También es posible indicar si deseamos que las respuestas estén
identificadas, es decir, que se visualice quién ha contestado qué.
Figura 9.2.4.a. (i) Ejemplo de encuesta. (ii) Visualización del resultado de la encuesta
161
(i)
(ii)
162
9.2.5. Foros de discusión
En los foros es donde la mayor parte de las discusiones tienen lugar. Los foros pueden
ser estructurados de diferentes formas. Además es posible que los estudiantes que
participan en los foros den una valoración de los mensajes que son enviados al foro.
Existen distintos tipos de foros de discusión que podemos crear, dependiendo del
objetivo con el que deseamos aplicarlos:
§
Debate sencillo. En este tipo, sólo se permite un único tema de discusión,
estando el contenido de este foro incluido completamente en una única página.
Este tipo de foros es útil para realizar reflexiones breves a cerca de algún tema.
§
Cada persona plantea un debate. En este tipo de foros cada uno de los
participantes puede crear como máximo un tema de discusión. Este tipo de foro
es interesante, por ejemplo, para que cada alumno plantee alguna reflexión
acerca del algún trabajo realizado y el resto de compañeros pueden
responderle.
§
Foro general. Como su nombre indica es el tipo de foro más general en el que
se permiten crean nuevos temas de conversación dentro del mismo.
Figura 9.2.5.a. Ejemplo de foro de discusión general
9.2.6. Exámenes
Dentro de Moodle existe un módulo para la creación y gestión de exámenes en línea.
Este módulo permite la creación de exámenes con distintos tipos de preguntas entre
las cuales podemos encontrar:
163
§
§
§
§
§
Opción múltiple.
Verdadero / Falso.
Respuesta Corta.
Ensayo.
Relación.
Figura 9.2.6.a. Vista de edición de una Pregunta Verdadero / Falso.
Figura 9.2.6.b. Vista previa del examen que estamos configurando
164
Este módulo también permite la gestión de un almacén de preguntas y la posibilidad
de agruparlas por categorías.Además también se nos proporciona la posibilidad de
poder importar y exportar las preguntas desde y hacia distintos formatos de preguntas
respectivamente.
9.2.7. Glosario
Este módulo permite a los participantes de la actividad crear y mantener una lista de
definiciones de términos, al estilo de un diccionario. Una vez creado, podemos realizar
búsquedas dentro del diccionario creado y además se nos permite visualizar el
diccionario de distintas formas. Cuando hacemos uso de este módulo para crear un
nuevo glosario, podemos configurar quién podrá crear nuevas entradas dentro del
glosario, es decir, podemos especificar si el profesor es el único que puede crear
nuevas entradas y si los alumnos también pueden hacerlo.
Figura 9.2.7.a. Ejemplo de glosario de terminología.
165
9.2.8. Encuestas
El módulo de encuestas proporciona un conjunto de herramientas que han demostrado
ser útiles para evaluar y estimular el aprendizaje mediante el uso de herramientas en
línea como Moodle.
Los profesores pueden utilizar estas herramientas para recolectar información de sus
estudiantes que podrá ser utilizada para mejorar le método docente aplicado en las
clases.
Figura 9.2.8.a. Ejemplo de encuesta presentada al estudiante en algún punto del curso
166
9.2.9. Wiki
El módulo de Wiki puede ser utilizado para promover el trabajo en colaboración de los
alumnos. Los alumnos pueden crear documentos de trabajo de manera colaborativa
mediante el uso de esta herramienta, en vez de pasarse entre ellos un documento a
editar con alguna herramienta ofimática.
Figura 9.2.9.a. Vista de creación de una WIKI para el curso
167
Figura 9.2.9.b. Vista previa en la edición del contenido de una página WIKI
168
9.3. Soporte de estándares educativos en MOODLE
En esta sección haremos uso de algunos de los estándares de e-learning que han sido
descritos en este documento. Utilizaremos Moodle como herramienta principal para
realizar las pruebas.
9.3.1. Ejemplo de Intercambio de módulos de cursos entre WebCT
y Moodle
Para poner en práctica el uso de algunas de las especificaciones que han sido
tratados a lo largo del documento, vamos a realizar el intercambio de un módulo de un
curso entre dos LMS, WebCT y Moodle.
En la figura 9.3.1.a se muestra la estructura del módulo de “Introducción a la
Geometría” introducido en el capítulo sobre la especificación IMS Content Packaging.
El módulo está compuesto de dos apartados, un tutorial y una tanda de ejercicios. El
tutorial está formado por varias páginas web contienen imágenes como contenidos
multimedia. El conjunto completo de archivos, tanto las páginas, como los archivos
auxiliares aparecen en la figura 9.3.1.b.
Figura 9.3.1.a. Vista del profesor en WebCT para el módulo de contenidos creado
para el caso de ejemplo del módulo de “Introducción a la Geometría” impartido por el
profesor Eméritus
Figura 9.3.1.b. Vista de los archivos físicos utilizados dentro del módulo.
169
Para poder exportar el contenido de un módulo de los cursos debemos hacer uso de la
herramienta “Exportar Contenido” disponible en WebCT a través del panel de control
de WebCT. Dentro de la herramienta seleccionaremos la opción de exportar módulos
de contenidos ya que deseamos exportar únicamente el módulo de contenido del
curso de Introducción a la Geometría.
Figura 9.3.1.c. Herramienta de para exportar contenidos de WebCT.
170
Figura 9.3.1.d. Proceso y resultado del uso de la herramienta “Exportar Contenido” de
WebCT. Tras el proceso de exportación, se genera un fichero .zip con el contenido del
curso, siendo este fichero un paquete compatible con IMS Content Packaging
171
Una vez que se ha exportado el módulo (ver figura 9.3.1.d) del curso, el resultado es
un archivo .zip que podemos descargar desde WebCT. El contenido de este archivo
.zip, como cualquier paquete compatible con IMS CP contiene el manifiesto (ver figura
9.3.1.e), junto con el resto de recursos, es decir, las páginas html junto a sus archivos
auxiliares multimedia.
Figura 9.3.1.e. Manifiesto del paquete de contenido generado por WebCT. El
manifiesto define una única organización para el módulo del curso, definiendo un
recurso por cada archivo
172
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- WebCT XML Content generated by WebCT Content Packaging API -->
<manifest identifier="CMD_1421887_M" version="1.0"
xmlns="http://www.imsproject.org/content"
xmlns:webct="http://www.webct.com/IMS">
<metadata>
<schema>WebCT Content</schema>
<schemaversion>2.0</schemaversion>
<lom xmlns="http://www.imsproject.org/metadata">
<general><title>
<langstring xml:lang="en-US">Contenidos del curso</langstring>
</title></general>
<educational><learningresourcetype>
<source><langstring xml:lang="x-none">WebCT</langstring></source>
<value><langstring xml:lang="x-none">Content Module</langstring></value>
</learningresourcetype></educational>
</lom>
</metadata>
<organizations><organization identifier="CMD_1421888">
<webct:properties identifierref="CMD_1421889"/>
<item identifier="CMD_1421890"><title>Tutorial</title>
<item identifier="CMD_1421891" identifierref="CMD_1421892">
<title>Introducción</title>
</item>
<item identifier="CMD_1421894" identifierref="CMD_1421895">
<title>Elementos Principales</title>
</item>
<item identifier="CMD_1421897" identifierref="CMD_1421898">
<title>Resumen</title>
</item>
</item>
<item identifier="CMD_1421900"><title>Ejercicios Básicos</title>
<item identifier="CMD_1421901" identifierref="CMD_1421902">
<title>Ejercicio de autoevaluación 1</title>
</item>
<item identifier="CMD_1421904" identifierref="CMD_1421905">
<title>Ejercicio de autoevaluación 2</title>
</item>
</item>
</organization></organizations>
<resources>
<resource identifier="CMD_1421889" type="webctproperties">
<file href="CMD_1421887_M/data/properties_CMD_1421888.xml"/>
</resource>
<resource identifier="CMD_1421892" type="webcontent">
<file href="CMD_1421887_M/my_files/tutorial/intro.html"/>
<file href="CMD_1421887_M/my_files/tutorial/fig1.jpg"/>
</resource>
<resource identifier="CMD_1421895" type="webcontent">
<file href="CMD_1421887_M/my_files/tutorial/principal.html"/>
<file href="CMD_1421887_M/my_files/tutorial/fig2.jpg"/>
</resource>
<resource identifier="CMD_1421898" type="webcontent">
<file href="CMD_1421887_M/my_files/tutorial/res.html"/>
</resource>
<resource identifier="CMD_1421902" type="webcontent">
<file href="CMD_1421887_M/my_files/ebasicos/ej1.html"/>
<file href="CMD_1421887_M/my_files/ebasicos/fig1.jpg "/>
</resource>
<resource identifier="CMD_1421905" type="webcontent">
<file href="CMD_1421887_M/my_files/ebasicos/ej2.html"/>
<file href="CMD_1421887_M/my_files/ebasicos/fig2.jpg"/>
</resource>
</resources>
</manifest>
173
Llegados a este punto estamos listos para importar el paquete IMS dentro de Moodle.
Para importar el curso simplemente necesitamos editar un curso Moodle y añadir un
nuevo recurso de tipo IMS Content Packaging (ver figura 9.3.1.f)
Figura 9.3.1.f. Vista de la edición general del curso.
Necesitaremos añadir cierta información para el recurso como su título y una breve
descripción que será mostrada en la página de recursos del curso.(figuras 9.3.1.g y
9.3.1.h).
Figura 9.3.1.g. Herramienta de exportación incluida dentro del LMS WebCT.
174
Figura 9.3.1.h. Vista de los recursos que actualmente están disponibles es en el curso.
Como recurso disponible encontramos el contenido del paquete IMS importado
175
Una vez que ha finalizado la importación del paquete IMS, este es un recurso más
dentro del curso de Moodle y por tanto podemos navegar dentro del recurso para
poder visualizar su contenido.
Figura 9.3.1.i. Vista del contenido del recurso IMS Content Packaging que incluye el
contenido del módulo de “Introducción a la Geometría” importado.
176
9.3.2. IMS QT I en Moodle
Otra especificación del consorcio IMS que está (parcialmente) soportada dentro de
Moodle, es la especificación IMS Question and Test Interoperability descrita
previamente.
En el caso de la especificación QTI está soportada parte de la versión 2.0 de la misma,
permitiendo a un profesor la posibilidad de poder exportar las preguntas que ha creado
utilizando Moodle al formato IMS QTI, sin embargo en la versión actual de Moodle
(1.6) aún no es posible el poder importar preguntas utilizando directamente el formato
IMS QTI v 2.0.
Para poder exportar preguntas desde Moodle simplemente tenemos que ir a la sección
de cuestionarios y seleccionar la pregunta o examen a exportar (ver figura 9.3.2.b). Si
seleccionamos un examen se exportará cada pregunta por separado ya que la
especificación IMS QTI v 2.0 no contempla el soporte para exámenes completos.
Una vez exportado el examen, podemos descargar un archivo .zip que no es más que
un paquete IMS en el que cada uno de los recursos descritos dentro de su manifiesto
se hace referencia a otro archivo XML que contiene la pregunta exportada.
Figura 9.3.2.a. Previsualización de una pregunta de elección múltiple
177
Figura 9.3.2.b. Herramienta de exportación de preguntas de Moodle. En la herramienta
se proporcionan varios formatos posibles de exportación
178
Figura 9.3.2.c. Una vez finalizado el proceso de exportación, Moodle informa al usuario
que la exportación ha tenido éxito, incluyendo un enlace al paquete IMS que contiene
todas las preguntas exportadas
Figura 9.3.2.d. Formato XML de la pregunta de elección múltiple exportada desde
Moodle.
179
<?xml version="1.0" encoding="UTF-8"?>
<manifest
xmlns="http://www.imsglobal.org/xsd/imscp_v1p1"
xmlns:imsmd="http://www.imsglobal.org/xsd/imsmd_v1p2"
xmlns:imsqti="http://www.imsglobal.org/xsd/imsqti_item_v2p0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
identifier="question_category_3---http-__localhost_moodle"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imscp_v1p1 imscp_v1p1.xsd
http://www.imsglobal.org/xsd/imsmd_v1p2 imsmd_v1p2p2.xsd
http://www.imsglobal.org/xsd/imsqti_item_v2p0 ./imsqti_item_v2p0.xsd">
<metadata>
<schema>ADL SCORM</schema>
<schemaversion>1.2</schemaversion>
<lom xmlns="http://www.imsglobal.org/xsd/imsmd_v1p2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 msmd_v1p2p2.xsd">
<general>
<title>
<langstring xml:lang="es_es_utf8">question_category_3</langstring>
</title>
<description>
<langstring xml:lang="es_es_utf8">All questions in category
3</langstring>
</description>
<keyword><langstring xml:lang="es_es_utf8"></langstring></keyword>
</general>
</lom>
</metadata>
<organizations/>
<resources>
<resource identifier="category3-question9" type="imsqti_item_xmlv2p0"
href="./category3-question9.xml">
<metadata>
<schema>IMS QTI Item</schema>
<schemaversion>2.0</schemaversion>
<imsmd:lom>
<imsmd:general>
<imsmd:identifier>category3-question9</imsmd:identifier>
<imsmd:title>
<imsmd:langstring xml:lang="es_es_utf8">Moodle y los
Estándares</imsmd:langstring>
</imsmd:title>
<imsmd:description>
<imsmd:langstring xml:lang="en">Question 9 from category
3</imsmd:langstring>
</imsmd:description>
</imsmd:general>
<imsmd:lifecycle>
<imsmd:version>
<imsmd:langstring xml:lang="en">1.0</imsmd:langstring>
</imsmd:version>
<imsmd:status>
<imsmd:source>
<imsmd:langstring xml:lang="en">LOMv1.0</imsmd:langstring>
</imsmd:source>
<imsmd:value>
<imsmd:langstring xml:lang="en">Draft</imsmd:langstring>
</imsmd:value>
</imsmd:status>
</imsmd:lifecycle>
</imsmd:lom>
<imsqti:qtiMetadata>
<imsqti:timeDependent>false</imsqti:timeDependent>
<imsqti:interactionType>choiceInteraction</imsqti:interactionType>
<imsqti:canComputerScore>true</imsqti:canComputerScore>
<imsqti:feedbackType>nonadaptive</imsqti:feedbackType>
<imsqti:solutionAvailable>true</imsqti:solutionAvailable>
</imsqti:qtiMetadata>
</metadata>
</resource>
</resources>
</manifest>
180
9.3.3. Actividades SCORM
Dentro de un curso Moodle tenemos disponible dentro de las posibles actividades del
curso la opción de añadir una actividad de tipo SCORM/AICC, esta actividad nos
permite importar un paquete SCORM que haya sido generado utilizando, por ejemplo,
la herramienta Reload.
Para poder crear una actividad de tipo SCORM simplemente tenemos que añadir la
nueva actividad, proporcionar un título, una breve descripción y proporcional el zip que
contiene el paquete SCORM (ver figura 9.3.3.a).
Figura 9.3.3.a. Editor de la actividad SCORM. El editor permite proporcionar un título,
una descripción y partir de que archivo .zip se importará la actividad SCORM
Al importar el paquete se nos muestra un informe de la estructura del paquete SCORM
(ver figura 9.3.3.b), donde se nos muestran con distintos iconos el tipo de contenido
Por ejemplo los recursos de tipo Assest están identificados con un icono con una A en
azul y los SCO dependiendo de su estado, es decir, de si se han visitado o no se
muestran con un icono u otro, por ejemplo, en el caso de SCO que no hayan sido
intentados se muestra un cuadro en blanco y en el caso de SCO visitados se muestra
un aspa verde en el cuadro (
).
Como ejemplo, se ha utilizado en las pruebas un paquete SCORM proporcionado por
la iniciativa ADL para ejemplificar las distintas posibilidades de uso de SCORM. Este
paquete contiene información básica acerca de la herramienta Adobe Photoshop.
181
Figura 9.3.3.b. Vista de la actividad SCORM que se acaba de importar.
Una vez importado la actividad SCORM podemos navegar a través de los assets que
están incluidos dentro del módulo (ver figura 9.3.3.c). Asimismo, también podemos
interactuar con los SCO, en este caso el SCO es una pregunta (ver figura 9.3.3.d).
182
Figura 9.3.3.c. Vista de uno de las lecciones de la actividad SCORM que acaba de ser
importada.
Figura 9.3.3.d. Vista de una de las autoevaluaciones que contiene la actividad
SCORM. Esta autoevaluación está codificada dentro del SCO y no utiliza la
especificación IMS QTI
183
184
10. BIBLIOGRAFÍA
Esta bibliografía es parte de la que se ha utilizado en la redacción del presente informe
pero dista mucho de ser completa. Debido a la propia naturaleza del campo del elearning que es relativamente joven a la vez que muy activo, y por tanto en continuo
cambio, hace que muchas de las referencias puedan quedar obsoletas muy
rápidamente. Por tanto, algunas de estas referencias son realmente meta-referencias
ya que son menciones a sitios web que contienen la información actualizada.
Por otro lado, a lo largo del trabajo se han proporcionado muchas referencias a
información disponible directamente en Internet, por ejemplo, sobre herramientas o
sistemas concretos. Aunque en muchos casos no se podrían considerar referencias
propiamente dichas son parte muy importante de la información disponible.
§
§
§
§
§
§
§
§
§
§
§
§
ADL (2002). Advanced Distributed Learning. http://www.adlnet.org (último
acceso, 16 Octubre 2006).
ADL SCORM (2002) Sharable Course Object Reference Model v1.2. Disponible
on-line:
http://adlnet.org/ADLDOCS/Other/SCORM_1.2_PDF.zip
(último
acceso, 16 Octubre 2006).
ADL SCORM (2006) Sharable Course Object Reference Model 2004 3rd
Edition
Documentation
Suite
Public
Draft
Disponible
on-line:
http://adlnet.org/ADLDOCS/Other/SCORM_1.2_PDF.zip (último acceso, 16
Octubre 2006).
Anido, L. E., Fernández, M. J., Caeiro, M., Santos, J. M., Rodríguez, J. S., and
Llamas, M. (2002). Educational metadata and brokerage for learning resources.
Comput.
Educ.
38,
4
(May.
2002),
351-374.
DOI=
http://dx.doi.org/10.1016/S0360-1315(02)00018-0
ARIADNE, Association of Remote Instructional Authoring and Distribution
Networks for Europe, http://www.ariadne-eu.org/ (último acceso, 16 Octubre
2006).
Bohl, O., Schellhase, J., Sengler, R., and Winand, U. (2002). The Sharable
Content Object Reference Model (SCORM) – A Critical Review. En Actas de
International Conference on Computers in Education (ICCE02), Auckland, New
Zealand, 950 – 951.
CanCore (2004). CanCore. http://www.cancore.ca/. (Ultimo acceso, 16 Octubre
2006).
CEN/ISSS,
European
Committee
for
Standardization,
http://www.cenorm.be/isss/ (último acceso, 16 Octubre 2006).
CEN/ISSS/LT, Learning Technologies Workshop, Observatory Contents,
European Committee for Standardization, http://www.cen-ltso.net/ (último
acceso, 16 Octubre 2006).
Cordova, D. I. and M. R. Lepper (1996). "Intrinsic Motivation and the Process of
Learning: Beneficial Effects of Contextualization, Personalization, and Choice."
Journal of Educational Psychology 88(4): 715-730.
Dublin Core (2004). Dublin Core. http://dublincore.org/. (Ultimo acceso, 16
Octubre 2006).
IEEE LOM 2002 Learning Object Metadata. Learning Technology Standards
Committee.
Borrador
final
del
estándar.
Disponible
en
http://ltsc.ieee.org/wg12/files/LOM_1484_12_1_v1_Final_Draft.pdf
(último
acceso, 16 Octubre 2006).
185
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
IEEE LTSC. Learning Technology Standards Committee. Accesible en
http://ieeeltsc.org/ (último acceso, 16 Octubre 2006).
IEEE LOM (2002). IEEE Standard for Learning Object Metadata. IEEE
Standard 1484.12.1-2002. 2002
IMS
CP
(2001-2004).
IMS
Content
Packaging.
http://www.imsglobal.org/content/packaging (último acceso, 16 Octubre 2006).
IMS CP USE (2001). Using IMS Content Packaging to Package Instances of
LIP and Other IMS Specifications Version 1.0 Implementation Handbook.
http://www.imsglobal.org/implementationhandbook/imspack_handv1p0.html.
(Ultimo acceso, 16 Octubre 2006).
IMS LD (2003). IMS Learning Design. http://www.imsglobal.org/learningdesign/
(último acceso, 16 Octubre 2006).
IMS
META
(2001).
IMS
Meta-Data
Versión
1.2.2.
http://www.imsglobal.org/metadata/#version1.2.2 (último acceso, 16 Octubre
2006).
IMS
META
(2006).
IMS
Meta-Data
Version
1.3.
http://www.imsglobal.org/metadata/#version1.3. (último acceso, 16 Octubre
2006).
ISO, International Standards Organisation http://www.iso.ch/ (último acceso, 16
Octubre 2006).
Koper, Rob & Manderveld, Jocelyn (2004) Educational modelling language:
modelling reusable, interoperable, rich and personalised units of learning.
British Journal of Educational Technology 35 (5), 537-551
Macromedia (2005) Getting Started with eLearning Standards. Disponible en
http://download.macromedia.com/pub/solutions/downloads/elearning/standards.
pdf (último acceso, 16 Octubre 2006).
Masie (2003). Making Sense of Learning Specifications and Standards: A
Decision Maker’s Guide to their Adoption, 2nd ed. e-Learning Consortium
Industry
Report,
The
Masie
Center.
Disponible
en:
http://www.masie.com/standards/s3_2nd_edition.pdf
(último
acceso,
16
Octubre 2006).
MIME (1996). Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types. http://www.isi.edu/in-notes/rfc2046.txt (último acceso, 16 Octubre 2006).
(LOM-ES 2006). Perfil de Aplicación LOM-ES V 1.0. GT9 / SC 36 AENOR
Polsani, P. R. (2003). Use and abuse of reusable learning objects. Journal of
Digital Information, 3(4).
RDF (2004). Resource Description Framework. http://www.w3.org/RDF/ (último
acceso, 16 Octubre 2006).Sun Microsystems (2002), e-learning Interoperability
Standards.
White
paper.
January
2002.
Disponible
en:
http://www.sun.com/products -nsolutions/edu/whitepapers/pdf/eLearning_Interoperability_Standards_wp.pdf
(último acceso, 16 Octubre 2006).
Using IMS Content Packaging to Package Instances of LIP and Other IMS
Specifications
Version
1.0
Implementation
Handbook.
http://www.imsglobal.org/implementationhandbook/imspack_handv1p0.html.
(último acceso, 16 Octubre 2006).
VCARD (1996). VCard The Electronic Bussiness Card Version 2.1.
http://www.imc.org/pdi/vcard-21.txt. (Ultimo acceso, 16 Octubre 2006).
XML
Base
(2001).
W3C
Recommedation.
XML
Base.
http://www.w3.org/TR/xmlbase/ (último acceso, 16 Octubre 2006).
XML Names (2006). W3C Recommendation. Namespaces in XML 1.1.
http://www.w3.org/TR/xml-names11/ (último acceso, 16 Octubre 2006).
186
§
§
§
XML Schema (2004). W3C Recommendation. XML Schema. Documentos
disponibles en http://www.w3.org/TR. (Ultimo acceso, 16 Octubre 2006).
Wenger, E. (1998). Communities of Practice: Learning, Meaning, and Identity.
New York, Cambridge University Press.
Wiley D. (ed.) (2000). The Instructional Use of Learning Objects. Bloomington,
AECT. Disponible en: http://reusability.org/read/ (último acceso, 16 Octubre
2006).
187