ESTANDARIZACIÓN Y DISEÑO EDUCATIVO

ESTANDARIZACIÓN Y DISEÑO EDUCATIVO
DIRECCIÓN DE LA SERIE
Instituto de Tecnologías Educativas (ITE)
Dirección: Antonio Pérez Sanz y Alfonso Berlanga
Coordinación: María Luisa Gutiérrez de la Concepción, Nieves
Gutiérrez de la Concepción y Antonio Galisteo del Valle
Corrección y revisión: Antonio Galisteo del Valle, Pamela
Fernández Sánchez y Antonio Estévez Funes
AUTORES
Dirección del Informe: Baltasar Fernández Manjón, José Luis
Sierra Rodríguez, Iván Martínez Ortiz y Pablo Moreno Ger
PUBLICACIÓN
Dirección: Antonio Pérez Sanz
Producción ejecutiva: Antonio Galisteo del Valle, Mª Luisa
Gutiérrez de la Concepción y Nieves Gutiérrez de la Concepción
Diseño gráfico: Aurelio Lorenzo Pérez y Mercedes Moral Maroto
Edición web: Antonio Estévez Funes y Pamela Fernández
Sánchez
2
Resumen Ejecutivo
Este informe aborda los aspectos de especificación, sistematización y estandarización
de los modelos educativos utilizados en la enseñanza que emplea como ayuda y
soporte las Tecnologías de la Información y la Comunicación (TIC). Todo este conjunto
de diseños o estrategias instruccionales, basados a su vez en diversos modelos
pedagógicos, es lo que se engloba bajo el término de “diseño educativo” (en inglés
Learning Design). La idea subyacente es que las primeras iniciativas de
estandarización (e.g. IMS Content Packaging, IEEE LOM) se han basado
principalmente en la organización y descripción de los contenidos (para una
descripción mas completa se puede consultar el informe 16 de esta misma colección
Uso de estándares aplicados a TIC en Educación que aunque resuelven el problema
de la interoperabilidad y portabilidad, no son suficientes para abordar y describir
completamente procesos educativos complejos como los que se utilizan de forma
habitual en las clases para lograr un aprendizaje efectivo. Por tanto se ha
evolucionado tratando de proporcionar formas de descripción de los procesos
educativos que vayan más allá de los contenidos y contemplen también los aspectos
dinámicos (e.g. actividades, secuenciación, interacciones) que son una parte
fundamental de los procesos de aprendizaje y que hacen posible la creación de
aplicaciones mas avanzadas como, por ejemplo, las basadas en competencias o las
colaborativas. La formalización de estas descripciones de modo que sean
automatizables y reproducibles por una computadora es lo que se ha denominado
Lenguajes de Modelado Educativo (en inglés, Educational Modelling Languages).
Es necesario destacar que este modelado educativo y en general la utilización de las
TIC para la educación y aprendizaje que englobamos bajo el término e-learning no
implica necesariamente una modalidad de formación a distancia ya que su uso es más
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). De hecho, por ejemplo, en las actividades modeladas pueden implicar
algún tipo de interacción entre los usuarios que, a su vez, puede ser realizado con
apoyo de las TIC o de forma presencial.
Este documento se basa, además de en la revisión bibliográfica y 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 (<e-UCM>, http://www.e-ucm.es) de la Facultad de Informática de la
Universidad Complutense de Madrid.
El propósito principal de este estudio es presentar una visión general sobre las
iniciativas y estándares de facto para modelado educativo que han surgido en el
mundo del e-learning y que son aplicables a distintos enfoques y contextos educativos.
No obstante hay que destacar que es una visión desde el punto de vista más técnico y
de aplicación, no siendo objetivo del trabajo un análisis en profundidad de las teorías
educativas subyacentes. Se presentan sus fundamentos y sus aplicaciones de la
forma 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, de modo que se ha tenido que limitar su
3
contenido para que únicamente considere aquellas iniciativas que son más utilizadas
actualmente o que consideramos que son más prometedoras.
Después de realizar una revisión general del modelado educativo, así como de las
iniciativas y herramientas más representativas, se realiza una revisión en profundidad
del estándar de facto que actualmente es más completo y versátil para el modelado
educativo: IMS Learning Design. Mediante un ejemplo sencillo pero a la vez
suficientemente significativo se introducen los distintos elementos necesarios para
entender un estándar tan expresivo (y por tanto, en algunos casos, complejo de
entender).
También se presentan otros estándares relacionados con la información sobre los
usuarios como es IMS Learner Information Profile (IMS LIP). IMS-LIP es una
especificación para expresar la información personal de los alumnos, su historial
dentro del sistema (incluyendo su porfolio de trabajos realizados) y las preferencias
que tengan estos usuarios. 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 –aunque este tema no se aborda en este
estudio- ) a culturales o de madurez de la propia especificación. A pesar del avance
que supone disponer de IMS-LIP, éste es un tema complejo en el que sigue habiendo
competencia comercial y falta de suficiente consenso.
No obstante, se están realizando avances en temas relacionados pues ya se ha
llegado al suficiente acuerdo para estandarizar una forma básica de definición de
competencias y capacidades de los estudiantes. Este aspecto se trata en la
especificación IMS RDCEO (y en su estándar oficial IEEE RCD asociado).
En este informe también se analizan las especificaciones que tratan de lograr que el elearning sea accesible a personas con diversidad funcional. AccessForAll es la
denominación genérica empleada por el consorcio IMS para designar sus iniciativas y
esfuerzos relacionados con potenciar la accesibilidad de los contenidos educativos a
personas con necesidades especiales derivadas de su entorno, circunstancias o
discapacidades.
En el capítulo final se ponen ejemplos de uso práctico de herramientas de edición de
diseños educativos con IMS-LD por ser el estándar y con LAMS por ser actualmente el
modelado, que aunque no sigue el estándar parece contar con mayor aceptación.
La organización de este trabajo está pensada para diferentes públicos. Si el lector está
interesado en tener solamente una visión general del modelado educativo en elearning podrá adquirirla mediante la lectura de los dos primeros capítulos. Un lector
que ya tenga un cierto conocimiento de este modelado educativo en e-learning y de
cómo se ve afectado por la estandarización, pero que quiera profundizar en aspectos
más técnicos de IMS-LD o de alguno de los estándares abordados (IMS LIP, IMS
RDCEO, IMS A4A) 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 comprensibles y de poner ejemplos simplificados siempre
tratando de no perder el rigor técnico.
Este campo tiene además la particularidad de su juventud y cambio continuo. Como
incesantemente surgen o bien nuevas especificaciones o bien correcciones o
añadiduras a las existentes, la bibliografía existente queda rápidamente superada por
4
la realidad. Esto hace que gran parte de las referencias que aparecen en este trabajo
lo sean a páginas web de las instituciones implicadas en la estandarización,
publicaciones electrónicas o documentos que están disponibles en Internet.
5
Mensaje de comunicación corporativa
Este informe ha sido encargado por el Instituto de Tecnologías Educativas del
Ministerio de Educación a los profesores Baltasar Fernández Manjón, José Luis Sierra
Rodríguez, Ivan Martinez Ortiz y Pablo Moreno Ger del grupo de Investigación de
Ingeniería del Software aplicado al e-learning (<e-UCM>, www.e-ucm.es)
perteneciente al Departamento de Ingeniería del Software e Inteligencia Artificial de la
Universidad Complutense de Madrid. El encargo se realizó en el año 2008, a raíz de
sus investigaciones relacionadas con el modelado educativo y en cómo estos aspectos
estaban viéndose reflejados en los estándares emergentes en e-learning y en los
sistemas e-learning. El tema central del informe es la situación actual del modelado
educativo y cómo dicho modelado puede utilizarse en la mejora de los procesos
educativos. El objetivo es descubrir a los lectores de este informe las principales
características, incluyendo cualidades y limitaciones, del modelado educativo y cómo
se refleja dicho modelado en los sistemas actuales de e-learning. Por completitud se
presentan también especificaciones relacionadas con el modelado educativo (e.g.
cómo se representa al estudiante o cómo se tienen en cuenta sus características
especiales o sus competencias) y cómo este modelado educativo se refleja en
sistemas concretos de e-learning que consideramos especialmente prometedores
como, por ejemplo, LAMS.
Baltasar Fernández Manjón es Doctor en Ciencias Físicas por la Universidad
Complutense de Madrid donde actualmente es profesor en la Facultad de Informática.
Es el codirector del grupo de Investigación de Ingeniería del Software aplicado al elearning (<e-UCM>, www.e-ucm.es). Ha dirigido distintos proyectos de investigación
relacionados con los usos educativos de las nuevas tecnologías y es miembro del
Working Group 3.3 "Research on the Educational uses of Communication and
Information Tecnlogies" de la International Federation for Information Processing
(IFIP), del Subcomité 36 de Tecnologías de la Información y la Comunicación para el
aprendizaje (SC36), de la Asociación Española de Normalización y Certificación
(AENOR CTN71/SC36) y del Capítulo Español para la Sociedad de la Educación de
IEEE (Red CESEI). Ha publicado más de 90 artículos de investigación en revistas y
congresos y ha participado en la organización de diversas conferencias del área (e.g.
SCORM, ICALT, SIIE). Sus áreas principales de investigación son las tecnologías y los
estándares de e-learning, las aplicaciones educativas de la web, la aplicación de los
videojuegos a la educación y los sistemas adaptativos (incluyendo modelado de
usuario y aspectos de accesibilidad).
José-Luis Sierra-Rodríguez es Doctor en Informática por la Universidad Complutense
de Madrid, donde actualmente ocupa una plaza de Profesor Titular de Universidad. El
Dr. Sierra es coautor de más de 70 artículos de investigación publicados en revistas y
actas de conferencias internacionales. Sus intereses investigadores incluyen la
Ingeniería del Software orientada a lenguajes, los lenguajes de marcado y el desarrollo
dirigido por lenguajes de Sistemas e-learning.
Ivan Martínez es licenciado en Informática por la Universidad Complutense de Madrid.
Desde 2007 trabaja como profesor Colaborador en la Facultad de Informática de la
dicha universidad donde está completando su doctorado en modelado educativo y
estándares de e-learning. Ha participado en diversos proyectos relacionados en el
área de la educación asistida por computador tanto en el ámbito nacional como
6
internacional. Además ha publicado más de 25 artículos en conferencias y revistas
internacionales. Sus áreas principales de investigación son el modelado educativo, los
estándares de e-learning, las aplicaciones educativas de la web y la aplicación de los
videojuegos a la educación.
Pablo Moreno Ger es Doctor en Informática por la Universidad Complutense de Madrid
y en la actualidad trabaja como Profesor Ayudante Doctor en el Departamento de
Ingeniería del Software e Inteligencia Artificial de la UCM. Ha participado en diversos
proyectos relacionados con el área de la educación asistida por computador tanto en
el ámbito nacional como internacional. Además ha publicado más de 30 artículos en
conferencias y revistas internacionales. Sus intereses de investigación abarcan todo
tipo de tecnologías educativas, centrándose en el desarrollo e integración de
contenidos altamente interactivos en los entornos de aprendizaje y sistemas elearning, especialmente en juegos educativos, así como la adaptación y la evaluación
de los procesos de aprendizaje.
7
Deseamos mostrar nuestro agradecimiento al resto de miembros del Grupo de elearning de la Facultad de Informática de la Universidad Complutense de Madrid así
como a los responsables del Campus Virtual de nuestra Universidad coordinados por
el profesor Alfredo Fernández-Valmayor. Algunas de las pruebas se han realizado en
dicho Campus Virtual.
Parte de los resultados reflejados en este trabajo se han obtenido en la investigación
realizada en los proyectos AdaptaLearn y OdA Virtual que han sido parcialmente
financiados por la Comisión Ministerial de Ciencia y Tecnología (TIN2007-68125-C0201, TIN2005 08788 C04-01) y con ayudas de la Comunidad de Madrid y de la
Universidad Complutense de Madrid para el grupo de Investigación Ingeniería del
Software y e-learning (<e-UCM>, 921340 UCM-CAM). También se han reutilizado
algunos de los resultados logrados en el proyecto Avanza Flexo (TSI-020301-2008-19)
realizado en colaboración con otras universidades y fundaciones (U. Carlos III, U. de
Cádiz, U de Santiago de Compostela, U de Harvard, LAMS-Australia y Sidar) y
empresas (Atos Origin, Indra, CEPAL) y en el proyecto Cenit INREDIS liderado por
Technosite y en el que participan mas de 25 univesidades y empresas españolas.
Finalmente este trabajo se ha beneficiado del contraste internacional proporcionado
por la participación del grupo <e-UCM> en el proyecto CID – Comunidad Intercultural
para el Desarrollo y Uso de Objetos de Aprendizaje (liderado por la U. de Chile y en el
que participan 8 universidades europeas e iberoamericanas). El proyecto CID
pertenece al programa europeo Alfa (II-0511-A).
8
1. LENGUAJES DE MODELADO EDUCATIVO........................... 13
1.1. INTRODUCCIÓN................................................................. 13
1.2. EL CONCEPTO DE MODELADO EDUCATIVO................ 13
1.3. LENGUAJES DE MODELADO EDUCATIVO.................... 15
1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS ............. 17
1.4.1. Lenguajes Especí?cos .................................................. 18
1.4.2. Lenguajes de Estructuración de Contenidos ................ 19
1.4.3. Lenguajes de Actividades ............................................. 22
1.5. IMS LEARNING DESIGN ................................................... 24
1.6. HERRAMIENTAS DE SOPORTE A IMS-LD ..................... 27
1.6.1. Herramientas de Autoría de IMS-LD............................. 28
1.6.2. Motores de ejecución compatibles con IMS-LD ........... 33
1.6.3. Reproductores de IMS-LD ............................................ 34
1.6.4. Otras iniciativas y proyectos de investigación
relacionados con IMS-LD........................................................... 36
1.7. A MODO DE CONCLUSIÓN .............................................. 38
2. LA ESPECIFICACIÓN IMS LEARNING DESIGN .................... 39
2.1. INTRODUCCIÓN................................................................. 39
2.2. UN CASO DE ESTUDIO..................................................... 39
2.3. VISIÓN CONCEPTUAL DE IMS LD ................................... 41
2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES ........ 46
2.4.1. IMS Content Packaging e IMS LD ................................ 46
2.4.2. Niveles en la Especificación ......................................... 49
2.5. EL NIVEL A......................................................................... 50
2.5.1. Estructura de alto nivel de un Diseño Educativo .......... 50
2.5.2. Descripción de los Componentes: Roles, Actividades y
Entornos ..................................................................................... 52
2.5.3. Descripción del método educativo ................................ 60
2.5.4. Modelo de Ejecución ..................................................... 62
2.5.5. Ejemplo de Diseño de Nivel A ...................................... 63
2.6. EL NIVEL B ......................................................................... 68
2.6.1. Propiedades .................................................................. 69
2.6.2. Expresiones................................................................... 71
2.6.3. Acciones........................................................................ 73
2.6.4. Condiciones................................................................... 74
2.6.5. Extensión de las condiciones de finalización de
actividades, actos, guiones y métodos ...................................... 76
9
2.6.6. Extensión de las acciones tras la finalización para
actividades, actos, guiones y métodos ...................................... 76
2.6.7. Elementos globales y monitores ................................... 76
2.6.8. Modelo de Ejecución ..................................................... 77
2.6.9. Ejemplo de diseño de nivel B........................................ 77
2.7. EL NIVEL C ......................................................................... 84
2.7.1. Notificaciones ................................................................ 84
2.7.2. Extensiones en IMS LD nivel C .................................... 85
2.7.3. Ejemplo de diseño de nivel C ....................................... 85
2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS ... 87
2.8.1. Codificación de la Estructura de Alto nivel del Diseño . 87
2.8.2. Codificación de los roles ............................................... 89
2.8.3. Codificación de las actividades..................................... 91
2.8.4. Codificación de los entornos ......................................... 94
2.8.5. Codificación de los métodos ......................................... 95
2.8.6. Codificación de las propiedades ................................... 99
2.8.7. Codificación de las expresiones, acciones y condiciones
101
2.8.8. Codificación de elementos globales y servicio de
monitorización .......................................................................... 103
2.8.9. Codificación de notificaciones..................................... 103
3. IMS LEARNER INFORMATION PACKAGE........................... 104
3.1. INTRODUCCIÓN............................................................... 104
3.2. VISIÓN CONCEPTUAL .................................................... 104
3.2.1. Categorías de datos .................................................... 105
3.2.2. Metadatos.................................................................... 107
3.3. UN CASO DE ESTUDIO................................................... 108
3.4. ESTRUCTURA XML ......................................................... 109
3.4.1. Metadatos y otros elementos comunes ...................... 109
3.4.2. El elemento learnerInformation................................... 113
3.4.3. El elemento identification ............................................ 115
3.4.4. El elemento qcl............................................................ 117
3.4.5. El elemento activity ..................................................... 120
3.4.5.1. Descripción de Actividades: definition............... 123
3.4.5.2. Productos Generados en Actividades: product. 125
3.4.5.3. Informes sobre Actividades: testimonial............ 127
3.4.5.4. Evaluación de Actividades: evaluation .............. 128
3.4.6. El elemento affiliation .................................................. 131
3.4.7. El elemento transcript ................................................. 133
10
3.4.8. El elemento accessibility ............................................. 134
3.4.8.1. Accesibilidad idiomática: language ................... 136
3.4.8.2. Preferencias de acceso: preference ................. 138
3.4.9. El elemento goal.......................................................... 139
3.4.10. El elemento competency............................................. 141
3.4.11. El elemento interest .................................................... 143
3.4.12. El elemento securitykey .............................................. 145
3.4.13. El elemento relationship.............................................. 146
4. IMS REUSABLE DEFINITION OF COMPETENCY OR
EDUCATIONAL OBJECTIVE ....................................................... 148
4.1. INTRODUCCIÓN............................................................... 148
4.2. VISIÓN CONCEPTUAL DE LA DEFINICIÓN DE
COMPETENCIAS ....................................................................... 151
4.3. EJEMPLOS DE POSIBLES APLICACIONES ................. 152
4.3.1. Casos de uso .............................................................. 152
4.3.2. Ejemplo de uso............................................................ 153
4.4. ESTRUCTURA XML ......................................................... 154
4.4.1. El elemento rdceo ....................................................... 154
4.4.2. El elemento identifier................................................... 157
4.4.3. El elemento title........................................................... 157
4.4.4. El elemento description............................................... 157
4.4.5. El elemento definition.................................................. 157
4.4.6. El elemento metadata ................................................. 159
4.5. EXTENSIBILIDAD............................................................. 159
5. IMS ACCESS FOR ALL .......................................................... 160
5.1. INTRODUCCIÓN............................................................... 160
5.1.1. Una problemática compleja ........................................ 161
5.1.2. Tres aspectos de un mismo problema........................ 162
5.2. IMS ACCESSIBILITY FOR LIP ........................................ 163
5.2.1. Definición de Preferencias .......................................... 164
5.2.2. Solicitud de servicios adicionales ............................... 166
5.3. IMS ACCESSFORALL METADATA ................................ 168
5.3.1. Descripción general .................................................... 169
5.3.2. Metadatos para recursos primarios ............................ 171
5.3.3. Metadatos para recursos equivalentes ....................... 173
6. HERRAMIENTAS DE SOPORTE PARA LOS DISEÑOS
EDUCATIVOS................................................................................ 175
11
6.1. WEBQUEST...................................................................... 176
6.2. JCLIC ................................................................................ 178
6.3. LAMS................................................................................. 183
6.3.1. Introducción................................................................. 183
6.3.2. La herramienta LAMS ................................................. 185
6.3.3. Actividades, secuencias de actividades y mecanismos
de adaptación........................................................................... 187
6.3.4. Configuración y uso básico de LAMS ......................... 193
6.3.4.1. Administración básica de LAMS........................ 195
6.3.4.2. Autoría y publicación de secuencias LAMS ...... 202
6.3.4.3. Monitorización y Seguimiento. .......................... 213
6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON
LAMS .......................................................................................... 219
6.4.1. Diseño de las unidades de aprendizaje / secuencias de
actividades LAMS para el caso de estudio.............................. 219
6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON
IMS LD ........................................................................................ 232
7. BIBLIOGRAFÍA ....................................................................... 249
12
1. LENGUAJES DE MODELADO EDUCATIVO
1.1. INTRODUCCIÓN
En la enseñanza apoyada por la tecnología, y que globalmente se denomina por el
término en inglés e-learning, se ha producido una gran revolución con la nueva forma
de crear contenidos que suponen los objetos de aprendizaje (OA, en inglés learning
objects). Aunque los objetos de aprendizaje tienen múltiples definiciones una de las
más aceptadas es la utilizada en el estándar LOM donde se definen como “cualquier
entidad que puede ser usada, reutilizada o referenciada durante un proceso de
aprendizaje apoyado por la tecnología”. La principal ventaja es que permite crear
cursos mediante combinación de contenidos previamente existentes es decir potencia
la reusabilidad y la interoperabilidad (para una descripción más completa se puede
consultar el informe 16 de esta misma colección Uso de estándares aplicados a TIC en
Educación). No obstante, y a pesar de las ventajas que aportan los OA en e-learning,
existe también un amplio consenso entre los educadores de que la creación y
presentación de materiales educativos de gran calidad no es su?ciente para obtener
una experiencia educativa plena y satisfactoria. Es igualmente importante la
plani?cación de las otras actividades (tutorías, exámenes, lectura de libros, etc.) que el
estudiante debe llevar a cabo para conseguir los objetivos educativos propuestos por
el profesor.
De este análisis surge el concepto de Lenguaje de Modelado Educativo (EML) (del
inglés Educational Modeling Language) como nueva piedra angular del e-learning, ya
que con este tipo de lenguajes se pretende que puedan ser utilizados por los
profesores para formalizar los procesos de enseñanza, de manera que las
descripciones resultantes puedan ser interpretadas por las computadoras.
No obstante, antes de seguir adelante es necesario destacar que estos lenguajes de
modelado educativo a pesar de su potencial se encuentran todavía más en los
aspectos de investigación y prueba académica que en los aspectos de aplicación
directa e inmediata a gran escala. Hay varias razones de diversa índole que justifican
esta situación, desde educadores que siguen teniendo dudas sobre su aplicabilidad
práctica hasta la falta de herramientas suficientemente maduras y sencillas de usar por
profesores que no tengan un previo conocimiento técnico. No obstante, parece
ampliamente aceptado que cualquier avance que se produzca en este campo sería
muy relevante y que, por tanto, a pesar de sus limitaciones actuales es necesario
continuar en esta línea. Aún así, como ya se ha mencionado en la introducción, hay
que destacar que este informe pretende dar una visión desde el punto de vista más
técnico y de aplicación, no siendo su objetivo un análisis en profundidad de las teorías
educativas subyacentes (un estudio más en esta línea es el de Mayes y de Freitas,
2004).
1.2. EL CONCEPTO DE MODELADO EDUCATIVO
El concepto de modelado educativo es muy amplio y es previo a su uso en el campo
del e-learning. Ya sea en enseñanza presencial como en enseñanza a distancia ha
13
habido muchos esfuerzos para planificar y documentar el proceso utilizado para
enseñar a los alumnos. No obstante, en la mayoría de los casos, se han realizado
descripciones informales (a veces descritas como “recetas”) o mediante fichas
(patrones o plantillas) pero no ha habido iniciativas exitosas ampliamente aceptadas
de formalización y documentación rigurosa y estándar del proceso educativo. En ese
sentido se pueden distinguir, por lo menos, tres categorías de diseños:
§
Los diseños informales donde sólo se proporcionan unas indicaciones sobre el
proceso educativo y que normalmente contemplan los contenidos, el contexto y
las estrategias a utilizar, pero en esas descripciones no siguen un patrón
común ni tienen por qué abordar todas los mismos aspectos.
§
Los diseños estructurados en base a plantillas que tienen un conjunto fijo de
aspectos a describir y que se cumplimentan en todos los casos. De esta forma
se tienen descripciones más regulares pero donde normalmente no se ponen
limitaciones o normas muy estrictas sobre cómo rellenar dichos apartados. En
el mejor de los casos se acompañan de una guía metodológica sobre cómo
rellenarlos que incluso en algunos campos proporciona un conjunto de valores
fijos entre los que seleccionar.
§
Los diseños formales en los que, normalmente mediante un lenguaje
específico, se proporciona una sintaxis que clarifica qué se puede describir y
una gramática que determina el significado de dichas descripciones. Estas
descripciones formales, aunque mucho más trabajosas de crear, son
susceptibles de automatización. Esto significa, por ejemplo, que se puede
comprobar que las descripciones son correctas y que es factible crear un
sistema informático que las ejecute automáticamente.
Desde el punto de vista del alcance del modelado se pueden distinguir los modelados
especializados, que pretenden cubrir sólo un ámbito o tipo determinado de actividades
educativas (e.g. WebQuest) y los modelados genéricos que pretenden cubrir cualquier
tipo de situación educativa tanto por el dominio como por el tipo de actividades o
medios utilizados.
En e-learning se comienza a hablar de modelado educativo cuando se deja de
considerar que los contenidos (y por tanto los objetos de aprendizaje) son el centro y
elemento principal del aprendizaje en el que sólo se tiene en cuenta el escenario de un
alumno individual accediendo al contenido. De ahí se ha pasado a una visión más
global en la que se tratan de especificar los procesos educativos de una forma más
completa en base a las condiciones en las que se realiza y a las actividades que
tienen que llevar a cabo, tanto los alumnos como los profesores, para lograr unos
determinados objetivos de aprendizaje. La idea es pasar de sistemas basados o
centrados en contenidos a sistemas orientados a actividades y aprendizajes activos
(aunque la calidad de los contenidos sigue siendo imprescindible) que permitan
incrementar las posibilidades que ofrecen los entornos de gestión de e-learning. Las
ideas subyacentes a este enfoque son (Britain, 2004):
§
Las personas aprenden mejor cuando están implicadas activamente en la
realización de una actividad (actividad de aprendizaje). El aprendizaje es un
proceso activo, que requiere esfuerzo, y en el cual no todos los alumnos tienen
la misma capacidad de aprender por sí mismos. Este aprendizaje puede verse
facilitado si se proporciona algún tipo de guiado o soporte (estrategia didáctica
14
o método de aprendizaje) que implique o motive a los alumnos (trabajo
colaborativo, aprendizaje basado en problemas, etc).
§
Las actividades de aprendizaje se pueden secuenciar y organizar para lograr
un aprendizaje más efectivo. Este secuenciamento es lo que se ha
denominado flujo de aprendizaje. El aprendizaje se mejora no sólo si se tienen
actividades que impliquen a los estudiantes si no también si se diseña de forma
cuidadosa su secuenciación en el tiempo o el tiempo que tienen asignado. De
esta forma se pueden considerar, por ejemplo, distintas “rutas” de aprendizaje,
tareas que puedan ser realizadas en paralelo o trabajos que deben
completarse en subgrupos antes de continuar con el desarrollo del curso.
§
Los diseños educativos se pueden describir de una forma consistente (formal)
y transferible para facilitar que se puedan compartir y reutilizar. Aquí surge el
problema de cómo describir una estrategia de enseñanza de modo lo
suficientemente abstracto como para que sea útil en un contexto que no sea
igual que en el que se ha creado, pero que a la vez sea suficientemente
detallada como para que se pueda reproducir sin perder su valor pedagógico.
Además, dicha descripción debe ser procesable automáticamente por una
computadora.
Parece ampliamente aceptado que el modelado educativo, a pesar de sus dificultades,
tiene una serie de ventajas. Por un lado permite que los profesores formalicen sus
diseños educativos de modo que quede reflejado qué actividades se realizan y cómo
se organizan dichas actividades. La otra ventaja es que cuando un diseño ha probado
su eficacia puede ser compartido con otros docentes o archivado para un uso o
consulta posterior.
1.3. LENGUAJES DE MODELADO EDUCATIVO
La generalización del término EML en e-learning proviene del trabajo desarrollado en
la Universidad Abierta de los Países Bajos (OUNL) durante ?nales de los años 90. El
grupo de investigación liderado por el Profesor Rob Koper analizó los sistemas de
gestión de la enseñanza (LMSs de su término en inglés Learning Management
Systems) que existían y que eran los más utilizados en aquella época, intentando
identi?car los problemas y defectos de dichos sistemas de e-learning. En particular se
identi?có como principal problema la falta de aplicación de la teoría instruccional y del
aprendizaje dentro de los mismos. Como resultado desarrolló y puso en práctica una
propuesta basada en la de?nición de un Lenguaje especí?co de dominio llamado
Educational Modelling Language (OUNL-EML) (para evitar ambigüedades se
denominará a este lenguaje OUNL-EML a lo largo de este capítulo, en lugar de
simplemente EML).
En un estudio realizado por el CEN/ISSS WS/LT Learning Technology Workshop
acerca de los Lenguajes de Modelado Educativo se de?nió el concepto de EML como:
Modelo de información semántico y su vinculación, que describen el contenido
y el proceso dentro de una “Unidad de Aprendizaje” desde una perspectiva
pedagógica y con el objetivo de dar soporte a la reutilización y la
interoperabilidad (Rawlings et al., 2002).
15
De esta de?nición pueden extraerse los siguientes conceptos principales:
§
Modelo de Información Semántico. Un modelo de información semántico es un
meta-modelo (conceptualización) de un dominio de discurso. En este caso se
trata de un meta-modelo que describe el proceso de enseñanza/aprendizaje.
§
Modelo de información y vinculación. La “vinculación” de un EML es una
formalización lingüística del modelo semántico. Habitualmente, esta
formalización se realiza mediante la de?nición de un Lenguaje Especí?co de
Dominio basado en las tecnologías XML a ?n de conseguir una vinculación o
representación directamente procesable en el ordenador.
§
Unidad de Aprendizaje. El concepto de Unidad de Aprendizaje (UOL) es el
punto clave de los EMLs. En palabras del profesor Koper (2001): “Una UOL
(también conocida como unidad de estudio) es la menor unidad que
proporciona eventos educativos a los estudiantes, satisfaciendo uno o más
objetivos educativos interrelacionados”.
En los EMLs se pasa del concepto de OA como elemento constructivo básico y
atómico a otro de mayor granularidad que es la UOL y que no sólo agrupa
contenidos. Por tanto, una UOL no puede dividirse sin perder su propia
semántica orientada al logro de los objetivos educativos. Una UOL puede ser
un curso, un taller, una práctica, una titulación completa, etc. Cada UOL de?ne
el modelo instructivo, y el entorno donde se realiza. Este entorno está
caracterizado por los recursos materiales (que pueden ser OAs) y los servicios
(v.g. foro, chat, videoconferencia, e-mail) que serán utilizados durante la puesta
en ejecución de la UOL.
§
Perspectiva Pedagógica. Un EML debe ser relativamente independiente de las
teorías instruccionales, de manera que el profesor o el diseñador instruccional
pueda decidir cuál de estas teorías desea aplicar. Una vez más los estándares
educativos no tratan de limitar la expresividad del docente o de imponer una
visión determinada de cómo debe realizarse la enseñanza.
§
Reutilización e Interoperatibilidad. La idea detrás de los EMLs no es sólo
permitir a las aplicaciones informáticas interpretar los guiones creados
mediante dichos lenguajes. Además tienen como objetivo promover la
reutilización de aquellas UOLs que hayan tenido una aplicación exitosa, así
como permitir el intercambio de estas unidades de aprendizaje entre distintos
sistemas de e-learning sin tener en cuenta cómo el sistema de información
implementará ?nalmente la semántica del modelo de?nido.
Además de estos conceptos básicos de los EMLs, el profesor Koper (2000) identi?ca
las siguientes características deseables que debería cumplir un EML:
§
Un Lenguaje de Modelado Educativo debe estar de?nido formalmente y tiene
que poder ser procesable en el ordenador, de manera que los guiones creados
con dicho lenguaje puedan ser interpretados por aplicaciones informáticas.
§
Un Lenguaje de Modelado Educativo tiene que ser pedagógicamente neutral.
Como ya se ha indicado anteriormente, el lenguaje no debe imponer
restricciones a la forma de enseñar y, por tanto, debe permitir la aplicación de
distintas estrategias pedagógicas que el educador considere oportunas en la
concepción de las UOLs.
16
§
Un Lenguaje de Modelado Educativo debe permitir a los diseñadores crear
UOLs completas que incluyan actividades a realizar por el estudiante (¿qué
hacer?), las personas involucradas en dichas actividades (¿con quién?) y el
entorno donde se llevarán a cabo las actividades (¿qué materiales son
necesarios?, ¿qué herramientas?, etc.).
§
Una UOL creada utilizando un EML debería ser perdurable, es decir, resistente
a los cambios y evoluciones tecnológicas, así como a cambios de plataformas,
puesto que su propósito es facilitar la reusabilidad e interoperabilidad entre
sistemas y herramientas distintas.
A modo de resumen, los EMLs son lenguajes que permiten describir UOLs, las cuáles
a su vez describen el proceso de aprendizaje como un todo (y no sólo centrado en los
contenidos como se hace en los objetos de aprendizaje).
Además, otra característica añadida de estos lenguajes es que proporcionan un
mecanismo para la comunicación entre el personal técnico de soporte y el personal no
técnico (normalmente los educadores) dentro de una organización durante la
operacionalización del EML. Ahora las UOLs son completas de modo que el personal
técnico puede saber qué es lo que está planificado y ayudar a resolver las incidencias
que pudieran producirse (e.g. no disponibilidad de un recurso).
1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS
A partir de las diferentes iniciativas desarrolladas en base a los principios de los
Lenguajes de Modelado Educativo previamente mencionados y a los EMLs descritos
en (Rawlings et al., 2002), es posible crear una clasi?cación para los mismos similar a
la propuesta en (Vantroys, 2003):
§
Lenguajes Especí?cos. En esta categoría se encuentran los lenguajes que, aún
sin cumplir estrictamente todas las características de un EML, permiten a los
diseñadores describir las etapas del proceso de aprendizaje utilizando una
metodología especí?ca. En particular, dentro de esta categoría podemos
destacar aquellos lenguajes aplicados a la metodología de enseñanza basada
en la resolución de problemas mediante el planteamiento de preguntas y a la
recolección de soluciones y respuestas.
§
Lenguajes de estructuración de contenidos. Esta categoría está formada por
aquellos lenguajes que permiten a los diseñadores organizar los recursos
educativos en una secuencia, siempre teniendo en cuenta las necesidades del
estudiante y la interacción con el propio contenido, a ?n de mejorar la
experiencia educativa.
§
Lenguajes de Actividad. En esta categoría se encuentran los lenguajes que
están enfocados principalmente a la organización de actividades en general
(utilizando computadoras o no) durante el proceso de aprendizaje.
En la tabla Tabla 1.4.a. se clasi?can diversos EMLs de acuerdo a estas tres
categorías. En los siguientes puntos se darán más detalles acerca de cada uno de
estos lenguajes.
17
Tabla 1.4.a. Clasi?cación de Alto nivel de algunos Lenguajes de Modelado Educativo.
Tipo
Lenguajes
Especí?cos
Lenguajes de
Estructuración
de
Contenidos
Lenguajes de
Actividad
Lenguage
Tutorial Markup Language
(TML)
IMS
Question
and
Test
Interoperability (IMS-QTI)
<e-Adventure>
TArgeted Reuse and GEne
ration of TEAching Mate-rials
(Targeteam)
Learning
Material
Mark-up
Language (LMML)
ARIADNE Course (Curriculum)
Description Format (A-CDF)
AICC Course Data Model
(AICC/CMI)
IMS Simple Sequencing (IMS
SS)
ADL Sharable Content Object
Reference
Model
2004
(SCORM)
<e-DocBook>
PALO
Educational
Environment
Modeling Language (EEML)
XEDU
Méthode
d’ingénierie
d’un
système
d’apprentissage
(MISA)
Educational
Modeling
Language -Open University of
the Netherlands (EML-OUNL
<e-LD>
PoEML
IMS Learning Design (IMS LD)
Sitio web
http://www.ilrt.bris.ac.uk/netquest
http://imsglobal.org/question
http://edventure.e-ucm.es
http://www.targeteam.net
No Disponible
http://www.ariadne-eu.org/
http://www.aicc.org
http://www.imsglobal.org/simplesequencing/
http://www.adlnet.gov/scorm/
http://e-docbook.e-ucm.es/
http://sensei.ieec.uned.es/palo/
http://www.istituti.usilu.net/botturil/
publications.htm
http://www.licef.teluq. uquebec.ca/gp/
http://eml.ou.nl
http://e-ld.e-ucm.es/
http://wwwgist.det.uvigo.es/~mcaeiro/thesis/
http://www.imsglobal.org/learningdesign/
1.4.1. Lenguajes Especí?cos
Tutorial Markup Language (TML) (Brickley, 1998) es una extensión de HTML para
crear preguntas. TML esta diseñado para separar por un lado la semántica del
contenido asociado a la distribución de la pregunta y por otro la semántica del
contenido de la pregunta en sí. El formato de los archivos TML es texto plano,
pudiendo ser generados a partir de otros formatos y otras preguntas que se
encuentren almacenadas en una base de datos.
IMS Question and Test Interoperability (IMS-QTI) es una propuesta llevada a cabo por
el consorcio internacional IMS (Instructional Management Systems – Global Learning
Consortium) para crear bancos de preguntas y de evaluaciones (IMS QTI, 2006). El
18
principal objetivo de IMS-QTI es permitir el intercambio de evaluaciones y de la
información asociada a las evaluaciones entre distintos LMSs. En las evaluaciones
creadas con IMS-QTI existe una división clara entre las preguntas en sí mismas (¿qué
es lo que se pregunta?) y la forma en la que se presentan dichas preguntas al alumno
y en la que se evalúan las respuestas dadas por el mismo. IMS-QTI permite crear test
interactivos, los cuáles pueden incluir pistas (información para ayudar a los alumnos).
También es posible crear plantillas de exámenes que pueden ser utilizadas cuando los
estudiantes llevan a cabo el examen, creando diferentes exámenes a partir de la
misma plantilla. En el Informe número 16 de esta misma colección se puede encontrar
una presentación completa y detallada de este estándar (Fernández-Manjón et al.,
2007).
<e-Adventure> (Moreno-Ger, 2007) es un proyecto que propone un modelo de
desarrollo de videojuegos educativos que son directamente desplegables en un LMS
(siempre que el LMS cumpla con los estándares de IMS Content Packaging). Con <eAdventure> es posible crear aventuras grá?cas y simulaciones con estructura de juego
que tengan un objetivo educativo. Esta iniciativa está compuesta por dos conceptos
principales: el motor <e-Adventure> y el lenguaje <e-Adventure>. Características
distintivas de este enfoque es que tanto el motor como el lenguaje <e-Adventure>
permiten crear juegos adaptativos e incluyen mecanismos que monitorizan e informan
acerca de la actividad de los estudiantes dentro del juego.
El motor de <e-Adventure> ejecuta los juegos que están representados (o codificados)
mediante el lenguaje <e-Adventure>. Este motor es capaz de comunicarse con un
sistema de e-learning o LMS permitiendo que el juego pueda informar al LMS acerca
del progreso del alumno al interactuar con el mismo.
El lenguaje <e-Adventure> es un lenguaje especí?co de dominio ya que permite a un
profesor con pocos conocimientos tecnológicos definir juegos educativos (Moreno-Ger,
2008). Este lenguaje permite la codi?cación del storyboard del juego, así como la
de?nición de los personajes y objetos con los que podrá interactuar el alumno. De la
misma manera, también es posible de?nir de manera simple las condiciones de las
que dependen las distintas acciones que pueden llevarse a cabo en el juego.
Finalmente, el lenguaje también incluye construcciones que permiten la monitorización
de características importantes desde el punto de vista pedagógico (e.g. si el alumno se
queda bloqueado en alguna parte del juego o si toma decisiones erróneas que
implican algún error de concepto) e incluso la creación de juegos que se adaptan a las
características específicas del usuario.
1.4.2. Lenguajes de Estructuración de Contenidos
Targeted Reuse and Generation of Teaching Materials (Targeteam) permite la
creación y el mantenimento (uso y reutilización) de contenidos educativos (Koch,
2002). Este EML permite el uso de los materiales en diferentes situaciones y dominios
pedagógicos (primaria, secundaria y nivel universitario). Haciendo uso de Targeteam,
es posible crear las notas de clase, además de otros contenidos, como aclaraciones,
explicaciones y ejemplos. Este lenguaje está enfocado al uso de tecnologías XML,
como TeachML, e introduce el concepto de tema (issue) como UOL.
19
Learning Material Markup Language (LMML) está basado en un meta-modelo que
puede encajar en distintos dominios de aplicación. LMML ha sido diseñado como
aplicación del meta-lenguaje XML para la descripción de los contenidos educativos
(Weitl et al., 2002). Estos contenidos educativos están estructurados en módulos, que
a su vez pueden estar estructurados en submódulos. LMML se basa en una
estructuración del contenido educativo de manera jerárquica y modular, donde los
contenidos creados con LMML pueden ser adaptados a diferentes situaciones de
aprendizaje y a distintos tipos de estudiantes. Utiliza el concepto de curso (course)
como UOL.
ARIADNE Course Description Format (A-CDF) es un EML que permite la creación de
cursos en línea (Verbert y Duval, 2004). Un curso en A-CDF consiste en documentos
XML que serán utilizados conjuntamente con una herramienta LMS que será la que
finalmente generará los cursos (Van Durm et al., 2001). A-CDF pone especial interés
en el contenido y en su agregación, siendo además lo su?cientemente expresivo como
para describir el proceso de aprendizaje de acuerdo con un modelo pedagógico. El
desarrollo con A-CDF se realiza a través de un conjunto de herramientas construidas
en el seno del consorcio ARIADNE (editores curriculares, LMS, KPS). Este lenguaje
establece el concepto de curso (course) como UOL.
AICC Course Data Model (AICC/CMI) contiene toda la información necesaria para
describir un curso (AICC, 2004). Este formato puede intercambiarse entre distintos
LMSs mediante herramientas de importación / exportación, utilizando el concepto de
Unidades de Asignación (Assignable Units) como unidad de intercambio. La
información generada durante la interacción del alumno con las unidades de
asignación también es almacenada por el LMS. Desde la descripción AICC/CMI es
posible hacer referencia a esta información para decidir qué datos se envían a las
unidades de asignación en tiempo de ejecución. La secuenciación dentro del curso se
controla mediante el uso de los prerequisitos que deben satisfacer los estudiantes
antes de acceder a una nueva unidad de asignación. AICC/CMI utiliza el concepto de
curso (course) como UOL.
IMS Simple Sequencing (IMS-SS) de?ne métodos para poder representar el
comportamiento dentro de una experiencia educativa, de manera que un LMS pueda
secuenciar actividades discretas de forma consistente (IMS SS, 2003). Los
diseñadores instruccionales o los desarrolladores de contenido declaran el orden
relativo en el cuál se presentan al alumno los elementos de contenido, y las
condiciones bajo las cuáles una pieza de contenido se selecciona, se muestra o se
omite durante la presentación. Utiliza el concepto de actividad de aprendizaje (learning
activity) como UOL.
ADL Sharable Content Object Reference Model (SCORM) representa un modelo de
coordinación que tiene el objetivo de proporcionar una colección de prácticas
estandarizadas susceptibles de ser ampliamente aceptadas y ampliamente
implementadas en entornos de e-learning (SCORM, 2004). De hecho, el modelo
SCORM puede ser considerado como un “per?l de aplicación” (en inglés application
profile) de estas prácticas ya que se apoya en otras especificaciones más generales
como, por ejemplo, las proporcionadas por IMS, pero además concreta algunos
aspectos que no están fijados en dichas especificaciones. La iniciativa SCORM pone
en práctica diferentes desarrollos tecnológicos de las iniciativas propuestas por grupos
como IMS, AICC, ARIADNE y IEEE-LTSC, todos ellos agrupados en un único modelo
20
de referencia para especi?car una implementación consistente que pueda ser utilizada
por toda la comunidad de e-learning.
SCORM de?ne los fundamentos técnicos de un LMS basado en tecnologías web,
estableciendo:
§
Un Modelo de agregación de Contenidos que describe los componentes
utilizados dentro de una experiencia educativa, cómo empaquetar estos
componentes para su intercambio y cómo describir estos componentes
mediante el uso de los metadatos para permitir su búsqueda y descubrimiento.
Además también de?ne los requisitos para la construcción de agregaciones de
contenidos (e.g. cursos, lecciones, módulos, etc.). Este modelo da lugar a un
concepto de OA denominado Shareable Content Object (SCO).
§
Un Entorno de ejecución dinámico para la reproducción de los SCOs,
proporcionando de esta forma, un modelo instruccional adaptativo basado en
OAs. Normalmente dicho entorno de ejecución se servirá a los distintos clientes
que acceden al sistema.
§
Un Mecanismo de interoperabilidad entre los SCOs que se ejecutan en el
citado entorno y el resto de componentes que se ejecutan en el LMS, que
habitualmente reside en el lado del servidor.
De forma adicional, en SCORM 2004 (anteriormente conocido como SCORM 1.3) se
ha introducido un Modelo de Secuenciación y Navegación para permitir la
presentación dinámica de los contenidos educativos en función de las necesidades de
aprendizaje. Está basado en la propuesta IMS Simple Sequencing (IMS-SS) y describe
cómo se puede secuenciar el contenido compatible con el modelo SCORM utilizando
una secuencia de eventos de navegación, donde estos eventos pueden ser iniciados
por el estudiante o por el sistema. El control de las bifurcaciones y el ?ujo puede ser
descrito utilizando un conjunto prede?nido de actividades que normalmente se deben
fijar en el momento del diseño del curso. Además, también describe cómo los LMSs
compatibles con SCORM tienen que interpretar estas reglas de secuenciación
expresadas por el desarrollador de contenidos, acompañadas por el conjunto de
eventos de navegación iniciados por el estudiante o por el sistema, y cuáles son sus
efectos sobre el entorno en tiempo de ejecución. SCORM utiliza el concepto de
“organización de contenido” (en inglés content organization) como UOL.
<e-DocBook> es una metodología y un conjunto de herramientas ideadas para
simpli?car el proceso de creación de materiales educativos adaptativos basados en el
concepto de OAs (Martinez-Ortiz, 2005, 2006). Esta iniciativa utiliza una extensión de
DocBook (Walsh, 1999), un lenguaje XML usado en entornos técnicos para la creación
de manuales.
La metodología propuesta por <e-DocBook> se basa en la metáfora de escritura de un
manual, proceso al que habitualmente están acostumbrados los docentes (aunque
para e-learning los contenidos deberían ser concebidos de forma diferente, en base a
los conceptos que se quieren enseñar y su relación con los OAs, y no sólo como un
libro que se publica en la red). A partir del manual generado y aplicando las
herramientas proporcionadas por <e-DocBook> se pueden obtener distintos productos:
un curso, módulos de curso basados en OAs, trasparencias para ser utilizadas como
notas de clase, etc.
21
En ambos casos el resultado ?nal será agregado en un paquete IMS Content
Packaging (IMS-CP) para poder simpli?car el intercambio de los contenidos entre
sistemas de e-learning. Además, las herramientas proporcionadas permiten la
generación de los contenidos en formatos HTML, PS, PDF, RTF, archivos de ayuda de
Eclipse y ?nalmente archivos de ayuda de Windows.
1.4.3. Lenguajes de Actividades
PALO es un lenguaje de modelado desarrollado en la Universidad Nacional de
Enseñanza a Distancia (UNED) (Rodriguez-Artacho et al., 1999). PALO permite
describir cursos organizados mediante módulos que contienen actividades educativas,
contenido y un plan de enseñanza. Utilizando PALO el diseñador puede crear plantillas
para de?nir tipos de escenarios de aprendizaje. Utilizando las características del
lenguaje, es posible secuenciar tareas de aprendizaje y módulos. Como complemento,
se pueden añadir restricciones sobre los cursos, permitiendo de?nir tiempos y fechas
límite, así como dependencias entre módulos y tareas. Utiliza el concepto de módulo
como UOL.
Educational Environment Modeling Language (E2ML) es una propuesta de EML que
proporciona un lenguaje visual con el objetivo de permitir diseñar entornos educativos
en el ámbito universitario (Botturi, 2006). Dicho lenguaje permite crear una de?nición
explícita del proceso de aprendizaje y de las actividades educativas. En particular
aborda los siguientes aspectos:
§
Facilita la comunicación entre los diferentes interesados dentro del proceso
(diseñadores de unidades de aprendizaje, personal técnico, profesores, etc).
Para ello propone una representación visual del diseño, que se puede utilizar
de manera similar a como se utilizan los planos de un edi?cio que va a
construir.
§
El diseño de una UOL puede utilizarse como base de otra UOL, no sólo por
parte del mismo diseñador, sino por toda la comunidad educativa.
E2ML utiliza el concepto de curso (course) como UOL.
XEDU está ideado para ofrecer a los diseñadores instruccionales un marco de trabajo
para la especi?cación de cualquier aplicación educativa, tanto desde el punto de vista
de las teorías instruccionales como desde el punto de vista de la ingeniería del
software (Buendía et al., 2003, 2004). Los principales conceptos de?nidos en XEDU
son:
§
Per?l de alumno. Almacena toda la información relevante acerca del
estudiante, incluyendo el resultado del proceso de aprendizaje.
§
Escenario educativo. Consta de actividades y condiciones en un contexto
educativo especí?co.
§
Estructura didáctica. Organiza el contenido educativo con un objetivo didáctico
especí?co.
22
El concepto de estructura didáctica representa una UOL en XEDU.
MISA introduce una nueva aproximación denominada “ingeniería instruccional” (en
inglés Instructional Engineering) (Paquette, 2004). La ingeniería instruccional está
basada en las teorías del Diseño Instruccional (en inglés Instructional Design)
(Reigeluth, 1983; Merrill, 1994; Dick, 2000) junto a la ingeniería cognitiva y la ingeniería
del software. Para ello proporciona una metodología que da soporte a la plani?cación,
análisis, diseño y entrega de un sistema de aprendizaje y comparte los principios de
los EMLs. MISA permite el diseño de sistemas de aprendizaje a través de 35 tareas,
produciendo 35 entregables denominados elementos de documentación. La creación
de estos documentos está dividida en fases bien de?nidas. El concepto de Escenario
de aprendizaje representa una UOL en MISA.
OUNL-EML ha sido desarrollado por la OUNL para su aplicación en e-learning. La
versión 1.0 de dicho lenguaje y su modelo XML fue distribuida en el año 2000 (Koper,
2000, 2001). OUNL-EML fue seleccionado como base de la especi?cación IMS-LD,
integrando OUNL-EML con la especi?cación IMS-CP e IMS-SS. OUNL-EML ha sido
utilizado y puesto en práctica en diversas aplicaciones de e-learning, y, en particular,
en la Universidad Complutense de Madrid en las primeras versiones del proyecto <eAula> (Sierra et al., 2006). OUNL-EML permite la de?nición de “diseños de
aprendizaje” (diseños instructivos) con el objetivo de permitir la creación de
herramientas avanzadas de e-learning, (e.g. herramientas que permitan la de?nición
de un modelo educacional basado en competencias, en portafolio o en el aprendizaje
colaborativo).
En OUNL-EML el concepto de “diseño de aprendizaje” (learning design) representa el
concepto de UOL. Un diseño de aprendizaje es una instancia concreta de un modelo
pedagógico, el cual a su vez es una instancia de un meta-modelo pedagógico. Este
meta-modelo no fuerza a los usuarios de OUNL-EML a utilizar un modelo pedagógico
concreto, sino que les permite crear y describir sus propios modelos de manera
expresiva. El meta-modelo ofrecido por OUNL-EML ha sido desarrollado a partir del
análisis de los modelos existentes basados en las aproximaciones constructivistas
(sociales), de comportamiento y cognitivas.
<e-LD> es una iniciativa que trata de simplificar la autoría y reutilización de diseños
educativos mediante la aplicación de conceptos de flujos de trabajo (en inglés
workflows) (Martínez-Ortiz et al., 2008). La idea es proponer un lenguaje específico de
dominio orientado a flujo (a secuenciamiento de actividades) que es más comprensible
para los docentes. La compatibilidad con otros estándares como IMS-LD se obtiene
mediante procesos de exportación automática. Además proporciona herramientas para
ayudar a la compresión de diseños previamente creados con IMS-LD de los que
únicamente se dispone de su representación en XML (permitiendo, por ejemplo, la
visualización de dependencias entre tareas o entre tareas y condiciones).
PoEML (Perspective-oriented EML) es un lenguaje basado en IMS-LD que se define a
partir de la propuesta de separación de asuntos o aspectos (Caeiro et al., 2007). El
lenguaje tiene una estructura modular con la que se pretende mejorar los problemas
de capacidad expresiva, complejidad y usabilidad identificados en los EMLs actuales.
Finalmente entre las diferentes propuestas de especi?caciones, IMS Learning Design
ha emergido como el estándar de-facto para la representación de cualquier UOL ya
que en principio permite utilizar cualquier teoría de aprendizaje. Debido a su
23
importancia tanto en el ámbito del e-learning como para este trabajo, se realiza una
presentación breve de esta especificación en la siguiente sección (el siguiente capítulo
está dedicado a realizar una presentación completa y con ejemplos de IMS-LD).
1.5. IMS LEARNING DESIGN
IMS Learning Design está basado en el lenguaje OUNL-EML. Esta especi?cación ha
sido elaborada por el grupo de trabajo IMS/LDWG enmarcado dentro de las iniciativas
desarrolladas por el IMS Global Learning Consortium (IMS LD, 2003). El punto de
partida de este grupo de trabajo fue la especi?cación OUNL-EML. El resultado ?nal ha
sido el desarrollo de una nueva especi?cación adaptada en aquellas partes en las que
existía un solapamiento con el resto de especi?caciones propuestas por IMS, junto a
una adaptación de la propia especi?cación para poder dividirla en varios niveles, al
estilo del modelo de capas en una arquitectura de software, para hacerla más
comprensible.
Una de las adaptaciones más relevantes llevada a cabo ha sido la adopción de la
especi?cación IMS Content Packaging como formato y medio de transmisión e
intercambio entre distintos LMSs y herramientas. Asimismo, otras partes de?nidas en
OUNL-EML no han sido reutilizadas (por ejemplo, el formato XML para la descripción
de los contenidos educativos, que era un dialecto del formato DocBook (Walsh y
Muellner, 1999).
Además de la adaptación al entorno de especi?caciones de IMS, otro objetivo ha sido
la inclusión de otros trabajos y especi?caciones que no se solapaban con el trabajo
realizado. Por ejemplo, IMS-SS ha sido incluido dentro del ámbito de trabajo de IMS
Learning Design para llevar a cabo el secuenciamiento de los OAs dentro de las
actividades que se llevan a cabo en el contexto de la UOL. Otro ejemplo ha sido IMS
Question and Test Interoperability, de manera que los exámenes y preguntas
presentadas con IMS QTI pueden utilizarse dentro de las actividades. De esta manera,
la puntuación obtenida en estas pruebas puede provocar que aparezcan nuevas
actividades o que desaparezcan otras.
En la Figura 2.3.a puede observarse la estructura de alto nivel de una UOL expresada
en IMS-LD.
Además, para facilitar el aprendizaje y la implementación de la especi?cación, el
modelo conceptual de IMS-LD (Figura 1.5.b) está dividido en tres niveles (A, B y C)
donde cada nivel está construido encima del modelo y de la semántica de?nida en los
niveles previos:
§
Nivel A. Contiene el núcleo de los componentes de la especi?cación. Cuando
se crea una UOL con IMS-LD, se debe especi?car un modelo estático y un
modelo dinámico.
§
Nivel B. Añade los conceptos de propiedades y condiciones al nivel anterior.
Las propiedades de?nen un modelo de datos para el alumno y las condiciones
se utilizan para personalizar las UOLs en base a los conocimientos previos de
los alumnos y a su interacción con dichas UOLs.
24
§
Nivel C. Añade el concepto de noti?cación al nivel anterior. Las noti?caciones
proporcionan un nuevo mecanismo de noti?cación de sucesos que ocurren
durante la ejecución de una UOL.
Figura 1.5.a. Estructura de alto nivel de una unidad de aprendizaje en IMS-LD.
El modelo estático de IMS-LD permite de?nir qué es lo que se va llevar a cabo en la
UOL, qué tipos de usuarios (e.g. profesores, alumnos, etc.) participan en la UOL y con
qué recursos se llevarán a cabo las actividades (e.g. páginas HTML, PDF, etc.). El
modelo estático está compuesto por los siguientes conceptos:
§
Título. Permite dar un título para la UOL.
§
Objetivos educativos. De?nición de los objetivos educativos de la UOL. Esta
descripción habitualmente se realiza en lenguaje natural.
§
Prerrequisitos. De?nición de los conocimientos previos que debe tener un
alumno para que pueda llevar a cabo las actividades de la UOL. La descripción
de los prerrequisitos también se realiza en lenguaje natural.
§
Metadatos. Esta meta-información permite la indexación de las UOLs, de
manera que se simpli?que su posterior clasi?cación, catalogación y
recuperación.
§
Roles. De?nición de los diferentes tipos de usuario que aparecerán en la UOL.
§
Actividades. De?nición de las actividades que se llevarán a cabo dentro de las
UOLs. En la de?nición de las actividades se incluyen los objetivos y los
prerrequisitos de las actividades. Además, también se incluye una descripción
textual de cuáles son los objetivos de la actividad. Finalmente, se incluye una
referencia al entorno donde se llevará a cabo la actividad.
25
§
Entornos. De?nen los contenidos educativos (OAs) y las herramientas
(servicios de aprendizaje) que se utilizarán en las distintas actividades de la
UOL.
Figura 1.5.b. Estructura conceptual de IMS-LD.
El modelo dinámico de IMS Learning Design permitir de?nir el quién y el cúando. El
modelo dinámico hace uso de los conceptos de?nidos en el modelo estático
anteriormente descrito.
El modelo dinámico permite de?nir qué tipo de usuario (rol) llevará a cabo una
actividad concreta y también permite de?nir la sincronización y las dependencias que
existirán entre las distintas actividades que componen la UOL.
El modelo dinámico puede verse como la esceni?cación de una obra teatral. El método
(method) consiste en una o varias representaciones (play) que son interpretadas en
paralelo. Cada una de las obras está formada por uno o más actos (acts) que serán
interpretados uno tras otro (ver Figura 1.5.c).
Dentro de cada acto se realiza la distribución de papeles (role-parts), es decir, se
de?ne qué actividades serán llevadas a cabo por cada uno de los tipos de usuario
involucrados en el proceso de aprendizaje (ver Figura 1.5.c).
Utilizando los niveles B y C podemos crear secuenciaciones dinámicas más
complejas. En particular podemos incluir dependencias entre actividades (por ejemplo,
para indicar que un profesor debe desempeñar una actividad en la que corrija un
examen después de que el alumno lo termina).
26
Figura 1.5.c. Representación de un método con tres actos secuenciales (a) y
representación de un método en el que se incluyen los roles de los usuarios en las
actividades y se muestra que puede haber actividades en paralelo (b).
1.6. HERRAMIENTAS DE SOPORTE A IMS-LD
Aunque la aplicación práctica de IMS-LD sigue siendo muy limitada sí existen diversas
iniciativas que proporcionan herramientas para trabajar con IMS-LD.
En esta sección se realiza una breve presentación de algunas de las iniciativas que
debido a su relevancia o madurez se han considerado como más prometedoras
actualmente.
Podemos encontrar tres tipos de herramientas:
§
Herramientas de Autoría. Son herramientas que permiten la creación de las
UOLs.
§
Motores de Ejecución. Son herramientas que, dada una UOL codi?cada con
IMS-LD, interpretan el proceso de aprendizaje, monitorizando la realización de
las actividades y actualizando el per?l del alumno según los resultados que se
vayan obteniendo en las actividades que tienen asignadas. Este tipo de
herramientas residen habitualmente en un servidor de aplicaciones y son
utilizadas tanto por los profesores como por los alumnos a través de una
interfaz web adecuada.
§
Reproductores. Estas herramientas son utilizadas por los actores que
interactúan con la UOL, tanto en el proceso de ejecución de la misma, como
27
durante el proceso de publicación de la UOL (es decir, el proceso de
preparación de la misma para su puesta en ejecución). De esta forma, estas
herramientas proporcionan la citada interfaz web con los motores de ejecución.
1.6.1. Herramientas de Autoría de IMS-LD
En esta sección se hace un breve análisis de distintas iniciativas de desarrollo de
herramientas de autoría compatibles con la especi?cación IMS-LD. Esta sección no
pretende realizar un análisis exhaustivo de todas las iniciativas existentes (para mayor
detalle se puede consultar Berggreen et al., 2005; Burgos y Griffiths, 2005; Dodero et
al., 2006; Berlanga y García, 2005) sino de las que en el momento de escritura del
documento hemos considerado más relevantes, como son ALFANET, CopperAuthor,
RELOAD, CoS-MoS, Collage, MOT+, ASK-LDT y LAMS.
ALFANET (Active Learning for Adaptive Internet) es una iniciativa europea que tiene
como objetivo el desarrollo de nuevos métodos y servicios para llevar a cabo un
proceso de aprendizaje activo y adaptado al alumno (http://alfanet.ia.uned.es). El
editor de IMS-LD de ALFANET representa los conceptos de IMS-LD mediante
elementos gráficos que conforman la interfaz. Esta herramienta sólo permite la
creación y el desarrollo de diseños educativos IMS-LD de nivel A (este proyecto ya
está concluido y no parece claro que se haya seguido con este desarrollo).
CopperAuthor (Figura 1.6.1.a) es una herramienta desarrollada en paralelo al motor de
ejecución CopperCore. Esta herramienta permite a los diseñadores construir y navegar
sobre la estructura del diseño educativo mediante una interfaz basada en tablas
(CopperAuthor, 2007). En su versión actual la interfaz es un tanto primitiva y sólo
permite el desarrollo de diseños educativos IMS-LD de nivel A.
28
Figura 1.6.1.a. Interfaz de CopperAuthor.
29
RELOAD (Reusable E-Learning Object Authoring & Delivery) (Figura 1.6.1.b) es un
editor desarrollado en el seno de un proyecto patrocinado por la iniciativa JISC del
Reino Unido (http://www.reload.ac.uk). Este editor permite la edición de una UOL
mediante la interacción con múltiples formularios y estructuras en forma de árbol que
representan la estructura de agregación de los conceptos de IMS-LD implícita en el
formato XML utilizado para representar las UOL de IMS-LD. Con esta herramienta se
pueden crear diseños educativos IMS-LD de los tres niveles (del nivel A al nivel C).
Figura 1.6.1.b. Interfaz del editor de IMS-LD de RELOAD.
30
CoSMoS (Collaboration Script Modelling System) (Figura 1.6.1.c) es una herramienta
de autoría ideada inicialmente para dar soporte a la formalización de procesos de
aprendizaje colaborativos (Miao, 2005). Posteriormente la herramienta fue modi?cada
para dar soporte a los conceptos de IMS-LD. La edición de la UOL se basa en la
navegación sobre la estructura en árbol de la misma y la edición de los conceptos
mediante formularios. Con esta herramienta se pueden crear diseños educativos IMSLD de nivel B.
Figura 1.6.1.c. Interfaz del editor de IMS-LD de CoSMoS.
Collage es una herramienta de autoría de alto nivel y de autoría colaborativa basada
en el concepto de los patrones de ?ujo colaborativos (Collaborative Learning Flow
Patterns), que son plantillas que de?nen el ?ujo de tareas para dirigir de manera
adecuada el proceso de aprendizaje (Hernandez-Leo et al., 2006). Esta herramienta
ha sido desarrollada sobre RELOAD y con ella sólo se pueden crear diseños
educativos IMS-LD de nivel A.
MOT+ es una herramienta desarrollada en el centro de investigación LICEF de
Canadá, con el objetivo inicial de estructurar mapas conceptuales para la
representación de conocimiento en diversos dominios (Paquette et al., 2005). MOT+
utiliza una notación grá?ca para representar las entidades de conocimiento con las que
trabaja la herramienta. MOT+ fue extendida para soportar la edición de IMS-LD, de
manera que la herramienta permite representar y editar los conceptos que están
31
de?nidos en IMS-LD. Con esta herramienta se pueden crear diseños educativos IMSLD de nivel A y se están realizando trabajos para soportar los niveles B y C.
ASK-LDT (Advanced e-Services for the Knowledge Society Research Unit) (Figura
1.6.1.d) es una herramienta que proporciona una notación grá?ca para los conceptos
de IMS-LD (Karampiperis y Sampson, 2004). ASK-LDT de?ne una notación grá?ca para
un conjunto de tipos de actividades prede?nidas como, por ejemplo, lecciones,
discusiones, exámenes, etc. Además, también proporciona una notación grá?ca para
poder de?nir el ?ujo entre dichas actividades. Con esta herramienta podemos crear
diseños educativos IMS-LD de nivel A y parcialmente de nivel B.
Figura 1.6.1.d. Interfaz del editor de ASK-LDT.
Finalmente, Learning Activity Management system (LAMS) es una herramienta que
permite el diseño, gestión y distribución de actividades colaborativas para e-learning
(Dalziel, 2003, 2005). LAMS proporciona una herramienta de autoría visual muy
intuitiva (Figura 1.6.1.e) que permite crear las secuencias de actividades de
aprendizaje. En los cursos de LAMS se pueden encontrar diferentes actividades:
individuales, para pequeños grupos de usuarios o para clases completas. Estas
actividades pueden incluir el trabajo con contenidos educativos o tareas de trabajo
colaborativo.
32
Figura 1.6.1.e. Interfaz del editor de LAMS.
1.6.2. Motores de ejecución compatibles con IMS-LD
Quizá el motor IMS-LD más popular sea CooperCore. CopperCore es un motor de
ejecución de UOLs formalizadas con IMS-LD desarrollado por la OUNL. Como
características principales de CopperCore podemos destacar:
§
Es un proyecto de software libre.
§
Soporta la ejecución de UOLs hasta el nivel C de IMS-LD.
§
CopperCore está desarrollado sobre la plataforma Java EE, y su puesta en
funcionamiento es relativamente simple.
§
CopperCore proporciona una Interfaz de Programación de Aplicaciones (API)
que permite extender sus funcionalidades, así como controlar el motor de
ejecución desde otra herramienta.
§
Proporciona una capa de abstracción, CopperCore Service Integration (CCSI),
que permite integrar de forma sencilla diversos servicios de aprendizaje, como,
por ejemplo, herramientas compatibles con IMS-QTI.
33
1.6.3. Reproductores de IMS-LD
CopperCore Player (Figura 1.6.3.a) es una aplicación web simple que permite
interactuar con el motor de ejecución CopperCore. Esta herramienta fue creada como
herramienta simple para realizar las pruebas necesarios durante el desarrollo del
motor CopperCore.
Figura 1.6.3.a. Reproductor CopperCore.
SLeD Player (Figura 1.6.3.b) es un nuevo cliente web para el motor de ejecución
CopperCore (McAndrew et al., 2004; Weller et al., 2006). Las principales características
de SLeD Player son:
1. Proporciona una interfaz web para la gestión de usuarios y de las ejecuciones
de las UOLs.
2. Permite la personalización del diseño y de la distribución de la interfaz de
reproducción de la UOL mediante el uso de tecnologías XML.
3. Proporciona implementaciones para los servicios de búsqueda y foro que
pueden ser referenciados dentro de los entornos de una UOL codi?cada con
IMS-LD.
4. Proporciona soporte a la capa de abstracción CCSI. Como ejemplo de uso de
CCSI, SLeD integra los servicios de foro y de búsqueda.
34
Figura 1.6.3.b. Reproductor SLeD.
RELOAD Player (Figura 1.6.3.c) ha sido desarrollado por Paul Sharples y Phillip
Beauvoir en la Universidad de Bolton. RELOAD Player ha sido construidO sobre la
plataforma Eclipse y hace uso de CopperCore como motor de ejecución de IMSLD.
Esta herramienta proporciona una interfaz simple para la publicación de UOLs
compatibles con IMS-LD y la creación de usuarios de prueba que pueden ser
utilizados para probar las UOLs. RELOAD Player está pensada principalmente para
probar de manera simple las UOLs que se están diseñando con el correspondiente
editor.
35
Figura 1.6.3.c. Reproductor de IMS-LD de RELOAD.
Otro entorno de ejecución es GRAIL (Gradient-lab RTE for Adaptive IMS-LD in .LRN)
desarrollado en la Universidad Carlos III de Madrid que permite la ejecución de UOL
en el LMS de código libre .LRN (Escobedo del Cid et al., 2007). GRAIL ejecuta OULs
de los tres niveles que permite la especificación y es una de las pocas herramientas
disponibles que se integra completamente en un LMS ampliamente difundido y
utilizado.
1.6.4. Otras iniciativas y proyectos de investigación relacionados con
IMS-LD
Como este campo del modelado educativo no está suficientemente maduro para su
aplicación industrial y generalizada, una forma de mantenerse al corriente de los
avances es considerar los proyectos de investigación relacionados. Aunque los
proyectos que tratan, al menos en parte, estos aspectos son muy numerosos nos
quedaremos con algunos que por su volumen y número de socios implicados son
susceptibles de tener un cierto impacto, bien en la evolución de las especificaciones o
bien en el desarrollo de herramientas.
Hay dos proyectos europeos del sexto programa marco que están relacionados con
IMS-LD y que tienen como objetivos avanzar en el uso de dicha especificación y, hasta
cierto punto, producir herramientas que simplifiquen su aplicación. Uno de ellos es
Prolix (http://www.prolixproject.org/) donde se ha creado una herramienta de autoría
denominada Prolix LD authoring tool que traduce un diseño de alto nivel a dicha
especificación (aunque en el momento de escribir este documento no está
36
públicamente disponible y no existen muchos detalles al respecto). Otro proyecto
europeo muy relacionado con el modelado educativo y las competencias es
TENCompetence (http://www.tencompetence.org), donde el mismo equipo que ha
participado en el desarrollo de RELOAD, está desarrollando un editor más amigable
para IMS-LD denominado ReCourse (Figura 1.6.4.a). No obstante a fecha de
redacción de este informe todavía no tenían ningún software públicamente disponible
mas allá de capturas de pantalla como la presentada.
Figura 1.6.4.a. Editor de ReCourse.
Otro punto de referencia en la red relativo a estándares educativos es el observatorio
de estándares de tecnologías educativas (CEN/ISSS Learning Technology Standards
Observatory) mantenido en la Universidad de Vigo (http://www.cen-ltso.net) que a
partir del verano de 2008 ha sido incluido en la red europea de buenas prácticas
ASPECT que busca mejorar la adopción de especificaciones y estándares de elearning. El sitio web del JISC en el Reino Unido (http://www.jisc.ac.uk/) mantiene
mucha información actualizada de los usos educativos de las tecnologías y financia,
por ejemplo, el proyecto LD4P (Learning Design for Practicioners) sobre la aplicación
práctica de IMS-LD (http://bsd1.phosphorix.co.uk/ld4p/index.php) dentro de su
iniciativa más general sobre diseño educativo
(http://www.jisc.ac.uk/elp_desinglearn.html).
El proyecto canadiense IDLD (www.idld.org) está dedicado a la diseminación del
diseño educativo y al uso de IMS-LD proporcionando acceso a información
metodológica sobre cómo aplicar dicho modelado y a un almacén (repositorio) de
diseños educativos.
37
Otro sitio web donde se puede encontrar mucha información relacionada con elearning y el modelado educativo, tanto en sus aspectos más técnicos como en sus
aspectos más educativos, es la Edutech wiki mantenida en la Universidad de Ginebra
(http://edutechwiki.unige.ch/en/Main_Page).
1.7. A MODO DE CONCLUSIÓN
Los EMLs permiten a profesores y educadores el diseño, la formalización y el
intercambio de cursos basados en el concepto general de unidad de aprendizaje.
Estas unidades de aprendizaje, debidamente formalizadas y descritas mediante
metadatos (e.g. IEEE LOM) pueden realmacenarse en una base de datos (también
llamada repositorio) para su reutilización posterior, tanto para repetir el proceso de
aprendizaje, como para la creación de unidades de aprendizaje nuevas tomando ésas
como punto de partida.
Además, los EMLs tienen también otro uso y es que sirven como medio de
comunicación entre el personal técnico y el personal docente. El personal docente es
responsable de la descripción de las experiencias educativas mientras que el personal
técnico es responsable de la creación de intérpretes que permitan ejecutar
automáticamente las UOLs creadas y su integración dentro del LMS que se utilice.
Al integrar el intérprete del EML dentro del LMS estamos proporcionando al personal
docente la posibilidad de adaptar y personalizar el propio LMS, teniendo en cuenta sus
necesidades educativas especí?cas, y sin demandar de ellos conocimientos de
programación profundos (aunque, a día de hoy, sí exige tener mucho conocimiento del
propio estándar IMS-LD debido a la ausencia de herramientas de autoría sencillas y
maduras para usuarios finales).
La especi?cación IMS-LD se ha convertido en el estándar de facto como medio de
incorporación en las herramientas de gestión de e-learning de aspectos más
avanzados de metodologías educativas, lo que permite que los LMS transciendan la
concepción simplista de ser meros artefactos de distribución de contenidos educativos.
Sin embargo, IMS-LD está en un punto medio entre un modelo puramente educacional
y un modelo puramente tecnológico. En nuestra opinión, para poder aplicar esta
especi?cación de manera efectiva necesitamos movernos simultáneamente hacia
ambos extremos. Efectivamente:
Desde el punto de vista educativo, se necesita diseñar y documentar el proceso de
enseñanza de manera cuidadosa, con el objetivo de que el diseño pueda ser analizado
y/o reutilizado por otros docentes y que, ?nalmente, este diseño pueda ponerse en
práctica (ejecutarse) automáticamente en un LMS. Por tanto es necesario elevar el
nivel de abstracción proporcionado por las herramientas de autoría de UOL para que
los docentes no tengan que conocer todos los detalles y complejidades del modelo
subyacente impuesto por IMS-LD.
Desde el punto de vista tecnológico, es necesario formalizar todos los detalles
relativos a la ejecución de la UOL diseñada, por ejemplo, cuando se interpreta en un
LMS. La especi?cación IMS-LD deja claramente fuera de su alcance los detalles
especí?cos de ejecución de una UOL de modo que sería necesario un perfil de
38
aplicación ampliamente aceptado que fijara dichos detalles y simplificara el desarrollo
de entornos de ejecución (del mismo modo que SCORM ha fijado detalles no incluidos
en las especificaciones IMS en las que se basa para simplificar su implementación en
sistemas comerciales).
2. LA ESPECIFICACIÓN IMS LEARNING DESIGN
2.1. INTRODUCCIÓN
Disponer de contenidos digitales de calidad y de servicios informáticos de alta
tecnología (por ejemplo, sofisticados programas de comunicación) no es suficiente, por
sí mismo, para dar lugar a aplicaciones e-learning totalmente funcionales. Además se
necesita indicar la forma en la que los distintos participantes en el proceso de
aprendizaje deben utilizar dichos recursos a fin de lograr los objetivos educativos
perseguidos. Dicho de otra forma, es necesario diseñar las distintas pedagogías en las
que se basan las citadas aplicaciones. La especificación IMS Learning Design (IMS
LD) surge, precisamente, como un mecanismo básico que permite describir dichas
pedagogías.
IMS LD proporciona un lenguaje de dominio específico que permite diseñar las
experiencias educativas a las que se expondrán a los usuarios de las aplicaciones de
e-learning. Aún siendo un lenguaje informático artificial, el lenguaje de IMS Learning
Design contiene primitivas y conceptos que pueden ser fácilmente entendidos por los
educadores. De esta forma, su uso no demanda conocimientos muy avanzados de
informática, programación o desarrollo de aplicaciones web. Por el contrario, con un
poco de entrenamiento y con un mínimo de herramientas de soporte (por ejemplo,
editores específicos para IMS LD), un educador motivado podrá utilizar el lenguaje
para plasmar sus diseños educativos. Estos diseños servirán como base para la
generación automática de las aplicaciones finales utilizando herramientas informáticas
adecuadas (por ejemplo, reproductores de IMS LD). De esta forma, el principal
potencial de IMS LD es permitir que sean los propios educadores, que son los que
realmente entienden las necesidades y objetivos finales de las aplicaciones
educativas, los que realmente lideren el desarrollo y mantenimiento de dichas
aplicaciones.
En este capítulo se analiza con detalle la especificación IMS LD. 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 presentan los
principales conceptos y estructuras subyacentes a la especificación. Para finalizar, se
muestra cómo dichos conceptos y estructuras se describen en XML.
2.2. UN CASO DE ESTUDIO
El Profesor Corbinus, primo segundo del conocido Profesor Eméritus (FernandezManjón et al., 2007) dicta clases de Enología Aplicada en la prestigiosa Escuela de
Estudios y Prospecciones Vinícolas (EEPV), en Villanueva del Tintorro. Corbinus
imparte un seminario de Iniciación a la Cata que, con los años, ha adquirido bastante
39
prestigio entre la comunidad de la EEPV. Parte de este éxito se debe a las grandes
dotes que Corbinus, siempre preocupado por las mejoras de sus procesos
pedagógicos, posee como docente.
Este año, Corbinus, que ha seguido un curso intensivo de verano en e-learning, se ha
planteado introducir en su seminario diversas mejoras con ayuda de las tecnologías de
la Información y las Comunicaciones (TICs). Consciente como es de que el éxito
último de la aplicación satisfactoria de estas tecnologías radica en basar las
aplicaciones en diseños pedagógicos bien fundados, Corbinus baraja los siguientes
escenarios educativos para la articulación de su seminario:
§
Escenario 1. Un proceso de enseñanza tradicional, que incluye algunas
actividades soportadas por las TICs. Inicialmente Corbinus impartirá una
serie de clases presenciales. A continuación pondrá a disposición de los
alumnos distinto material complementario sobre el Arte de la Cata. Este
material incluye: (i) un vídeo de 10 minutos de duración en el que el insigne
Profesor Bacus (de la Universidad de Uva Dulce) analiza la importancia del
retrogusto en la evaluación de los matices del vino de Rueda, variedad
Verdejo; (ii) un artículo escrito por el conocido experto italiano Giorgio Birra,
en el que se realiza un estudio comparativo entre las tonalidades de los
caldos de la Baja Toscana y (iii) un estudio llevado a cabo por la Profesora
Yoyo Bebo sobre el efecto de los sulfitos en el regusto y en el postgusto del
vino de mesa común. De la misma manera, Corbinus también quiere
recomendar a sus alumnos la visita del sitio www.lacatadelvinotinto.org.
Por último, Corbinus quiere fomentar también el aprendizaje colaborativo
mediante la organización de un debate on-line en el que, aparte de los
alumnos matriculados en el seminario, participarán también alumnos de
anteriores promociones. Una vez finalizadas todas estas actividades, los
alumnos deben preparar un trabajo escrito, que Corbinus evaluará a fin de
decidir las notas finales de los mismos.
§
Escenario 2. Introducción de mecanismos de adaptación del proceso a las
necesidades particulares de los alumnos. Este escenario se basa en el
anterior. No obstante, antes de iniciar las actividades complementarias,
Corbinus somete a sus alumnos a un examen tipo test. En función de los
resultados obtenidos en este examen y como paso previo al inicio de las
actividades complementarias, Corbinus puede decidir recomendar a los
alumnos repasar el material básico contenido en su libro Introducción a la
Esencia de la Cata (Corbinus tiene una versión electrónica en formato PDF
de este libro que, a pesar de su carácter autoeditado, ha llegado a ganar un
merecido renombre entre los miembros especializados de la comunidad
vinícola). Asimismo, Corbinus también desea introducir una fase de
recuperación para aquellos alumnos cuyo trabajo no haya superado ciertos
umbrales mínimos de calidad. Esta fase consiste en el repaso del libro
Introducción a la Esencia de la Cata, del artículo de Birra y del material
contenido en el sitio www.lacatadelvinotinto.org. Seguidamente el alumno
deberá revisar y mejorar su trabajo, trabajo que de nuevo será evaluado por
Corbinus.
§
Escenario 3. En este escenario Corbinus desea mejorar el proceso de
entrega de trabajos, permitiendo que se le notifique cada entrega, a fin de
facilitar el solapamiento del período de corrección con el período de
40
redacción de trabajos para aquellos trabajos que se hayan entregado antes
de la expiración de la fecha de entrega.
2.3. VISIÓN CONCEPTUAL DE IMS LD
La especificación IMS LD permite diseñar las pedagogías de componentes educativos
denominados “unidades de aprendizaje”. Una unidad de aprendizaje es un concepto
abstracto con el que se denota cualquier pieza utilizada con un propósito educativo o
de entrenamiento como, por ejemplo, un curso, un módulo, una lección, etc. Es
importante notar que, desde el punto de vista de IMS LD, una unidad de aprendizaje
no es una mera organización de recursos de soporte al aprendizaje (v.g. contenidos
educativos tales como textos, diagramas, ejercicios, enunciados de prácticas o
servicios informáticos y telemáticos tales como e-mail, foros, chats, etc.), sino que
también integra las actividades necesarias que los distintos participantes en el proceso
deben llevar a cabo con ayuda de dichos recursos a fin de lograr una experiencia
educativa satisfactoria (v.g. realización de prácticas, resolución de ejercicios,
realización y corrección de exámenes, exposiciones y debates, etc.). Los recursos, las
actividades y los participantes concretos dependen de cada unidad de aprendizaje
particular. De hecho, la identificación y la adecuada orquestación de estos
componentes constituyen el núcleo fundamental de todo diseño educativo.
En el caso de estudio cada uno de los escenarios planteados dará lugar a una unidad
de aprendizaje, integrando distintos recursos, participantes y actividades.
41
Figura 2.3.a. Recursos, participantes y actividades en las unidades de aprendizaje
derivadas del caso de estudio.
(c) UACata3
(b) UACata2
(a) UACata1
Repaso
Sitio Web
Evaluación
Test
ACTIVIDADES
Lectura
Articulo
Birra
Impartición
Clase Presencial
Visionado
Video
Lectura
Articulo Bebo
Examen
Sitio Web
Evaluación
Trabajo
Realización
Trabajo
Repaso
Libro
Corbinus
Realización
Test
Lectura
Libro
Corbinus
Debate
Repaso
Artículo
Birra
Revisión y
Mejora del
Trabajo
Consulta
Resultados
Consulta
Resultados
Repesca
Re-evaluación
Trabajo
PARTICIPANTES
Profesor
Alumnos
Antiguos
Alumnos
test.zip
birra.pdf bebo.pdf
www.
lacatadelvinotinto.
Servidor
org
Archivos Tablón
RECURSOS
bacus.avi
Chat
libroCorbinus.pdf
Efectivamente:
§
En el escenario 1 surge una unidad de aprendizaje (UACata1)
caracterizada por los siguientes componentes − Figura 2.3.a (a):
-
Recursos: Los recursos incluyen todos los contenidos digitales
utilizados por Corbinus en la articulación de las actividades
complementarias: el vídeo con la charla del Prof. Bacus, el artículo de
Giorgio Birra (v.g. contenido en un archivo PDF), el estudio de la Profª.
Bebo (otro PDF) e incluso la propia web www.lacatadelvinotinto.org. Del
mismo modo, también es necesario incluir recursos adicionales en
forma de herramientas telemáticas de soporte al proceso: un chat que
permita articular el debate entre los alumnos de nueva promoción y los
alumnos de promociones anteriores, un servidor de archivos en el que
los alumnos puedan depositar sus trabajos para que estos puedan ser
42
corregidos por Corbinus y un tablón de notas en el que Corbinus
publicará los resultados.
§
§
-
Participantes: El propio Corbinus, los alumnos de nueva promoción y
los alumnos de promociones anteriores.
-
Actividades: Impartición de la clase presencial, Visionado del vídeo de
Bacus, Lectura del artículo de Birra, Lectura del artículo de Bebo,
Examen del sitio web, Debate, Realización del Trabajo, Evaluación del
Trabajo y Consulta Resultados.
En el escenario 2 la unidad de aprendizaje anterior se extiende con nuevos
recursos y actividades, para dar lugar a la Unidad de Aprendizaje UACata2
− Figura 2.3.a (b):
-
Recursos: Todos los de UACata1. Se incluye además el test previo a
las actividades complementarias (codificado en la especificación de
representación de exámenes IMS QTI: ver IMS QTI, 2006), así como el
libro de Corbinus (un PDF).
-
Participantes: Los mismos que en UACata1.
-
Actividades: Todas las de UACata1. Además se añaden las siguientes:
Realización de Test, Evaluación de Test, Lectura del libro de Corbinus,
Repaso del libro de Corbinus, Repaso del Artículo de Birra, Repaso del
material del sitio web, Revisión y Mejora del Trabajo, Revaluación del
Trabajo y Consulta Resultados Repesca.
Los componentes de la unidad de aprendizaje que surge en el escenario 3
(UACata3) son los mismos que los de la unidad de aprendizaje UACata2 −
Figura 2.3.a (c).
Es importante notar que la especificación de los componentes no es suficiente para
caracterizar completamente una Unidad de Aprendizaje. Efectivamente, también es
preciso especificar la forma en la que dichos componentes interactúan entre sí durante
el proceso educativo. O, lo que es lo mismo, diseñar el método pedagógico seguido en
cada unidad de aprendizaje. En el caso de estudio, el método seguido en cada unidad
de aprendizaje queda capturado a grosso modo en las narraciones de cada uno de los
escenarios y supone, en gran medida, decidir qué participantes llevan a cabo qué
actividades, así como el orden de realización de dichas actividades:
§
Método seguido en la unidad UACata1 − Figura 2.3.b (a): Corbinus lleva a
cabo la Impartición de la Clase Presencial. Una vez finalizada dicha clase,
los alumnos deben llevar a cabo el Visionado del vídeo de Bacus, la Lectura
del artículo de Birra y la Lectura del artículo de Bebo (el orden es
indiferente). Seguidamente los alumnos deben realizar el Examen del sitio
web. A continuación, los alumnos participan junto con los de las
promociones anteriores en el Debate (aquí Corbinus puede jugar el papel
de moderador). Una vez finalizado el debate, los alumnos proceden a la
Realización del Trabajo. Pasada la fecha de entrega, Corbinus lleva a cabo
la Evaluación del Trabajo. Finalizada esta evaluación, los alumnos pueden
consultar los resultados.
43
§
Método seguido en la unidad UACata2 − Figura 2.3.b (b): Lo mismo que en
la unidad UACata1, Corbinus lleva a cabo la Impartición de la Clase
Presencial. Una vez finalizada dicha clase, los alumnos llevan a cabo la
Realización del Test y Corbinus la Evaluación del Test. Si la nota obtenida
en el test es menor que 5, el alumno debe llevar a cabo la Lectura del libro
de Corbinus antes de pasar a realizar el resto de actividades (visionado del
vídeo, lectura de artículo e informe, etc). Si no, puede pasar a realizar
directamente dichas actividades. Asimismo, una vez corregido el trabajo, si
la nota obtenida en el mismo es menor que 5, el alumno debe llevar a cabo
el Repaso del libro de Corbinus, el Repaso del Artículo de Birra, el Repaso
del material del sitio web así como la Revisión y Mejora del Trabajo. Por su
parte, Corbinus deberá llevar a cabo la Revaluación del Trabajo. Finalizada
la revaluación, los alumnos pueden consultar los resultados.
§
Método seguido en la unidad UACata3 − Figura 2.3.b (c): Idéntico al
seguido en la unidad UACata2, salvo que ahora, cuando el alumno finaliza
el trabajo notifica este hecho a Corbinus, lo que evita que éste tenga que
estar mirando de vez en cuando el espacio de archivos compartidos.
44
Figura 2.3.b. Métodos pedagógicos asociados con las unidades derivadas del caso
de estudio.
(a)
Lectura
Articulo
Birra
Impartición
Clase Presencial
Visionado
Video
Profesor
Alumno
Todos los
alumnos
Todos los alumnos
antiguos
Lectura
Articulo Bebo
Examen
Sitio Web
Debate
Realización
Trabajo
Consulta
resultados
Evaluación
Trabajo
Nota < 5
(b)
Realización
Test
Impartición
Clase Presencial
Evaluación
Test
Lectura Libro
Corbinus
Consulta
resultados
Nota ≥5
Lectura
Articulo
Birra
Visionado
Video
Examen
Sitio Web
Debate
Realización
Trabajo
Evaluación
Trabajo
Lectura
Articulo Bebo
Nota < 5
Re-evaluación
Trabajo
Revisión y
Mejora del
Trabajo
Consulta
Resultados
Repesca
(c)
Realización
Trabajo
Revisión y
Mejora del
Trabajo
45
Repaso
Libro
Corbinus
Repaso
Sitio Web
Repaso
Artículo
Birra
IMS LD permite formalizar de manera rigurosa la estructura y el método pedagógico de
las unidades de aprendizaje, de manera que el diseño educativo resultante pueda ser
interpretado por un programa informático apropiado (un reproductor de IMS LD),
haciendo posible, por tanto, la automatización del proceso educativo. Las siguientes
secciones proporcionan más detalle sobre dicho proceso de formalización.
2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES
Desde un punto de vista técnico, las unidades de aprendizaje pueden representarse
como paquetes IMS, siguiendo la especificación IMS Content Packaging (IMS CP).
Esta especificación se organiza en niveles de complejidad creciente, cada uno de los
cuáles permite expresar diseños educativos más sofisticados. A continuación se
analizan estos aspectos de empaquetado y de organización en niveles.
2.4.1. IMS Content Packaging e IMS LD
Tal y como se detalla en (Fernández-Manjón et al., 2007), la especificación IMS CP
dicta la forma de encapsular contenidos educativos interrelacionados en piezas de
información denominadas “paquetes”. En la Figura 2.4.1.a (a) se muestra la estructura
de alto nivel de un paquete IMS.
46
Figura 2.4.1.a. En la parte (a) se muestra el esquema de la estructura de un
paquete IMS;En la parte (b) se muestra una unidad de aprendizaje representada
como un paquete IMS: es un paquete en el que la organización está descrita de
acuerdo con la especificación IMS LD.
(a)
(b)
Organizaciones
Subpaquetes
Recursos
Archivos
internos
Archivos
externos
47
Diseño educativo
expresado en IMS LD
Figura 2.4.1.b. Esbozo del paquete IMS asociado con la unidad UACata1.
Diseño educativo descrito en IMS
LD
rbacus
bacus.avi
rbirra
rweb
rbebo
birra.pdf bebo.pdf
www.lacatadelvinotintotinto.org
Otros archivos
Otros archivos externos
Tal y como se esquematiza en la Figura:
§
El paquete puede involucrar archivos internos y archivos externos. Los
archivos internos son archivos digitales que forman parte del paquete y
pueden estar físicamente organizados en carpetas. En el caso de estudio,
el vídeo, los artículos, el libro, el examen tipo test son todos ellos archivos
internos. Los archivos externos, por su parte, 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, el sitio web
puede considerarse un archivo externo.
§
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”. En el caso de estudio los recursos se
corresponden directamente con archivos. No obstante, existen otros casos
en los que es conveniente agrupar varios archivos interrelacionados en un
único recurso. Un ejemplo típico es el de una página HTML. Dicha página
constará, por una parte, de un archivo HTML pero también de todos
aquellos elementos referidos desde la página (v.g. imágenes). En este
caso, el recurso en sí es toda una colección de archivos: el archivo HTML
(que será el archivo primario) y los archivos asociados con todos los
elementos referidos desde el mismo (que serán los archivos secundarios).
A modo de ejemplo, si Corbinus hubiera ofertado su libro en formato HTML,
probablemente tendría que haber considerado una colección de archivos en
48
el recurso asociado con dicho libro (el texto HTML en sí y todos los
elementos multimedia referidos desde el mismo).
§
Los archivos externos están asociados con recursos externos. En el caso
de estudio, el sitio web dará lugar a un recurso externo.
§
Los recursos pueden, a su vez, organizarse siguiendo un determinado
convenio a efectos de su presentación, dando lugar a distintas
organizaciones.
§
Por último, el paquete puede incluir, además, otros subpaquetes con la
misma estructura descrita.
La conexión entre IMS CP e IMS LD se lleva a cabo a través de las organizaciones.
Efectivamente, IMS LD permite sustituir el formalismo descriptivo de organizaciones
básico introducido por IMS CP (que, a grandes rasgos, se reduce a organizar
jerárquicamente los contenidos) con un formalismo de diseño pedagógico mucho más
rico y sofisticado. De hecho, desde el punto de vista de IMS LD, un paquete IMS
puede considerarse como una unidad de aprendizaje si y sólo si incluye una
descripción en IMS LD en la parte de organizaciones del paquete − Figura 2.4.1.a (b).
A modo de ejemplo, en la Figura 2.4.1.b se esboza el encapsulado de la unidad
UACata1 como un paquete IMS. Para mayor detalle sobre la especificación IMS CP
puede consultarse (IMS CP, 2004).
2.4.2. Niveles en la Especificación
La especificación IMS LD se estructura en tres niveles de complejidad creciente. Cada
nivel se construye sobre el anterior, añadiendo al mismo nuevas características que
pueden utilizarse para expresar diseños educativos más sofisticados. En concreto:
§
El nivel A de la especificación introduce los principales elementos
estructurales (recursos y servicios, participantes -roles-, actividades, etc.) y
dinámicos (aquellos correspondientes al método pedagógico) de IMS LD.
No obstante, este nivel no permite describir métodos pedagógicos cuyo
comportamiento varía dependiendo de la propia ejecución de dichos
métodos. Efectivamente, los métodos pedagógicos que pueden ser
descritos a nivel A se ejecutarán siempre de la misma manera. Esto
permite, por ejemplo, modelar el diseño educativo que surge en el
escenario A del caso de estudio (unidad UACata1), pero no así los que
surgen en los escenarios B y C (en los cuáles la ejecución depende de
resultados dinámicos tales como la puntuación obtenida por los
participantes en el examen y en el trabajo).
§
El nivel B de la especificación introduce un mecanismo sencillo que permite
representar el estado de la ejecución del método pedagógico: las
propiedades. Los valores de las propiedades pueden modificarse durante la
reproducción de la unidad de aprendizaje. Del mismo modo, el nivel B
permite expresar condiciones sobre los valores de las propiedades,
condiciones cuya verdad o falsedad puede provocar la visibilidad o
invisibilidad de nuevas actividades y, por tanto, la adaptación del flujo de
aprendizaje a las necesidades de cada participante. El nivel B permite, por
49
ejemplo, representar el diseño pedagógico que surge en el escenario B del
caso de estudio (unidad UACata2), manteniendo propiedades que
almacenen los resultados de las evaluaciones y utilizando dichos valores en
condiciones que permitan determinar qué actividades deben proponerse a
continuación.
§
El nivel C, por último, introduce un mecanismo de notificación que ofrece
paradigmas alternativos para controlar el flujo de aprendizaje. Utilizando
este mecanismo de nivel C es posible, por ejemplo, modelar fácilmente el
diseño educativo asociado con la unidad de aprendizaje del escenario C
(unidad UACata3).
Las siguientes secciones analizan con más detalle cada uno de estos niveles.
2.5. EL NIVEL A
El nivel A de la especificación permite describir diseños educativos no adaptativos, en
el sentido de que el método pedagógico siempre exhibirá el mismo comportamiento,
independientemente del resultado de las distintas actividades. No obstante, en este
nivel se introducen los principales constructores del lenguaje. A continuación se
analizan las principales características de este nivel. La sección termina ejemplificando
el uso de estas características mediante el modelado de la unidad de aprendizaje
UACata1.
2.5.1. Estructura de alto nivel de un Diseño Educativo
La Figura 2.5.1.a esquematiza la estructura de alto nivel de la especificación de un
diseño educativo de nivel A.
Figura 2.5.1.a. Estructura de un diseño educativo de nivel A
.
0..1
0..1
Diseño educativo
0..1
1
Título
Objetivos de Aprendizaje
Prerequisitos
Componentes
1
Método
0..1
50
Metadatos
De acuerdo con esta figura, la especificación del diseño consta de:
§
Un título opcional que describe brevemente el diseño educativo y que
puede utilizarse, a efectos informativos, durante la inspección de alto nivel
de la unidad de aprendizaje.
§
Opcionalmente, los objetivos de aprendizaje de la unidad asociada con el
diseño. Estos objetivos hacen referencia a los logros de aprendizaje que se
espera que consigan los distintos alumnos que cursen la unidad. Es
importante indicar que IMS LD no proporciona mecanismos específicos
para formalizar dichos objetivos. Este elemento de información permite
únicamente referir a un recurso que contendrá una descripción (informal o
formal) de tales objetivos. De hecho, en el caso más simple los objetivos
harán referencia a recursos que expliquen textualmente dichos objetivos.
Por ejemplo, en nuestro caso de estudio Corbinus podría preparar un
recurso adicional (v.g. un archivo PDF) en el que planteara los objetivos
generales del seminario. IMS también ha propuesto otras especificaciones
alternativas para la descripción de tales objetivos como, por ejemplo, IMS
RDCEO (Reusable Definition of Compentency or Educational Objectives –
veáse IMS RCDEO, 2002 y también el capítulo sobre RDCEO en este
informe).
§
Opcionalmente, los prerrequisitos necesarios para cursar la unidad. De
nuevo debe indicarse que IMS LD no proporciona mecanismos específicos
para formalizar tales requisitos. El elemento de información permitirá
únicamente referir a un recurso (v.g. un archivo con un documento
apropiado) que describa dichos requisitos. Si se desea un grado mayor de
formalización, puede utilizarse también IMS RDCEO para este propósito.
§
Los componentes del diseño educativo. Dichos componentes enumeran
los participantes, las actividades y los materiales involucrados en el proceso
de aprendizaje.
§
El método pedagógico que se sigue en la unidad de aprendizaje. Esta
característica (la posibilidad de formalizar explícitamente el método más
apropiado para cada unidad / escenario de aprendizaje) es uno de los
elementos distintivos de IMS LD y suele calificarse normalmente de
neutralidad pedagógica. Efectivamente, IMS LD no se compromete con
ninguna pedagogía concreta, sino que se sitúa al metanivel, permitiendo a
los diseñadores describir la pedagogía más apropiada para cada dominio /
aplicación.
§
Los metadatos son un componente esencial de cualquier material
educativo informatizado con mínimas aspiraciones de permitir su
descubrimiento y reutilización por terceros. Dichos metadatos son
información adicional que se añade a los contenidos y que describen
distintas características semánticas de los mismos. En este caso se podría
describir quién ha codificado el diseño educativo, quién ha sido el último
revisor del mismo, cómo puede clasificarse el diseño educativo en una
taxonomía de diseños, etc. Para ello, la especificación permite utilizar
cualquier convenio de descripción de metadatos (por ejemplo la Norma
española UNE 71361:2010 Perfil de Aplicación LOM-ES v1.0), aunque
51
recomienda el uso de la especificación Learning Object Metadata (LOM)
para tal fin. Para una descripción detallada de LOM puede consultarse
(IEEE LOM, 2002; IMS META, 2006; Fernández-Manjón et al., 2007).
Además, como se verá a lo largo de este capítulo, existen otros muchos
lugares de la especificación donde pueden utilizarse metadatos.
La diferencia entre componentes y método es esencial para entender la estructura
formal de un diseño educativo. En palabras de la propia especificación, esta diferencia
es la misma que existe en una receta de cocina entre la lista de ingredientes (los
componentes) y la descripción de los pasos que hay que seguir para preparar el plato
(el método). Para aquellos lectores con conocimientos de programación, una analogía
útil puede ser considerar la sección de componentes como la sección de declaraciones
y la sección de método como la sección de instrucciones.
2.5.2. Descripción de los Componentes: Roles, Actividades y Entornos
La Figura 2.5.2.a muestra la estructura de la especificación de los componentes del
diseño educativo. Dicha Figura introduce también la terminología utilizada en IMS LD
en relación con los participantes (en IMS LD: roles) y con los contenidos y servicios
utilizados en las actividades (en IMS LD: entornos).
Figura 2.5.2.a. Estructura de la especificación de los componentes.
1
Componentes
0..1
0..1
Roles
Actividades
Entornos
En la Figura 2.5.2.b se esquematiza la estructura de la especificación de los roles. Tal
y como muestra dicha figura, IMS LD introduce dos tipos predefinidos de roles:
aprendiz y plantilla (en inglés, staff). Cada rol puede, a su vez, especializarse en
nuevos subroles, tal y como indican los ciclos introducidos en la Figura 2.5.2.b. Por
ejemplo, en nuestro caso de estudio el rol aprendiz se especializará en el subrol
alumno de nueva promoción y alumno de promociones antiguas, mientras que el rol
plantilla se especializará en el subrol profesor del seminario − Figura 2.5.2.c (a).
52
Figura 2.5.2.b. Estructura de la especificación de los roles.
0..1
0..∞
Aprendiz
0..1
Título
Información
0..∞
0..1
Metadatos
Roles
0..1
0..∞
Plantilla
0..1
Título
Información
0..∞
0..1
Metadatos
Figura 2.5.2.c. (a) Roles en el caso de estudio; (b) hipotética asignación de usuario
a roles durante la ejecución de la unidad de aprendizaje.
(a)
(b)
Aprendiz
Alumno de nueva promoción <agregar>
José Botella
Ana Brandy
Pedro Rioja
Alumno de promociones antiguas <agregar>
Anselmo Cacique
María Valdepeñas
Profesor del Seminario <agregar>
Corbinus Bodeguero
Alumno de
promociones
antiguas
Alumno de nueva
promoción
Plantilla
Profesor del
Seminario
Es importante señalar que los roles no introducen participantes concretos, sino tipos
de participantes. Por ejemplo, supongamos que José Botella es un alumno de nueva
promoción matriculado en el curso de Corbinus. El rol, identificado en tiempo de
diseño, será alumno de nueva promoción. Por su parte, José Botella será un usuario
concreto de la unidad de aprendizaje, asignado al rol alumno de nueva promoción. En
general cada rol podrá tener asignados múltiples usuarios en tiempo de ejecución,
aunque, por supuesto, también pueden concebirse roles que tengan asignados un
53
único usuario (v.g. Corbinus es el único usuario asignado al rol profesor del seminario).
Qué usuarios están asignados a qué roles es un aspecto que no se describe en el
diseño educativo (es decir, no se describe usando IMS LD), sino que se decide
posteriormente, en tiempo de explotación, administración y ejecución de la unidad de
aprendizaje −por ejemplo, mediante una herramienta de administración que permite
asignar usuarios a roles, como se sugiere en la Figura 2.5.2.c (b). En lo que se refiere
al resto de los elementos de información en sí introducidos en la Figura 2.5.2.b, su
significado es directo:
§
Cada rol puede tener asociado un título descriptivo breve.
§
Asimismo, cada rol puede tener asociado un elemento de información, que
permite hacer referencia a recursos que describen de manera detallada
dicho rol. Por ejemplo, Corbinus podría usar esta característica para enlazar
documentos descriptivos de cada uno de los roles asociados con los
alumnos.
§
Por último, cada rol puede tener asociados metadatos. Entre las múltiples
posibilidades que ofrece esta característica puede pensarse en la
disposición de una biblioteca externa de roles y en la selección de dichos
roles en la biblioteca utilizando esta sección de metadatos (aunque, por
supuesto, estos usos no están ni deben estar normativizados en IMS LD).
Figura 2.5.2.d. Estructura de la especificación de las actividades. Las llaves quieren
decir que puede elegirse entre cualesquiera de los elementos de información que
agrupan.
Actividad de Aprendizaje
Actividades
Actividad de Soporte
1..∞
Actividad Estructurada
La estructura de las actividades se esquematiza en la Figura 2.5.2.d. Como puede
observarse en dicha Figura, se distinguen los siguientes tres tipos de actividades:
§
Actividades de aprendizaje: estas actividades deben ser realizadas
individualmente por cada participante, que logrará alcanzar ciertos objetivos
educativos mediante la realización de las mismas. Por ejemplo, en nuestro
caso de estudio, las actividades Lectura Artículo Birra y Realización Trabajo
son ejemplos de actividades de aprendizaje
§
Actividades de soporte: actividades que permiten a un rol proporcionar
algún tipo de soporte a otro rol. Un ejemplo típico son las actividades de
evaluación. Aquí, el profesor proporciona un soporte de evaluación a cada
uno de los miembros de un rol alumno. Por ejemplo, en nuestro caso de
estudio, la actividad Evaluación Trabajo es una actividad de soporte.
§
Actividades estructuradas: estas actividades permiten agrupar otras
actividades más simples. El resultado puede considerarse como una
54
actividad individual a efectos de su uso en el método pedagógico. En
nuestro caso de estudio, las actividades Lectura Artículo Birra, Visionado
Vídeo y Lectura Artículo Bebo pueden agruparse en una actividad
estructurada, ya que el grupo resultante se trata como un todo en la
especificación del método pedagógico. Estas actividades estructuradas
pueden, además, configurarse de dos formas diferentes:
-
En modo secuencia. Este modo indica que la realización de la actividad
estructurada supondrá realizar consecutivamente, una detrás de la otra,
las actividades constituyentes.
-
En modo selección. Este modo indica que el orden de realización de las
actividades componentes puede ser elegido por el usuario. En el caso
de la actividad estructurada puesta como ejemplo, tendrá sentido
configurar la misma en modo selección.
Figura 2.5.2.e. Estructura de la especificación de una actividad de aprendizaje.
0..1
0..1
0..1
0..∞
Titulo
Objetivos de Aprendizaje
Prerequisitos
Entorno (referencia)
Actividad de Aprendizaje
1
0..1
0..1
0..1
Descripción
Condición de Finalización
Acción tras la finalización
Metadatos
La Figura 2.5.2.e esquematiza la estructura de la descripción de una actividad de
aprendizaje. Los elementos de información explicitados en esta figura son:
§
Un breve título descriptivo opcional.
§
Opcionalmente, descripción de los objetivos de aprendizaje y de los
prerrequisitos de la actividad. La naturaleza de estos elementos es análoga
a la de los asociados con el diseño educativo global, aunque esta vez
referida a la actividad concreta.
§
Referencias a los distintos entornos que caracterizan los materiales
educativos y servicios requeridos por la actividad (más adelante se
ampliarán los detalles sobre estos componentes). Es importante notar que
los entornos en sí no se describen aquí, sino que en este campo se sitúan
55
únicamente referencias a los mismos. Esto permite reutilizar un mismo
entorno en múltiples actividades.
§
Descripción de la actividad. Referencias a recursos que describen la
actividad. Por ejemplo, en la actividad Visionado de Vídeo, aparte del
entorno conteniendo el material concreto a utilizar (v.g. el vídeo), Corbinus
podrá incluir una referencia a un recurso asociado con un PDF explicando
la actividad.
§
Descripción opcional sobre la forma de finalizar la actividad. En IMS LD una
actividad de aprendizaje se puede finalizar, bien porque así lo decida el
aprendiz (v.g. pulsando un botón de finalización asociado con la actividad
en el reproductor), bien porque se haya superado el tiempo límite asignado
por el diseñador educativo para su finalización. Es importante indicar que, si
no se especifica esta descripción, por defecto la actividad se asume
finalizada (es decir, la actividad estará finalizada desde el comienzo mismo
de la reproducción).
§
Descripción opcional de la acción a llevar a cabo una vez que se ha
completado la actividad. A nivel A dicha acción puede ser, únicamente,
mostrar un recurso proporcionando información de realimentación al
aprendiz. Por ejemplo, Corbinus podría utilizar esta opción en Visionado de
Vídeo para visualizar un texto resumen con los principales puntos
expuestos en el vídeo, una vez que dicho vídeo hubiera finalizado.
§
Un elemento con metadatos acerca de la actividad.
La estructura de la especificación de una actividad de soporte es, por su parte, similar
a la de una actividad de aprendizaje, tal y como se muestra en la Figura 2.5.2.f. La
principal diferencia es que en este tipo de actividades pueden identificarse
explícitamente los roles a los que se da soporte (rol soportado).
Figura 2.5.2.f. Estructura de la especificación de una actividad de soporte.
0..1
0..∞
0..1
0..1
Actividad de Soporte
0..∞
1
0..1
0..1
0..1
56
Titulo
Rol soportado (referencia)
Objetivos de Aprendizaje
Prerequisitos
Entorno (referencia)
Descripción
Condición de finalización
Acción tras la finalización
Metadatos
La Figura 2.5.2.g esboza cómo se especifica una actividad estructurada en IMS LD.
Los elementos de información involucrados son:
§
Título descriptivo opcional.
§
Referencia a recursos que describen la actividad. Al contrario que con el
elemento de descripción de una actividad simple, este elemento es opcional
(ya que, en última instancia, las actividades estructuradas podrán
entenderse descritas por sus actividades constituyentes). No obstante,
puede haber muchos casos donde desee puntualizarse mejor el propósito
de la actividad estructurada. Por ejemplo, Corbinus podría explicar que el
propósito de la actividad estructurada formada por Lectura Artículo Birra,
Visionado Vídeo y Lectura Artículo Bebo es clarificar una serie de
conceptos (v.g. la función de la papila gustativa en el proceso de la cata, y
la importancia del retrogusto frutal en la apreciación de la variedad de uva
Malvasía), a fin de guiar al alumno en la realización de las distintas
actividades constituyentes.
§
Referencia a los entornos necesarios para llevar a cabo esta actividad
estructurada. Por ejemplo, es posible referir un entorno con un vídeo o un
texto introductorios o preparatorios de / para la actividad, que puede ser
presentado al usuario antes de que éste aborde la consecución de las
actividades constituyentes.
§
Referencias a las actividades constituyentes. Nótese que dichas actividades
constituyentes pueden ser actividades de aprendizaje, actividades de
soporte, otras actividades estructuradas, e, incluso, otras unidades de
aprendizaje. De nuevo el uso de referencias permite reutilizar una misma
actividad en múltiples actividades estructuradas.
§
Metadatos asociados con la actividad.
Figura 2.5.2.g. Estructura de la especificación de una actividad estructurada.
0..1
Titulo
0..1
0..∞
Información
Entorno (referencia)
Actividad Estructurada
Actividad de aprendizaje (referencia)
1..∞
Actividad de soporte (referencia)
Unidad de aprendizaje (referencia)
Actividad estructurada (referencia)
0..1
Metadatos
57
La estructura de los entornos se esboza en la Figura 2.5.2.h. Como evidencia dicha
estructura, un entorno agrupa los recursos educativos necesarios para llevar a cabo
una actividad. IMS LD discrimina entre dos tipos básicos de recursos educativos:
§
Los objetos de aprendizaje. Recursos reproducibles y referenciables,
normalmente, aunque no necesariamente, digitales, que se utilizan en la
realización de una actividad. En nuestro caso de estudio, los artículos, el
libro o el vídeo son buenos ejemplos de este tipo de objetos. El elemento de
información en sí permitirá referir a tales recursos, que estarán disponibles
en el contexto de uso del diseño educativo (v.g. en el paquete IMS utilizado
para representar la unidad de aprendizaje). IMS LD contempla también la
extensión del lenguaje básico con otros sublenguajes que permitan
describir in situ tipos concretos de objetos de aprendizaje (v.g. descripción
de la estructura de un examen utilizando IMS QTI).
§
Los servicios. Herramientas y programas de soporte a las actividades de
aprendizaje. En nuestro caso, el Chat es un buen ejemplo de servicio.
Figura 2.5.2.h. Estructura de la especificación de los entornos.
0..1
Titulo
Objeto de Aprendizaje
Entornos
1..∞
0..∞
Entorno
Servicio
Entorno (referencia)
0..1
Metadatos
El cometido de los elementos de información en la Figura 2.5.2.h es directo:
§
Un título descriptivo opcional.
§
Los objetos de aprendizaje y los servicios.
§
La posibilidad de referir y reutilizar entornos previamente definidos.
§
Una sección de metadatos.
Merece la pena profundizar un poco más en la diferencia entre objeto de aprendizaje y
servicio. De nuevo podemos apelar aquí a criterios estrictamente formales.
Efectivamente, IMS LD concibe los objetos de aprendizaje como recursos que pueden
reproducirse de forma incontextual, independientemente del contexto particular de
cada ejecución. Por ejemplo, para visualizar una serie de archivos, únicamente es
necesario conocer el formato de dichos archivos y esto puede decidirse en tiempo de
58
diseño. Por su parte, los servicios requieren información del contexto de ejecución de
la unidad de aprendizaje para su correcta reproducción. Así, el envío de un correo
electrónico a todos los usuarios asignados a un determinado rol depende de los
usuarios concretos asociados con dicho rol y esto no se decide, como ya se ha dicho,
en tiempo de diseño, sino que es una característica que dependerá de la puesta en
marcha y la reproducción de la unidad de aprendizaje. IMS LD contempla la existencia
de distintos tipos de servicios. La Figura 2.5.2.i muestra la estructura de la
especificación de estos servicios en IMS LD.
Figura 2.5.2.i. Estructura de la especificación de los servicios.
Correo Electrónico
Conferencia
Servicio
Búsqueda
Otro servicio
Dicha figura incluye la posibilidad de configurar servicios de los siguientes tipos:
§
Servicio de correo electrónico. Su configuración permite identificar los
destinatarios del e-mail (un grupo de usuarios identificados por uno o varios
roles). Esta descripción se interpretará como una orden para invocar a un
servicio de correo electrónico que, previsiblemente, permitirá editar el
mensaje y dirigirlo a los destinatarios.
§
Servicio de conferencia. Este servicio permite articular conferencias
virtuales. Su configuración permite fijar los siguientes aspectos de uso del
servicio:
§
-
La lista de participantes. Cada participante se refiere a un rol.
-
La lista de observadores (usuarios que observan, pero que no pueden
participar). Cada observador se asocia con un rol.
-
El moderador de la conferencia. Una conferencia puede tener más de
un moderador. De hecho, los moderadores se identifican mediante
referencias a roles.
-
El administrador de la conferencia. Un administrador de conferencia
puede crear nuevas sub-conferencias (por ejemplo, asignando
dinámicamente subgrupos de usuarios a las mismas), así como destruir
dichas sub-conferencias. No puede, no obstante, destruir la conferencia
base (ésta será liberada automáticamente por el entorno de ejecución).
Servicio de búsqueda. Este servicio permite configurar un buscador que
actúa sobre la información contenida en la unidad de aprendizaje. Para ello
es posible acotar los fragmentos de la unidad de aprendizaje sobre los que
59
se realizará la búsqueda (es decir, definir los índices de la misma), así
como seleccionar el tipo de búsqueda que se llevará a cabo: por texto libre
o distintos estilos de búsqueda guiada.
Aparte de estos servicios, IMS LD ofrece un mecanismo de extensión que permite la
inclusión de nuevos servicios para cada escenario particular de aplicación. Por
ejemplo, los administradores de la infraestructura e-learning de Corbinus podrían
utilizar este mecanismo para incorporar los servicios de archivística y de publicación
de anuncios utilizados por Corbinus en sus diseños. No obstante, por motivos de
simplicidad no contemplaremos esta posibilidad, tratando como objetos de aprendizaje
todas aquellas herramientas telemáticas no incluidas por defecto como servicios.
2.5.3. Descripción del método educativo
IMS LD introduce una metáfora basada en una obra de teatro para la descripción de
los métodos educativos. De esta forma, la descripción de uno de estos métodos se
equipara a la descripción de la estructura de una obra que consta de un guión (o
incluso de varios guiones alternativos). El guión se estructura, a su vez, en una
secuencia de actos. Cada acto se caracteriza, por último, por un conjunto de
actuaciones. Cada actuación consiste en la realización de una actividad por parte de
un rol. La dinámica resultante de esta metáfora supone la ejecución simultánea de
todos los guiones, la ejecución en secuencia de cada acto dentro de cada guión y la
ejecución simultánea de todas las actuaciones dentro de cada acto.
Figura 2.5.3.a. Estructura de la especificación de un método.
1..∞
Metodo
0..1
0..1
Guión
Condición de finalización
Acción tras finalización
La Figura 2.5.3.a esquematiza la estructura de la descripción de un método. Dicha
descripción se ajusta a la metáfora teatral e incluye:
§
Uno o más guiones.
§
Una condición que dicta la finalización de la ejecución del método. Dicha
condición puede ser: (i) la finalización de uno de los guiones o (ii) la
superación de un tiempo límite. Es importante notar que, si esta condición
no se especifica, se asume que el método está finalizado.
§
Una acción a realizar una vez que dicho método ha finalizado. En el nivel A
dicha acción puede consistir únicamente en proporcionar material de
realimentación al usuario.
La Figura 2.5.3.b muestra la estructura de la descripción de un guión. Dicha estructura
contempla la existencia de:
60
§
Un título opcional.
§
Uno o más actos.
§
Opcionalmente, una condición de finalización del guión. Dicha condición
puede ser: (i) la finalización del último acto del guión o (ii) la superación de
un tiempo límite. Es importante señalar que si esta condición no se
especifica, se asume que el guión está finalizado.
§
Opcionalmente, una acción a realizar tras la finalización del guión. En el
nivel A, dicha acción consiste, al igual que en otras situaciones, en
proporcionar realimentación al usuario.
§
Un cuerpo opcional de metadatos.
Figura 2.5.3.b. Estructura de la especificación de un guión.
0..1
1..∞
Guión
0..1
0..1
0..1
Título
Acto
Condición de finalización
Acción tras finalización
Metadatos
Figura 2.5.3.c. Estructura de la especificación de un acto.
0..1
1..∞
Acto
0..1
0..1
0..1
Título
Actuación
Condición de finalización
Acción tras finalización
Metadatos
La Figura 2.5.3.c muestra la estructura de la descripción de un acto. Dicha descripción
incluye:
§
Un título opcional.
§
Una o más actuaciones.
61
§
Opcionalmente, una condición de finalización. Dicha condición puede ser:
(i) la finalización de una actuación o (ii) la superación de un tiempo límite. Si
esta condición no se especifica, se asume que el acto habrá finalizado.
§
Opcionalmente, una acción de finalización (a nivel A, mostrar información
de realimentación al usuario).
Figura 2.5.3.d. Estructura de la especificación de una actuación.
0..1
Título
rol (referencia)
Actuación
actividad (referencia)
0..1
Metadatos
Por último, la Figura 2.5.3.d muestra cómo se describe una actuación. Básicamente
dicha descripción consiste en referir el rol involucrado, así como la actividad
involucrada. Una restricción importante impuesta por IMS LD es que en un mismo acto
cada rol puede participar, a lo sumo, en una actuación. Las actividades estructuradas
constituyen, de esta forma, un mecanismo fundamental para agrupar actividades más
simples en una única, a fin de que todas ellas puedan ser llevadas a cabo por un rol en
un acto.
2.5.4. Modelo de Ejecución
Una vez introducidos los componentes de modelado, es interesante reflexionar sobre
el modelo de ejecución de los métodos. Un aspecto relevante para entender este
modelo es el aceptar que cada usuario tendrá una vista diferente de la ejecución, que
dependerá del rol al que dicho usuario esté asignado, o, dicho de otra forma, su propia
vista de la obra. Efectivamente:
§
El usuario verá únicamente aquellas actividades asociadas a las
actuaciones en las que interviene su rol.
§
Asimismo, las actuaciones serán llevadas a cabo por cada uno de los
miembros de un rol.
§
La forma de sincronizar las actuaciones de los distintos usuarios es
mediante los actos, ya que es posible hacer depender la finalización de un
acto de la finalización de una actuación. De esta forma, el acto no finalizará
hasta que no finalicen sus actuaciones todos los usuarios que juegan el
papel especificado en la actuación.
Otro aspecto importante a tener en cuenta es el relativo al secuenciamiento de las
actividades en el interior de los actos. Efectivamente, dicho secuenciamiento no se
62
decide a nivel de acto, sino que debe especificarse a nivel de actividad, mediante la
creación de actividades estructuradas adecuadas.
2.5.5. Ejemplo de Diseño de Nivel A
En este apartado se esboza el diseño educativo de la unidad de aprendizaje UACata1,
utilizando para ello características de nivel A de IMS LD. A fin de simplificar el
desarrollo, se omiten muchas de las características opcionales, características que se
podrían incluir en sucesivas revisiones y mejoras del diseño.
Figura 2.5.5.a. Fragmento de diseño con roles.
Roles
..Aprendiz
....Título: Alumno de nueva promoción
..Aprendiz
....Título: Alumno de promociones antiguas
..Plantilla
....Título: Profesor del seminario
El fragmento de diseño esbozado en la Figura 2.5.5.a muestra el diseño de los tres
roles (los dos roles de tipo aprendiz: Alumno de nueva generación y Alumno de
promociones antiguas, y el rol de tipo plantilla: Profesor de Seminario).
El diseño de los entornos para las actividades se muestra en la Figura 2.5.5.b Este
fragmento de diseño esboza los siguientes entornos:
§
El entorno Artículo Birra, que refiere al artículo del Profesor Birra.
§
El entorno Artículo Bebo, que hace referencia al artículo de la Profesora
Bebo.
§
El entorno Vídeo Bacus, que hace referencia al vídeo con la charla del
Profesor Bacus.
§
El entorno Sitio Web,
www.lacatadelvinotinto.org.
§
El entorno Servicio Debate, que configura un servicio de conferencia a fin
de articular el debate.
§
El entorno Espacio de Archivos, que hace referencia a una URL que da
paso a un servidor de archivos (se asume que dicha URL está asociada con
el recurso archivos). Se supone que en la página accesible vía esta URL se
pedirá el nombre y la contraseña del usuario concreto. Esto permite
concebir el recurso como un objeto de aprendizaje, en lugar de cómo un
servicio.
§
El entorno Tablón, que hace referencia a una URL que permite consultar /
editar un tablón de notas (recurso rtablon). Al igual que en el caso anterior,
se supone que en la página correspondiente se pedirán los datos del
usuario, lo que permite usar el recurso como un objeto de aprendizaje en
lugar de como un servicio.
que
63
hace
referencia
al
sitio
web
Figura 2.5.5.b. Fragmento de diseño con la descripción de los entornos.
Entornos
..Entorno
....Título: Artículo Birra
....Objeto de Aprendizaje:
<referencia a recurso rbirra>
..Entorno
....Título: Artículo Bebo
....Objeto de Aprendizaje: <referencia a recurso rbebo>
..Entorno
....Título: Video Bacus
....Objeto de Aprendizaje:
<referencia a recurso rbacus>
..Entorno
....Título: Sitio web
....Objeto de Aprendizaje:
<referencia a recurso rweb>
..Entorno
....Título: Servicio Debate
....Servicio
......Conferencia: Participantes:
<referencia a rol alumno de nueva promoción>
<referencia a rol alumno de promociones antiguas>
Moderador:
<referencia a rol profesor del seminario>
..Entorno:
....Título: Espacio de Archivos
....Objeto de Aprendizaje: <referencia a recurso rarchivos>
..Entorno:
....Título: Tablón
....Objeto de Aprendizaje:
<referencia a recurso rtablón>
La Figura 2.5.5.c esquematiza el diseño de las actividades. Nótese que cada actividad
hace referencia a un entorno apropiado, así como a un recurso que la describe (por
simplicidad estos recursos no se listaron en la Figura 2.4.1.b). Más concretamente, se
incluyen las siguientes actividades de aprendizaje:
§
La actividad Lectura Artículo Birra hace referencia al entorno Artículo Birra.
También hace referencia al recurso rdalectartbirra, que estará asociado con
una descripción de esta actividad.
§
Las actividades Lectura Artículo Bebo y Visionado Vídeo son análogas. Los
entornos referidos son, respectivamente, Artículo Bebo y Vídeo Bacus,
mientras que los recursos descriptivos referidos son, respectivamente,
rdalectartbebo y rdavisvideo.
§
Las actividades Examen sitio web, Realización trabajo y Consulta
Resultados, por su parte, refieren a los entornos asociados con los recursos
web externos correspondientes al sitio web (Sitio Web), al punto de entrada
al servidor de archivos (Espacio de Archivos) y al punto de entrada al tablón
de resultados (Tablón). Los recursos descriptivos son, respectivamente,
rdaexweb, rdarealtrabajo y rdaconresultados.
§
La actividad Debate, que representa el debate mantenido entre alumnos de
nueva promoción y alumnos de promociones antiguas. En la descripción de
64
dicha actividad se refiere al entorno que configura el servicio de conferencia
para llevar a cabo el debate.
§
La actividad Impartición Clase Presencial. El propósito de esta actividad es
únicamente que, una vez impartida dicha clase, Corbinus pueda indicar la
misma como finalizada, dando lugar a la parte on-line del diseño educativo.
Nótese que esta actividad no involucra entorno alguno ya que, desde un
punto de vista meramente operacional, su función es ofrecer únicamente el
botón de arranque del proceso.
65
Figura 2.5.5.c. Fragmento de diseño con la descripción de las actividades.
Actividades
..Actividad de Aprendizaje
....Título: Lectura Artículo Birra
....Entorno: <referencia a entorno Artículo Birra>
....Descripción: <referencia a recurso rdalectartbirra>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Lectura Artículo Bebo
....Entorno: <referencia a entorno Artículo Bebo>
....Descripción: <referencia a recurso rdalectartbebo>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Visionado Video
....Entorno: <referencia a entorno Video Bacus>
....Descripción: <referencia a recurso rdavisvideo>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Examen sitio web
....Entorno: <referencia a entorno Sitio Web>
....Descripción: <referencia a recurso rdexweb>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Realización Trabajo
....Entorno: <referencia a entorno Espacio de Archivos>
....Descripción: <referencia a recurso rdrealtrabajo>
....Condición de finalización: una vez transcurrida una semana
..Actividad de Aprendizaje
....Título: Consulta Resultados
....Entorno: <referencia a entorno Tablón>
....Descripción: <referencia a recurso rdaconresultados>
....Condición de finalización: finalizada por el usuario
..Actividad de Aprendizaje
....Título: Debate
......Entorno: <referencia a entorno Debate>
......Descripción: <referencia a recurso rdadebate>
......Condición de finalización: una vez transcurridas dos horas
..Actividad de Aprendizaje
....Título: Impartición Clase Presencial
....Descripción: <referencia a recurso rdaimpclase>
....Condición de finalización: finalizada por el usuario
..Actividad de Soporte
....Título: Corrección de Trabajo
....Rol soportado: <referencia a Alumno de nueva promoción>
....Entorno: <referencia a entorno Espacio de Archivos>
....Entorno: <referencia a entorno Tablón>
....Condición de finalización: finalizada por el usuario
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3)
....Título: Examen materiales
....Actividad de aprendizaje (referencia): Lectura Artículo Bebo
....Actividad de aprendizaje (referencia): Lectura Artículo Birra
....Actividad de aprendizaje (referencia): Visionado Video
..Actividad Estructurada (tipo secuencia)
....Título: Autoaprendizaje
....Actividad estructurada (referencia): Examen materiales
....Actividad de aprendizaje (referencia): Examen sitio web
66
Figura 2.5.5.d. Fragmento de diseño con la descripción del método pedagógico.
Método
..Guión
....Acto
......Título: clase presencial
.......Actuación
.........Título: Actuación impartición
.........Rol(referencia): <referencia a Profesor del Seminario>
.........Actividad(referencia): <referencia a Impartición clase presencial>
.......Actuación
.........Título: Actuación asistencia
.........Rol(referencia): <referencia a Alumnos de nueva promoción>
.........Actividad(referencia): <referencia a Impartición clase presencial>
......Condición de finalización: <finalizada Actuación impartición>
....Acto
......Título: período autoaprendizaje
......Actuación
........Título: Actuación autoaprendizaje
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Autoaprendizaje>
......Condición de finalización: <finalizada Actuación autoaprendizaje>
....Acto
......Título: discusión
......Actuación
........Título: Actuación debate alumno nuevo
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Debate>
......Actuación
........Título: Actuación debate alumno antiguo
........Actividad(referencia): <referencia a Debate>
........Rol(referencia): <referencia a Alumno de promociones antiguas>
......Actuación
........Título: Actuación debate profesor
........Rol(referencia): <referencia a Profesor del seminario>
........Actividad(referencia): <referencia a Debate>
......Condición de finalización: <finalizada Actuación debate profesor>
....Acto
......Título: trabajo
......Actuación
........Título: Actuación trabajo
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Realización Trabajo>
......Condición de finalización: <finalizada Actuación trabajo>
....Acto
......Título: evaluación
......Actuación
........Título: Actuación evaluación
........Rol(referencia): <referencia a Profesor del seminario>
........Actividad(referencia): <referencia a Corrección de Trabajo>
......Condición de finalización: <finalizada Actuación evaluación>
....Acto
......Título: resultados
......Actuación
........Título: Actuación resultados
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Consulta resultados>
......Condición de finalización: <finalizada Actuación resultados>
....Condición de finalización: finalizado último acto
67
El diseño incluye, además, la actividad de soporte Evaluación de Trabajo. El papel
soportado es el de los alumnos de nueva promoción. De esta forma, quien realice esta
actividad deberá notificar, de alguna manera que dependerá del entorno de ejecución,
que cada uno de los alumnos de nueva promoción han sido atendidos antes de que el
entorno de ejecución decida que la actividad ha sido completada. La actividad en sí
requiere tanto el espacio de archivos (donde Corbinus podrá encontrar los trabajos)
como el tablón de anuncios (donde podrá publicar los resultados). Nótese, asimismo,
cómo distintas actividades pueden compartir los mismos entornos.
Para finalizar, se incluyen también las siguientes actividades estructuradas:
§
Las actividades Lectura Artículo Birra, Visionado Vídeo y Lectura Artículo
Bebo se agrupan en Examen Materiales.
§
Por su parte, esta actividad se agrega con la actividad Examen sitio web
para dar lugar a la actividad estructurada Autoaprendizaje.
Esta estructuración permite situar todas estas actividades en un único acto en el
método que se esboza en la Figura 2.5.5.d. Los actos incluidos en el método son:
§
El acto clase presencial, que representa la impartición de la clase
presencial (en realidad, y tal y como se ha indicado, el efecto de este acto
será permitir decidir al profesor cuándo comenzar el proceso de aprendizaje
on-line representado en este diseño).
§
El acto periodo autoaprendizaje, que representa para el alumno el examen
de todo el material educativo proporcionado por el profesor.
§
El acto discusión, en el que se lleva a cabo el debate entre los alumnos de
nueva promoción y los antiguos alumnos. Nótese que en este acto se
incluye una actuación para cada uno de los roles involucrados, aunque
dichas actuaciones incluyan todas ellas la misma actividad Debate.
§
El acto trabajo, en el que el alumno realiza el trabajo.
§
El acto evaluación, en el que el profesor evalúa el trabajo.
§
El acto resultados, en el que el alumno consulta los resultados
2.6. EL NIVEL B
La ejecución de los diseños de nivel A está predeterminada por la estructura de los
propios diseños y no puede ser alterada como consecuencia de la realización de las
actividades. En muchas situaciones esta dinámica es bastante limitada, ya que no
permite explotar una de las principales ventajas de un escenario e-learning: la
personalización de los contenidos y de los intinerarios educativos a las necesidades de
cada participante en el proceso. Por ejemplo, en base al conocimiento previo del
alumno (que puede venir descrito externamente, en su información curricular o bien
puede determinarse durante el proceso, mediante algún tipo de evaluación previa) es
posible ofrecer material más básico o más avanzado, así como incluir u omitir
actividades. De hecho, en IMS LD nivel A es imposible modelar un escenario
68
educativo tradicional típico donde, si un alumno aprueba en Junio, aprueba la
asignatura, y si el alumno suspende, debe ir a Septiembre. En IMS LD este
comportamiento adaptativo de los métodos pedagógicos requiere el uso de facilidades
de nivel B. En esta sección se analizan dichas características. La sección termina
ejemplificando el uso de las mismas mediante el modelado de la unidad de
aprendizaje UACata2, donde los itinerarios de aprendizaje de cada alumno dependen
de su rendimiento en las evaluaciones realizadas y, por tanto, no pueden
predeterminarse completamente en tiempo de diseño.
2.6.1. Propiedades
IMS LD nivel B añade un nuevo tipo de componente educativo a los diseños: las
propiedades. Dichas propiedades almacenan información relevante que se produce
durante la ejecución del método educativo (v.g. puntuación del alumno en un test), o
bien que se extrae del contexto educativo donde dicho método se ejecuta (v.g. lista de
asignaturas que tiene aprobadas el alumno).
Las propiedades constituyen una representación explícita del contexto y estado de los
métodos pedagógicos. Su valor puede modificarse conforme avanza la ejecución para
reflejar dicho estado y puede utilizarse para decidir la forma de llevar a cabo dicha
ejecución. Desde un punto de vista informático, las propiedades son análogas a las
variables en un lenguaje informático de programación convencional.
Figura 2.6.1.a. El nivel B introduce las propiedades como nuevos componentes en
el diseño.
1
0..1
Componentes
Roles
Propiedades
0..1
Actividades
0..1
69
Entornos
Figura 2.6.1.b. Estructura de la especificación de las propiedades.
Propiedad local personal
Propiedad local de rol
Propiedades
1..∞
Propiedad local general
Propiedad global personal
Propiedad global general
La Figura 2.6.1.a ilustra la extensión de la descripción de los componentes de nivel A
para incorporar la descripción de las propiedades de un diseño. Nótese que dichas
propiedades pasan a ser componentes educativos de pleno derecho, situándose al
mismo nivel que roles, actividades y entornos. La Figura 2.6.1.b muestra, por su parte,
la estructura de la descripción de las propiedades. Este esbozo hace patente la
distinción de propiedades en distintas categorías. Una primera distinción hace
referencia a la localidad o la globalidad de las propiedades:
§
Las propiedades locales son aquéllas que se crean y se mantienen
únicamente dentro de cada ejecución de la unidad de aprendizaje.
§
Las propiedades globales son aquellas que se crean y se mantienen en el
entorno en el que se ejecutan las unidades de aprendizaje. El valor de
dichas propiedades sobrevivirá, por tanto, a las distintas ejecuciones y
prevalecerá entre ejecuciones de la misma unidad y/o de unidades
distintas.
Esta categorización puede refinarse como sigue:
§
§
Las propiedades locales pueden ser de tres tipos diferentes:
-
Propiedades locales personales: Propiedades cuyo valor puede ser
distinto para cada participante (por ejemplo, la nota obtenida en un
test).
-
Propiedades locales de rol: Propiedades cuyo valor es el mismo para
todos los miembros de un mismo rol, pero que puede variar entre
distintos roles (por ejemplo, el número de usuarios asignados al rol).
-
Propiedad local general: Propiedades cuyo valor es el mismo para
todos los participantes (por ejemplo, el tiempo transcurrido desde que
comenzó a ejecutarse la unidad).
Las propiedades globales pueden ser de los dos tipos siguientes:
-
Propiedad global personal: Propiedad global cuyo valor varía para cada
posible usuario (por ejemplo, el nombre de usuario en el sistema
70
informático en el que está instalada la infraestructura de ejecución de
IMS LD).
-
Propiedad global general: Propiedad global cuyo valor es el mismo para
todos los usuarios (por ejemplo, el nombre y la versión del sistema
operativo de la máquina en la que está instalada la infraestructura de
ejecución de IMS LD).
2.6.2. Expresiones
IMS LD nivel B incluye mecanismos para describir expresiones cuya evaluación da
lugar a valores. Ejemplos de este tipo de expresiones son el sumar una serie de
valores, comprobar si todos los valores de una serie son ciertos, comparar dos
valores, etc. Estas expresiones podrán utilizarse en contextos y constructores de más
alto nivel.
IMS LD introduce los formatos de expresiones que se esquematizan en la Figura
2.6.2.a y en la Figura 2.6.2.b. Más concretamente:
§
Expresión de tipo “es miembro de rol”, que será cierta cuando el usuario
pertenece al rol referido y falsa en otro caso.
§
Expresión “es”, que permite comprobar si dos valores son iguales. Aparte
de los entes tipificados como expresiones en IMS LD, también es posible
utilizar propiedades y valores literales como argumentos en esta expresión
(lo mismo ocurre con todas aquellas en las que se indica “operando” como
argumentos en la Figura 2.6.2.a; ver también Figura 2.6.2.b).
§
Expresión “no es”, que permite comprobar si dos valores son distintos.
§
Expresión “y”, que es cierta cuando lo son todos sus argumentos.
§
Expresión “o”, que es cierta cuando lo es alguno de sus argumentos.
§
Expresión “suma”, que suma todos sus argumentos1.
§
Expresión “resta”, que resta a su primer argumento el segundo.
§
Expresión “mul”, que multiplica el primer argumento por el segundo.
§
Expresión “div”, que divide el primer argumento entre el segundo.
§
Expresión “mayor que”, que permite comprobar si el valor del primer
argumento es mayor que el valor del segundo.
§
Expresión “menor que”, que permite comprobar si el valor del primer
argumento es menor que el valor del segundo.
§
Expresión “usuarios en rol”, que restringe la aplicabilidad de la expresión a
todos aquellos usuarios que pertenecen al rol indicado.
1
La especificación únicamente permite un número par de argumentos para “suma” (2, 4, 8, etc.
argumentos). Si bien los autores de este informe entienden que ésta es una errata en la
especificación, han preferido constatarla en el informe a fin de ajustarse a la realidad de dicha
especificación.
71
§
Expresión “no valor”, que es cierta sobre propiedades que no tienen valor
asignado.
§
Expresión “inicio unidad”, cuyo valor es el momento en el que comenzó a
ejecutarse la unidad.
§
Expresión “inicio actividad”, cuyo valor es el momento en el que comenzó a
ejecutarse la actividad actualmente activa.
§
Expresión “día y hora”, cuyo valor es el día y la hora actual.
§
Expresión “finalizado”, que permite comprobar si un determinado
componente (actividad, actuación, acto o guión) ha finalizado.
§
Expresión “no”, que permite comprobar el incumplimiento de un
determinado aserto.
Figura 2.6.2.a. Expresiones.
inicio unidad
es miembro de rol (referencia)
operando
es
inicio actividad
operando
operando
no es
y
o
día y hora
unidad de aprendizaje (referencia)
expresión
finalizado
actuación (referencia)
expresión
no
operando
2..∞
2..∞
suma
expresión
expresión
acto (referencia)
operando
guión (referencia)
1.∞
operando
operando
resta
operando
mul
operando
operando
operando
div
actividad (referencia)
operando
operando
mayor que
operando
rol (referencia)
usuarios en rol
no valor
expresión
propiedad (referencia)
72
Figura 2.6.2.b. Operandos.
expresión
operando
propiedad (referencia)
valor
2.6.3. Acciones
IMS LD nivel B también incluye mecanismos para expresar acciones que, al igual que
la expresiones, podrán utilizarse en contextos de más alto nivel. La Figura 2.6.3.a
esquematiza las posibles acciones expresables en IMS. Dichas acciones son:
§
Mostrar algún componente educativo o recurso. Efectivamente,
componentes como las actividades, los entornos de las actividades, etc.
pueden ser o no ser visibles, estado que puede alterarse en IMS LD nivel B.
Más concretamente y tal y como se sugiere en la Figura 2.6.3.a, es posible
mostrar (hacer visibles):
-
Todos los recursos o entornos de una determinada clase.
Efectivamente, los recursos de una actividad de aprendizaje, así como
los entornos, pueden clasificarse semánticamente en clases. La acción
mostrar puede actuar globalmente sobre todos los elementos así
clasificados.
-
Un recurso concreto.
-
Un entorno concreto.
-
Una actividad concreta.
-
Un guión.
-
Toda una unidad de aprendizaje.
§
Ocultar algún componente educativo o recurso. Los tipos de elementos que
pueden ocultarse son los mismos que los que pueden mostrarse.
§
Cambiar el valor de una propiedad. Nótese que el nuevo valor puede ser,
bien un literal, bien el valor de otra propiedad, bien venir dado por una
expresión.
73
Figura 2.6.3.a. Acciones.
clase
recurso (referencia)
entorno (referencia)
Mostrar
actividad (referencia)
acción
guión (referencia)
unidad (referencia)
Ocultar
Propiedad (referencia)
Cambiar valor de propiedad
operando
2.6.4. Condiciones
La introducción de propiedades tiene una repercusión importante a nivel de método.
Efectivamente, IMS LD nivel B incluye un nuevo elemento descriptivo en los métodos
educativos: las condiciones. Dichas condiciones son reglas que, en función del
cumplimiento de una determinada guarda (un aserto o condición sobre el estado de
ejecución), permiten actualizar los valores de las propiedades. Las condiciones en sí
se plasman en reglas tipo si <guarda> entonces <acción-cierto> en otro caso
<acción-falso>, con el significado: si <guarda> es cierta, realiza las acciones indicadas
en <acción-cierto> y, si no, realiza las acciones indicadas en <acción-falso>. Evaluar
una condición supone, por tanto, evaluar su guarda y, dependiendo de si dicha guarda
es cierta o falsa, ejecutar la acción correspondiente. Dado que la parte else es
opcional, la evaluación de condiciones sin parte else no tendrá efecto cuando la
guarda sea falsa.
Es importante notar que el modelo de ejecución de estas reglas es reactivo u
oportunista (al contrario del modelo de ejecución secuencial típico en lenguajes
informáticos de programación más usuales). Efectivamente, las condiciones se
evalúan:
§
Al comienzo de la ejecución de la unidad.
§
Siempre y cuando el valor de una propiedad haya cambiado.
74
Asimismo, dado que las acciones de las reglas pueden modificar valores de
propiedades que, a su vez, afectan a las guardas de otras reglas, en general la
ejecución de las reglas se encadenará, como sucede con los sistemas basados en
reglas clásicos (Li, 1991) utilizados en campos específicos de la informática como, por
ejemplo, la Inteligencia Artificial.
La Figura 2.6.4.a esquematiza la extensión de la descripción de los métodos con la
incorporación de las condiciones a nivel B. Nótese que puede haber varios conjuntos
de condiciones, cada uno de los cuáles podrá incluir varias condiciones. La estructura
de estos conjuntos de condiciones se especifica en la Figura 2.6.4.b.
Figura 2.6.4.a. Extensión de la estructura para los métodos con condiciones.
1..∞
Metodo
0..1
0..1
Guión
Condición de finalización
Acción tras finalización
0..∞
Condiciones
Figura 2.6.4.b. Estructura de la especificación de las condiciones.
0..1
Condiciones
expresión
si
Título
1..∞
0..1
entonces
Metadatos
0..1
en otro caso
acción
acción
La descripción de tales conjuntos incluye:
§
Un título opcional.
§
La secuencia de las condiciones en sí. Nótese que la parte en otro caso en
cada condición es opcional. Obsérvese también que la estructura de la
parte si se corresponderá con una expresión, mientras que las de las partes
entonces y en otro caso se corresponderán con una acción.
§
Un cuerpo de metadatos opcional.
75
2.6.5. Extensión de las condiciones de finalización de actividades, actos,
guiones y métodos
IMS LD nivel B extiende también las condiciones de finalización de actividades, actos,
guiones y métodos, permitiendo que dicha finalización dependa de la asignación de
cierto valor a cierta propiedad. Más concretamente, las condiciones de finalización
pueden también tomar en el nivel B, el formato descrito en la Figura 2.6.5.a. La
condición se hará cierta cuando la propiedad se actualice y, en caso de que se
especifique valor adicional, cuando el valor de actualización coincida con el
especificado.
Figura 2.6.5.a. Extensión de las condiciones de finalización en IMS LD nivel B.
Propiedad (referencia)
Condición de finalización
Propiedad actualizada
0..1
operando
2.6.6. Extensión de las acciones tras la finalización para actividades,
actos, guiones y métodos
En IMS LD nivel B la finalización de una actividad, acto, guión o método puede
desencadenar la asignación de un valor a una propiedad, tal y como se sugiere en el
esquema mostrado en la Figura 2.6.6.a. En conjunción con el condicionamiento de la
terminación de elementos en términos de valores de propiedades, esta extensión
permite llevar a cabo un secuenciamiento de actividades mucho más complejo, que
depende de la forma en la que se ejecuta la unidad de aprendizaje, así como del
contexto inicial de ejecución de la misma.
Figura 2.6.6.a. Extensión de las acciones tras la finalización en IMS LD nivel B.
Cambiar valor de propiedad
Acción tras la finalización
2.6.7. Elementos globales y monitores
IMS LD nivel B contempla también la posibilidad de que durante la realización de una
actividad se modifiquen los valores de las propiedades de la unidad. Dado que IMS LD
no norma la forma concreta en la que se ejecutan las actividades elementales, sino
únicamente cómo se integran éstas en el diseño educativo, dichas modificaciones
76
exceden el alcance de la especificación. No obstante, la especificación introduce
artefactos descriptivos estándar que pueden utilizarse para declarar en la descripción
de un determinado tipo de contenidos que dichos contenidos van a consultar y/o
modificar propiedades de la unidad de aprendizaje. Dichos artefactos se denominan
elementos globales.
De igual manera, a nivel B se introduce un nuevo tipo de servicio (servicio de
monitorización), que permite consultar y/o modificar los valores de las propiedades de
la unidad de aprendizaje.
2.6.8. Modelo de Ejecución
El nivel B permite modular el modelo de ejecución por defecto introducido a nivel A.
Efectivamente:
§
Las actividades pueden ser visibles o no visibles (este criterio de visibilidad
también se aplica a nivel A, aunque es a nivel B donde realmente adquiere
sentido).
§
Esta condición de visibilidad / invisibilidad puede alterarse mediante la
ejecución de las condiciones, las cuales, como ya se ha indicado
anteriormente, se consideran al comienzo de la ejecución, así como cada
vez que cambia el valor de una propiedad. Dichas propiedades engloban
tanto las definidas en la unidad de aprendizaje como aquellas cuyo valor se
establece de manera automática (v.g. el estado de visibilidad o invisibilidad
de las actividades).
Es importante, no obstante, considerar también la interacción de este modelo de
ejecución con algunas características de nivel A. En particular, la especificación
establece que todas las actividades que forman parte de una actividad estructurada de
tipo secuencia visible son visibles, independientemente de que éstas se hayan
marcado como no visibles en su descripción, e independientemente de las
condiciones. Dicho de otro modo, la visibilidad de las actividades que, en un acto, se
ejecutan en secuencia viene predeterminada y no puede alterarse.
2.6.9. Ejemplo de diseño de nivel B
En este apartado se esboza el diseño educativo de la unidad de aprendizaje
UACata2, utilizando para ello características de nivel B de IMS LD. Como en el
esbozo del diseño para UACata1 y con el fin de simplificar el desarrollo se omiten
muchas de las características opcionales. De este modo y dado que esta unidad es,
en realidad, una extensión de UACata1, únicamente se describirán los nuevos
elementos que deben añadirse así como aquellos que han de modificarse.
La descripción del diseño introduce las siguientes propiedades:
§
Propiedad nota en el test. Esta propiedad contendrá la puntuación obtenida
por los alumnos en el test previo realizado.
77
§
Propiedad nota en el trabajo. Esta propiedad contendrá la puntuación
obtenida por cada alumno en el trabajo.
§
Propiedad recuperación finalizada. Esta propiedad se actualizará a cierto
cuando se haya finalizado la recuperación.
§
Propiedad asignatura superada. Esta propiedad se actualizará a cierto
cuando se haya superado la asignatura.
Estas propiedades son ambas de tipo locales personales, ya que cada alumno tendrá
las suyas propias, almacenando sus calificaciones y controlando la finalización de la
recuperación. La Figura 2.6.9.a esboza su descripción:
Figura 2.6.9.a. Fragmento de diseño con la descripción de las propiedades.
Propiedades
..Propiedad
..Propiedad
..Propiedad
..Propiedad
local
local
local
local
personal:
personal:
personal:
personal:
nota en el test
nota en el trabajo
recuperación finalizada
asignatura superada
Tal y como se muestra en la Figura 2.6.9.b, será necesario añadir los siguentes
entornos a los ya existentes:
§
Entorno test, que hará referencia a un sitio web que aloja una herramienta
de realización de tests. En este sitio web, los alumnos podrán identificarse y
realizar los tests asignados.
§
Entorno libro Corbinus, que hará referencia al libro de Corbinus en formato
electrónico.
Figura 2.6.9.b. Nuevos entornos que aparecen en el diseño de UACata2.
..Entorno
....Título: Test
....Objeto de Aprendizaje:
<referencia a recurso rherramientatests>
..Entorno
....Título: Libro Corbinus
....Objeto de Aprendizaje:
<referencia a recurso rcorbinus>
La Figura 2.6.9.c muestra las nuevas actividades que aparecen en este diseño. Se
incluyen las siguientes actividades de aprendizaje y de soporte:
§
Actividad de aprendizaje Realización Test, orientada a la resolución del test
previo.
§
Actividad de soporte Evaluación Test, orientada a la corrección del test
previo.
78
§
Actividad de aprendizaje Lectura libro Corbinus, en la que los alumnos que
han obtenido peores notas en el test refuerzan sus conocimientos mediante
la lectura del libro de Corbinus.
§
Actividades de aprendizaje Repaso libro Corbinus, Repaso Artículo Birra,
Repaso Sitio Web, orientadas al repaso de los distintos materiales
propuestos en el curso.
§
Actividad de aprendizaje Revisión y Mejora del Trabajo, en la que los
alumnos podrán mejorar y corregir los defectos detectados en sus trabajos.
§
Actividad de soporte Re-evaluación del Trabajo, en la que el profesor
corregirá los trabajos revisados.
§
Actividad de aprendizaje Consulta Resultados Repesca, en la que los
alumnos podrán consultar los resultados definitivos de sus trabajos. Nótese
que dicha actividad actualiza la propiedad recuperación finalizada tras su
finalización.
79
Figura 2.6.9.c. Nuevas actividades de soporte y de aprendizaje que aparecen en
UACata2.
..Actividad de Aprendizaje
....Título: Realización test
....Entorno: <referencia a entorno test>
....Descripción: <referencia a recurso rdareltest>
....Condición de finalización: una vez transcurrida 1 hora
..Actividad de Soporte
....Título: Evaluación test
....Rol soportado: <referencia a Alumno de nueva promoción>
....Entorno: <referencia a entorno test>
....Condición de finalización: finalizada por el usuario
..Actividad de Aprendizaje
....Título: Lectura libro Corbinus
....Entorno: <referencia a entorno Libro Corbinus>
....Descripción: <referencia a recurso rdalectlibcorbinus>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Repaso libro Corbinus
....Entorno: <referencia a entorno Libro Corbinus>
....Descripción: <referencia a recurso rdalectlibcorbinus>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Repaso Artículo Birra
....Entorno: <referencia a entorno Artículo Birra>
....Descripción: <referencia a recurso rdalectartbirra>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Repaso sitio web
....Entorno: <referencia a entorno Sitio Web>
....Descripción: <referencia a recurso rdexweb>
....Condición de finalización: una vez transcurrido un día
..Actividad de Aprendizaje
....Título: Revisión y mejora del trabajo
....Entorno: <referencia a entorno Espacio de Archivos>
....Descripción: <referencia a recurso rdrealtrabajo>
....Condición de finalización: una vez transcurrida una semana
..Actividad de Soporte
....Título: Re-evaluación del Trabajo
....Rol soportado: <referencia a Alumno de nueva promoción>
....Entorno: <referencia a entorno Espacio de Archivos>
....Entorno: <referencia a entorno Tablón>
....Condición de finalización: finalizada por el usuario
..Actividad de Aprendizaje
....Título: Consulta Resultados Repesca
....Entorno: <referencia a entorno Tablon>
....Descripción: <referencia a recurso rdaconresultados>
....Condición de finalización: finalizada por el usuario
....Acción tras finalización
......Cambiar valor de propiedad
........Propiedad(referencia): <referencia a propiedad recuperación finalizada>
........valor: Cierto
80
Además, tal y como muestra la Figura 2.6.9.d, se incluyen las siguientes actividades
estructuradas:
§
Autoaprendizaje con repaso que incluye la lectura del libro de Corbinus
como paso previo al autoaprendizaje.
§
Autoaprendizajes, actividad tipo selección que engloba los dos métodos de
autoaprendizaje contemplados. Obsérvese que, para completar esta
actividad, bastará con elegir una de las que engloba. En realidad, en el
método de aprendizaje se incluirán condiciones que asegurarán que
únicamente una de éstas sea visible, dependiendo de la nota obtenida en el
test.
§
Realización Repaso, que engloba las tres actividades básicas de repaso
contempladas.
Figura 2.6.9.d. Nuevas actividades estructuradas que aparecen en UACata2.
..Actividad Estructurada (tipo secuencia)
....Título: Autoaprendizaje con repaso
....Actividad de aprendizaje (referencia): Lectura Libro Corbinus
....Actividad estructurada (referencia): Autoaprendizaje
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=1)
....Título: Autoaprendizajes
....Actividad estructurada (referencia): Autoaprendizaje con repaso
....Actividad estructurada (referencia): Autoaprendizaje
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3)
....Título: Realización Repaso
....Actividad de aprendizaje (referencia): Repaso Libro Corbinus
....Actividad de aprendizaje (referencia): Repaso Artículo Birra
....Actividad de aprendizaje (referencia): Repaso Sitio Web
La Figura 2.6.9.e esquematiza cómo se modifican los actos del método de UACata1
en el contexto del nuevo diseño:
§
Se añaden nuevos actos orientados a la realización y corrección del test
(test previo y corrección test previo).
81
Figura 2.6.9.e. Modificación y extensión de los actos.
........................
....Acto
......Título: test previo
......Actuación
........Título: Actuación test previo
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): Realización de test
......Condición de finalización: <finalizada Actuación test previo>
....Acto
......Título: corrección test previo
......Actuación
........Título: Actuación corrección test previo
........Rol(referencia): <referencia a Profesor del seminario>
........Actividad(referencia): Corrección de test
......Condición de finalización: <finalizada Actuación corrección test previo>
....Acto
......Título: período autoaprendizaje
......Actuación
........Título: Actuación autoaprendizaje
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Autoaprendizajes>
......Condición de finalización: <finalizada Actuación autoaprendizaje>
........................
....Acto
......Título: repaso
......Actuación
........Título: Actuación repaso
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Realización Repaso>
......Condición de finalización: <finalizada Actuación repaso>
....Acto
......Título: revisión
......Actuación
........Título: Actuación revisión
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Revisión y mejora del trabajo>
......Condición de finalización: <finalizada Actuación revisión>
....Acto
......Título: re-evaluación
......Actuación
........Título: Actuación re-evaluación
........Rol(referencia): <referencia a Profesor del seminario>
........Actividad(referencia): <referencia a Re-Evaluación del Trabajo>
......Condición de finalización: <finalizada Actuación re-evaluación>
....Acto
......Título: resultados2
......Actuación
........Título: Actuación resultados2
........Rol(referencia): <referencia a Alumno de nueva promoción>
........Actividad(referencia): <referencia a Consulta resultados de repesca>
......Condición de finalización: <finalizada Actuación resultados2>
En este diseño es necesario, además, adaptar la ejecución dependiendo de los
valores de las notas del test y del trabajo. Dicha adaptación se logra como sigue:
82
§
Se incluyen condiciones que permiten adaptar el proceso de aprendizaje
dependiendo de los resultados obtenidos en el test y en el trabajo (Figura
2.6.9.f). La primera de dichas condiciones comprueba el resultado del test.
Si éste es menor que 5 oculta la actividad Autoaprendizaje. En otro caso
(es igual o supera el 5), oculta la actividad Autoaprendizaje con repaso.
Como aspecto sutil cabe destacar que, aunque cuando la nota es menor
que 5 se oculta la actividad Autoaprendizaje, dicha actividad estructurada
se hará visible una vez alcanzada la actividad Autoaprendizaje con repaso,
ya que dicha actividad es una actividad de tipo secuencia y, por tanto, hace
visibles a todas las actividades secuenciadas independientemente del
efecto de las condiciones. La segunda de las condiciones determina la
finalización de la asignatura. Para ello debe haberse superado el trabajo o
bien debe haberse terminado la recuperación.
§
Se modifica la finalización del guión para que ésta dependa de que la
asignatura haya finalizado (Figura 2.6.9.g).
Figura 2.6.9.f. Condiciones para la adaptación del estilo de aprendizaje.
..Condiciones
.....si
.......menor
............propiedad(referencia): <referencia a propiedad nota en el test>
............valor: 5
........entonces
............ocultar: <referencia a actividad Autoaprendizaje>
........en otro caso
............ocultar: <referencia a actividad Autoaprendizaje con repaso>
.....si
........o
..........o
............mayor
..............propiedad(referencia): <referencia a nota en el trabajo>
..............valor: 5
............es
..............propiedad(referencia): <referencia a nota en el trabajo>
..............valor: 5
........ es
...............propiedad(referencia): <referencia a finalizada recuperación>
................valor: Cierto
.....entonces
...........fijar asignatura superada a cierto
Figura 2.6.9.g. Condición de finalización del guión.
Método
..Guión
........................
....Condición de finalización
......fijada propiedad asignatura superada a cierto
Nótese que en este método no se especifica en ningún lugar dónde se actualizan las
propiedades nota en el test y nota en el trabajo. Dicha actualización dependerá del
entorno de ejecución del diseño. Por ejemplo, el reproductor podrá ofrecer a usuarios
83
con suficiente privilegio la posibilidad de modificar los valores de las propiedades de
otros usuarios. De esta forma, el profesor podrá fijar las notas de cada uno de sus
alumnos durante las respectivas actividades de soporte. Del mismo modo,
dependiendo del grado de integración de los materiales con el entorno de ejecución, la
actualización de algunas propiedades podría llevarse a cabo automáticamente (v.g.
como resultado de la corrección automática del test: en este caso, la actividad de
soporte Corrección del test no sería necesaria).
2.7. EL NIVEL C
El nivel C añade un mecanismo que permite el envío de mensajes y la configuración
de actividades dependiendo de la ocurrencia de determinados eventos. Dicho
mecanismo está soportado por notificaciones e introduce un paradigma de ejecución
guiado por eventos en IMS LD. Utilizando este mecanismo es posible, por ejemplo,
hacer que se envíe un mensaje al profesor cada vez que un alumno concreto termine
de realizar un trabajo.
2.7.1. Notificaciones
La Figura 2.7.1.a esquematiza la estructura de la descripción de una notificación.
Figura 2.7.1.a. Estructura de la especificación de las notificaciones.
Dirigida a
Notificación
0..1
Actividad (referencia)
0..1
Asunto
De esta forma, la notificación incluye:
§
Una identificación del o los destinatarios a los que se dirige la notificación.
Dicha identificación pueden realizarse: (1) indicando un rol, de tal forma que
la identificación se dirigirá a todos los usuarios de dicho rol, (2) una
referencia a una propiedad que contiene el e-mail del usuario concreto al
que se dirige la notificación y, opcionalmente, una propiedad que contiene
el nombre de dicho usuario.
§
Opcionalmente, una referencia a una actividad simple (de aprendizaje o de
soporte). En el contenido de la notificación se incluirá un enlace a dicha
actividad, que pasará a ser visible si no lo era ya.
§
Opcionalmente, un campo de asunto con la descripción de la notificación.
84
2.7.2. Extensiones en IMS LD nivel C
La inclusión de notificaciones afecta a:
§
Las acciones de finalización de actividades, actos, guiones y unidades, que
pueden incluir ahora múltiples notificaciones.
§
La parte de acción de las condiciones, que pueden incluir también
notificaciones.
§
Los elementos globales, que pueden lanzar también notificaciones.
2.7.3. Ejemplo de diseño de nivel C
En este apartado se utilizará el mecanismo de notificaciones para mejorar el diseño de
la unidad de aprendizaje UACata2. El objetivo es que cada vez que un alumno
termine el trabajo, se envíe a Corbinus una notificación a fin de que pueda corregirlo.
El diseño resultante se integrará en la unidad de aprendizaje UACata3.
Para obtener el diseño educativo de UACata3, el primer paso es modificar ligeramente
el método de UACata2 para que las actividades Evaluación del trabajo y Revaluación
del trabajo se realicen en los mismos actos que las actividades Realización del trabajo
y Revisión y mejora del trabajo (en otro caso, el comienzo de las mismas dependería
de la finalización de las actividades de realización y revisión de trabajos por parte de
todos los alumnos). La Figura 2.7.3.a esboza la modificación.
85
Figura 2.7.3.a. En UACata3 el acto trabajo puede fundirse con el acto corrección, y
el acto revisión con revaluación.
........................
....Acto
......Título: trabajo y corrección
......Actuación
........Título: Actuación trabajo
........Rol(referencia): <referencia a Alumno nueva promoción>
........Actividad(referencia): <referencia a Realización Trabajo>
......Actuación
........Título: Actuación corrección
........Rol(referencia): <referencia a Profesor de seminario>
........Actividad(referencia): <referencia a Corrección de Trabajo>
......Condición de finalización: <finalizada Actuación corrección>
........................
....Acto
......Título: revisión y re-evaluación
......Actuación
........Título: Actuación revisión
........Rol(referencia): <referencia a Alumno nueva promoción>
........Actividad(referencia): <referencia a Revisión y mejora del trabajo>
......Actuación
........Título: Actuación re-evaluación
........Rol(referencia): <referencia a Profesor de seminario>
........Actividad(referencia): <referencia a Re-Evaluación del Trabajo>
......Condición de finalización: <finalizada Actuación re-evaluación>
El segundo paso consiste, simplemente, en incluir notificaciones en las acciones de
finalización de las actividades Realización del trabajo y Revisión y mejora del trabajo
(también es necesario dejar que sea el alumno el que decida la terminación de estas
actividades). Dichas notificaciones irán dirigidas a los miembros del rol profesor del
seminario y portarán un enlace a la correspondiente actividad de corrección. La Figura
2.7.3.b esboza estas extensiones.
86
Figura 2.7.3.b. Modificaciones de las actividades Realización del Trabajo y Revisión
y Mejora del Trabajo para permitir que se notifique al profesor del seminario cada vez
que se finalicen dichas actividades.
........................
..Actividad de Aprendizaje
....Título: Realización Trabajo
....Entorno: <referencia a entorno Espacio de Archivos>
....Descripción: <referencia a recurso rdrealtrabajo>
....Condición de finalización: decidida por el usuario
.... Acción de finalización
......Notificación
........dirigida a: rol <referencia a rol profesor de seminario>
........actividad (referencia): <referencia a actividad Corrección de Trabajo>
........................
..Actividad de Aprendizaje
....Título: Revisión y mejora del trabajo
....Entorno: <referencia a entorno Espacio de Archivos>
....Descripción: <referencia a recurso rdrealtrabajo>
....Condición de finalización: decidida por el usuario
.... Acción de finalización
......Notificación
........dirigida a: rol <referencia a rol profesor de seminario>
........actividad (referencia): <referencia a actividad Re-evaluación de Trabajo>
2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS
IMS LD utiliza XML para definir un lenguaje de marcado específico que permite
describir los diseños educativos. De esta forma, las estructuras descritas
informalmente en las secciones anteriores tienen una representación formalizada en
XML, representación que puede ser procesada automáticamente por las herramientas
de edición y reproducción de diseños educativos. 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.
2.8.1. Codificación de la Estructura de Alto nivel del Diseño
La descripción del diseño se encierra en un elemento learning-design. Dicho
elemento tiene los siguientes atributos:
§
identifier. Atributo obligatorio que identifica unívocamente el elemento
en el contexto del manifiesto de la unidad de aprendizaje.
§
version. Atributo opcional que indica el número de versión de IMS LD.
§
uri. Atributo obligatorio que asocia una URI al diseño (un identificador
globalmente único).
87
§
level. Atributo opcional que indica el nivel de IMS LD utilizado en el
diseño (su valor puede ser A, B, C, a, b, c).
§
sequence-used. Atributo obligatorio que, en caso de ser true, permite
utilizar IMS Simple Sequencing (IMS SS, 2003) como mecanismo de
secuenciamiento en lugar de IMS LD.
El título del diseño se encierra en un elemento title. Los objetivos de aprendizaje se
encierran en un elemento learning-objectives. Los prerrequisitos se encierran
en un elemento prerequisites. El contenido de estos dos elementos, que identifica
un recurso que describe los objetivos y prerrequisitos, se describe mediante los
siguientes elementos:
§
title. Elemento opcional, que encierra un título descriptivo.
§
Una o más ocurrencias de item. Elemento que, a su vez, sigue el formato
especificado en IMS CP, y que permite referir a un recurso descriptivo del
objetivo o del prerrequisito (IMS CP, 2004).
§
metadata. Elemento de metadatos opcional.
Los componentes se describen mediante un elemento components. El método se
describe mediante un elemento method. Los metadatos se encierran en un elemento
metadata.
La Figura 2.8.1.a esboza la codificación XML de la estructura de alto nivel del diseño
para UACata1. Los identificadores han sido creados automáticamente utilizando una
herramienta de autoría como las que se describirán en el capítulo dedicado a
herramientas. Se ha añadido tambien una sección de objetivos de aprendizaje y de
prerrequisitos para que se aprecie su codificación. Obsérvese que en el paquete IMS
deberá haber sendos recursos identificados mediante robjetivoscurso y
rprerequisitoscurso.
88
Figura 2.8.1.a. Codificación XML de la estructura de alto nivel del diseño de
UACata1.
<learning-design
identifier="ld-1e523a0b-dcad-c0a7-d07b-9d7e52fe65fb"
level="A"
sequence-used="false"
uri="http://www.cnice.mec.es/uri/ld-1e523a0b-dcad-c0a7-d07b-9d7e52fe65fb">
<title>Seminario de introducción a la cata</title>
<learning-objectives>
<title>Objetivos del curso</title>
<item identifier="item-79b4a276-a911-444e-35fc-c0f8cf2db93e"
identifierref="robjetivoscurso" isvisible="true" />
</learning-objectives>
<prerequisites>
<title>Prerequisitos del curso</title>
<item identifier="item-784a1745-bb1f-5e86-1e2a-9102cb31082c"
identifierref="rprerequisitoscurso" isvisible="true" />
</prerequisites>
<components>
...
</components>
<method>
...
</method>
</learning-design>
2.8.2. Codificación de los roles
La descripción de los roles se delimita con un elemento roles. Dicho elemento
contempla los siguientes atributos:
§
identifier. Atributo obligatorio que identifica unívocamente el rol.
En el interior de este elemento, los roles de tipo aprendiz se marcan con el elemento
learner, mientras que los de tipo plantilla se marcan con staff. Ambos elementos
contemplan los siguientes atributos:
§
create-new. Atributo obligatorio que indica si es o no posible asociar
múltiples usuarios con este rol cuando se ejecuta la unidad de aprendizaje.
Si el valor es not-allowed, únicamente se permitirá asociar un actor con
dicho rol. Si no, es posible asociar varios.
§
href. Atributo opcional que asocia una URI con el rol, que permite
identificar el rol como uno global definido a nivel institucional (v.g. un rol
definido en un instituto).
§
identifier. Atributo obligatorio que identifica unívocamente al rol en el
manifiesto.
§
match-persons. Atributo opcional que, en caso de existir varios subroles,
permite decidir si el mismo usuario deberá asociarse de forma exclusiva a
89
uno de los subroles (valor exclusively-in-roles) o bien si puede
asociarse de manera no exclusiva a los distintos subroles (valor notexclusively).
§
min-persons.Atributo opcional que indica el mínimo número de
integrantes del rol. Si no está presente, se supone que el mínimo número
de integrantes es 0.
§
max-persons. Atributo opcional que indica el máximo número de
integrantes del rol. Si no está presente, se supone que el máximo número
de integrantes no está limitado.
El contenido de estos elementos contiene un elemento title opcional (con el título
del rol), un elemento information opcional (que hace referencia a recursos que
detallan el rol, mediante elementos title, item y metadata, al estilo de
learning-objectives y prerequisites), una secuencia de 0 o más elementos
describiendo los subroles (de nuevo con learner o staff, dependiendo del tipo de
rol) y un elemento opcional metadata.
La Figura 2.8.2.a esboza la codificación XML de los roles para las unidades de
aprendizaje de nuestro caso de estudio. Los identificadores también se han generado
automáticamente con una herramienta de autor y se asume, además, que en el
paquete
IMS
deberá
haber
recursos
identificados
con
rrolAlumnoNuevaPromocion,
rrolAlumnoPromocionesAntiguas
y
rrolProfesorDeSeminario.
90
Figura 2.8.2.a. Codificación XML de los roles en las unidades de aprendizaje del
caso de estudio.
<roles>
<learner identifier="role-512dc775-0d84-9461-bf67-0ca1a23b8907"
create-new="allowed">
<title>Alumno de nueva promoción</title>
<information>
<item identifier="item-bcd3d171-72ad-7472-a49e-e1b9516f23fa"
identifierref="rrolAlumnoNuevaPromocion" isvisible="true" />
</information>
</learner>
<learner identifier="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5"
create-new="allowed">
<title>Alumno de promociones antiguas</title>
<information>
<item identifier="item-f1f510c6-ad57-277d-3332-068a5de3cf9a"
create-new="allowed"
identifierref="rrolAlumnoPromocionesAntiguas" isvisible="true" />
</information>
</learner>
<staff identifier="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9"
create-new="allowed"min-persons="1" max-persons="1">
<title>Profesor de seminario</title>
<information>
<item identifier="item-a9cd7404-186b-1f5d-2470-b650c126e5a4"
identifierref="rrolProfesorDeSeminario" isvisible="true" />
</information>
</staff>
</roles>
2.8.3. Codificación de las actividades
La descripción de las actividades se delimita con un elemento activities. Dentro de
dicho elemento, cada actividad de aprendizaje se delimita mediante un elemento
learning-activity, cada actividad de soporte mediante support-activity y
cada actividad estructurada mediante activity-structure.
Los elementos learning-activity contemplan los siguientes atributos:
§
identifier. Atributo obligatorio que identifica unívocamente al elemento
en el manifiesto.
§
isvisible. Atributo obligatorio que permite controlar la visibilidad inicial
de la actividad (si vale true la actividad será visible, si vale false será
invisible).
§
parameters. Atributo opcional que permite especificar una lista de
parámetros, en caso de que dicha lista se precise para lanzar la actividad.
Asimismo, en la descripción el título se encierra en un elemento title, los objetivos
de aprendizaje en un elemento learning-objectives, los prerrequisitos en un
elemento prerrequisites, los entornos se referencian mediante elementos
91
environment-ref (estos elementos tienen un atributo ref que permite referir al
entorno por su identificador único), la descripción de la actividad mediante un elemento
activity-description (utilizando los ya familiares elementos title, item y
metadata), la condición de finalización con un elemento complete-activity, la
acción de finalización con un elemento on-completion y los metadatos asociados
con un elemento metadata.
Los elementos complete-activity pueden, a su vez, encerrar un elemento vacío
user-choice (que indica que la finalización es decisión del usuario), un elemento
time-limit (que indica la duración de la actividad de forma relativa al comienzo de
la ejecución de la actividad, bien directamente, como contenido del elemento, bien
haciendo referencia a una propiedad local que debe contener dicho valor, a través del
atributo property-ref), o, a nivel B, un elemento when-property-value-is-set
(que supedita la finalización a que una propiedad alcance un valor dado). El contenido
de este último elemento se describirá mediante un elemento property-ref (este
elemento tiene un atributo ref que refiere la propiedad por su nombre), así como
mediante un elemento property-value, que indicará el valor que debe alcanzar la
propiedad para que se cumpla la condición de finalización. Dicho valor puede indicarse
de manera literal (delimitado el valor literal con un elemento langstring), mediante
una expresión delimitada con calculate, o como el valor de otra propiedad, referida
mediante otro elemento property-ref.
Figura 2.8.3.a. Codificación XML de la actividad de aprendizaje Lectura Artículo
Birra.
<learning-activity identifier="la-53a23357-d67b-1991-d0bd-5751cfbc92f8"
isvisible="true">
<title>Lectura Articulo Birra</title>
<environment-ref ref="env-d2465bb9-5a4b-1b11-5897-70191e2de62b" />
<activity-description>
<title>Descripcion</title>
<item identifier="i tem-0e113665-6501-358a-7453-84c925ff020c"
identifierref="rdalectartbirra" isvisible="true" />
</activity-description>
<complete-activity>
<time-limit>P1D</time-limit> <!— codificación de duración de un 1 día -->
</complete-activity>
</learning-activity>
Por su parte, los elementos on-completion pueden encerrar un elemento
feedback-description (proporciona realimentación al usuario, realimentación que
se describe mediante la típica secuencia de elementos title, item y metadata). A
nivel B, también puede encerrar la descripción del cambio de valor de una propiedad
mediante
un
elemento
change-property-value.
El
contenido
de
change-property-value es análogo al de property-value, aunque, por
supuesto, la semántica difiere (ahora consiste en actualizar la propiedad referida al
valor indicado). A nivel C puede encerrar también una notificación.
La estructura de los elementos support-activity es análoga a la de los elementos
learning-activity, salvo que también pueden incluir las referencias a los roles
92
soportados. Dichas referencias se marcan con role-ref, elemento que tiene un
atributo obligatorio ref que refiere al rol soportado nombrando el identificador único
de dicho rol.
Por último, los elementos activity-structure
atributos:
contemplan los siguientes
§
identifier. Atributo obligatorio que identifica unívocamente al elemento
en el manifiesto.
§
structure-type. Atributo opcional que indica el tipo de la actividad
estructurada (sequence, para las actividades tipo secuencia y selection,
para las actividades tipo selección).
§
number-to-select. Atributo que para las actividades de tipo selección
permite indicar el número de actividades constituyentes que tienen que
completarse para que la actividad total esté completada.
§
sort. Atributo opcional que determina el orden en el que las actividades
constituyentes aparecen en la bandeja del usuario. Si vale as-is (valor por
defecto) las actividades se ordenarán según aparecen en la estructura. Si
vale visibility-order las actividades se ordenan por el momento en el
que se han hecho visibles.
Figura 2.8.3.b. Codificación XML de la actividad de soporte Corrección de trabajo.
<support-activity identifier="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c"
isvisible="true">
<title>Corrección de trabajo</title>
<role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<environment-ref ref="env-123ba1c8-a943-8f96-59ba-c42365f43778" />
<environment-ref ref="env-8ddee08c-f267-253b-4ffa-c9836fed5f35" />
<activity-description>
<item identifier ="item-355b4f47-3add-8e39-9bc1-9499ec873be6"
identifierref="rdacorrtrabajo"
isvisible="true" />
</activity-description>
<complete-activity>
<user-choice />
</complete-activity>
</support-activity>
En la descripción de las actividades estructuradas el título se marca mediante un
elemento title, su descripción mediante un elemento information, la referencia a
los entornos mediante environment-ref, las actividades refereridas mediante
elementos de referencia apropiados y los metadatos mediante metadata. Los
elementos de referencia a las actividades dependen del tipo de las mismas y todos
ellos incluyen un atributo ref que permite referir a las actividades constituyentes por
su identificador. Las actividades de aprendizaje se refieren mediante elementos
learning-activity-ref,
las
actividades
de
soporte
mediante
93
support-activity-ref,
activity-structure-ref.
y
las
estructuradas
mediante
Figura 2.8.3.c. Codificación XML de la actividad estructurada Examen Materiales.
<activity-structure identifier="as-9c621522-af53-d875-81ab-741cd3097e39"
structure-type="selection">
<title>Examen materiales</title>
<learning-activity-ref ref="la-53a23357-d67b-1991-d0bd-5751cfbc92f8" />
<learning-activity-ref ref="la-2147820d-22b0-25ff-4387-65d7cc7d5e26" />
<learning-activity-ref ref="la-c04f2483-5479-b250-e031-5798d2923a94" />
</activity-structure>
La Figuras 2.8.3.a, la Figura 2.8.3.b y la Figura 2.8.3.c esbozan la codificación XML
de: (i) la actividad de aprendizaje Lectura Artículo Birra, (ii) la actividad de soporte
Corrección de Trabajo y (iii) la actividad estructurada Examen Materiales. Al igual que
en los puntos anteriores, los identificadores también se han generado
automáticamente y se asume que en el paquete IMS deberán estar los recursos
referidos desde la codificación.
2.8.4. Codificación de los entornos
Los entornos se delimitan mediante environments. Cada entorno en sí se delimita
con environment, elemento que puede exhibir los siguientes atributos:
§
identifier. Atributo obligatorio que identifica unívocamente al elemento
en el manifiesto.
El título del entorno se delimita con title. Cada objeto de aprendizaje se delimita
mediante learning-object. Este elemento contempla los siguientes atributos:
§
class. Atributo opcional que etiqueta el objeto de aprendizaje con una
clase o conjunto de clases, en el sentido de HTML 4.0 o XHTML.
§
identifier. Atributo obligatorio que identifica unívocamente al elemento
en el manifiesto.
§
isvisible. Atributo obligatorio que determina la visibilidad o invisibilidad
del entorno.
§
parameters. Atributo opcional con los parámetros requeridos para activar
el entorno.
§
type. Atributo opcional que determina el tipo de objeto de aprendizaje.
La estructura de dicho elemento puede seguir el patrón ya familiar title – item –
metadata para referir los materiales del objeto de aprendizaje, aunque IMS LD
contempla también el uso de cualquier otro formato de descripción de objetos de
aprendizaje, mediante el uso de un vocabulario XML adecuado.
94
Por su parte, cada servicio se delimita mediante un elemento service. Dicho
elemento acepta atributos class, identifier, isvisible and parameters
análogos a los de learning-object. Igualmente, para describir cada tipo de servicio
se incluye un vocabulario de marcado adecuado (dicho vocabulario se omitirá aquí por
simplicidad, relegando al lector interesado a la especificación, aunque sí se dará un
ejemplo de descripción de servicio).
La Figura 2.8.4.a muestra la descripción del entorno Artículo Birra, que ilustra el uso
de un objeto de aprendizaje en un entorno. Por su parte, en la Figura 2.8.4.b
ejemplificamos la prometida descripción de un servicio (en este caso, servicio de
conferencia), en el contexto del entorno Servicio Debate. Aunque los identificadores y
referencias a identificadores han sido generados automáticamente, el lector puede
comprobar cómo los participantes, gestor de la charla y moderador se corresponden
con los distintos roles introducidos en la Figura 2.8.2.a.
Figura 2.8.4.a. Codificación XML del entorno Artículo Birra.
<environment identifier="env-d2465bb9-5a4b-1b11-5897-70191e2de62b">
<title>Articulo Birra</title>
<learning-object identifier="lo-b6fa59c3-74f7-f4c7-484e-2fb290ee54cc"
isvisible="true">
<title>articulo</title>
<item identifier="item-16543567-5502-d539-034b-4a8e72c5ad4b"
identifierref="rarticulobirra"
isvisible="true" />
</learning-object>
</environment>
Figura 2.8.4.b. Codificación XML del entorno Servicio Debate.
<environment identifier="env-083026bb-1a97-7ecf-63ef-8d772b7a2f99">
<title>Servicio Debate</title>
<service identifier="service-bf953b45-c770-2c1e-c844-d424e1c8384a"
isvisible="true">
<conference conference-type="synchronous">
<title>chat</title>
<participant role-ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<participant role-ref="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5" />
<observer role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
<conference-manager role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
<moderator role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
</conference>
</service>
</environment>
2.8.5. Codificación de los métodos
Los métodos se limitan con elementos de tipo method. Cada guión se marca mediante
play. La condición de finalización del método (y por tanto, de la unidad de
95
aprendizaje) se marca mediante complete-unit-of-learning. El contenido de
este elemento puede ser de alguno de los tipos siguientes:
§
Elemento when-play-completed. Este elemento hace referencia, a
través de un atributo ref, al guión que ha de completarse para considerar
que la unidad de aprendizaje ha terminado.
§
Elemento time-limit. Al igual que en las actividades, este elemento
permite especificar un tiempo máximo, transcurrido el cual la unidad se
considerará terminada.
§
Elemento when-property-value-is-set, que, con sentido y uso
análogo al de las actividades, permite supeditar el final de un método a que
una propiedad tome un determinado valor.
Además, la acción a realizar tras la finalización del método se marca con oncompletion. La estructura es análoga a la ya descrita para las actividades.
Cada elemento play puede tener asociado un identificador opcional (atributo
identifier), así como un atributo isvisible obligatorio, que determina la
visibilidad del guión. Asimismo, dentro de este tipo de elementos es posible utilizar los
siguientes:
§
Elemento title para marcar el título del guión.
§
Elementos act para describir los actos
§
Elemento complete-play para describir la condición de finalización.
Dicha condición puede indicarse con un elemento when-last-actcompleted para indicar que el guión termina cuando termine su último
acto, con time-limit, o con when-property-value-is-set.
§
Elemento on-completion para describir la acción realizada tras la
finalización. La estructura es análoga a la de las actividades y guiones.
§
Elemento metadata para delimitar el cuerpo de metadatos asociado al
guión.
Por su parte, los actos pueden exhibir también identificadores opcionales (atributo
identifier), así como encerrar los siguientes tipos de elementos:
§
Elemento title con el título del acto.
§
Elementos role-part con cada actuación del acto.
§
Elemento complete-act con la condición de finalización. Dicha condición
puede describirse como when-role-part-completed (elemento que, a
través del atributo ref, hará referencia a la actuación que debe terminar
para considerar el acto finalizado). También pueden usarse los ya familiares
time-limit o when-property-value-is-set.
§
Elemento on-completion indicando la acción de finalización. La
estructrura es análoga a la ya descrita para los otros elementos.
96
§
Elemento metadata con los metadatos asociados.
Por último, las actuaciones también pueden tener un identificador opcional (atributo
identifier). Su contenido incluye:
§
Un título (elemento title).
§
El rol que participa en la actuación. Dicho rol se refiere mediante el atributo
ref de un elemento role-ref.
§
La actividad que debe llevarse a cabo se refiere mediante learningactivity-ref (en caso de tratarse de una actividad de aprendizaje),
support-activity-ref (en caso de tratarse de una actividad de
soporte) o activity-structure-ref (en caso de ser una actividad
estructurada). La referencia en sí se realiza mediante un atributo ref en el
elemento correspondiente. IMS LD permite también referir directamente un
entorno (a través de environment-ref) para abreviar actividades de
aprendizaje muy simples que involucran únicamente el entorno referido.
§
Como es habitual, también es posible asociar metadatos con la actuación,
mediante metadata.
La Figura 2.8.5.a ilustra la codificación en XML del método para la unidad de
aprendizaje UACata1 (método que fue descrito más informalmente en la Figura
2.5.5.d).
97
Figura 2.8.5.a. Codificación XML del método de UCata1.
<method>
<play identifier="play-d746ba58-9a56-0da7-b40e-ae1713641291" isvisible="true">
<title>Play</title>
<act identifier="act-aabc540f-3d3c-a6a5-1384-bcd0d61b3c88">
<title>clase presencial</title>
<role-part identifier="rolepart-d8aa496c-7152-453d-e9dc-f0d35cbbf9f6">
<title>Actuacion Imparticion</title>
<role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
<learning-activity-ref ref="la-fb255f1c-cd59-208e-85c7-5f7820a0fb4f" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-d8aa496c-7152-453d-e9dc-f0d35cbbf9f6" />
</complete-act>
</act>
<act identifier="act-bee7ffd0-d092-0696-0b26-1108811b5f8f">
<title>periodo autoaprendizaje</title>
<role-part identifier="rolepart-ab90c945-6918-d9b6-0945-c52afff5832b">
<title>actuacion autoaprendizaje</title>
<role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<activity-structure-ref ref="as-b65b7cf6-6438-e9ca-ca41-f502a4a67133" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-ab90c945-6918-d9b6-0945-c52afff5832b" />
</complete-act>
</act>
<act identifier="act-5bbbfa6f-2c25-fdac-0046-1ef6a2e73a78">
<title>discusion</title>
<role-part identifier="rolepart-512ead89-fb94-5a95-92da-21ebddc611b9">
<title>actuacion debate alumno nuevo</title>
<role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" />
</role-part>
<role-part identifier="rolepart-5da960cb-e0f0-05b5-66a8-8a91b2f464c5">
<title>actuacion debate alumno antiguo</title>
<role-ref ref="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5" />
<learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" />
</role-part>
<role-part identifier="rolepart-aa5d278f-dd14-fa23-dcf2-d6ffe28c9f11">
<title>actuacion debate profesor</title>
<role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
<learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-aa5d278f-dd14-fa23-dcf2-d6ffe28c9f11" />
</complete-act>
</act>
<act identifier="act-58133d9e-fd08-8055-a6e0-01838c03eed0">
<title>trabajo</title>
<role-part identifier="rolepart-af8aaf22-a6f7-2420-813a-2c047718e38d">
<title>actuacion trabajo</title>
<role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<learning-activity-ref ref="la-75c7788b-cc11-3db6-a881-921c5d214ed6" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-af8aaf22-a6f7-2420-813a-2c047718e38d" />
</complete-act>
</act>
<act identifier="act-bef87d0c-6b22-a464-6dd9-fce61033727f">
<title>evaluacion</title>
<role-part identifier="rolepart-768cf77c-40c9-27ae-0b06-e211659cc04c">
<title>actuacion evaluacion</title>
<role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
<support-activity-ref ref="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-768cf77c-40c9-27ae-0b06-e211659cc04c" />
</complete-act>
</act>
<act identifier="act-91023aab-d4e0-4762-e80c-0967b8a3d339">
<title>resultados</title>
<role-part identifier="rolepart-60876a2e-371d-ebcc-f456-aa7997a5ee5b">
<title>Actuacion resultados</title>
<role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" />
<learning-activity-ref ref="la-c8f0184c-bb4e-9241-b104-35add9ba30e3" />
</role-part>
<complete-act>
<when-role-part-completed ref="rolepart-60876a2e-371d-ebcc-f456-aa7997a5ee5b" />
</complete-act>
</act>
<complete-play>
<when-last-act-completed />
</complete-play>
</play>
<complete-unit-of-learning>
<when-play-completed ref="play-d746ba58-9a56-0da7-b40e-ae1713641291" />
</complete-unit-of-learning>
</method>
98
2.8.6. Codificación de las propiedades
Las propiedades se delimitan mediante un elemento properties. La descripción de
cada propiedad en sí depende de su tipo:
§
Las propiedades locales generales se marcan mediante loc-property.
§
Las propiedades locales personales se marcan mediante locpersproperty.
§
Las propiedades locales de rol se marcan mediante locrole-property.
§
Las propiedades globales generales se marcan como glob-property.
§
Las propiedades globales personales se marcan como globpersproperty.
Todos estos elementos tienen un identificador único (atributo identifier). Los
elementos loc-property, locpers-property y locrole-property contienen, a
su vez, los siguientes:
§
title. Elemento opcional que delimita el título de la propiedad.
§
role-ref (únicamente para locrole-property). Elemento obligatorio
que refiere a través de un atributo ref al rol al que se refiere la propiedad
local del rol.
§
datatype. Elemento obligatorio que determina el tipo (el formato de los
posibles valores) de la propiedad. Dicho elemento posee un atributo
también llamado datatype que permite determinar el citado tipo. El tipo
puede ser: boolean (el valor de la propiedad ha de ser un valor lógico: true
–cierto- o false –falso-), integer (valor número entero), real (valor número
real), string (valor cadena de caracteres), duration (valor duración
temporal), text (valor texto), uri (valor dirección web) o other (valor de tipo
no especificado).
§
initial-value. Valor inicial de la propiedad (si no se especifica, el valor
inicial es <no value>).
§
restriction. Este elemento, que puede ocurrir cero o más veces,
constriñe el posible rango de valores que puede adoptar la propiedad. Para
ello utiliza el atributo restriction-type, así como los convenios de
descripción de restricciones de valores introducidos por la especificación
XML Schema (véase XML Schema, 2004).
§
metadata. Metadatos asociados con la propiedad.
Por su parte, globpers-property y glob-property pueden contener, bien un
elemento existing, bien un elemento global-definition:
§
El elemento existing permite referir una propiedad global ya declarada
en otra unidad de aprendizaje. Para ello utiliza un atributo href. Esto
99
permite introducir en un diseño educativo propiedades globales ya
declaradas en otros.
§
El elemento global-definition permite definir una propiedad global en
sí. Esta propiedad podrá entonces referirse desde otros diseños mediante
elementos existing. El contenido de global-definition en sí viene
dado por los elementos title, datatype, initial-value,
restriction y metadata ya descritos anteriormente en relación con las
propiedades locales.
Por último, IMS LD también permite agrupar propiedades en grupos, a fin de permitir
su edición conjunta (por ejemplo, a través de un formulario). Para ello las propiedades
pueden agruparse mediante el elemento property-group. Dicho elemento tiene un
identificador único (atributo identifier). Además, pueden contener los siguientes
elementos:
§
title. Opcional. Título del grupo.
§
property-ref. Múltiples ocurrencias. Refiere a una propiedad que se
incluye en el grupo (a través del atributo ref).
§
property-group-ref. Múltiples ocurrencias. Refiere a un grupo de
propiedades que se incluye en el grupo (a través del atributo ref).
La Figura 2.8.6.a ilustra la codificación en XML de las propiedades para la unidad de
aprendizaje UACata2.
Figura 2.8.6.a. Codificación XML de las propiedades de la actividad UACata2.
<properties>
<locpers-property identifier="prop-94680282-98c1-eae2-1836-ce7142ccb065">
<title>nota en el test</title>
<datatype datatype="integer" />
</locpers-property>
<locpers-property identifier="prop-19d3a408-8be8-c70f-58a9-05e385d4d1f3">
<title>nota en el trabajo</title>
<datatype datatype="integer" />
</locpers-property>
<locpers-property identifier="prop-63135b88-e236-6e85-709b-231f6be36808">
<title>recuperación finalizada</title>
<datatype datatype="boolean" />
<initial-value>false</initial-value>
</locpers-property>
<locpers-property identifier="prop-5e3513ed-6eef-5a85-fdcc-617f9c14a551">
<title>asignatura superada</title>
<datatype datatype="boolean" />
<initial-value>false</initial-value>
</locpers-property>
</properties>
100
2.8.7. Codificación de las expresiones, acciones y condiciones
La codificación de las expresiones introducidas por IMS LD nivel B es como sigue:
§
Las expresiones “es miembro de rol” se codifican mediante elementos ismember-of-role. Estos elementos refieren el rol en cuestión mediante un
atributo ref.
§
Las expresiones “es” se codifican mediante elementos is delimitando los
dos operandos involucrados.
§
Las expresiones “no es” se codifican mediante elementos not-is que
delimitan los dos operandos involucrados.
§
Las expresiones “y,” “o”, “suma”, “resta”, “mul”, “div”, “mayor que” , “menor
que” y “no” se codifican respectivamente mediante elementos and, or, sum,
substract, multiply, divide, greater-than, less-than, y not.
§
Las expresiones “usuarios en rol” se codifican mediante elementos usersin-role. El atributo role-ref refiere el rol al que se aplica la expresión,
mientras que la expresión en sí aparece como hija del elemento.
§
Las expresiones “no valor” se codifican mediante no-value.
§
Las expresiones “inicio unidad” se codifican mediante time-unit-oflearning-started (mediante el atributo unit-of-learning-uri se
refiere la unidad en sí), las de tipo “inicio actividad” mediante daytimeactivity-started (mediante el atributo ref se refiere la actividad) y las
de tipo “día y hora” mediante current-datetime.
§
Las expresiones “finalizado” se codifican mediante elementos complete.
Para referir el componente finalizado se usan alguno de los siguientes
elementos:
learning-activity-ref,
support-activity-ref,
unit-of-learning-href, activity-structure-ref, role-partref, act-ref o play-ref. En todos ellos se utiliza el atributo ref para
realizar la referencia, excepto en unit-of-learning-href, donde se
utiliza el atributo href con la dirección web de la unidad de aprendizaje
referida.
La Figura 2.8.7.a ejemplifica la codificación en XML de la primera de las condiciones
esbozadas en la Figura 2.6.9.f.
101
Figura 2.8.7.a. Codificación XML de una condición.
<conditions>
<if>
<less-than>
<property-ref ref="prop-94680282-98c1-eae2-1836-ce7142ccb065" />
<property-value>5</property-value>
</less-than>
</if>
<then>
<hide>
<activity-structure-ref ref="as-b65b7cf6-6438-e9ca-ca41-f502a4a67133" />
</hide>
</then>
<else>
<hide>
<activity-structure-ref ref="as-670cf498-d489-6adf-1dfb-a688cb00f6a3" />
</hide>
</else>
</conditions>
En lo que se refiere a la codificación de las acciones:
§
La visualización de los componentes educativos o recursos se codifican
mediante elementos show. La referencia al componente o recurso a
visualizar se realiza mediante elementos hijo de los siguientes tipos: class,
item-ref, environment-ref, learning-activity-ref, supportactivity-ref, activity-structure-ref, play-ref, unit-oflearning-href. En todos los elementos cuyo nombre termina por –ref
se usa un atributo ref para realizar la referencia. En unit-oflearning-href se usa un atributo href. En class la referencia se lleva
a cabo usando un atributo class. También es posible utilizar los atributos
title y with-control para refinar la forma en la que se lleva a cabo la
expansión y el colapso del componente.
§
La ocultación de los componentes o recursos se lleva a cabo mediante
elementos hide. Las referencias se realizan en los mismos términos
utilizados en show (elementos class, item-ref, environment-ref,
etc).
§
El cambio del valor de propiedades se codifica mediante elementos
change-property-value. Dentro de estos, mediante property-ref se
refiere a la propiedad cuyo valor cambia (usando un atributo ref), y
mediante property-value se delimita el nuevo valor que debe tomar la
propiedad. Para ello es posible especificar un valor literal (delimitado
mediante un elemento langstring), referir a otra propiedad (elemento
property-ref) o especificar una expresión que debe utilizarse para llevar
a cabo el cálculo (elemento calculate).
Por último, las condiciones se delimitan mediante un elemento conditions. Este
elemento encierra un grupo de condiciones, que puede tener un título (elemento
102
title), así como un cuerpo de metadatos (elemento medatata). Cada condición en
sí se describe mediante dos o tres elementos consecutivos:
§
El primero, elemento if, representa la parte “si”.
§
El segundo, elemento then, representa la parte “entonces”.
§
El tercero, elemento else, representa la parte “en otro caso”.
2.8.8. Codificación de elementos globales y servicio de monitorización
IMS LD proporciona elementos globales para visualizar propiedades (viewproperty) y grupos de propiedades (view-property-group), así como para fijar el
valor de propiedades (set-property) y de grupos de propiedades (set-propertygroup). Asimismo, proporciona un vocabulario de marcas para describir servicios de
monitorización de propiedades (elemento monitor y su contenido). Dado que el uso
de estas características es avanzado y radica (en el caso de los elementos globales)
en características técnicas de las tecnologías XML, se dirige al lector interesado a la
especificación.
2.8.9. Codificación de notificaciones
Las notificaciones se codifican mediante elementos de tipo notification. Dichos
elementos pueden contener, a su vez, los siguientes:
§
email-data. Utilizado para posibilitar la notificación a través de e-mail a
distintos participantes. Este elemento incluye un atributo emailproperty-ref que hace referencia a una propiedad que debe contener la
dirección del destinatario de la notificación. Por su parte, mediante
username-property-ref puede referirse a una propiedad con el nombre
de dicho destinatario.
§
role-ref. Elemento que permite seleccionar el papel objetivo de la
notificación.
§
learning-activity-ref. Elemento que permite seleccionar la actividad
de aprendizaje que se activará como resultado de la notificación.
§
support-activity-ref. Elemento que permite seleccionar la actividad
de soporte que se activará como resultado de la notificación.
La Figura 2.8.9.a muestra la codificación de la notificación provocada por la actividad
Revisión y Mejora del Trabajo en la Figura 2.7.3.b
103
Figura 2.8.9.a. Codificación XML de una notificación.
<notification>
<email-data>
<role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" />
</email-data>
<support-activity-ref ref="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c" />
</notification>
3. IMS LEARNER INFORMATION PACKAGE
3.1. INTRODUCCIÓN
La especificación Learner Information Package de IMS (de ahora en adelante, IMS
LIP) permite el almacenamiento de información sobre los alumnos para su
procesamiento, mantenimiento e interoperabilidad en distintos sistemas de gestión del
aprendizaje (IMS Global Consortium, 2005).
Partiendo de una estructura modular que permite su aplicación en distintos contextos,
la especificación plantea un formato digital estándar para representar información
relativa a todo el proceso de formación del alumno, incluyendo su historial educativo,
experiencia profesional, calificaciones y certificados obtenidos, objetivos educativos y
habilidades adquiridas.
En este capítulo se detallan las características de la especificación IMS LIP. Para ello,
se comienza describiendo una visión conceptual de la especificación, haciendo
especial énfasis en su estructura modular. Tras esto, se presenta un caso de estudio
sencillo consistente en el modelado de un Curriculum Vitae empleando los distintos
elementos de la especificación. Este caso de ejemplo será empleado para ilustrar las
principales características de la especificación.
3.2. VISIÓN CONCEPTUAL
La idea de partida de la especificación es ofrecer un modelo de datos para almacenar
los distintos datos de los alumnos que puedan ser relevantes para el proceso de
aprendizaje. Dado que los posibles tipos de información son ricos y variados, los datos
sobre el alumno pueden provenir desde fuentes distintas e incluso estar ubicados en
sistemas de almacenamiento distintos. La especificación IMS LIP intenta maximizar su
flexibilidad permitiendo que cada dato se guarde de manera aislada.
En este contexto, un dato podría ser la información de contacto del alumno, un
certificado de estudios obtenido anteriormente, una actividad educativa ya completada,
un objetivo educativo a largo plazo, etc. Dada esta riqueza y variedad, cada dato se
104
describe como perteneciente a una determinada categoría (actividades educativas,
calificaciones, etc.) tal y como se describe en la sección 3.2.1.
Similarmente, cada dato del perfil del alumno puede tener asociada su propia sección
de metadatos, cuya estructura se detalla en la sección 3.2.2.
También cabe señalar que, aunque cada dato individual se describe por separado en
una jerarquía plana, es posible establecer conexiones entre datos que estén
relacionados. Este modelo de organización se refleja en la Figura 3.2.a.
Figura 3.2.a. Visión conceptual de un documento LIP. Los distintos datos del
alumno se guardan de manera independiente, pudiendo añadir metadatos o establecer
relaciones entre ellos.
Alumno 1
metadatos
Dato 1
metadatos
Dato 2
metadatos
Dato 3
metadatos
Dato n
relación
3.2.1. Categorías de datos
La especificación IMS LIP propone once tipos de datos o categorías para almacenar la
información del alumno. La especificación sigue un criterio de flexibilidad y de permitir
que las distintas organizaciones usen estas categorías según sus necesidades. No es
necesario usar todas estas categorías al crear los perfiles de alumno, algunas
categorías incluso se pueden usar con distintos fines. Un documento IMS LIP constará
por tanto de una serie de bloques de información desconectados, cada uno de ellos
perteneciente a alguna de las categorías que se describen a continuación.
Datos Personales
La sección identification incluye información sobre los alumnos. Esta información
puede incluir datos personales (nombre, edad, género, información demográfica, etc.)
o datos de contacto (dirección, teléfono, email, etc.).
Accesibilidad
Aunque el término accesibilidad se emplea habitualmente en el contexto de facilitar el
acceso a personas con discapacidades, el apartado accessibility de IMS LIP describe
una mayor variedad de características relativas a la capacidad del alumno para
interactuar con los entornos de aprendizaje. Así, esta sección incluye información
sobre las habilidades idiomáticas del alumno, sus preferencias acerca de formatos de
presentación, sus características cognitivas o, finalmente, sus limitaciones físicas que
105
requieran un trato especial. Para este último caso, la última versión de la
especificación IMS LIP no detalla mecanismos concretos para expresar información
relativa a discapacidades, limitándose a indicar que la especificación IMS ACCLIP
(IMS Global Consortium, 2003) deberá ser empleada para completar dicha sección tal
y como se describe en la sección 3.4.8.
Calificaciones, Certificados y Licencias
Esta sección, denominada qcl (del inglés, Qualifications, Certificates and Licenses),
incluye aquellas acreditaciones oficiales de su formación, como pueden ser títulos
obtenidos, licencias otorgadas. La especificación indica que se deberá añadir una de
estas secciones para cada título, incluyendo información de los mismos tal como la
agencia emisora, la fecha de obtención y posiblemente, una versión digitalizada de los
mismos.
Actividades
Las secciones de tipo activity describen todo tipo de actividades realizadas por el
alumno relativas al proceso educativo o de formación. También se incluyen como
actividades los servicios prestados (militar, voluntariado, etc.) y productos creados
(como trabajos o documentos). Cada actividad (por ejemplo, una asignatura) puede
acompañarse de la calificación o evaluación correspondiente, con la excepción de los
premios oficiales, que deben incluirse en secciones qcl.
Objetivos
Los objetivos educativos y las aspiraciones de los alumnos se definen mediante
secciones de tipo goal. Estas secciones pueden incluir, opcionalmente, información
para la monitorización del progreso del alumno de cara a alcanzar dichos objetivos.
Competencias
Las secciones de tipo competency describen habilidades adquiridas por el alumno.
Estas competencias pueden asociarse opcionalmente con elementos descritos en
secciones qcl o activity, indicando que son el resultado de dichas certificaciones o
actividades. En este caso, la versión actual de la especificación IMS LIP también
queda abierta, indicando que deberán usarse las estructuras identificadas por el grupo
de trabajo IMS Competency Definition. En la actualidad, este grupo de trabajo ha
publicado ya la primera versión de la especificación IMS Reusable Definition of
Competency or Educational Objective Specification (IMS Global Consortium, 2002),
que posteriormente ha sido publicada como estándar por el Institute of Electrical and
Electronics Engineers (IEEE) bajo el nombre Reusable Competency Definition (IEEE
RCD). El capítulo 4 incluye una descripción detallada de esta nueva especificación.
Intereses
Las secciones de tipo interest describen aficiones u otras actividades recreativas
practicadas por el alumno. Estas secciones pueden incluir productos asociados (como,
por ejemplo, fotos) y los intereses también pueden asociarse con premios formales
descritos en secciones qcl.
Transcripciones
Ciertas informaciones como, por ejemplo, un informe emitido por una entidad
académica, no siguen una estructura fija. Para estos casos, las secciones de tipo
transcript son las más flexibles al no forzar estructuras internas específicas.
106
Afiliaciones
Las secciones de tipo affiliation almacenan información de las organizaciones a las
que el alumno está o ha estado asociado. La información a incluir en estas secciones
contempla datos sobre la organización en cuestión, sobre la duración de dicha
afiliación y sobre el rol del alumno en la organización.
Códigos de Seguridad
Las secciones securitykey se emplean para guardar claves y contraseñas para su uso
en la comunicación con el alumno.
Relaciones
Como se ha mencionado en las descripciones de las estructuras anteriores, en
muchos casos determinados elementos de distintas secciones están relacionados. Así,
una determinada actividad educativa definida en una sección activity (por ejemplo,
completar un curso de formación profesional), puede estar relacionada con la
obtención de un certificado oficial descrito en una sección qcl y suponer la adquisición
de una serie de habilidades descritas en una sección competency. Las secciones de
tipo relationship indican relaciones entre estos elementos definidos en secciones
distintas.
3.2.2. Metadatos
Tanto el documento principal como todas las secciones incluidas en el documento
incluyen una serie de metadatos que aportan información sobre dicha sección. La
información de estos bloques de metadatos se divide en tres bloques:
Datos de identificación/referencia
Información empleada para identificar el contenido de manera única dentro del
documento, del entorno de enseñanza o de manera universal. La especificación no
detalla los mecanismos a emplear para gestionar los identificadores únicos, dejando
este aspecto en manos de las distintas implementaciones.
Datos temporales
Cada sección del documento puede tener información que describe su vigencia
temporal. Esta información incluye, por ejemplo, el periodo de validez de cada
información (por ejemplo, para indicar que una cierta licencia sólo es válida hasta una
fecha determinada).
Datos de privacidad
Cada elemento del documento puede tener asociada información relativa a los
permisos de acceso a la misma. Así, es posible indicar que determinadas
informaciones (demográficas, por ejemplo) sólo son accesibles por el propio alumno,
que otras informaciones sólo son accesibles por los instructores del propio sistema (y
por tanto no deben ser incluidas en el documento si va a ser exportado) e indicar que
otras informaciones son de dominio público. Es importante destacar que la
especificación sólo provee mecanismos para indicar esta información. Es
107
responsabilidad de las distintas implementaciones asegurar la correcta gestión de los
problemas de privacidad.
3.3. UN CASO DE ESTUDIO
Fulanito Pérez es un licenciado en informática que, para mantener sus conocimientos
actualizados, decide inscribirse en una serie de cursos online dirigidos a complementar
la formación de profesionales. Como parte de su proceso de inscripción, el Sr. Pérez
entrega el siguiente currículum:
Fulanito Pérez
INFORMACIÓN PERSONAL
•
DNI: 12345678-A
•
Fecha de Nacimiento: 08-Abril-1981
•
Lugar de nacimiento: Madrid, España
•
Nacionalidad: Española
•
Teléfono: 912 345 678
•
Dirección postal: Calle del ejemplo 234, 28199 Villaejemplo, Madrid.
•
E-Mail: [email protected]
FORMACIÓN
•
1999 – 2004: Ingeniero en Informática por la Universidad Complutense de
Madrid
RESUMEN DE CALIFICACIONES
•
Nota media en enseñanza secundaria y Selectividad: 8,40
•
Nota media en titulación universitaria (formato 1-4): 2,31
IDIOMAS
•
Nivel de Inglés Escrito y Oral: Muy Alto
•
University of Cambridge Certificate of Proficiency in English (1997) Calificación:
A
CONOCIMIENTOS TÉCNICOS
•
Programación
•
o
Programación Imperativa: Pascal, C, Basic
o
Programación Orientada a Objetos: Java, C++, Div / Div 2
o
Programación Declarativa (Lógica y funcional): Haskell, Prolog, Clips
Experiencia con la plataforma J2EE
o
Arquitecturas J2EE
o
Tecnologías J2EE (JSP, JDBC, JNDI…)
108
EXPERIENCIA LABORAL
•
2006– … : Ejemplo Consulting Inc.
o
Jefe de diseño
AFICIONES
•
Fotografía digital (http://www.misfotosdigitales.es/fulanito)
Al darse de alta en el sistema, se crea la primera versión de su currículum formalizada
mediante la especificación IMS LIP. Dado que el currículum sólo indica la obtención
del título universitario, el sistema solicita a la universidad de origen información más
detallada sobre la formación del alumno. La universidad remite esta información,
indicando las asignaturas superadas y las calificaciones detalladas siguiendo también
el formato de IMS LIP para su integración con la información ya disponible.
A medida que Fulanito va superando cursos dentro del propio sistema de formación,
estas calificaciones y habilidades quedan también reflejadas en su perfil IMS LIP. Si en
un futuro éste decidiese inscribirse en otro entorno de aprendizaje virtual compatible
con IMS LIP, toda esta información puede ser exportada directamente para su uso en
el nuevo sistema.
En las siguientes secciones se analiza la estructura concreta de la especificación IMS
LIP indicando cómo se puede usar para formalizar todos los elementos de este caso
de estudio.
3.4. ESTRUCTURA XML
El modelo de información de IMS LIP se puede expresar como lenguaje de marcado
XML. En este apartado se describen los distintos tipos de elementos (las etiquetas)
introducidos por dicho lenguaje. Para cada elemento discutido se muestra un ejemplo
de cómo emplearlo para modelar fragmentos del caso de estudio anterior.
3.4.1. Metadatos y otros elementos comunes
Como ya se ha indicado en la sección 3.2.2, todas las secciones y elementos de la
especificación IMS LIP pueden incluir una sección con metadatos que afectan a la
sección en la que se incluyan. Estos metadatos se introducen siempre mediante un
bloque contenttype cuya estructura se puede observar en la Figura 3.4.1.a. El resto
de esta sección describe estos elementos así como otras construcciones comunes a
toda la especificación IMS LIP.
109
Figura 3.4.1.a. Estructura gramatical del elemento contenttype.
Elemento
opcional
contenttype
0 .. 1
0 o más
ocurrencias
0 .. ∞
referential
0 .. 1
0 .. 1
Debe constar
al menos
uno de estos
elementos
0 .. ∞
1 .. ∞
indexid
typename
temporalfield
privacy
0 .. 1
1 .. ∞
0 .. ∞
0 .. 1
sourceid
temporal
0 .. 1
0 .. ∞
Uno de los
dos
comment
typename
privacyfield
date
ext_contenttype
Identificación/Referencia
En el bloque referential se incluye la información de identificación. Esta referencia
puede ser única para el documento, para una determinada institución o incluso
globalmente. El mecanismo de identificación emplea una de las dos siguientes
etiquetas:
§
Un elemento sourceid se emplea para identificar un registro de un alumno
específico y consta de dos partes (source e id). La primera identifica de
manera única un sistema de registro de alumnos (entorno virtual de
enseñanza, universidad, escuela, etc.) mientras que la segunda especifica el
indicador concreto del alumno.
110
§
Un elemento indexid se emplea para identificar elementos dentro del perfil de
un alumno concreto como pueden ser una calificación o la descripción de una
actividad educativa.
Temporalidad
El bloque temporal incluye la información relativa a la vigencia de los datos a los que
describe. Contiene, a su vez, dos tipos de elemento:
§
§
El elemento typename aparece en diversos campos de la especificación para
indicar un tipo dentro de una cierta taxonomía (en este caso, se emplea para
indicar el tipo de limitación temporal del dato). A su vez, este elemento se
divide en dos elementos:
-
El elemento tysource indica el vocabulario de los tipos posibles. La
especificación IMS LIP ofrece vocabularios por defecto para los
distintos contextos en los que puede aparecer un elemento typename,
denominado imsdefault. En el caso de los metadatos temporales,
este vocabulario ofrece los términos Expiry, Creation, Update y Purge.
-
El elemento tyvalue indica el tipo en sí, escogido del vocabulario
especificado en el elemento anterior.
El elemento temporalfield incluye el dato temporal en sí en forma de un par
atributo-valor compuesto por los elementos fieldlabel y fieldata.
Privacidad
El bloque privacy incluye los datos de privacidad que definen quién puede acceder a
cada dato del documento e incluye los siguientes elementos:
§
El elemento typename es similar al descrito en el apartado anterior. En este
caso, indica qué personas pueden acceder al dato que se está definiendo,
teniendo como vocabulario por defecto Creator, Owner, Steward, Learner,
Default y All.
§
Los elementos privacyfield se emplean para describir la política de
privacidad en sí mediante pares atributo-valor compuestos por los elementos
fieldlabel y fielddata.
§
Se pueden incluir opcionalmente algunos elementos de tipo date para asociar
fechas a la mencionada política de privacidad (por ejemplo, la fecha de
implantación o expiración de la política de privacidad).
Extensiones
La especificación IMS LIP está diseñada para poder ser extendida para cubrir las
necesidades emergentes de las distintas organizaciones que la adopten. En la
terminología de IMS esto se denomina crear un Perfil de Aplicación (del inglés,
Application Profile) tal y como se indica en (Fernández-Manjón et al., 2007).
Así, en la Figura 3.4.1.a podemos observar también un elemento final denominado
ext_contenttype. La especificación no indica el contenido de este elemento,
111
dejando en manos de las distintas implementaciones expandirlo según crean
conveniente.
Como se puede observar en el resto de secciones, este mismo patrón lo encontramos
en prácticamente todos los elementos de la especificación, permitiendo así introducir
modificaciones en distintas ubicaciones según sea necesario.
Descripciones
Muchos de los elementos de la especificación pueden incluir un campo denominado
description en el que se pueden incluir descripciones textuales o referencias a
ficheros externos. Estas descripciones, cuya estructura se puede observar en la Figura
3.4.1.b constan de los siguientes elementos:
•
El elemento short se emplea para incluir una descripción breve (inferior a 255
caractéres) en formato textual.
•
El campo long se emplea en cambio para incluir descripciones textuales de
longitud mayor.
•
El elemento full se emplea para hacer referencia a ficheros externos
mediante el elemento media. El elemento comment se emplea para incluir en
el fichero comentarios sobre el fichero en cuestión.
Figura 3.4.1.b. Estructura gramatical del elemento description.
description
0 .. 1
Debe constar
al menos
uno de estos
elementos
0 .. 1
0 .. 1
short
long
full
0 .. 1
1 .. ∞
112
comment
media
3.4.2. El elemento learnerInformation
El elemento learnerInformation es el elemento raíz de los documentos marcados
mediante la especificación IMS LIP. Toda la información de un documento IMS LIP se
guarda por tanto dentro de este elemento, el cual se divide en subsecciones que se
corresponden con los distintos tipos de información a almacenar. La Figura 3.4.2.a
esquematiza la estructura gramatical del mismo.
El primer elemento, de carácter opcional, es el elemento comment, empleado para
añadir comentarios u observaciones sin formato formalizado para su interpretación por
humanos. El siguiente elemento es el campo contenttype que, tal y como se
describe en la sección 3.4.1, se emplea para indicar los metadatos del elemento
activo. En este caso, el bloque contenttype del elemento learnerInformation
incluye metadatos relativos al documento completo.
Tras estos dos elementos opcionales, el elemento learnerInformation contiene
una sucesión de secciones no ordenadas que se corresponden con las 11 categorías
de datos descritas en la sección 3.2.1. Por último, encontramos el elemento
ext_learnerinfo para que las distintas organizaciones puedan añadir aquellos
elementos que consideren necesarios para extender la funcionalidad de la
especificación.
113
Figura 3.4.2.a. Estructura gramatical del elemento learnerInformation.
learnerInformation
0 .. 1
0 .. 1
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. 1
comment
contenttype
identification
goal
qcl
activity
competency
transcript
accesibility
interest
affiliation
securitykey
relationship
ext_learnerinfo
En nuestro caso de estudio, la estructura general del documento es la descrita en la
Figura 3.4.2.b. El formato del contenido concreto de cada sección (indicado en la
figura en forma de elipsis) se describe en los siguientes apartados.
114
Figura 3.4.2.b. Estructura de alto nivel de un documento IMS LIP.
<learnerinformation>
<!-- Metadatos -->
<comment>Ejemplo de uso de IMS para almacenar datos de un alumno</comment>
<contentype>
<referential>
<sourcedid>
<source>Sistema de Ejemplo</source>
<id>12345678-A</id>
</sourcedid>
</referential>
</contentype>
<!-- Secciones de contenido -->
<identification> (…) </identification>
<qcl> (…) </qcl>
<activity> (…) </activity>
<affiliation> (…) </affiliation>
<transcript> (…) </transcript>
<accesibility> (…) </accesibility>
<goal> (…) </goal>
<competency> (…) </competency>
<interest> (…) </interest>
<securitykey> (…) </securitykey>
<relationship> (…) </relationship>
<!-- Extensiones -->
<ext_learnerinfo> (…) </ext_learnerinfo>
</learnerinformation>
3.4.3. El elemento identification
El propósito de la sección de contenido identification es incluir la información
personal del alumno que no es directamente relevante para el proceso educativo,
como pueden ser datos de contacto o información demográfica.
115
Figura 3.4.3.a. Estructura gramatical del elemento identification.
identification
0 .. 1
0 .. 1
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. 1
comment
contenttype
formname
name
address
contactinfo
demographics
agent
ext_identification
Tal y como se observa en la Figura 3.4.3.a, el elemento identification incluye, al
igual que el elemento raíz learnerinformation, elementos opcionales comment y
contenttype. En este caso, los mencionados elementos contienen los comentarios y
metadatos aplicables específicamente a la sección de datos personales. Aparte de
estos elementos, que son comunes a todas las secciones de contenido de la
especificación, la sección identification también puede incluir tantas instancias
como sea necesario de los siguientes elementos:
§
Los elementos formname se emplean para definir nombres completamente
formateados, como por ejemplo “Sr. Fulanito Pérez”.
§
Los elementos name, en cambio, se emplean para almacenar el nombre del
alumno separado en campos (nombre de pila, apellidos, prefijos, etc.).
§
En los elementos address se incluyen las posibles direcciones de contacto del
alumno, usando los campos apropiados.
§
Cada elemento contactinfo se emplea para listar un modo de contactar con
el alumno, como puede ser un teléfono, un número de fax, un teléfono móvil o
una dirección de correo electrónico. Es reseñable que la especificación emplea
un elemento contactinfo para cada dato, de modo que si queremos incluir
por ejemplo dos números de teléfono y una dirección de correo electrónico,
deberemos introducir tres instancias de contactinfo.
116
§
El elemento demographics se emplea para registrar información demográfica
como pueden ser la fecha de nacimiento, el género o una referencia a una
fotografía.
§
Los elementos agent se emplean para incluir información sobre los posibles
representantes del alumno. El caso más común de representante en
enseñanza reglada son los padres o tutores del alumno y en caso de entornos
corporativos, la organización empleadora.
La figura Figura 3.4.3.b muestra el uso de estos elementos para codificar la
información correspondiente del caso de estudio. En esta figura podemos apreciar
también el uso del elemento ext_identification para extender la especificación y
añadir un nuevo campo para almacenar la nacionalidad.
Figura 3.4.3.b. Marcado en XML de la información de identificación del alumno del
caso de estudio.
<identification>
<contactinfo>
<name>
<telephone>
<partname>
<countrycode>34</countrycode>
<typename>
<areacode>91</areacode>
<tysource sourcetype="imsdefault"/>
<indnumber>2345678</indnumber>
<tyvalue>First</tyvalue>
</telephone>
</typename>
</contactinfo>
<text>Fulanito</text>
<contactinfo>
</partname>
<email>
<partname>
[email protected]
<typename>
</email>
<tysource sourcetype="imsdefault"/>
</contactinfo>
<tyvalue>Last</tyvalue>
<demographics>
</typename>
<date>
<text>Pérez</text>
<typename>
</partname>
<tysource sourcetype="imsdefault"/>
</name>
<tyvalue>Birth</tyvalue>
<address>
</typename>
<typename>
<datetime>1981-04-08</datetime>
<tysource sourcetype="imsdefault"/>
</date>
<tyvalue>Private</tyvalue>
<placeofbirth>Madrid, España</placeofbirth>
</typename>
</demographics>
<street>
<ext_identification>
<streetnumber>234</streetnumber>
<fieldlabel>
<streetname>
<typename>
Calle del ejemplo
<tyvalue>Nacionalidad</tyvalue>
</streetname>
</typename>
</street>
</fieldlabel>
<city>Villaejemplo</city>
<fielddata>Española</fielddata>
<statepr>Madrid</statepr>
</ext_identification>
<postcode>28199</postcode>
</identification>
</address>
3.4.4. El elemento qcl
Cada elemento de tipo qcl se emplea para incluir información sobre una certificación
oficial, un título académico, una licencia o, en general, calificaciones de carácter
117
general emitidas por organismos apropiados. Se debe emplear una sección qcl para
cada certificación que se desee incluir.
La Figura 3.4.4.a indica la estructura gramatical de un elemento qcl, cuyos campos
más relevantes son los siguientes:
§
El elemento typename se emplea para indicar el tipo de certificado o licencia
referido. La especificación IMS LIP incluye un vocabulario por defecto para este
campo, aunque se contempla la opción de extenderlo o adaptarlo por parte de
las distintas implementaciones.
§
El campo title se emplea para almacenar el título otorgado por la
certificación.
§
El campo organization describe a la agencia u organismo emisor de la
calificación.
§
En los casos en los que el certificado lleve asociado un número de serie o de
licencia, se debe emplear el elemento registrationno para indicarlo.
§
El elemento level se emplea para indicar si el certificado se corresponde con
algún nivel en especial (“Primera Clase”, “Con Honores”, etc.).
§
Se pueden incluir uno o varios elementos date, indicando, por ejemplo, la
fecha en que fue obtenido o el vencimiento en el caso de licencias temporales.
§
El elemento description permite incluir textos explicativos o asociar ficheros
adicionales relativos a la certificación (por ejemplo, una copia escaneada de un
título oficial).
118
Figura 3.4.4.a. Estructura gramatical del elemento qcl.
qcl
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
typename
comment
contenttype
title
organization
registrationno
level
date
description
ext_qcl
La Figura 3.4.4.b muestra cómo usar secciones qcl para registrar el título universitario
y el certificado de inglés del currículum del caso de estudio. Es interesante observar el
uso de los campos date para mostrar las fechas de inicio y graduación del alumno en
el caso del título universitario, mientras que en el segundo ejemplo sólo se indica la
fecha en la que fue obtenido el certificado.
119
Figura 3.4.4.b. Marcado en XML del título universitario y la certificación de idiomas
del caso de estudio.
<qcl>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Degree</tyvalue>
</typename>
<title>Ingeniero en Informática</title>
<organization>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Educational</tyvalue>
</typename>
<description>
<short>
Universidad Complutense de Madrid
</short>
</description>
</organization>
<date>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Start</tyvalue>
</typename>
<datetime>1999</datetime>
</date>
<date>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Finish</tyvalue>
</typename>
<datetime>2004</datetime>
</date>
</qcl>
<qcl>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Certification</tyvalue>
</typename>
<contentype>
<referential>
<indexid>qcl_cpe</indexid>
</referential>
</contentype>
<title>Certificate of Proficiency in English</title>
<organization>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Educational</tyvalue>
</typename>
<description>
<short>University of Cambridge</short>
</description>
</organization>
<date>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Award</tyvalue>
</typename>
<datetime>1999</datetime>
</date>
</qcl>
3.4.5. El elemento activity
La secciones más relevantes de los perfiles de alumno son las descripciones de las
actividades educativas llevadas a cabo. Estas actividades se describen mediante
secciones activity, las cuales a su vez se organizan en subsecciones que separan
la descripción de la actividad, los productos creados por el alumno durante la
actividad, las evaluaciones obtenidas y los posibles informes que describan el
rendimiento del alumno durante la realización de la actividad.
En la Figura 3.4.5.a se puede observar la estructura general de una sección
activity, cuyos elementos principales son los siguientes:
§
El elemento typename se emplea para indicar el tipo de informe o
transcripción. La especificación IMS LIP incluye un vocabulario por defecto
para este campo que incluye los términos Work, Service, Education, Training, y
Military, aunque se contempla la opción de extenderlo o adaptarlo por parte de
las distintas implementaciones.
120
§
Se pueden incluir uno o varios elementos date para indicar las fechas de inicio
o finalización de la actividad.
§
El elemento status refleja el estado actual de la actividad (Activa,
Completada, etc.). Dentro de este elemento se pueden incluir, aparte del
estado, la fecha en que se entró en dicho estado o una descripción más
detallada del significado de dicho estado.
§
El elemento units se emplea si se quiere asociar a la actividad algún tipo de
unidad de medida (como, por ejemplo, créditos) para cuantificar las posibles
evaluaciones asociadas.
§
El campo learningactivityref se emplea para asociar un identificador
único a la actividad correspondiente.
§
El uso de la sub-sección definition se describe en la sección 3.4.5.1.
§
El uso de la sub-sección product se describe en la sección 3.4.5.2.
§
El uso de la sub-sección testimonial se describe en la sección 3.4.5.3.
§
El uso de la sub-sección evaluation se describe en la sección 3.4.5.4.
§
El elemento description permite incluir textos explicativos o asociar ficheros
adicionales relativos a la afiliación.
§
La posibilidad de incluir más elementos de tipo activity dentro de estas
estructuras permite definir jerarquías de actividades y sub-actividades.
121
Figura 3.4.5.a. Estructura gramatical del elemento activity.
activity
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
0 .. ∞
0 .. 1
0 .. 1
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. ∞
0 .. 1
0 .. ∞
0 .. 1
date
status
units
learningactivityref
definition
product
testimonial
evaluation
description
activity
ext_qcl
La respresentación en XML de esta estructura se puede observar en la Figura 3.4.5.b,
que muestra la versión abreviada de la descripción de la actividad educativa
correspondiente a la carrera universitaria del alumno del caso de estudio. El formato
concreto de las secciones definition, product, testimonial y evaluation se
describe en los siguientes apartados.
122
Figura 3.4.5.b. Estructura general de una actividad describiendo el título
universitario del alumno del caso de estudio.
<activity>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Education</tyvalue>
</typename>
<learningactivityref>
<sourcedid>
<source>Universidad_Complutense_de_Madrid</source>
<id>306-Ingeniero_en_Informatica</id>
</sourcedid>
</learningactivityref>
<definition> (...) </definition>
<product> (...) </product>
<testimonial> (...) </testimonial>
<evaluation> (...) </evaluation>
</activity>
3.4.5.1. Descripción de Actividades: definition
Para la descripción detallada de las actividades se emplean secciones definition.
Este elemento, aunque de estructura sencilla (ver Figura 3.4.5.1.a) permite crear
definiciones complejas mediante anidamiento (ver Figura 3.4.5.1.a). Sus elementos
más relevantes son los siguientes:
§
El elemento typename se emplea para indicar el tipo de definición que
describe la sección. La especificación IMS LIP incluye un vocabulario por
defecto para este campo que incluye los términos Class, Course, Curriculum,
Module, Topic y Unit, aunque se contempla la opción de extenderlo o adaptarlo
por parte de las distintas implementaciones.
§
Los elementos definitionfield se emplean para incluir pares atributo-valor
que aportan los contenidos de la definición.
§
En los casos en los que se prefiera emplear una descripción textual en lugar (o
como complemento) de los pares atributo-valor, podemos emplear un elemento
description para incluir textos explicativos o asociar ficheros relativos a la
definción (por ejemplo, una copia escaneada de un título oficial).
§
La presencia de nuevo del elemento definition permite crear estructuras
jerárquicas. Por ejemplo, un bloque definition que describa un curso puede
incluir sub-definiciones para cada una de las clases que lo componen.
123
Figura 3.4.5.1.a. Estructura gramatical del elemento definition.
definition
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
typename
comment
contenttype
definitionfield
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
fieldlabel
fielddata
description
definition
ext_definition
En el caso de estudio, cuando el alumno Fulanito Pérez se matricula en el sistema sus
instructores requieren conocer en mayor profundidad el contenido concreto de los
estudios del alumno. Para ello, solicitan a la universidad de origen una descripción
formalizada mediante IMS LIP de los contenidos de la carrera estudiada empleando el
identificador único descrito en el elemento learningactivityref (ver Figura
3.4.5.b). La respuesta generada por los sistemas de información de la universidad de
origen podría asemejarse al contenido de la Figura 3.4.5.1.b, que comienza
empleando una serie de pares atributo-valor para definir algunas características de la
titulación (el tipo, el número de años, etc.) y posteriormente emplea la estructura
jerárquica del elemento definition para estructurar los cursos y las asignaturas
correspondientes a cada curso.
124
Figura 3.4.5.1.b. Marcado en XML de la descripción detallada de la estructura del
programa educativo de la titulación del caso de estudio.
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Curriculum</tyvalue>
</typename>
<definitionfield>
<fieldlabel>
<typename>
<tyvalue>Tipo de titulación</tyvalue>
</typename>
</fieldlabel>
<fielddata>Ingeniería Superior</fielddata>
</definitionfield>
<definitionfield>
<fieldlabel>
<typename>
<tyvalue>Número de años</tyvalue>
</typename>
</fieldlabel>
<fielddata>5</fielddata>
</definitionfield>
<!-- Primer curso -->
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Course</tyvalue>
</typename>
<description>
<short>Primer curso</short>
</description>
<!-- Asignaturas -->
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Class</tyvalue>
</typename>
<description>
<short>
Introducción a la programación
</short>
</description>
</definition>
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Class</tyvalue>
</typename>
<description>
<short>Análisis Matemático</short>
</description>
</definition>
(…)
</definition>
<!-- Segundo curso -->
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Course</tyvalue>
</typename>
<description>
<short>Segundo curso</short>
</description>
<!-- Asignaturas -->
(…)
</definition>
<!-- Tercer curso -->
<definition>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Course</tyvalue>
</typename>
<description>
<short>Segundo curso</short>
</description>
<!-- Asignaturas -->
(…)
</definition>
<!-- Resto de cursos -->
(…)
</definition>
3.4.5.2. Productos Generados en Actividades: product
Los elementos de tipo product se emplean para incluir referencias a posibles
productos generados por el alumno como parte de la actividad que está siendo
descrita. La estructura de este elemento se puede observar en la Figura 3.4.5.2.a y
estos son sus elementos principales:
§
El elemento typename se emplea para indicar el tipo de producto. La
especificación IMS LIP incluye un vocabulario por defecto para este campo
125
que incluye los términos Exam, Coursework, Portfolio y Participation,
aunque se contempla la opción de extenderlo o adaptarlo por parte de las
distintas implementaciones.
§
Se pueden incluir uno o varios elementos date para indicar las fechas de
ingreso o terminación del trabajo correspondiente.
§
El elemento description permite incluir textos explicativos que aporten
más información sobre el producto, así como ficheros digitales del mismo.
Figura 3.4.5.2.a. Estructura gramatical del elemento product.
product
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
typename
comment
contenttype
date
description
ext_product
Para ejemplificar el uso de esta sección, tomamos la posibilidad de incluir junto con los
datos del alumno, una copia de la memoria de su proyecto de fin de carrera tal y como
se observa en la Figura 3.4.5.2.b.
126
Figura 3.4.5.2.b. Marcado en XML de la inclusión de un producto asociado a una
actividad educativa.
<product>
<typename>
<tysource sourcetype="imsdefault"></tysource>
<tyvalue>Coursework</tyvalue>
</typename>
<description>
<short>Memoria del proyecto de fin de carrera</short>
<full>
<media mediamode="Text" mimetype="text/pdf">alumno/proyecto.pdf</media>
</full>
</description>
</product>
3.4.5.3. Informes sobre Actividades: testimonial
La subsección testimonial se emplea para incluir posibles comentarios formales o
informales sobre el rendimiento del alumno durante la realización de las actividades
descritas. Estos testimonios pueden ser informes de los profesores, directores de
estudios o de los superiores del alumno en el caso de actividades profesionales.
Dado que el único objetivo de las subsecciones testimonial es la inclusión de estos
informes, su estructura es realmente sencilla tal y como se puede observar en la
Figura 3.4.5.3.a. Sus elementos principales son los siguientes:
•
El elemento typename se emplea para indicar el tipo de informe. La
especificación IMS LIP incluye un vocabulario por defecto para este campo que
incluye los términos Academic, Personal, Work, Military y Service, aunque se
contempla la opción de extenderlo o adaptarlo por parte de las distintas
implementaciones.
•
Se pueden incluir uno o varios elementos date para indicar las fechas
relacionadas con el informe.
•
El elemento description se emplea para incluir el propio informe, bien como
descripción textual dentro del propio documento o mediante una referencia a
un fichero externo.
127
Figura 3.4.5.3.a. Estructura gramatical del elemento testimonial.
testimonial
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
typename
comment
contenttype
date
description
ext_testimonial
Para ejemplificar el uso de esta sub-sección, añadimos al perfil del alumno de ejemplo
una carta de recomendación escrita por su tutor durante la realización del proyecto de
fin de carrera.
Figura 3.4.5.3.b. Marcado en XML de la inclusión de un testimonio en forma de
carta de recomendación.
<testimonial>
<typename>
<tysource sourcetype="imsdefault"></tysource>
<tyvalue>Academic</tyvalue>
</typename>
<description>
<short>Informe del tutor del proyecto de fin de carrera</short>
<full>
<media mediamode="Text" mimetype="text/pdf">alumno/informeTutor.pdf</media>
</full>
</description>
</testimonial>
3.4.5.4. Evaluación de Actividades: evaluation
Las evaluaciones y notas obtenidas como parte de las actividades educativas se
representan mediante sub-secciones evaluation. Aunque la estructura de estos
apartados está muy relacionada con la especificación IMS Question and Test
Interoperability (IMS Global Consortium, 2005), la descripción detallada de dichas
relaciones queda fuera del ámbito de este informe concreto. Para mayor información,
puede consultarse el informe número 16 de esta misma serie (Fernández-Manjón et
128
al., 2007). En cualquier caso, la estructura de estos elementos (detallada en la Figura
3.4.5.4.a) se puede emplear también de manera independiente. Estos son sus
elementos más relevantes:
•
El elemento typename se emplea para indicar el tipo de evaluación. El
vocabulario inicial se centra en la especificación IMS QTI, presentando las
opciones QTI_Assessment, QTI_Section y QTI_Item.
•
El elemento result incluye la puntuación concreta de la evaluación. Este
resultado puede incluir información adicional para facilitar su interpretación.
•
Podemos emplear el campo description para incluir textos explicativos o
asociar ficheros relativos a la evaluación.
•
La presencia de nuevo del elemento evaluation permite crear estructuras
jerárquicas. Por ejemplo, una nota que es el resultado de ponderar diversas
calificaciones puede incluir sub-evaluaciones con dichas calificaciones.
129
Figura 3.4.5.4.a. Estructura gramatical del elemento evaluation.
evaluation
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
0 .. ∞
0 .. ∞
0 .. 1
0 .. ∞
0 .. 1
typename
comment
contenttype
evaluationid
date
eval_metadata
objectives
status
noofattempts
duration
result
description
evaluation
ext_evaluation
En el caso de estudio, el alumno indica en su currículum una calificación media en sus
estudios universitarios. Esta calificación es el resultado de aplicar una media a las
notas obtenidas durante la carrera y sigue un criterio de calificación entre 1 y 4 (1 =
Aprobado, 2 = Notable, 3 = Sobresaliente, 4 = Matrícula de Honor). Toda esta
información se puede formalizar mediante la especificación IMS LIP tal y como se
ejemplifica en la Figura 3.4.5.4.b.
130
Figura 3.4.5.4.b. Marcado en XML de la calificación final del alumno junto con
instrucciones para la interpretación del resultado.
<evaluation>
<interpretscore>
<result>
<fieldlabel>
<interpretscore>
<typename>
<fieldlabel>
<tyvalue>
<typename>
Matrícula de Honor
<tyvalue>Aprobado</tyvalue>
</tyvalue>
</typename>
</typename>
</fieldlabel>
</fieldlabel>
<fielddata>1</fielddata>
<fielddata>4</fielddata>
</interpretscore>
</interpretscore>
<interpretscore>
<fieldlabel>
<!-- Puntuación final -->
<typename>
<score>
<tyvalue>Notable</tyvalue>
<fieldlabel>
</typename>
<typename>
</fieldlabel>
<tyvalue>
<fielddata>2</fielddata>
Calificación Global
</interpretscore>
</tyvalue>
<interpretscore>
</typename>
<fieldlabel>
</fieldlabel>
<typename>
<fielddata>2,31</fielddata>
<tyvalue>Sobresaliente </tyvalue>
</score>
</typename>
</fieldlabel>
</result>
<fielddata>3</fielddata>
</evaluation>
</interpretscore>
3.4.6. El elemento affiliation
Las secciones de tipo affiliation se emplean para almacenar la información
relativa a la pertenencia del alumno a distintos grupos profesionales, personales,
militares o cívicos. Estas secciones son anidables, pudiendo incluir bloques
affiliation dentro de otros para dar lugar a estructuras jerárquicas.
La Figura 3.4.6.a indica la estructura gramatical de un elemento affiliation, cuyos
campos más relevantes son los siguientes:
§
El elemento typename se emplea para indicar el tipo de afiliación (Profesional,
Personal, Militar, etc.). La especificación IMS LIP incluye un vocabulario por
defecto para este campo, aunque se contempla la opción de extenderlo o
adaptarlo por parte de las distintas implementaciones.
§
El campo classification se emplea para almacenar el tipo de afiliación.
§
Si la afiliación lleva asociado una referencia (un número de socio o un
identificador de empleado), ésta se puede almacenar empleando el elemento
affiliationid.
§
Se pueden incluir varios campos role para almacenar los cargos que ha
ocupado el alumno en la organización correspondiente. Cada uno de estos
131
campos incluye información adicional sobre las fechas de comienzo y
finalización del cargo, así como otros datos relativos a las características del
mismo.
§
El campo organization describe a la agencia u organismo correspondiente.
§
Se pueden incluir uno o varios elementos date para indicar las fechas de
ingreso o terminación de la afiliación.
§
El elemento description permite incluir textos explicativos o asociar ficheros
adicionales relativos a la afiliación.
§
La presencia de nuevo del elemento affiliation permite crear jerarquías de
afiliaciones y sub-afiliaciones como, por ejemplo, la pertenencia a grupos
específicos dentro de una organización.
Figura 3.4.6.a. Estructura gramatical del elemento affiliation.
affiliation
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
132
typename
comment
contenttype
classification
affiliationid
role
organization
date
status
description
affiliation
ext_affiliation
La Figura 3.4.6.b muestra una sección affiliation de ejemplo, describiendo la
experiencia profesional del alumno del caso de estudio.
Figura 3.4.6.b. Marcado en XML de la experiencia profesional del alumno del caso
de estudio.
<affiliation>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Professional</tyvalue>
</typename>
<role>
<date>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Start</tyvalue>
</typename>
<datetime>2005</datetime>
</date>
<description>
<short>Jefe de Diseño</short>
</description>
</role>
<organization>
<description>
<short>Ejemplo Consulting Inc.</short>
</description>
</organization>
</affiliation>
3.4.7. El elemento transcript
Las secciones de tipo transcript se emplean para guardar resúmenes acerca del
rendimiento del alumno en diversas áreas o en determinadas instituciones. Son el
elemento más flexible, presentando la estructura de la Figura 3.4.7.a cuyos elementos
principales son los siguientes.
§
El elemento typename se emplea para indicar el tipo de informe o
transcripción. La especificación IMS LIP incluye un vocabulario por defecto
para este campo que incluye los términos Academic, Vocational y Training,
aunque se contempla la opción de extenderlo o adaptarlo por parte de las
distintas implementaciones.
§
El campo exrefrecord se emplea para indicar un fichero externo que
contenga el informe correspondiente. Dentro de éste elemento se puede incluir,
aparte del propio fichero, información adicional como fechas o una descripción
del contenido del informe.
§
El elemento description permite incluir textos explicativos que describan el
informe.
133
Figura 3.4.7.a. Estructura gramatical del elemento transcript.
transcript
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
exrefrecord
description
ext_transcript
Dada la naturaleza abierta de las secciones transcript, es común utilizarlas para
almacenar textos o ficheros que no terminen de encajar en otras secciones. En
nuestro caso de estudio, empleamos una sección transcript para almacenar los
datos de conocimientos técnicos del currículum de ejemplo, tal y como se muestra en
la Figura 3.4.7.b.
Figura 3.4.7.b. Marcado en XML del resumen de conocimientos técnicos del caso
de estudio.
<transcript>
<description>
<short>Conocimientos Técnicos</short>
<long>
Programación
Programación Imperativa: Pascal, C, Basic
Programación Orientada a Objetos: Java, C++
Programación Declarativa (Lógica y funcional): Haskell, Prolog, LISP
Experiencia con la plataforma J2EE
Arquitecturas J2EE
Tecnologías J2EE (JSP, JDBC, JNDI…)
</long>
</description>
</transcript>
3.4.8. El elemento accessibility
Los elementos accessibility se emplean para almacenar información relativa a las
necesidades y preferencias del alumno de cara a interactuar con el contenido
educativo. A pesar de que el término “accesibilidad” (traducción literal de
134
accessibility) se emplea a menudo en el campo de las tecnologías de
comunicación en referencia a facilitar el acceso a personas con discapacidades, en el
caso de la especificación IMS LIP se emplea este concepto de una manera más
amplia, cubriendo aspectos como los idiomas dominados por el alumno o sus
preferencias personales en cuanto al formato de contenido.
Como se puede observar en la figura Figura 3.4.8.a, el elemento accessibility
consta de cuatro subsecciones que cubren los distintos aspectos de accesibilidad
contemplados por la especificación.
§
Los elementos language se emplean para incluir información sobre las
capacidades lingüísticas del alumno. Debe incluirse un elemento de tipo
language para la información de cada uno de los idiomas dominados por el
alumno. Su uso se describe en la sección 3.4.8.1.
§
El elemento eligibility se emplea para indicar posibles recursos
adicionales que el alumno pueda requerir, como podrían ser atenciones
especiales o criterios de corrección específicos. En la versión actual de la
especificación IMS LIP este elemento queda pendiente de ser extendido en
versiones futuras de la especificación. Tal y como se describe en el capítulo 5,
la especificación IMS ACCLIP emplea este elemento para detallar los servicios
especiales que los alumnos con discapacidades puedan requerir a la hora de
realizar, por ejemplo, exámenes de evaluación.
§
El propósito de los elementos preference es indicar las preferencias
personales de acceso planteadas por el alumno y su uso se detalla en la
sección 3.4.8.2.
§
Las limitaciones ambientales o debidas a discapacidades del alumno se
expresan dentro del elemento accessForAll. Cabe señalar que la
especificación IMS LIP, en su versión actual, incluye en realidad el elemento
disability. Tal y como se describe en el capítulo 5, la especificación IMS
ACCLIP introduce en su lugar el elemento accessForAll dejando el
elemento disability obsoleto.
135
Figura 3.4.8.a. Estructura gramatical del elemento accessibility.
accesibility
0 .. 1
0 .. 1
0 .. ∞
Debe constar
al menos
uno de estos
elementos
0 .. ∞
0 .. ∞
0 .. ∞
0 .. 1
comment
contenttype
language
eligibility
preference
accessForAll
ext_accesibility
3.4.8.1. Accesibilidad idiomática: language
Dentro de una sección accessibility podemos incluir tantos elementos language
como idiomas conozca el alumno. Para cada idioma se puede definir el nivel de
habilidad en distintos aspectos siguiendo la estructura observable en la Figura
3.4.8.1.a cuyos elementos principales son los siguientes:
§
El elemento typename se emplea para indicar el lenguaje en cuestión. Como
vocabulario por defecto se sugiere emplear los estándares ISO de
denominación de lenguajes.
§
Para indicar el nivel
emplearemos varios
incluyen el atributo
(hablar), OralComp
(escribir).
de habilidad del alumno en el idioma correspondiente
elementos de tipo proficiency. Estos elementos
profmode, cuyos posibles valores son OralSpeak
(escuchar y comprender), Read (lectura) y Write
136
Figura 3.4.8.1.a. Estructura gramatical del elemento language.
language
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
0 .. ∞
0 .. 1
proficiency
ext_language
La Figura 3.4.8.1.b muestra el uso de estructuras language para indicar las
habilidades idiomáticas del alumno de ejemplo. Aparte de su conocimiento del
castellano como su idioma nativo, su elevado nivel de inglés queda también reflejado
en el ejemplo.
Figura 3.4.8.1.b. Marcado en XML de los conocimientos idiomáticos del alumno.
<language>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Spanish</tyvalue>
</typename>
<proficiency profmode="OralComp">Excelente</proficiency>
<proficiency profmode="OralSpeak">Excelente</proficiency>
<proficiency profmode="Read">Excelente</proficiency>
<proficiency profmode="Write">Excelente</proficiency>
</language>
<language>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>English</tyvalue>
</typename>
<contentype>
<referential>
<indexid>acc_ingles</indexid>
</referential>
</contentype>
<proficiency profmode="OralComp">Excelente</proficiency>
<proficiency profmode="OralSpeak">Bueno</proficiency>
<proficiency profmode="Read">Excelente</proficiency>
<proficiency profmode="Write">Bueno</proficiency>
</language>
137
3.4.8.2. Preferencias de acceso: preference
Independientemente de sus posibles discapacidades o limitaciones, los alumnos en
estos sistemas pueden expresar sus preferencias sobre el proceso de aprendizaje,
sobre los formatos a emplear, sus horarios, etc. Existe, además, una tendencia en los
entornos virtuales de enseñanza consistente en adaptar los itinerarios de aprendizaje
en función de los perfiles psicológicos de los alumnos para favorecer sus estilos
individuales de enseñanza. Este tipo de factores se describen empleando elementos
de tipo preference siguiendo la estructura de la Figura 3.4.8.2.a. y empleando los
siguientes elementos:
§
El elemento typename se emplea para indicar el tipo de preferencia. La
especificación IMS LIP incluye un vocabulario por defecto para este campo que
incluye los términos Cognitive, Physical, InputTech y OutputTech, aunque se
contempla la opción de extenderlo o adaptarlo por parte de las distintas
implementaciones.
§
El campo principal de un bloque preference es el elemento prefcode.
Dentro de este campo se incluye la referencia o descripción de la preferencia.
El formato concreto a seguir para denominar dichas preferencias depende de
las distintas implementaciones.
§
El elemento description permite incluir textos explicativos que describan
con mayor detalle la preferencia o incluyan material adicional sobre la misma.
Figura 3.4.8.2.a. Estructura gramatical del elemento preferente.
z preference
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
prefcode
description
ext_preference
Para ejemplificar el uso de estos elementos, se incluyen posibles preferencias del
alumno del caso de estudio en relación a su estilo de aprendizaje (prefiere un proceso
guiado en lugar de abierto) y su preferencia de formatos de contenido (prefiere recibir
el contenido en formato PDF para imprimir los documentos) tal y como se observa en
la Figura 3.4.8.2.b.
138
Figura 3.4.8.2.b. Marcado en XML de las preferencias del alumno para el proceso
de aprendizaje.
<preference>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Cognitive</tyvalue>
</typename>
<prefcode>Aprendizaje guiado</prefcode>
</preference>
<preference>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>OutputTech</tyvalue>
</typename>
<prefcode>Documentos PDF</prefcode>
</preference>
3.4.9. El elemento goal
Los distintos alumnos pueden tener distintos objetivos laborales, educativos o incluso
de realización personal. Estos objetivos se pueden representar en secciones de tipo
goal. Las estructuras goal presentan la estructura descrita en la Figura 3.4.9.a,
cuyos elementos principales son los siguientes.
§
El elemento typename se emplea para indicar el tipo de objetivo. La
especificación IMS LIP incluye un vocabulario por defecto para este campo que
incluye los términos Work, Education, Personal, aunque se contempla la opción
de extenderlo o adaptarlo por parte de las distintas implementaciones.
§
Se pueden incluir varios elementos de tipo date describiendo las fechas
relativas a dicho objetivo como, por ejemplo, la fecha en la que el alumno
comenzó a perseguir dicho objetivo o el plazo propuesto para alcanzarlo.
§
El campo priority se emplea para reflejar la prioridad relativa del objetivo.
Este elemento carece de estructura predefinida y no se aporta un vocabulario
concreto para su uso.
§
El elemento status refleja el estado actual del objetivo (Activo, Conseguido,
Pospuesto, etc.). Dentro de este elemento se pueden incluir, aparte del estado,
la fecha en que se entró en dicho estado o una descripción más detallada del
significado de dicho estado.
§
El elemento description permite incluir textos explicativos que describan el
objetivo en cuestión.
§
La posibilidad de incluir más elementos de tipo goal dentro de estas
estructuras permite definir jerarquías de objetivos y sub-objetivos que las
componen.
139
Figura 3.4.9.a. Estructura gramatical del elemento goal.
z goal
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
0 .. 1
typename
comment
contenttype
date
priority
status
description
goal
ext_goal
Como se mencionaba en la descripción del caso de estudio en la sección 3.3, el
objetivo del alumno al inscribirse en estos cursos es mantener sus conocimientos
informáticos actualizados. Dada su especialización, al recibir su registro, los
responsables del programa educativo analizan el objetivo principal y lo dividen en dos
sub-objetivos que quedan registrados en el perfil del alumno tal y como se puede
observar en la Figura 3.4.9.b
140
Figura 3.4.9.b. Marcado en XML de los objetivos educativos del alumno del caso de
estudio.
<goal>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Educational</tyvalue>
</typename>
<priority>Objetivo Principal</priority>
<status>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Active</tyvalue>
</typename>
</status>
<description>
<short>Mantener conocimientos actualizados</short>
</description>
<goal>
<description>
<short>Aprender nuevos lenguajes de programación</short>
</description>
</goal>
<goal>
<description>
<short>Conocer las tendencias en el uso de J2EE</short>
</description>
</goal>
</goal>
3.4.10. El elemento competency
El propósito de las secciones de tipo competency es incluir información sobre las
habilidades obtenidas por el alumno como resultado de su proceso formativo. Cuando
la primera versión de IMS LIP fue publicada, estas secciones tenían un carácter
temporal a la espera de los resultados del grupo de trabajo sobre definición de
competencias (IMS Competency Definition working-group), por lo que su estructura es
muy sencilla tal y como se observa en la Figura 3.4.10.a, incluyendo como campos
relevantes sólo los siguientes:
§
El campo exrefrecord se emplea para indicar un fichero externo que
contenga la descripción de las habilidades o competencias.
§
El elemento description permite incluir textos explicativos que describan la
competencia.
141
Figura 3.4.10.a. Estructura gramatical del elemento competency.
z competency
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
exrefrecord
description
ext_competency
Las definiciones de competencias pueden emplearse también para ofrecer una vista
más detallada de la sección de “Conocimientos Técnicos” del currículum de ejemplo.
Tal y como se ejemplificó en la sección 3.4.7, la experiencia previa del alumno se
puede almacenar dentro de un elemento transcript, pero esas descripciones no
siguen un formato estandarizado.
Asimismo, la última versión de IMS LIP publicada en enero de 2005 (1.0.1) no
contempla ninguna estructuración concreta del elemento competency para aumentar
su funcionalidad (IMS Global Consortium, 2005).
En su lugar, la especificación IMS Reusable Definition of Competency or Educational
Objective (IMS Global Consortium, 2002), descrita en mayor detalle en el capítulo 4,
sugiere emplear el campo description para incluir referencias a documentos XML
con la descripción detallada de las competencias, tal y como se observa en la Figura
3.4.10.b. La estructura detallada de este fichero externo con la definición de la
competencia “Programación imperativa: Pascal” se puede encontrar más adelante en
la sección 4.4.1.
142
Figura 3.4.10.b. Integración de documentos formalizados mediante la especificación
IMS RDCEO en una sección competency.
<competency>
<description>
<short>Programación imperativa: Pascal</short>
<full>
<media encoding="uri" mediamode="text" mimetype="text/xml">
ficheros/competencia-pascal.xml
</media>
</full>
</description>
</competency>
3.4.11. El elemento interest
Las secciones de tipo interest carecen, en principio, de significado educativo. Su
propósito es reflejar intereses o aficiones del alumno trascendiendo el ámbito
educativo. Tal y como se puede ver en la Figura 3.4.11.a, que describe la estructura
de estas secciones, las aficiones se describen mediante los siguientes campos:
§
El elemento typename se emplea para indicar el tipo de afición o actividad. La
especificación IMS LIP incluye un vocabulario por defecto para este campo que
incluye los términos Recreational, Vocational y Domestical, aunque se
contempla la opción de extenderlo o adaptarlo por parte de las distintas
implementaciones.
§
En los casos en que las aficiones del alumno se quieran ejemplificar mediante
trabajos u otros ejemplos, el campo product permite relacionar la definición
de la afición con ficheros externos siguiendo la estructura descrita en la sección
3.4.5.2.
§
El elemento description permite incluir textos explicativos que aporten más
información sobre la afición.
143
Figura 3.4.11.a. Estructura gramatical del elemento interest.
z goal
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
product
description
ext_interest
En el caso de estudio, el alumno de ejemplo mencionaba su afición por la fotografía e
incluso aportaba la dirección URL de su álbum de fotos en Internet. La Figura 3.4.11.b
muestra el uso de IMS LIP para registrar esta información mediante una sección
interest.
Figura 3.4.11.b. Uso de la sintaxis IMS LIP para almacenar información relativa a la
afición por la fotografía del alumno del caso de estudio.
<interest>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Recreational</tyvalue>
</typename>
<product>
<description>
<short>Photo Album</short>
<full>
<media mediamode="Text" mimetype="text/html" contentreftype="uri">
http://www.flickr.com/photos/fulanitoperez/
</media>
</full>
</description>
</product>
<description>
<short>Fotografía Digital</short>
</description>
</interest>
144
3.4.12. El elemento securitykey
Las secciones securitykey se emplean para almacenar las contraseñas o
credenciales de acceso del alumno. Se debe emplear una de estas secciones para
cada conjunto de credenciales. La estructura general del elemento securitykey se
puede observar en la Figura 3.4.12.a y sus campos más relevantes son los siguientes:
§
El elemento typename se emplea para indicar el tipo de credencial de acceso.
El vocabulario por defecto incluye los términos Password, Certificates, PIN y
Username, aunque se contempla la opción de extenderlo o adaptarlo por parte
de las distintas implementaciones.
§
El elemento keyfields se emplea para indicar una credencial concreta,
incluyendo los campos fieldlabel y fielddata para almacenar
respectivamente la etiqueta y el valor de la credencial.
§
El elemento description permite incluir textos explicativos que describan el
uso apropiado de la credencial.
Figura 3.4.12.a. Estructura gramatical del elemento securitykey.
securitykey
0 .. 1
0 .. 1
0 .. 1
0 .. ∞
typename
comment
contenttype
keyfields
0 .. 1
0 .. 1
0 .. 1
0 .. 1
fieldlabel
fielddata
description
definition
En el caso de estudio, cuando el alumno se registra en el sistema de gestión del
aprendizaje, éste recibe una contraseña para poder acceder al propio sistema. Esta
contraseña se puede guardar junto con el resto de la información del alumno mediante
la especificación IMS LIP tal y como se muestra en el ejemplo de la Figura 3.4.12.b.
Nótese que, dado lo sensible de la información, se emplea el campo de metadatos
145
para indicar la privacidad de este dato empleando la sintaxis descrita en la sección
3.4.1.
Figura 3.4.12.b. Uso de la especificación IMS LIP para guardar contraseñas de los
alumnos.
<securitykey>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Password</tyvalue>
</typename>
<contentype>
<privacy>
<typename>
<tysource sourcetype="imsdefault"/>
<tyvalue>Learner</tyvalue>
</typename>
<privacyfield>
<fieldlabel>
<typename>
<tyvalue>Access</tyvalue>
</typename>
</fieldlabel>
<fielddata>Read,Write,Delete</fielddata>
</privacyfield>
</privacy>
</contentype>
<keyfields>
<fieldlabel>
<typename>
<tyvalue>Clave de acceso al sistema</tyvalue>
</typename>
</fieldlabel>
<fielddata>clave_de_ejemplo</fielddata>
</keyfields>
</securitykey>
3.4.13. El elemento relationship
Todos los tipos de sección vistos hasta este momento se emplean para almacenar
distintos tipos de datos. En ocasiones, determinados hechos o datos que estén
almacenados en secciones distintas pueden estar relacionados. El último tipo de
sección, denominado relationship se encarga de establecer las conexiones entre
estas secciones separadas. La estructura gramatical de este elemento se puede
observar en la Figura 3.4.13.a y éstos son sus elementos más relevantes:
§
El elemento typename se emplea para indicar el tipo de relación establecida.
El vocabulario por defecto incluye los tipos de sección principales de la
especificación IMS LIP (Activity, Accessibility, Affiliation, Competency, Goal,
Identification, Interest, Qcl, SecurityKey y Transcript).
§
El elemento tuple representa la asociación propiamente dicha, constando a
su vez de los siguientes elementos:
146
§
-
tuplesource representa el origen de la relación y consta básicamente
de una referencia al identificador del elemento que queremos
relacionar.
-
tupledest representa el destino de la relación. Es interesante notar
que puede haber más de un elemento tupledest, lo cual permite
establecer relaciones desde un elemento de origen a varios elementos
de destino.
-
Finalmente, el elemento tuplerelation se emplea para describir el
tipo de asociación que estamos estableciendo, pudiendo usar para ello
un elemento typename o un elemento text para incluir una cadena de
texto libre.
El elemento description permite incluir textos explicativos que describan
con mayor detalle la relación entre los conceptos conectados.
Figura 3.4.13.a. Estructura gramatical del elemento relationship.
relationship
0 .. 1
0 .. 1
0 .. 1
0 .. 1
typename
comment
contenttype
tuple
1 .. 1
1 .. 1
1 .. ∞
0 .. 1
0 .. 1
tuplesource
tuplerelation
tupledest
description
ext_relationship
En el caso de estudio, el alumno incluía referencia a la obtención de un certificado de
idiomas (Certificate of Proficiency in English de la Universidad de Cambridge). La
descripción de la certificación en sí la podemos encontrar en la Figura 3.4.4.b dentro
de una estructura qcl. Similarmente, al definir su perfil de accesibilidad en la Figura
3.4.8.1.b. empleamos una entrada en la que se definían precisamente sus habilidades
idiomáticas con el inglés. Las habilidades descritas en la sección de accesibilidad se
basaban precisamente en haber obtenido la certificación. La Figura 3.4.13.b
representa precisamente esta relación, indicando que se empleó la información de la
147
certificación (con el identificador qcl_cpe, ver Figura 3.4.4.b) para establecer las
habilidades idiomáticas del alumno (con el identificador acc_ingles, ver Figura
3.4.8.1.b.).
Figura 3.4.13.b. Uso de la especificación IMS LIP para representar una relación
entre dos secciones separadas.
<relationship>
<tuple>
<tuplesource>
<indexid>acc_ingles</indexid>
</tuplesource>
<tuplerelation>
<typename>
<tyvalue>obtenido_de</tyvalue>
</typename>
</tuplerelation>
<tupledest>
<indexid>qcl_cpe</indexid>
</tupledest>
</tuple>
</relationship>
4. IMS REUSABLE DEFINITION
EDUCATIONAL OBJECTIVE
OF
COMPETENCY
OR
4.1. INTRODUCCIÓN
La especificación Reusable Definition of Competency or Educational Objective de IMS
(de ahora en adelante, IMS RDCEO) permite la descripción, referencia e intercambio
de definiciones de competencias principalmente orientadas al contexto de la
enseñanza en línea y a distancia (IMS Global Consortium, 2002). El primer aspecto es
qué se entiende por competencias ya que, aunque es el término habitualmente
empleado como traducción de competency, ni siquiera aparece con esta acepción en
el Diccionario de la Real Academia de la Lengua (www.rae.es). Una traducción
alternativa sería “cualificación” que tiene el significado de preparación para ejercer
determinada actividad o profesión. No obstante, y a pesar del abuso del lenguaje que
supone, seguiremos utilizando el término competencia ya que en esta especificación
se considera en un sentido muy general y engloba conceptos diversos como
habilidades (en inglés skills), conocimientos, tareas, resultados aprendidos (en inglés
learning outcomes) y objetivos del proceso educativo.
El propósito de la especificación es representar formalmente las características clave
de una competencia de forma general, es decir, independientemente de un uso
particular determinado o de un contexto concreto de aplicación. De este modo se
posibilita la interoperabilidad entre sistemas de enseñanza heterogéneos que
148
contemplen competencias ya que proporciona un método estándar para referirse a las
mismas de una forma común y con un mismo significado.
El núcleo de la información contemplada en RDCEO es una definición textual no
estructurada de la competencia que puede ser referenciada mediante un identificador
único. Esta información puede ser refinada si se dispone de un modelo definido por el
usuario que proporcione una determinada estructura a dicha competencia. De este
modo esta especificación permite que una comunidad de práctica determinada (un
grupo social con intereses comunes como por ejemplo, la comunidad médica)
formalice e intercambie información de competencias según el modelo propio que ellos
utilicen.
La formalización propuesta por la especificación RDCEO proporciona una forma de
crear un punto de vista común de las competencias que aparecen como parte de la
descripción de un diseño educativo o de un plan de formación ya sea como
prerrequisitos de conocimiento o como resultados a obtener. El modelo de información
en esta especificación se puede utilizar con distintos propósitos como, por ejemplo,
para intercambiar las definiciones de competencias entre sistemas de enseñanza,
entre sistemas de gestión de personal o de recursos humanos, entre sistemas de
almacenamiento de contenido educativo (repositorios) o entre sistemas de
almacenamiento de habilidades o competencias. RDCEO proporciona referencias
únicas para la descripción de competencias u objetivos educacionales que se puedan
incluir en otros modelos de información (e.g. en la información de los alumnos en un
documento que siga la especificación IMS Learner Information Package tal y como se
describe en el capítulo 3).
RDCEO se basa en un marco general de competencias que puede incluir datos sobre (ver
Figura 4.1.a):
§
Definición genérica y reusable de la competencia, incluyendo características clave
como, por ejemplo, identificador, título y descripción, pero que no incluye aspectos
contextuales de la competencia.
§
Contexto en el que se define la competencia o que define dicha competencia. El
contexto puede incluir competencias asociadas con una persona o con la
clasificación de un trabajo.
§
Evidencias de la competencia tales como resultados de evaluación, hora, fecha,
método de evaluación o identificación de la autoridad de certificación de dicha
competencia.
§
Dimensiones relacionadas con el contexto, tales como el nivel de interés de la
persona en dicha competencia o la importancia de una competencia para un
puesto de trabajo, o con la propia evidencia, tal como el nivel de alcanzado en una
competencia.
149
Figura 4.1.a. Marco general de competencias de IMS RDCEO.
Contexto
Definición
Evidencia
Dimensiones
No obstante, aunque el modelo formal propuesto por RDCEO simplifica procesos de
intercambio e integración de competencias también tiene algunas limitaciones debido
principalmente a que se centra en el formato de los datos en vez de en cómo deben
utilizarse dichos datos. Por ejemplo, permite el intercambio automático de la
información entre sistemas diferentes pero la interpretación de dicha información debe
ser realizada por una persona. Además la especificación no contempla la agregación
de competencias simples en otras competencias de mayor nivel ni aborda cómo
dichas competencias pueden ser contrastadas, certificadas, almacenadas o utilizadas
como parte de un proceso de diseño instructivo o de gestión del conocimiento.
Finalmente, tampoco especifica cómo se estructuran, almacenan o intercambian los
registros de competencias asociados con un individuo.
Esta especificación RDCEO está relacionada con otras especificaciones de IMS como
son IMS LIP, IMS Meta-Data (o su estándar relacionado IEEE LOM) o IMS Simple
Sequencing. Quizás el ejemplo más directo es su uso con IMS LIP ya que en un perfil
determinado las entradas a los objetivos (goals) o competencias (competency) pueden
ser referencias RDCEO. Otro uso indirecto es cuando se referencia un certificado
desde LIP y dicho certificado puede a su vez hacer referencia a una instancia RDCEO
concreta. La relación con LOM es doble: por un lado un registro o instancia RDCEO
puede tener su parte opcional de metadatos asociados que identifiquen aspectos
relativos, por ejemplo, al autor, al catálogo, a la fecha de creación, etc. Por otro lado,
hay campos de LOM que pueden hacer referencia a instancias RDCEO como, por
ejemplo, objetivo educacional o prerrequisito.
Tomando como partida IMS RDCEO la asociación IEEE ha propuesto un nuevo
estándar denominado Reusable Competency Definition (IEEE RCD) que ha sido
formalmente aprobado como el estándar 1484.20.1 (IEEE RCD, 2008) y publicado
definitivamente el 25 de enero de 2008.
Aunque todavía no existen clasificaciones o jerarquías estándar de competencias ni
representaciones o métodos ampliamente aceptados y usados en la industria para
articular organizar e intercambiar competencias entre sistemas sí hay un creciente
interés en el tema. Dos ejemplos de esta situación son los esquemas para la
representación de competencias en el mundo de los recursos humanos desarrollado
150
por
el
consorcio
HR-XML
(http://ns.hr-xml.org/2_3/HR-XML2_3/CPO/Competencies.html) y, en el mundo de la medicina, la iniciativa MedBiquitous
(http://www.medbiq.org/working_groups/competencies/index.html) que trata de mejorar
la educación en el campo médico mediante el desarrollo de estándares tecnológicos y
tiene un grupo de trabajo centrado en competencias.
En este capítulo se detallan las características de la especificación IMS RDCEO. Para
ello, se comienza describiendo una visión conceptual de la especificación. Tras esto,
siguiendo el caso de estudio planteado en la sección 3.3 se presenta un ejemplo de
uso consistente en el modelado de una competencia del alumno de ejemplo.
4.2. VISIÓN
CONCEPTUAL
COMPETENCIAS
DE
LA
DEFINICIÓN
DE
El modelo de datos planteado por RDCEO es minimalista pero extensible. El objetivo
es que permita representar las competencias de una forma simple pero que a la vez
no imponga restricciones sobre qué modelo de competencias se considere o de cómo
se pretendan utilizar. Esto permite que la especificación sea utilizada por diferentes
grupos de interés o comunidades de práctica para intercambiar información de
acuerdo a su propio modelo de competencias (por ejemplo, el modelo HR-XML para el
caso de la gestión de recursos humanos).
La extensibilidad se puede lograr de dos maneras: o bien mediante la propia definición
de competencia u objetivo educacional o bien mediante la inclusión de metadatos
(este aspecto se describe más adelante con mayor nivel de detalle).
El modelo de información propuesto para una definición de competencia reutilizable es
bastante simple y consta de cinco elementos principales (Figura 4.2.a):
Identificador
El campo identificador (identifier) es una etiqueta que identifica de forma unívoca una
definición de competencia o un objetivo educacional. Este identificador es suficiente
para poder hacer referencia a una competencia en cualquier sistema. Este
identificador consta de dos partes: un catálogo y una entrada.
Título
El campo título (title) es una etiqueta obligatoria que identifica la competencia de forma
que pueda ser comprensible para las personas. Habitualmente la referencia unívoca
que es el identificador no da idea de lo que representa dicha competencia. El título
puede repetirse en distintos idiomas.
Descripción
El campo descripción (description) es un campo de texto opcional que describe la
competencia de forma que sea interpretable por una persona. Esta descripción puede
repetirse en varios idiomas.
Definición
El campo definición (definition) es una descripción opcional y estructurada de la
competencia, en la que normalmente se usan atributos tomados de un modelo
151
específico sobre cómo deben estructurarse o definirse estas competencias u objetivos
educativos. Con este propósito una definición puede incluir un identificador opcional
del modelo usado (model) y una colección arbitraria de asertos o expresiones
(statements) que determinan dicha competencia. En una definición reutilizable pueden
aparecer varias definiciones, por ejemplo, para describir una misma competencia de
acuerdo con distintos modelos.
Metadatos
Los metadatos (metadata) son opcionales y corresponden a toda la definición. Se
recomienda que para este campo se empleen los elementos que se consideren
relevantes de los definidos por LOM.
Figura 4.2.a. Estructura de una definición de competencia IMS RDCEO.
1
1
competencia
identificador
título
0.. ∞
descripción
0.. ∞
0..1
definición
Metadatos
4.3. EJEMPLOS DE POSIBLES APLICACIONES
Como ya se ha mencionado la especificación se centra en la representación de los
datos de las competencias dentro de su marco general de referencia pero no entra en
cómo deben usarse. No obstante en el documento de buenas prácticas y guía de
implementación que se incluyen con la especificación también se describen algunas
posibles formas en las que se puede aplicar RDCEO.
4.3.1. Casos de uso
Uno de los usos descritos es su aplicación como bloques constructivos para crear
mapas o taxonomías de competencias. Estos mapas o taxonomías serían
básicamente una colección organizada de referencias a definiciones de competencias
RDCEO. Esto normalmente implica incluir información de relación y clasificación y la
forma de realizarlo es mediante el uso del campo de metadatos para cada
competencia.
Un segundo ejemplo típico es el uso de RDCEO en el análisis de habilidades de una
persona. Normalmente los registros de competencias personales contienen
información sobre la evidencia de habilidades o conocimientos (o la ausencia de ellos)
152
conjuntamente con una referencia a una definición de competencia. Estas definiciones
de competencia también se pueden referenciar desde un determinado modelo de
competencias. Por tanto haciendo la correspondencia entre estos dos usos se puede
generar una colección de referencias de definición de competencias donde se
relacionan habilidades y competencias sin tener que repetir información. Además de
este modo la información se almacena de una forma estándar y, por tanto, de una
forma más interoperable. Este aspecto podría usarse, por ejemplo, en los sistemas de
enseñanza que son capaces de adaptar y personalizar el comportamiento del sistema
para cada usuario concreto, de modo que tener una descripción de sus conocimientos
previos y sus objetivos es crucial en todo el proceso.
Pero quizás el mayor campo de aplicación es en e-learning en relación con el nuevo
modelo introducido con el modelo de objetos de aprendizaje (OA) (Polsani, 2003;
Balatsoukas et al., 2008) y su evolución a unidades de aprendizaje (con el significado
introducido por la especificación IMS LD descrita en la sección 1.5). Si el sistema de elearning que usa OA tiene incluidos procesos de evaluación del conocimiento
adquirido al superar cada OA, entonces la relación con competencias RDCEO puede
establecerse directamente. En el caso de unidades de aprendizaje que tienen un
mayor tamaño las competencias y objetivos educativos pueden agregarse en
competencias de mayor complejidad.
Esto permite crear nuevos escenarios de uso en el diseño de cursos ya que un
educador podría comenzar el diseño de un curso especificando cuáles son sus
objetivos educativos (learning outcomes) para, a continuación, buscar o desarrollar los
OA o unidades de aprendizaje que mediante su composición permiten obtener los
objetivos educativos deseados. Esto mismo se podría hacer con los procesos de
evaluación formal de la adquisición de dichas competencias (si es que existen).
Este enfoque permite también nuevas oportunidades para los usuarios ya que
simplificaría la localización de cursos en función de los intereses que tengan, del
conjunto de carencias que se quieran resolver o de las habilidades que se necesiten
adquirir para resolver una determinada necesidad (por ejemplo, habilidades o
capacidades laborales necesarias para obtener un mejor puesto de trabajo).
4.3.2. Ejemplo de uso
Para ejemplificar el uso de la especificación RDCEO en las siguientes secciones, se
trata de complementar el caso de estudio propuesto en el capítulo 3. Dicho caso de
estudio incluía un ejemplo de currículum vítae de un alumno con informaciones
diversas que podían ser formalizadas empleando la especificación IMS Learner
Information Package (IMS Global Consortium, 2005).
Desde el punto de vista de la definición de competencias, resulta especialmente
interesante el siguiente fragmento extraído del currículum de ejemplo de la sección
3.3, que nos servirá para ejemplificar el uso de RDCEO para definir competencias.
153
(…)
CONOCIMIENTOS TÉCNICOS
•
Programación Imperativa: Pascal
(…)
En el caso de estudio, este fragmento correspondiente a los conocimientos técnicos
del alumno se describía informalmente como parte un bloque de tipo transcript
como se observa en la Figura 3.4.7.b. Tal y como se indicaba en la sección 3.4.10, el
campo description de una definición de competencia en un documento IMS LIP
puede incluir una referencia a un documento externo codificado de acuerdo con la
especificación RDCEO (ver Figura 3.4.10.b). Este documento contiene una descripción
más formal y estructurada de las competencias del alumno. La siguiente sección
describe la estructura detallada de estos documentos de definición de competencias.
4.4. ESTRUCTURA XML
El modelo de información de IMS RDCEO se puede expresar como lenguaje de
marcado XML. En este apartado se describen los distintos tipos de elementos (las
etiquetas) introducidos por dicho lenguaje en el esquema documental (XML schema)
propuesto en la especificación.
En la definición de las competencias hay dos elementos comunes que se utilizan en
distintas partes:
§
Cadenas de caracteres. Las cadenas de caracteres representan frases
orientadas a ser interpretadas por una persona. Se usa el elemento
langstring que tiene el atributo xml:lang para permitir especificar el idioma
en el que está dicha frase.
§
Términos de un vocabulario. Los términos de un vocabulario vienen
determinados por el elemento source que identifica el vocabulario fuente y por
el elemento value que describe el término concreto (token) dentro de dicho
vocabulario.
4.4.1. El elemento rdceo
El elemento rdceo es el elemento raíz de los documentos marcados mediante la
especificación IMS RDCEO.
§
§
El primer elemento, de carácter obligatorio, es el elemento identifier, que
identifica de forma única a la competencia.
El siguiente elemento es el campo title que debería ser una etique concisa
para que una persona pueda saber de qué trata la competencia.
154
§
§
§
El elemento description permite añadir una descripción en lenguaje natural
que describa la competencia y puede aparecer varias veces, por ejemplo, en
distintos idiomas.
El elemento definition es opcional y contiene una definición estructurada
de la competencia. Esta definición estructurada consiste en una posible
referencia a un modelo y una serie de expresiones (como se describe más
adelante). Si se repite el elemento cada ocurrencia debe corresponder a un
modelo distinto.
El elemento metadata es opcional y contiene metadatos globales a la
competencia. Se recomienda que estos metadatos sigan el estándar LOM.
La Figura 4.4.1.a esquematiza la estructura gramatical del elemento rdceo.
Figura 4.4.1.a. Estructura gramatical del elemento rdceo.
Siguiendo esta estructura, la competencia “Programación Imperativa: Pascal” del caso
de estudio se puede describir con mucho detalle. En la figura Figura 4.4.1.b podemos
encontrar la descripción de acuerdo con el Currículo Conjunto en Computación
definido por el Institute of Electrical and Electronics Engineers (IEEE) y la Association
for Computing Machinery (ACM)
(http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf ).
155
Figura 4.4.1.b. Ejemplo de documento IMS RDCEO que define la competencia
“Programación imperativa: Pascal” según el currículo propuesto por los organismos
IEEE y ACM.
<?xml version="1.0" encoding="utf-8"?>
<rdceo>
<identifier>
http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf#PF1
</identifier>
<title>
<langstring xml:lang="es-ES">Programación Imperativa: Pascal</langstring>
</title>
<description>
<langstring xml:lang="es-ES">
Domina los conceptos de la programación imperativa estructurada y el lenguaje de
programación Pascal
</langstring>
</description>
<definition>
<model>IEEE and ACM Join Computing Curricula</model>
<statement statementname="Condition">
<statementtext>
<langstring xml:lang="es-ES">
Ha superado un curso de Introducción a la Programación centrado en los principios
de la programación estructurada
</langstring>
</statementtext>
</statement>
<statement statementname="Condition">
<statementtext>
<langstring xml:lang="es-ES">
Domina la sintaxis del lenguaje de programación Pascal
</langstring>
</statementtext>
</statement>
<statement statementname="CoreKnowledge">
<statementtext>
<langstring xml:lang="es-ES">
Construcciones fundamentales de la programación imperativa
</langstring>
</statementtext>
</statement>
<statement statementname="CoreKnowledge">
<statementtext>
<langstring xml:lang="es-ES">Algoritmos y solución de problemas</langstring>
</statementtext>
</statement>
<statement statementname="CoreKnowledge">
<statementtext>
<langstring xml:lang="es-ES">Fundamentos de estructuras de datos</langstring>
</statementtext>
</statement>
</definition>
<metadata>
<rdceoschema>IMS RDCEO</rdceoschema>
<rdceoschemaversion>1.0</rdceoschemaversion>
<lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1">
<!-- Metadatos LOM -->
</lom>
</metadata>
156
4.4.2. El elemento identifier
El propósito del elemento identifier es tener una identificación unívoca de la
competencia. De hecho una vez publicada una competencia nunca debería ser
modificada y si es necesario modificarla habría que crear una nueva o incluso una
copia.
Este identificador es obligatorio y está compuesto de un identificador de catálogo y una
entrada en dicho catálogo que se concatenan con el carácter “#” formando una cadena
única. La idea es que el identificador sea un URN (Universal Resource Name) o una
URI (Universal Resource Indicator). Si no aparece el carácter “#” se asume que la
cadena es la entrada del catálogo y el valor del catalogo es nulo. Por ejemplo, en la
figura Figura 4.4.1.b encontramos la siguiente cadena:
http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/
cc2001/cc2001.pdf#PF1
La primera parte es la dirección web del informe que describe los contenidos del
currículo, mientras que la entrada concreta en dicho catálogo sería “PF1”.
4.4.3. El elemento title
El propósito del elemento title es tener una etiqueta de la definición de competencia
que sea comprensible por una persona. Tiene que haber un único título para cada
definición de competencia pero dicho título puede aparecer en distintos idiomas. Por
ejemplo, una definición con un título tanto en inglés americano como en español sería:
<title>
<langstring xml:lang="en-US">Imperative Programming: Pascal
</langstring>
<langstring xml:lang="es-ES">Programación Imperativa:
Pascal</langstring>
</title>
4.4.4. El elemento description
El propósito del elemento description es tener un campo de texto opcional que
describe la competencia de forma más extensa y que sea entendible por una persona.
Esta descripción también puede repetirse en varios idiomas.
4.4.5. El elemento definition
El elemento definition es opcional y su propósito es poder proporcionar una
definición estructurada de la competencia. Como se observa en la Figura 4.4.5.a, una
definición puede incluir un identificador opcional del modelo usado (model) y una
colección arbitraria de asertos o expresiones (statements) que determinan dicha
157
competencia. En una competencia pueden aparecer varias definiciones, por ejemplo,
para describir esa misma competencia de acuerdo con distintos modelos.
Figura 4.4.5.a. Estructura gramatical del elemento definition (omitiendo
atributos).
0..1
definition
1.. ∞
model
statement
0.. ∞
0.. ∞
statementtext
statementtoken
El elemento opcional model permite incluir una cadena que identifique qué modelo se
utiliza como referencia para proporcionar la definición estructurada de la definición.
Este modelo debe ser suficientemente específico para evitar conflictos de nombres,
por tanto, se recomienda que sea una URI (Universal Resource Indicator).
El elemento statement es una colección arbitraria de uno o más asertos o
expresiones que determinan la definición de estructura de la competencia. Cada
expresión es una descripción de una característica de la definición. Una expresión está
compuesta de las siguientes partes:
§
statementid, este atributo opcional es una cadena de texto que actúa como
identificador local de la expresión dentro del modelo
§
statementname, este atributo opcional es un token que se usa para etiquetar
la expresión. Este token se toma del vocabulario fuente definido en el modelo
identificado por el elemento model.
§
statementtext, este elemento opcional es una descripción textual de los
aspectos de la competencia. Este texto puede aparecer repetido en varios
idiomas.
§
statementtoken, este elemento opcional es un token que se obtiene de una
fuente controlada como, por ejemplo, un vocabulario. Es un término de un
vocabulario y como se ha descrito previamente, está compuesto por dos
elementos que determinan el propio token (value) y la fuente de de la que
proviene (source).
Aunque propiamente dichos todos los elementos y atributos de una expresión son
opcionales, en la práctica en una expresión debe aparecer por lo menos uno de dichos
componentes para que la expresión sea útil. Normalmente si aparece el elemento
statementtext entonces no aparece el elemento statementtoken y viceversa.
158
4.4.6. El elemento metadata
El elemento metadata es opcional y su propósito es proporcionar un contenedor para
cualquier tipo de metadatos (aunque se recomienda que para estos metadatos se use
el estándar LOM). Los componentes de este elemento son:
§
rdceoschema, es un elemento opcional que determina el esquema (schema)
documental RDCEO utilizado en la definición de competencia. Si no aparece se
asume que su valor es “IMS RDCEO”. Si aparece otro valor puede indicar que
se está usando un perfil de aplicación concreto (eso sí, no debe usarse para
indicar qué modelo concreto se está empleando).
§
rdceoschemaversion, es un elemento opcional que permite especificar la
versión del esquema RDCEO que se utiliza. Si no aparece se asume que es la
versión 1.0.
4.5. EXTENSIBILIDAD
Esta especificación contempla desde un principio que, a pesar de la generalidad con la
que se tratan de definir las competencias, puede darse el caso de aplicaciones que
consideren que dichas definiciones son demasiado restrictivas y, por tanto, necesiten
ampliarlas o extenderlas para lograr sus objetivos concretos.
La extensibilidad se puede lograr de dos maneras: o bien mediante la ampliación de la
propia definición de competencia con nuevos elementos y atributos, o bien mediante la
utilización del elemento de metadatos. En la especificación se recomienda que se
emplee la primera de las formas.
La extensibilidad mediante la inclusión de elementos adicionales es posible en los
siguientes elementos:
§
<rdceo>
§
<title>
§
<description>
§
<definition>
§
<statement>
§
<statementtext>
§
<statementtoken>
§
<metadata>
Los elementos adicionales deben cumplir dos condiciones: la primera es que deben ir
después de los elementos ya definidos en la especificación, y la segunda es que los
elementos de extensión deben contener una declaración de espacio de nombres
159
diferente a la del elemento contenedor. En este segundo caso el espacio de nombres
puede ser expresado mediante mecanismos de bloque o de prefijo.
Figura 4.5.a. Visualización del schema RDCEO en XMLSpy donde aparece el
mecanismo de extensibilidad extelement para el elemento rdceo.
5. IMS ACCESS FOR ALL
5.1. INTRODUCCIÓN
Una de las principales características de los entornos virtuales de enseñanza es que
universalizan el acceso a la información y el conocimiento, facilitando los procesos de
aprendizaje “en cualquier momento” y “en cualquier lugar”. Pero esta característica
realmente no se extiende a “cualquier persona” ya que muchos de estos sistemas
tienden a excluir a las personas con distintos tipos de discapacidad.
Las más afectadas suelen ser las personas con ceguera total o parcial. Lo más
habitual en estos casos es que los usuarios accedan a Internet empleando
navegadores textuales con capacidad de leer el texto de las páginas web en voz alta,
pero la mayoría de las aplicaciones web, en un intento de mejorar sus diseños y
estética, tienden a ignorar este hecho y emplean elementos que resultan muy
160
disruptivos para este tipo de navegadores (como interfaces realizadas con Flash u
otros elementos activos no textuales).
Existen distintos esfuerzos que intentan conseguir que la Web sea universalmente
accesible, la mayoría de ellos encaminados a crear páginas limpias y organizadas
empleando aquellos elementos del estándar HTML que casan mejor con el uso de
navegadores adaptados para personas con discapacidad. Estándares y
recomendaciones como los propuestos por el Consorcio W3C a través del Grupo de
Trabajo para Guías de Accesibilidad del Contenido Web (Web Content Accessibility
Guidelines Working Group o WCAG WG - http://www.w3.org/WAI/GL/) tratan este
problema de una manera genérica, intentando mejorar la accesibilidad de la web en
general.
En el caso de los entornos virtuales de enseñanza el problema es incluso más
acuciante. Muchos contenidos educativos se basan en el uso de diagramas, imágenes
y vídeos que no son aptos para personas ciegas. Similarmente, un vídeo en el que el
sonido juegue un papel importante (por ejemplo, al incluir una voz que describe los
eventos) no resulta accesible para personas sordas.
Cuanto más ricos y variados son los formatos en los que se plasma el contenido
educativo, más necesario se hace ir más allá de las recomendaciones publicadas por
el Consorcio W3C para la generación de documentos accesibles.
5.1.1. Una problemática compleja
AccessForAll es la denominación genérica empleada por el consorcio IMS para
designar sus iniciativas y esfuerzos relacionados con potenciar la accesibilidad de los
contenidos educativos a personas con necesidades especiales derivadas de su
entorno, circunstancias o discapacidades.
Es importante señalar que en aunque otros estándares y recomendaciones emplean el
término “accesibilidad” para referirse a la habilidad de ciertos sistemas de información
para ajustarse a las necesidades de personas con discapacidades, desde IMS se
amplía la definición de este concepto defendiendo que, en ciertos contextos, cualquier
usuario puede necesitar contenidos especialmente adaptados independientemente de
su condición física (por ejemplo, una persona en un sitio público no puede acceder a
contenidos sonoros independientemente de sus condiciones físicas) . Se redefine por
tanto el concepto de “accesibilidad” para incluir cualquier desajuste entre las
necesidades del alumno y las características del contenido educativo presentado. Un
sistema se considera accesible si es capaz de modificar su comportamiento y
contenido para ajustarse a las necesidades de los distintos alumnos en los distintos
contextos de aprendizaje. Esto supone ampliar la noción específica de “discapacidad”
por la noción de “diversidad funcional”.
Esto añade una complejidad más en el proceso, al exigir que el proceso de adaptación
para accesibilidad no se centre en alumnos concretos, sino en una combinación del
alumno y el entorno. Para ejemplificar esta problemática, planteamos el siguiente
ejemplo, adaptado a partir de uno de los casos de uso de la especificación IMS
ACCLIP (IMS Global Consortium, 2003):
161
Los técnicos de mantenimiento de una compañía aérea tienen
acceso a un repositorio de materiales didácticos con información
sobre los procesos de reparación y mantenimiento de los motores
de los distintos aviones con los que trabajan. Los trabajadores
suelen acceder a estos contenidos como parte de su programa de
entrenamiento, habitualmente desde su casa. Por otro lado, durante
muchos procedimientos, estos trabajadores emplean ordenadores
portátiles para seguir los contenidos y tutoriales mientras realizan las
reparaciones. Pero estos procedimientos se realizan en entornos
ruidosos (como un hangar de un aeropuerto) y la normativa de
seguridad exige que los trabajadores empleen protecciones
auditivas. Por tanto, uno de estos trabajadores que accede al
sistema desde su casa puede seguir sin dificultad contenidos en
forma de, por ejemplo, video-tutoriales. Pero si el mismo trabajador
accede desde el hangar, el sistema deberá adaptar o sustituir estos
contenidos para permitir su consulta sin necesidad de escuchar los
contenidos sonoros (por ejemplo, añadiendo subtítulos al vídeo).
5.1.2. Tres aspectos de un mismo problema
La idea de partida de la iniciativa IMS AccessForAll es que para garantizar que los
alumnos con necesidades especiales (debidas a condiciones personales o de su
entorno) puedan acceder a los contendos educativos digitales es necesario un
enfoque que ataque el problema desde varias perspectivas distintas (ver Figura
5.1.2.a).
En primer lugar, es necesario ser consciente durante la creación de los contenidos de
aquellas características de los mismos que los pueden hacer poco accesibles, como
por ejemplo el uso de materiales sonoros sin subtítulos descriptivos o el uso de
diagramas que no puedan ser interpretados por sistemas sonoros para personas de
visión limitada. Este primer tema, de gran importancia y complejidad, no es tratado por
IMS a nivel de especificación al considerar que existen numerosos recursos y
materiales con indicaciones sobre la creación de contenidos accesibles. Aún así, el
grupo de trabajo AccessForAll ha publicado un documento con una descripción
abreviada y muy general de algunas de las ideas que deberían aplicarse (IMS Global
Consortium, 2005). Este documento incluye numerosas referencias a información
sobre la creación de contenidos más accesibles.
Pero este problema no es el principal desde el punto de vista de la creación de
entornos virtuales de enseñanza. El problema que debe abordarse y en el que se
centran los esfuerzos de AccessForAll es el de alinear las necesidades de los distintos
usuarios y entornos con los materiales educativos apropiados.
Para cada alumno es necesario conocer sus necesidades personales concretas así
como los posibles contextos que puedan añadir nuevas necesidades puntuales. Una
vez se dispone de esta información, es necesario encontrar los contenidos apropiados
para satisfacer estas necesidades concretas.
Por este motivo, el grupo de trabajo IMS AccessForAll ha publicado dos
especificaciones distintas, las cuales se describen en este capítulo. La especificación
162
IMS Accessibility for LIP (IMS Global Consortium, 2003) extiende la especificación IMS
LIP descrita en el capítulo 3, permitiendo registrar las preferencias y necesidades de
accesibilidad de los alumnos registrados en el sistema en sus distintos contextos.
La especificación IMS AccessForAll Metadata (IMS Global Consortium, 2004), por su
parte, se centra en asociar metadatos relativos a la accesibilidad a los contenidos
educativos desplegados en el sistema.
El proceso de permitir el acceso universal consiste por tanto en encontrar y servir
contenidos cuyos metadatos sobre accesibilidad coincidan con las necesidades del
perfil de cada alumno específico.
Figura 5.1.2.a. Especificaciones y documentos producidos por el grupo de trabajo
IMS AccessForAll.
Guidelines for the Development
of Accessible Applications
AccessForAll
IMS AccessForAll
MetaData specification
IMS Accessibility for LIP
specification
5.2. IMS ACCESSIBILITY FOR LIP
La especificación IMS Accessibility for LIP (de ahora en adelante, IMS ACCLIP)
supone una extensión de la especificación original IMS LIP (descrita en el capítulo 3)
orientada a permitir la inclusión en los perfiles de los alumnos información acerca de
sus necesidades derivadas de características ambientales o fisiológicas.
La especificación se centra en dos modificaciones concretas que se realizan sobre la
especificación IMS LIP. La primera, tal y como se describe en la sección 5.2.1 es la
inclusión de estructuras para indicar las preferencias y necesidades de cada alumno
de cara a interactuar con el contenido del sistema. La otra modificación, descrita en la
sección 5.2.2, es la inclusión de mecanismos para definir peticiones especiales de los
alumnos de cara a interactuar con determinados elementos de contenido, como podría
ser la necesidad de usar un intérprete durante un examen.
163
5.2.1. Definición de Preferencias
Las preferencias que se pueden definir mediante la especificación IMS ACCLIP se
dividen en tres categorías fundamentales:
§
Formato: Los perfiles de los alumnos pueden incluir peticiones sobre los
dispositivos de salida especiales que pudiesen necesitar así como el formato
de los contenidos a mostrar, incluyendo elementos como los tamaños de los
textos, las combinaciones de colores o el comportamiento de la interfaz de
usuario.
§
Control: En esta categoría incluimos las necesidades especiales referidas a los
mecanismos de entrada mediante los cuales el alumno interactúa con el
sistema como pueden ser un teclado, un ratón, un sistema de comandos de
voz, un dispositivo de braille, etc.
§
Contenido: Ciertos contenidos incluyen características que los hacen poco
accesibles como pueden ser diagramas explicativos o recursos sonoros. La
especificación IMS ACCLIP permite definir las necesidades que un alumno
pueda tener de cara a disponer de contenidos alternativos en estos casos.
Por otro lado, como ya se mencionaba en el ejemplo de la sección 5.1.1, los requisitos
de AccessForAll incluyen la posibilidad de que un mismo alumno tenga necesidades
distintas en distintos contextos (distinguiendo por ejemplo entre acceder desde un
ambiente tranquilo o un entorno ruidoso).
Partiendo de estos requisitos, la especificación IMS ACCLIP extiende la funcionalidad
del elemento accessibility de la especificación IMS LIP (ver sección 3.4.8)
añadiendo un nuevo elemento denominado accessForAll2, cuya estructura
podemos observar en la Figura 5.2.1.a.
Figura 5.2.1.a. Estructura gramatical del elemento accessForAll empleado para
indicar las preferencias y necesidad de accesibilidad de los alumnos.
accessForAll
1 .. ∞
context
0 .. 1
display
0 .. 1
control
0 .. 1
content
El elemento accessForAll del perfil de cada alumno puede contener uno o más
elementos de tipo context. Esto permite definir, para un mismo alumno, distintos
2
La especificación IMS LIP incluye el elemento disability originalmente pensado para
cubrir algunos de los aspectos ahora cubiertos por IMS ACCLIP. Con la introducción del
elemento AccessForAll, el elemento disability queda obsoleto y no debe usarse.
164
perfiles de accesibilidad en función del entorno o la situación en que se encuentre, de
acuerdo con las necesidades identificadas en el ejemplo de la sección 5.1.1, tal y
como se observa en la Figura 5.2.1.b. Cada posible perfil definido puede contener,
opcionalmente, los siguientes elementos:
§
El elemento display se emplea para definir requerimientos y preferencias
relativas a los formatos y tecnologías de salida empleados por el sistema. Este
elemento, de gran complejidad, permite indicar cuestiones como la necesidad
de emplear software que lea la información textual de la pantalla (así como
todos sus parámetros de configuración), la necesidad de emplear técnicas que
aumenten la legibilidad de los contenidos (por ejemplo, ampliando el tamaño de
las letras o aumentando el contraste), el uso de dispositivos que traduzcan los
textos a braille, etc.
§
El elemento control se emplea para definir requerimientos y preferencias
relativas a los mecanismos de entrada. Mediante este elemento se pueden
indicar necesidades como el empleo de teclados especiales (con teclas más
accesibles o mostrados por pantalla), emulación del uso del ratón mediante
mecanismos alternativos (uso del teclado o de dispositivos que detectan el
lugar hacia donde apuntan los ojos) o incluso interacción mediante
reconocimiento de voz.
§
El elemento content, por su parte, se emplea para indicar los tipos de
contenido alternativo que el alumno puede usar en caso de que los contenidos
por defecto no se ajusten a sus necesidades de accesibilidad. Mediante este
elemento se definen, por ejemplo, posibles alternativas al uso de elementos
visuales, alternativas a los elementos sonoros, necesidad de evitar textos o
incluso la necesidad de emplear materiales adicionales como diccionarios o
calculadoras de cara a interactuar con el contenido. Este elemento se refleja
directamente en la especificación IMS AccessForAll Metadata, empleada para
indicar las modalidades de cada unidad de contenido y para describir las
características de los posibles recursos alternativos tal y como se describe en
la sección 5.3.
165
Figura 5.2.1.b. Ejemplos de definición de contextos para su inclusión en el perfil de
un usuario concreto formalizados mediante la especificación IMS ACCLIP. Se
muestran definiciones de contextos para casos de discapacidad visual o para acceso
mediante un dispositivo móvil.
<context identifier="Discapacidad-Visual">
<display>
<braille>
<brailleGeneric>
<grade usage="required" value="1"/>
<numDots value="8"/>
<numCells value="80"/>
<dotPressure value="0.5"/>
<statusCell value="left"/>
</brailleGeneric>
</braille>
</display>
<control>
<voiceRecognition>
<voiceRecognitionGeneric>
<microphoneGain value="0.5"/>
<controlsWindow value="true"/>
</voiceRecognitionGeneric>
</voiceRecognition>
</control>
<content>
<alternativesToVisual>
<audioDescription
usage="required" type="expanded"/>
</alternativesToVisual>
</content>
</context>
<context identifier="Dispositivo-Movil ">
<display>
<structuralPresentation>
<contentDensity
usage="preferred" value="overview"/>
<contentViews
usage="notUse" value="imageIntensive"/>
</structuralPresentation>
</display>
<control>
<tactile>
<tactileGeneric/>
</tactile>
</control>
<content>
<alternativesToVisual>
<audioDescription
usage="preferred" type="expanded"/>
<longDescriptionLang
usage="preferred"/>
</alternativesToVisual>
</content>
</context>
5.2.2. Solicitud de servicios adicionales
Los alumnos con necesidades especiales de accesibilidad pueden necesitar de
apoyos o servicios adicionales cuando interactúan con determinadas unidades de
contenido. Esto es especialmente aplicable cuando tratamos con exámenes y tests
para los cuales un alumno puede solicitar estos apoyos adicionales de cara a realizar
la prueba en las mejores condiciones posibles. Estos apoyos podrían incluir el uso de
un intérprete, ubicarse en una sala distinta al resto de participantes, usar dispositivos
de entrada/salida alternativos o disponer de tiempo adicional para realizar la prueba.
La especificación IMS ACCLIP presenta los elementos necesarios para formalizar y
almacenar el proceso de solicitar estos servicios y la gestión de su autorización si
procede. Según la visión de esta especificación, una autorización para el uso de
servicios adicionales se descompone en las siguientes partes:
§
Descripción del objeto de aprendizaje: Consiste en identificar a qué examen o
prueba se refiere la solicitud.
166
§
Petición de servicios: Un texto que contiene la solicitud realizada por el alumno
para disponer de servicios adicionales durante la realización de la prueba.
§
Descripción de los servicios autorizados: Un texto que contiene la respuesta de
la institución ante la petición del alumno. Este texto puede coincidir o no con la
petición original, en función de si todos los servicios solicitados son
autorizados.
§
Autorización: Persona responsable de la autorización/denegación de los
servicios solicitados.
§
Fechas: La fecha en la que se firmó la autorización y el tiempo de expiración de
la misma (si procediese).
Para incluir este tipo de transacciones en el perfil del alumno, la especificación IMS
ACCLIP modifica el elemento eligibility de la especificación IMS LIP (ver sección
3.4.8) añadiendo un nuevo elemento denominado accommodation cuya estructura se
puede observar en la Figura 5.2.2.a.
Figura 5.2.2.a. Estructura gramatical del elemento accommodation empleado
para almacenar las peticiones de servicios de apoyo realizadas por el alumno.
authorizedDate
expirationDate
accommodation
1 .. ∞
atributos
accommodatationPackage
1 .. 1
learningObjectDescription
0 .. 1
requestForAccommodation
1 .. 1
1 .. 1
accommodationDescription
authorizedBy
El elemento accommodation consta básicamente de una serie de ocurrencias del
elemento accommodationPackage. Cada una de estas instancias, describe un
proceso de solicitud de servicios de apoyo realizado por el alumno. Este elemento
incluye los atributos authorizedDate y expirationDate empleados para indicar,
respectivamente, la fecha en la que fue autorizada la petición de servicios de apoyo y
la fecha de expiración de dicha autorización. El campo incluye además los siguientes
elementos:
167
§
El elemento learningObjectDescription incluye una cadena de texto en
la que se incluye la descripción del examen o prueba al que se refiere la
petición.
§
El elemento requestForAccommodation contiene una cadena de texto con
la petición original realizada por el alumno.
§
A su vez, el elemento accommodationDescription contiene la descripción
de los servicios autorizados (o no) por parte del instructor responsable.
§
El elemento authorizedBy se emplea para identificar al instructor
responsable de la decisión de autorizar o no la solicitud.
El uso de estos elementos se ejemplifica en la Figura 5.2.2.b, donde se representa una
petición de servicios de apoyo solicitada por un alumno con discapacidad visual de
cara a realizar un examen de inglés.
Figura 5.2.2.b. Ejemplo de una petición de servicios de apoyo formalizado mediante
la especificación IMS ACCLIP.
<accomodationPackage authorizedDate="2008-07-01" expirationDate="2008-07-30">
<learningObjectDescription>
Examen de Inglés - Nivel 5 - Junio de 2008
</learningObjectDescription>
<requestForAccomodations>
Se solicitan los siguientes elementos de apoyo: Realización del examen en una
habitación aparte; disponer de un sistema de lectura automática para escuchar
el contenido; disponer de una máquina Braille para leer el contenido; tiempo
adicional para la realización del examen (un 25% adicional).
</requestForAccomodations>
<accomodationDescription>
El alumno podrá realizar el examen en una habitación aparte, podrá emplear la
máquina Braille y dispondrá del tiempo adicional solicitado. No se aprueba el uso
de tecnología de lectura automática pues podría comprometer la neutralidad de
la parte oral del examen.
</accomodationDescription>
<authorizedBy>
Pedro Fernández - Director de la Escuela de Idiomas UCM
</authorizedBy>
</accomodationPackage>
5.3. IMS ACCESSFORALL METADATA
Existen distintas especificaciones y estándares para añadir metadatos a los contenidos
educativos con el propósito de facilitar su catalogación, interoperabilidad o su
descubrimiento en repositorios (Fernández-Manjón, Sierra et al. 2007). Pero estas
especificaciones no cubren las necesidades relativas a la accesibilidad de los
contenidos.
La especificación IMS AccessForAll Metadata (IMS ACCMD) intenta cubrir este hueco
definiendo las estructuras de metadatos a emplear para indicar las características
relativas a la accesibilidad de los contenidos educativos.
168
La especificación fue diseñada para actuar como complemento de la especificación
IMS ACCLIP (ver sección 5.2), pudiendo emplear los metadatos definidos mediante
IMS ACCMD para identificar si un determinado contenido se ajusta a las necesidades
indicadas por un alumno concreto en su perfil IMS ACCLIP.
5.3.1. Descripción general
En lugar de emplearse meramente como instrumento para comprobar si un recurso es
apropiado para un determinado alumno en un determinado contexto, la especificación
IMS ACCMD define también los mecanismos para complementar o sustituir los
contenidos que no cumplan determinados requisitos de accesibilidad.
Por poner un ejemplo, una pieza “contenido” puede consistir en un vídeo con narración
y gráficos explicativos. Sus metadatos indicarán por tanto que no es accesible para
personas con discapacidad auditiva (o en ambientes ruidosos) ni para personas con
discapacidad visual (o que escuchan una narración del contenido mientras realizan
alguna otra actividad). Pero estos mismos metadatos pueden incluir referencias a otros
contenidos que extienden o sustituyen al vídeo principal.
Si el perfil del alumno indicase necesidades relacionadas con el uso de imágenes
(discapacidad visual o uso de navegadores que sólo interpreten texto), será necesario
incluir una referencia a un fichero que en lugar del vídeo contenga una descripción
textual del mismo. Este tipo de fichero secundario se denomina “equivalente” dado que
proporciona la misma información que el fichero principal y puede ser empleado en
lugar del mismo.
Por otro lado, si el perfil del alumno indica necesidades especiales relacionadas con el
sonido (discapacidad auditiva, ambiente ruidoso, carencia de equipo sonoro en
dispositivo de acceso…), los metadatos pueden incluir una referencia a un fichero
adicional que contenga los subtítulos para la narración del vídeo. Este fichero
secundario se denomina “equivalente suplementario” ya que modifica el fichero
principal ampliando su usabilidad, siendo posible emplear ambos a la vez.
Como se observa en la Figura 5.3.1.a, un recurso primario puede relacionarse con
distintos recursos equivalentes, pero los recursos equivalentes sólo pueden
relacionarse con un único recurso primario. Esto simplifica las dependencias e impide
que se puedan llegar a crear cadenas de referencias circulares.
169
Figura 5.3.1.a. Relación entre un recurso primario y distintos recursos equivalentes.
Recurso Equivalente
(texto explicativo)
Recurso Equivalente
(subtítulos español)
Recurso Primario
(video explicativo)
suplementario
Recurso Equivalente
(subtítulos ingles)
Recurso Equivalente
(subtítulos francés)
La especificación IMS ACCMD distingue por tanto distintos tipos de metadatos para
los recursos primarios y equivalentes. Los recursos primarios consisten en los
documentos originales y es posible que sus creadores no sigan ningún tipo de
recomendación o estándar para garantizar o evaluar la accesibilidad de los contenidos.
Los metadatos de este tipo de recursos se reducen por tanto al mínimo, limitándose a
indicar aspectos como las capacidades sensoriales requeridas (visual, auditiva, etc.),
si el contenido se puede transformar directamente (permitiendo por ejemplo cambios
de tamaño de fuente o distintas combinaciones de colores) y si existe un fichero
alternativo equivalente.
Por otro lado, los recursos equivalentes se crean específicamente para tratar con
problemas de accesibilidad, por lo que los metadatos de este tipo de recursos son
mucho más ricos y detallados.
Como es el caso con todas las especificaciones de IMS, los metadatos de la
especificación IMS ACCMD se definen mediante documentos XML. El elemento base
para los metadatos de un determinado recurso se denomina accessibility y
podemos observar su estructura general en la Figura 5.3.1.b. Los dos elementos
fundamentales para describir la accesibilidad de un determinado recursos son
precisamente los dedicados a definir el recurso primario y los posibles recursos
equivalentes asociados. Los siguientes apartados describen con mayor detalle estos
dos conjuntos de metadatos.
170
Figura 5.3.1.b. Estructura gramatical de una sección de metadatos sobre
accesibilidad.
accesibility
1 .. 1
Elemento
opcional
resourceDescription
0 .. 1
0 .. ∞
primary
equivalent
0 o más
ocurrencias
5.3.2. Metadatos para recursos primarios
Como se mencionaba en la sección anterior, los metadatos empleados para describir
recursos primarios se centran fundamentalmente en tres aspectos:
§
Modalidades de acceso: Las modalidades de acceso indican los sentidos y
capacidades necesarios para interactuar con el contenido (visión, oído, tacto o
lectura de texto).
§
Adaptabilidad: Los contenidos primarios de por sí pueden tener la capacidad de
adaptarse a determinadas condiciones.
§
Recursos equivalentes: El recurso primario puede incluir referencias a aquellos
ficheros equivalentes (suplementarios o no) inicialmente conocidos. Dado que
los ficheros equivalentes incluyen obligatoriamente una referencia al recurso
primario, el uso de referencias en los recursos primarios es opcional (aunque
recomendable).
En la Figura 5.3.2.a podemos observar la estructura de un bloque de metadatos de un
recurso primario, tomando como raíz el elemento primary. Dicho elemento raíz
incluye los siguientes atributos que tratan los aspectos relacionados con las
modalidades de acceso:
§
El atributo hasAuditory indica si el recurso incluye una componente auditiva,
como puede ser un fichero de sonido o un vídeo con pista de sonido.
§
El atributo hasTactile indica si es necesario emplear el tacto para interactuar
con este contenido.
§
Para indicar la presencia de texto que deba ser leído (o interpretado por un
sistema de lectura automática) se emplea el atributo hasText.
171
§
Por último, el atributo hasVisual indica la presencia de contenidos visuales
como imágenes, vídeos o animaciones.
Figura 5.3.2.a. Estructura gramatical de una sección de metadatos de un recurso
primario.
? hasAuditory
? hasTactile
atributo
opcional
? hasText
? hasVisual
atributos
type
0 .. ∞
adaptability
0 .. ∞
equivalentResource
primary
Dentro del elemento primary podemos incluir varios elementos adaptability, que
describen la adaptabilidad del contenido. Cada uno de estos elementos incluye un
atributo type cuyos posibles valores son “displayTransformability” y “controlFlexibility”,
para indicar respectivamente las alternativas contempladas para modificar la
apariencia del contenido (tamaños de letra, combinaciones de colores, etc.) y los
mecanismos de control (teclado, ratón, lector de braille, etc.). El contenido de estos
elementos es una referencia a un fichero externo con la descripción de estos
mecanismos de adaptabilidad. La especificación IMS ACCMD sugiere emplear
informes EARL (http://www.w3.org/TR/EARL10/) para crear estos ficheros.
Por último, en caso de conocer a priori uno o más recursos equivalentes, podemos
emplear elementos equivalentResource para indicar la ubicación de los mismos,
tal y como se observa en la Figura 5.3.2.b
Figura 5.3.2.b. Ejemplo de metadatos de un recurso primario.
<resourceDescription>
<primary hasAuditory="true" hasTactile="false" hasText="false" hasVisual="true">
<equivalentResource>documentos/descripcionDelVideo.html</equivalentResource>
<equivalentResource>video/subtitulosEspañol.srt</equivalentResource>
<equivalentResource>video/subtitulosIngles.srt</equivalentResource>
<equivalentResource>video/subtitulosEspañol.srt</equivalentResource>
</primary>
</resourceDescription>
172
5.3.3. Metadatos para recursos equivalentes
En los casos en los que un recurso primario tenga asociado uno o varios recursos
equivalentes, los metadatos correspondientes a dicho recurso incluirán un bloque
describiendo cada uno de los mencionados recursos equivalentes.
La definición de los metadatos para recursos equivalentes cubre los siguientes
aspectos:
§
Suplementario o alternativo: Como ya se ha mencionado en la sección 5.3.1,
los recursos equivalentes pueden ser alternativas completas (se emplean en
lugar del recurso primario) o suplementarios (se emplean junto con el recurso
primario).
§
Recurso principal: Todo recurso equivalente va siempre asociado a un único
recurso principal mediante una referencia al mismo.
§
Contenido: Como se describe en la sección 5.3.2, los recursos primarios
indican sus modalidades de contenido (texto, imágenes, sonido, etc.). Los
recursos equivalentes ofrecen alternativas a dichas modalidades. Así, un
recurso con los subtítulos de un vídeo puede actuar como alternativa a la
modalidad sonora, pero no a la modalidad visual. Por este motivo es necesario
especificar para qué modalidades un determinado recurso equivalente supone
una alternativa al recurso primario.
La estructura gramatical de los metadatos para un recurso equivalente se puede
observar en la Figura 5.3.3.a. Como indica la figura, el elemento raíz se denomina
equivalent. Este elemento incluye un atributo supplementary empleado para
indicar si es un recurso equivalente suplementario o alternativo. Dentro del elemento
equivalent encontramos también los siguientes elementos:
§
El elemento primaryResource es obligatorio y consiste en una referencia al
recurso primario relacionado con este elemento equivalente.
§
Los elementos opcionales primaryFile se emplean para incluir también
referencias a los ficheros concretos que forman el recurso primario.
§
El elemento content refleja qué tipo de alternativas ofrece este recurso
equivalente ante las modalidades del recurso primario. Sus elementos
constituyentes se relacionan directamente con el modelo de datos del elemento
content de la especificación IMS ACCLIP:
-
El elemento alternativesToVisual indica en qué manera el
recurso equivalente supone una alternativa a la modalidad visual del
recurso primario.
-
El elemento alternativesToText por su parte indica las alternativas
ofrecidas a la modalidad textual del recurso primario.
173
-
El elemento alternativesToAuditory indica en qué manera el
recurso equivalente supone una alternativa a la modalidad sonora del
recurso primario.
-
El elemento learnerScaffold se emplea para indicar recursos
adicionales requeridos por el alumno para interactuar con el contenido
como pueden ser un diccionario o una calculadora. En este caso, el
recurso secundario no supone una alternativa en sí, sino que
representa una herramienta externa que el alumno necesita usar para
poder interactuar con el recurso primario.
Figura 5.3.3.a. Estructura gramatical de una sección de metadatos de un recurso
equivalente.
? supplementary
equivalent
1 .. 1
primaryResource
0 .. ∞
primaryFile
0 .. 1
content
0 .. 1
alternativesToVisual
0 .. 1
alternativesToText
0 .. 1
alternativesToAuditory
0 .. 1
learnerScaffold
En la Figura 5.3.3.b podemos encontrar un ejemplo del uso del elemento equivalent
para marcar dos de los recursos equivalentes del ejemplo de la Figura 5.3.1.a.
174
Figura 5.3.3.b. Ejemplo de metadatos de un recurso primario.
<resourceDescription>
<equivalent supplementary="false">
<primaryResource>videos/video1</primaryResource>
<primaryFile>videos/video1.avi</primaryFile>
<content>
<alternativesToVisual>
<audioDescription type="standard" xml:lang="es"/>
</alternativesToVisual>
</content>
</equivalent>
</resourceDescription>
<resourceDescription>
<equivalent supplementary="true">
<primaryResource>videos/video1</primaryResource>
<primaryFile>videos/video1.avi</primaryFile>
<content>
<alternativesToAuditory>
<camption type="standard" xml:lang="es"/>
</alternativesToAuditory>
</content>
</equivalent>
</resourceDescription>
6. HERRAMIENTAS
EDUCATIVOS
DE
SOPORTE
PARA
LOS
DISEÑOS
Otra forma alternativa de ver los lenguajes de modelado educativo (EMLs de su
término en inglés Educational Modeling Languages) es como lenguajes que
proporcionan un mecanismo a los profesores para que puedan controlar y adaptar un
sistema de gestión de aprendizaje (LMS de su término en inglés Learning
Management System).
Como se ha descrito en el capítulo 1 existen diversos EMLs que varían principalmente
en su generalidad y potencia expresiva. Desde el punto de vista tecnológico, podemos
dividir las herramientas de soporte a EMLs en diversos tipos:
§
Herramientas de autoría. Dentro de este conjunto se encuentran las
herramientas que son utilizadas principalmente por los profesores para
crear las unidades de aprendizaje (UAs o UoL, por sus siglas del inglés
Units of Learning). Estas UAs pueden verse como plantillas, de modo que la
misma plantilla puede ponerse en práctica, es decir ejecutarse, múltiples
veces con distintos participantes en cada reproducción. El proceso
requerido para poner en práctica una UA una vez creada recibe el nombre
de proceso de publicación.
§
Herramientas de reproducción. Estas herramientas son utilizadas por los
profesores y estudiantes (los participantes) para interactuar con ejecución
concreta de una UA. En el caso de los alumnos, estas herramientas
permiten acceder a todas las actividades que se incluyen en una UA,
además de realizar la función de portal para el resto de herramientas de
apoyo que se utilizan en las actividades. En el caso de los profesores, estas
175
herramientas sirven para monitorizar el estado de la UA para cada uno de
los alumnos participantes, así como para llevar a cabo las actividades que
tengan asignadas los profesores.
§
Intérpretes. Los intérpretes son aplicaciones informáticas encargadas de
interpretar el diseño educativo descrito en una UA. Su misión es gestionar
las actividades que deben llevar a cabo los participantes de la UA y la
sincronización necesaria que haya entre participantes y actividades. Las
herramientas de interpretación interactúan con las herramientas de
reproducción para coordinar la secuenciación y la sincronización entre los
distintos participantes de la UA.
§
Herramientas de soporte. Estas herramientas son utilizadas dentro de las
actividades educativas definidas en las UAs. Habitualmente se tratan de
herramientas informáticas que ya existen y que se utilizan directamente o
con ligeras modificaciones para poder ser aplicadas con propósitos
pedagógicos. En IMS LD los requisitos de herramientas de soporte son
especificados en los entornos asociados a las actividades. Algunos
ejemplos de herramientas son los reproductores de contenidos educativos
(e.g vídeos, objetos educativos SCORM, etc.), herramientas de
comunicación para promover el trabajo colaborativo (e.g. chat, foros, etc.),
intercambio de contenidos (e.g. espacio personal, Wiki, etc.), etc. El uso de
estas herramientas enriquecen los diseños de aprendizaje a costa,
habitualmente, de un mayor trabajo por parte del profesor o el personal
técnico. Para simplificar su aplicación, los EMLs normalmente permiten
definir de una forma bastante abstracta las herramientas o servicios
educacionales que estarán disponibles a la hora de crear una UA. De este
modo, las herramientas de interpretación y reproducción de un EML
concreto ya pueden tener en cuenta la necesidad de proporcionar un
conjunto de herramientas de soporte de forma que las tareas de
administración y gestión se ven simplificadas.
En la actualidad podemos encontrar diversas herramientas informáticas aplicadas en
la educación y más en particular en la creación y publicación de unidades de
aprendizaje. Como se introdujo en el capítulo 1 existen diversas aproximaciones a la
hora de crear unidades de aprendizaje. En las siguientes sub-secciones se
introducirán las WebQuest (sección 6.1) como mecanismo de creación de unidades de
aprendizaje informal y JClic (sección 6.2) como herramienta para la creación de
unidades de aprendizaje estructurado. La sección 6.3 introducirá la herramienta LAMS
que, si bien en la actualidad no sigue ningún estándar educativo particular, ha tenido
una gran acogida por la comunidad educativa. La sección 6.4 pone en práctica el caso
de estudio del seminario de enología descrito a lo largo del capítulo 2 utilizando LAMS.
Finalmente la sección 6.5 describe cómo poner en práctica el caso de del seminario de
enología utilizando herramientas concretas para la especificación IMS LD.
6.1. WEBQUEST
El concepto de WebQuest fue desarrollado en 1995 por Bernie Dodge y Tom March en
la Universidad Estatal de San Diego (Dodge, 1995; Adell, 2004 y Fernández CarballoCalero, 2008). Uno de los objetivos principales de las WebQuest es la integración de
las TIC, en particular internet, en las escuelas. Las WebQuest pueden ser
176
consideradas como un mecanismo informal (o en el mejor de los casos estructurado)
para definir unidades de aprendizaje en las que el proceso de aprendizaje está guiado
y descrito en lenguaje natural.
Una WebQuest es una actividad orientada a la investigación en la que la información
con la que interactúan los alumnos proviene total o parcialmente de recursos de
internet (Dodge, 1995). Las WebQuest pretenden rentabilizar el tiempo del alumno,
centrando su actividad en el uso de la información más que en su búsqueda,
apoyando la reflexión del alumno en los niveles de análisis, síntesis y evaluación.
La estructura que debería tener una WebQuest es la siguiente:
§
Introducción. Establece el escenario y proporciona la información previa
necesaria para llevar a cabo la tarea.
§
Descripción de la tarea a realizar. Descripción de la tarea investigadora a
realizar. Se recomienda que sea una tarea factible en tiempo y que, en
particular, sea una tarea de investigación interesante desde el punto de
vista del alumno.
§
Descripción del proceso a seguir. Descripción del proceso recomendado
a los alumnos para llevar a cabo su tarea. Es recomendable que este
proceso se divida en pasos y tareas más simples.
§
Descripción de los recursos necesarios. Descripción de los recursos
necesarios para llevar a cabo la tarea propuesta en la WebQuest, en
particular, enlaces a los recursos web necesarios.
§
Guía para la recolección de información. Descripción acerca de cómo
organizar la información obtenida por los alumnos (e.g. mapas de
conceptos, preguntas y respuestas, etc.) que formará parte de los
resultados de la actividad y que serán entregados por los alumnos.
§
Conclusiones. Proporciona unas conclusiones para finalizar la tarea
propuesta en la WebQuest. En particular las conclusiones deben hacer
referencia a los conceptos con los que el alumno ha trabajado y los
conceptos que ha aprendido.
La promoción de actividades de investigación siguiendo el paradigma de las
WebQuest ha tenido y tiene una gran aplicación en todo el mundo. Algunos sitios web
interesantes acerca de la creación, aplicación, uso y herramientas aplicables a las
WebQuest son:
§
http://www.webquest.org
§
http://questgarden.com/
§
http://www.xtec.es/~cbarba1/
§
http://www.aula21.net/index.htm
§
http://www.isabelperez.com/webquest/
La creación de unidades de aprendizaje en base a las WebQuest se lleva a cabo
mediante la creación de una página web que guíe a los alumnos tanto en el proceso
177
como a los recursos que estos utilizarán durante el uso de la WebQuest. La estructura
de la página web utilizada para guiar el proceso de la WebQuest habitualmente es la
misma, por lo que se han creado un conjunto de plantillas básicas (ver Figura 6.1.a)
para facilitar la creación de un WebQuest por parte de profesores con conocimientos
limitados en informática. Algunas de estas plantillas y herramientas gratuitas para la
creación de WebQuest pueden encontrarse en los enlaces mencionados
anteriormente.
Figura 6.1.a Ejemplo de plantilla web para la creación de una WebQuest.
6.2. JCLIC
La iniciativa JClic (http://clic.xtec.net/es/jclic/) proporciona un conjunto de aplicaciones
informáticas que permiten la autoría y la publicación de unidades de aprendizaje. En el
contexto de JClic una unidad de aprendizaje, denominada proyecto, incluye una o más
actividades educativas junto a una o varias secuencias de dichas actividades. Las
distintas herramientas que se encuentran dentro del contexto de la iniciativa JClic han
sido desarrolladas tras la experiencia del proyecto Clic iniciado en 1992. Además la
iniciativa JClic aloja un repositorio de actividades que pueden ser descargadas y
modificadas (habitualmente bajo licencias que permiten la libre distribución con ciertas
condiciones).
178
La iniciativa JClic distribuye las siguientes herramientas:
§
JClic Author. La herramienta de autor que permite crear, editar y modificar
actividades a través de una interfaz sencilla y amigable.
§
JClic Player. Es una aplicación de escritorio que permite ejecutar
secuencias JClic que se encuentran en el ordenador donde está instalado
JClic Player. También existe una versión web, denominada JClic Applet,
que permite incrustar el reproductor JClic dentro de una página web.
§
JClic Reports. Permite recolectar la información generada por los JClic
Player en una red de ordenadores, por ejemplo un aula, permitiendo la
generación de informes estadísticos sobre los resultados obtenidos por
todos los alumnos.
Como se ha descrito anteriormente una unidad de aprendizaje en JClic se compone de
un conjunto de actividades educativas y la definición de secuencias de actividades
simples. JClic permite la creación actividades educativas de los siguientes tipos:
§
Asociaciones. Los alumnos tendrán que asociar los conceptos que se
presentan en dos conjuntos de elementos.
§
Juegos de memoria. Los alumnos tendrán que ir descubriendo parejas de
elementos relacionados que se encuentran escondidos.
§
Exploración, identificación e información. Permite definir un conjunto de
elementos interactivos. En el caso de las actividades de exploración los
elementos mostrados son reactivos de modo que al hacer clic con el ratón
se muestra información adicional acerca del elemento. En el caso de
actividades de identificación permite definir un conjunto de elementos de
modo que el alumno tiene que elegir cuáles de ellos cumplen una
condición. Finalmente la actividad de información permite definir un
conjunto de elementos interactivos que permiten lanzar contenidos
textuales y multimedia al hacer clic en alguna de las opciones mostradas.
§
Puzzles. Plantean actividades en las que el alumno debe reconstruir la
información que se presenta inicialmente desordenada. Los tipos de
información que pueden ser incluidos son: gráficos, texto y sonidos.
También es posible combinar distintas fuentes de información.
§
Respuesta escrita. Permiten la creación de actividades en las que la
respuesta se basa en la escritura de una palabra o frases completas.
§
Texto. Plantean ejercicios basados siempre en las letras, palabras, frases y
párrafos de un texto que hay que completar, entender, corregir u ordenar.
Además de contenido textual la actividad puede contener contenidos
multimedia y contenidos interactivos.
§
Sopas de letras y crucigramas. Estas actividades son variantes
interactivas de los conocidos pasatiempos del mismo nombre.
Las secuencias de los proyectos JClic permiten especificar el orden en el que se
muestran las actividades del proyecto a los alumnos. El orden de las actividades de
una secuencia puede definirse de las siguientes formas:
179
§
Automáticamente. Transcurrido un cierto tiempo desde la finalización de
una actividad se pasa a la siguiente actividad.
§
Interacción con la actividad. Haciendo clic en alguna casilla que tenga
como contenido activo la acción de saltar a un determinado punto de la
secuencia.
§
Elegido por el alumno. Haciendo clic en los botones de avance y
retroceso de la interfaz de JClic.
Durante la autoría, el profesor puede definir el comportamiento de los botones de
avance y retroceso que aparecen en la interfaz de JClic Player y que, por defecto,
avanzan a la siguiente actividad o retroceden a la actividad anterior. De forma
adicional, se pueden especificar saltos a actividades concretas de la secuencia e
incluso se pueden definir saltos condicionales en base a los resultados obtenidos o el
tiempo empleado por el alumno en una actividad.
Como ejemplo de proyectos que se pueden encontrar en el repositorio de actividades
de la iniciativa JClic la Figura 6.2.a muestra un conjunto de actividades relacionadas
con la conversión entre sistemas de numeración (Redondo Templado, 2006). La
Figura 6.2.b muestra el informe generado por JClic Player donde se incluyen distintas
medidas que resumen el progreso del alumno con la unidad de aprendizaje: tiempo
invertido, número de actividades y secuencias completadas, porcentaje de completitud
global. Además también se incluye un resumen detallado por actividad en forma
tabular con las mismas medidas. Finalmente, la Figura 6.2.c muestra la unidad de
aprendizaje cargada en el editor de secuencias JClic Author.
180
Figura 6.2.a Ejecución de una secuencia de actividades en JClic sobre el sistema
binario (Redondo Templado, 2006).
181
Figura 6.2.b Informe generado durante la ejecución de las secuencias de
actividades.
182
Figura 6.2.c. Captura de JClic abriendo el proyecto acerca del Sistema Binario
(Redondo Templado, 2006).
6.3. LAMS
6.3.1. Introducción
La herramienta Learning Activity Management System (LAMS) es uno de los proyectos
que se llevan a cabo dentro del Centro de Excelencia en e-learning de la Universidad
de Macquarie en Australia (Macquarie University’s E-Learning Centre Of Excellence,
MELCOE) dirigido por James Dalziel, creador del propio sistema LAMS.
El objetivo de LAMS es proporcionar una herramienta informática para diseñar y
automatizar secuencias de actividades educativas. Dentro del conjunto de actividades
disponibles en la herramienta se pueden encontrar desde actividades que los alumnos
deben llevar a cabo de manera individual (e.g. análisis de contenidos educativos,
183
entregas de trabajos, etc.) a actividades colaborativas que pueden desarrollarse en
grupos reducidos de alumnos dentro de una misma clase o incluso la clase completa
(e.g. sesiones de chat, foros de debate, etc.). La herramienta LAMS puede utilizarse
de manera aislada o en colaboración con otros sistemas de gestión de aprendizaje
ampliamente utilizados como, por ejemplo, Moodle, Sakai y Blackboard. Esta
integración permite la utilización de LAMS desde el LMS que actualmente se esté
usando de manera oficial en la organización o institución educativa pasando a formar
parte del repertorio de recursos disponibles a través de dichas plataformas.
LAMS surge alrededor de 2002 como herramienta informática que cubre algunas de
las deficiencias detectadas en los sistemas de gestión de aprendizaje y en las
propuestas de estandarización educativas de la época y que, al menos en parte,
permanecen en la actualidad. LAMS aborda los mismos problemas que los lenguajes
de modelado educativo (ver capítulo 1), en particular, la tendencia de los sistemas y
estándares a centrarse en los contenidos educativos y en los problemas técnicos que
surgen con motivo de facilitar el intercambio de dichos contenidos educativos, dejando
un poco de lado a profesores y alumnos y sus necesidades pedagógicas. LAMS
aborda este problema utilizando las actividades educativas como pieza fundamental y
facilitando la aplicación de diseños de aprendizaje en la creación de secuencias de
actividades.
Cabe destacar que LAMS se inspira en las ideas propuestas en los lenguajes de
modelado educativo, en particular, en los lenguajes: Educational Modeling Language
(EML-OUNL) e IMS Learning Design (IMS LD) (ver capítulo 1), sin embargo, LAMS no
es una implementación de referencia de ninguno de estos lenguajes, sino que pone en
práctica el concepto de diseño de aprendizaje promovido por los EMLs. En la
actualidad LAMS (en su versión 2.2) es capaz de exportar las secuencias de
aprendizaje utilizando IMS LD nivel A, sin embargo no permite la importación de
unidades de aprendizaje IMS LD en ninguno de sus niveles.
La herramienta LAMS se ofrece con una licencia doble similar a la licencia del servidor
de base de datos MySQL. El resultado es que LAMS es una herramienta de software
libre bajo las condiciones de la licencia GNU GPL de la Fundación de Software Libre.
En particular, la herramienta LAMS puede obtenerse de manera gratuita desde la
página de la Fundación LAMS (http://www.lamsfoundation.org/) en sus distintas
versiones. Como complemento también se ofrece una licencia comercial dirigida
principalmente a empresas.
Esta sección no pretende ser un manual completo de la herramienta LAMS, sino una
breve introducción a la herramienta y a las posibilidades que ofrece a los profesores
para crear secuencias de aprendizaje. Para un mayor detalle acerca del uso de la
herramienta LAMS, puede consultar las siguientes fuentes de información:
§
Wiki oficial de LAMS (en inglés). Esta Wiki se actualiza continuamente
con los cambios y características que se incluyen en las nuevas versiones
de LAMS. Pueden encontrase varias secciones dirigidas a desarrolladores
de herramientas, a administradores de LAMS y, principalmente, a
profesores. Gran parte del contenido de esta sección está basado en el
material que está disponible en esta Wiki.
http://wiki.lamsfoundation.org/display/lamsdocs/Home
184
§
Wiki LAMS en castellano. Esta Wiki es una traducción de la Wiki en
inglés, y aunque se actualiza regularmente, su información puede estar
desfasada respecto a la Wiki en inglés. En particular en esta Wiki (al igual
que en su versión en inglés) se proporcionan unas instrucciones muy
detalladas para la instalación de LAMS.
http://wiki.lamsfoundation.org/display/lamsdocses/Home
§
Comunidad LAMS. La comunidad de LAMS permite la comunicación y el
intercambio de experiencias entre los profesores que actualmente están
utilizando LAMS. Dentro de esta comunidad se pueden encontrar muchos
ejemplos de secuencias de actividades LAMS, que se pueden importar
directamente en la herramienta de autor para su modificación y posterior
publicación. Además la comunidad LAMS informa acerca de los distintos
eventos de la comunidad en todo el mundo (e.g. conferencias, seminarios,
etc.). Finalmente, esta comunidad sirve como mecanismo para contactar e
intercambiar experiencias con los desarrolladores de LAMS.
http://www.lamscommunity.org
§
Monográfico sobre LAMS en el Observatorio Tecnológico del ITE
(antiguo CNICE). Proporciona un conjunto de tutoriales que cubren diversos
aspectos de LAMS (de la versión 2.0.4 en la fecha de escritura de este
trabajo), desde su instalación hasta la puesta en práctica de varios casos
de estudio.
http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag
e&pageid=72.
6.3.2. La herramienta LAMS
La herramienta LAMS proporciona una solución completa que puede ser utilizada no
sólo de apoyo y refuerzo a las clases presenciales si no también como una
herramienta de soporte para un curso totalmente online. LAMS ofrece cuatro
perspectivas complementarias basadas en la distinción del papel que juegan los
actores involucrados en el proceso pedagógico:
§
Reproducción. Esta perspectiva se centra en el papel de los alumnos
proporcionando un reproductor web utilizado para interactuar con las
distintas actividades que se proponen en las secuencias. A través del
reproductor los alumnos pueden acceder a los contenidos y a las
herramientas suministradas en las actividades. Además pueden hacer
anotaciones de su progreso en cada una de las actividades, a modo de
apuntes, y realizar la entrega de ejercicios y trabajos que se propongan en
dichas actividades.
§
Autoría. Esta perspectiva se centra en el papel de los profesores
encargados de crear las secuencias educativas. La herramienta de autor
proporciona una notación gráfica que permite la creación, almacenamiento
y reutilización de secuencias de actividades. También ofrece la posibilidad
de previsualizar la secuencia que actualmente se está editando.
185
§
Monitorización y seguimiento. Esta perspectiva se centra en el papel de
los profesores y de los ayudantes del profesor. La herramienta de
monitorización y seguimiento permite al profesor que creó la secuencia (o a
un ayudante del mismo) monitorizar el progreso de los alumnos dentro de la
secuencia. En particular, una parte de las tareas de monitorización es
permitir el avance de los alumnos cuando se han establecido puntos de
sincronización (hitos) dentro de la secuencia de actividades. La herramienta
de seguimiento también se utiliza para evaluar los trabajos enviados por los
alumnos a través de LAMS. Finalmente, cabe destacar que es posible
realizar una edición en vivo (con ciertas restricciones) de las secuencias de
actividades que se están ejecutando. Esto es útil, por ejemplo, para añadir
alguna actividad extra o para modificar alguna de las actividades cuando se
ha cometido un error ortográfico al crear los contenidos o en las
descripciones de las actividades.
§
Administración. Esta perspectiva se centra en el papel de los
administradores de la instalación de LAMS. LAMS proporciona una interfaz
web simple y a la vez versátil para realizar las tareas básicas de
administración del servidor LAMS. Permite, por ejemplo, la creación de
clases, grupos, usuarios y la asignación de usuarios a grupos y clases.
LAMS incluye una administración jerárquica, de modo que un profesor
pueda administrar sus propias clases lo que simplifica la administración
general del servidor.
El administrador de LAMS es el encargado de la creación de los distintos usuarios que
tendrán acceso a la herramienta y, en particular, la asignación de los privilegios del
usuario permitiendo el acceso a una o varias de las perspectivas descritas.
LAMS es una aplicación web permitiendo que una única instalación de LAMS pueda
ser utilizada por múltiples usuarios. Desde el punto de vista técnico la estructura
interna de LAMS ha sufrido una gran modificación en el paso de la versión 1.0 a la
versión 2.0 con el objetivo de facilitar la integración de LAMS con otras herramientas y
plataformas educativas ya existentes. Esto permite que LAMS pueda ser utilizada
como un recurso adicional dentro de dichas herramientas. No obstante, con la versión
2.2 los desarrolladores de LAMS han dado un paso más allá permitiendo que los
recursos y herramientas de los sistemas en los que LAMS está integrado también
puedan ser utilizados y configurados desde la propia herramienta de autor de LAMS.
Esta nueva característica (que en la redacción de este trabajo estaba todavía en fase
de pruebas) permite que los profesores puedan crear secuencias LAMS utilizando
herramientas que ya conocen, e incluso que colaboren con otras actividades LAMS.
Uno de los casos prueba es el de la configuración de los foros de Moodle desde LAMS
cuando LAMS está integrado dentro de la plataforma Moodle.
Finalmente, como detalle técnico cabe destacar que la herramienta LAMS está
desarrollada utilizando la plataforma Java Enterprise Edition. Para facilitar la creación
de una interfaz atractiva visualmente y que soporte una gran interactividad, la interfaz
web ha sido desarrollada con tecnología Adobe Flash. De este modo los usuarios
finales de la herramienta, profesores y alumnos, pueden utilizar LAMS a través de un
navegador web con la única condición de que tenga soporte para Flash (activado el
complemento o plug-in de Flash). Además, como la herramienta LAMS se ha
186
desarrollado sobre la plataforma Java, un servidor LAMS es compatible con todos los
sistemas operativos comúnmente utilizados como Windows, Linux y Mac.
6.3.3. Actividades,
adaptación
secuencias
de
actividades
y
mecanismos
de
Los dos conceptos fundamentales en LAMS son las actividades educativas y las
secuencias de actividades. A lo largo de esta sección se introducen estos dos
conceptos describiendo sus posibles equivalencias o relaciones con elementos de IMS
LD.
Las actividades educativas LAMS proporcionan un mecanismo simple para configurar
y adaptar herramientas que habitualmente se encuentran en los LMS y en las
plataformas de trabajo colaborativo. De este modo, lo importante son las posibilidades
pedagógicas ofrecidas por la herramienta, pretendiendo simplificar al máximo los
conocimientos técnicos necesarios para su configuración. En comparación con IMS LD
las actividades de LAMS pueden verse como plantillas de las Actividades de
Aprendizaje y sus Entornos asociados (ver sección 2.5.2). En particular, las
actividades LAMS pueden verse como plantillas para los recursos y herramientas que
se proporcionarían en un Entorno IMS LD equivalente.
LAMS ofrece una gran variedad de actividades. A continuación se describen los
distintos tipos de actividades junto a las que están incluidas dentro de dichos tipos:
§
Actividades de comunicación y colaboración: Foro, Chat, Wiki, DimDim
(herramienta de conferencia web).
§
Actividades de distribución de contenidos: Cartelera, Compartir
Recursos.
§
Actividades para evaluar al alumno y entrega de trabajos: Enviar
Archivos, Opción múltiple, Anotador, Preguntas y Respuestas, Lista de
tareas, Votación, Encuestas y Colección de datos.
§
Otras Herramientas. Mapas (Google Maps), Hojas de cálculo.
§
Actividades combinadas. Permiten configurar dos herramientas a la vez
de modo que el alumno tenga la pantalla dividida en dos mitades
permitiendo el uso de ambas herramientas al mismo tiempo. Estas
herramientas son particularmente útiles, por ejemplo, para escenarios en
los que uno de los alumnos actúa de escriba o secretario en una sesión de
chat resumiendo los aspectos más importantes debatidos durante la sesión.
Las secuencias de actividades no son más que un conjunto de actividades LAMS
sobre las que se ha definido un orden concreto. La Figura 6.3.3.a muestra un ejemplo
de secuencia de actividades LAMS compuesta por las actividades: Actividad 1 (de tipo
Cartelera), Actividad 2 (de tipo Encuesta) y Actividad 3 (de tipo Envío de Archivos). Sin
embargo, en este ejemplo aún no se ha establecido el orden entre actividades. El
orden entre las actividades de una secuencia LAMS se define mediante el uso de una
notación de flecha. Estas flechas se denominan “transiciones” en LAMS. La figura
Figura 6.3.3.b muestra las mismas actividades de ejemplo y su ordenación utilizando
187
la notación flecha, donde el orden concreto de las actividades es: primero la Actividad
2, después la Actividad 1 y finalmente la Actividad 3.
Figura 6.3.3.a. Ejemplo de notación gráfica para actividades LAMS sin definir el
orden de las actividades.
Figura 6.3.3.b. Ejemplo de notación gráfica para actividades y la definición del
orden entre las actividades.
Además de secuencias de actividades puramente lineales, LAMS ofrece la posibilidad
de incluir los siguientes elementos dentro de una secuencia:
§
Grupos. Los grupos permiten definir agrupaciones de alumnos dentro de
una clase, de modo que una actividad pueda ser asignada a un grupo de
estudiantes en vez de a la clase completa [ver Figura 6.3.3.c 1)]. Este
mecanismo permite la creación de pequeños grupos de trabajo facilitando el
uso de las herramientas de comunicación como el chat y el foro. Los grupos
pueden ser elegidos y creados por el profesor cuando se llega a la actividad
de grupo (a través de la interfaz de seguimiento) o LAMS puede generarlos
aleatoriamente en base a la configuración de número de grupos y/o
participantes por grupo. Es posible crear varios grupos en una misma
secuencia, dejando que en cada actividad se pueda seleccionar si se usa o
no algún tipo de agrupación. Los grupos de LAMS se asemejan a los roles
de IMS LD pero su aplicación es diferente. Los roles en IMS LD se utilizan
para asignar actividades a un grupo de alumnos concreto, sin embargo, en
LAMS los alumnos deben llevar a cabo todas las actividades de la
secuencia y los grupos se usan como mecanismo para establecer grupos
de trabajo reducido en tareas colaborativas.
§
Actividades Opcionales. Este mecanismo define un conjunto de
actividades de las cuales el alumno puede elegir cuales desea llevar a cabo
[ver Figura 6.3.3.c 2)]. El profesor puede configurar cuál es el número
mínimo y máximo de actividades que el alumno debe llevar a cabo para
considerar que la actividad opcional ha sido completada. Nótese que es
posible incluir una actividad opcional dentro de otra actividad opcional
188
permitiéndose la creación de actividades complejas. Este mecanismo es
similar a las Actividades Estructuradas de tipo selección que existen en IMS
LD.
§
Puertas. Las puertas permiten que los profesores puedan definir puntos de
espera dentro de una secuencia de actividades [ver Figura 6.3.3.c 3)]. De
este modo, los alumnos no pueden avanzar a la siguiente actividad hasta
que la puerta se "abra". Las puertas pueden configurarse para que se abran
cuando lo decida el profesor (a través de la interfaz de seguimiento) o
cuando todos los alumnos han finalizado la actividad previa a la puerta. Las
puertas son similares a los mecanismos de finalización de las Actividades,
Actos y Guiones de IMS LD.
Figura 6.3.3.c. Notación visual para distintos elementos de control utilizados en las
secuencias de actividades. 1) Notación visual para la definición de grupos. 2) Notación
visual para la definición de actividades opcionales y 3) notación visual para las
puertas.
Con las versiones 2.1 y 2.2 de LAMS se han introducido nuevos tipos de actividades y
características que enriquecen los mecanismos para adaptar las secuencias a los
conocimientos y destrezas de los alumnos. Estos nuevos mecanismos se basan en la
ramificación de la secuencia principal, de modo que cada alumno o grupos de alumnos
puedan pasar por distintas ramas de la secuencia principal. Las nuevas características
que influyen en la personalización y adaptación de las secuencias de actividades son:
§
Puertas mejoradas. Se introducen la espera basada en tiempo y la espera
condicional. Las puertas con espera basada en tiempo se abren
automáticamente transcurrido un cierto lapso de tiempo desde el comienzo
de la ejecución de la secuencia. Las puertas de espera condicional
bloquean el paso de un alumno hasta que la condición no se haga cierta
para dicho alumno. Las posibles condiciones de espera son iguales a las
condiciones que se pueden utilizar en las ramificaciones (por simplicidad se
189
describen más adelante). En ambos casos el profesor (o ayudante del
profesor) puede abrir la puerta saltándose las restricciones temporales o las
condiciones.
§
Grupos mejorados. Se permite que los estudiantes se agrupen ellos
mismos. Desde LAMS se puede establecer el número máximo de grupos (y
sus nombres) y los estudiantes elegirán en qué grupo desean participar.
También se ofrece la posibilidad de especificar el número máximo de
estudiantes por grupo, de modo que LAMS generará automáticamente los
grupos según se vayan llenando los que ha creado.
§
Secuencias opcionales. Este nuevo mecanismo permite la definición de
un conjunto de secuencias (hasta diez) de las cuales el alumno puede
elegir algunas secuencias a realizar [ver notación gráfica en Figura 6.3.3.d
2)]. De manera similar a las actividades opcionales, el profesor define el
número mínimo y máximo de secuencias que el alumno debe realizar para
considerar finalizada la actividad de secuencias opcionales. La Figura
6.3.3.d 2) muestra un ejemplo de secuencias opcionales. Las actividades
de cada una de las secuencias aparecen en la misma fila y con un color de
fondo distinto. Las actividades están identificadas por su icono
correspondiente. El orden de las actividades de una secuencia se define
ordenando las actividades (de izquierda a derecha) dentro de cada una de
las filas que representan a las secuencias, es decir, la actividad más a la
izquierda se ejecuta en primer lugar y la que está en el extremo derecho en
último lugar. En el caso del ejemplo, la primera secuencia contiene (en este
orden): una actividad de tipo Colección de datos, una actividad de tipo
Compartir Recursos y una actividad de tipo Encuesta. La segunda
secuencia contiene (en este orden): una actividad de tipo Cartelera y una
actividad de tipo Foro de discusión. Nótese que las secuencias que se
incluyen dentro de la actividad opcional no tienen por qué tener la misma
longitud. Al igual que con las actividades opcionales, es posible incluir
dentro de una secuencia cualquier tipo de actividad (incluidas las
actividades opcionales, secuencias opcionales y ramificaciones)
permitiendo crear secuencias complejas.
§
Actividades de Ramificación. Las ramificaciones son similares a las
actividades y secuencias opcionales ya que permiten crear secuencias de
actividades paralelas. Sin embargo, en las ramificaciones el alumno no
decide la actividad o secuencia que va seguir sino que automáticamente se
le asigna una secuencia concreta. Al igual que con las secuencias
opcionales dentro de una actividad de ramificación se pueden incluir otras
ramificaciones y otras actividades opcionales. Este mecanismo de
ramificación es similar al uso de las condiciones de IMS LD para ocultar y
mostrar Actividades dentro de un mismo Acto. Los mecanismos para decidir
automáticamente qué rama sigue un alumno concreto son:
-
Seleccionado por el profesor. El profesor (o el ayudante) a través de la
herramienta de seguimiento asigna a los alumnos una rama concreta al
llegar a la actividad de ramificación.
-
Basado en grupos. Los alumnos son asignados automáticamente a las
distintas ramas dependiendo de alguna agrupación que se haya
realizado en la secuencia. Durante la creación de la actividad de
190
ramificación el profesor decide cómo se asignan los grupos a cada una
de las ramas.
-
§
Condicional basado en el resultado de otras actividades. Los alumnos
son asignados automáticamente a las distintas ramas dependiendo de
los resultados que hayan obtenido en alguna de las actividades
anteriores a la actividad de ramificación. Al igual que en las puertas, la
descripción de las condiciones se realiza más adelante.
Notificaciones. Las notificaciones son un mecanismo de comunicación de
LAMS con los alumnos y profesores que están involucrados en la ejecución
de una secuencia de actividades. LAMS notifica, enviando un correo
electrónico, eventos importantes que han sucedido durante la ejecución de
alguna de las actividades de la secuencia. Por ejemplo, en las actividades
de tipo Enviar Archivo el autor de la secuencia puede configurar que se
envíe un correo electrónico cuando los alumnos hayan enviado sus trabajos
y, de manera similar, los alumnos pueden recibir una notificación indicando
que las notas de los trabajos enviados ya están disponibles. Aunque las
notificaciones no modifican el número o tipo de actividades que realiza un
alumno, sí modifican el modo de trabajo tanto de los alumnos como de los
profesores. Con el uso de las notificaciones, profesores y alumnos no
tienen que acceder al sistema para comprobar si se han enviado trabajos o
si ya están corregidos. Las notificaciones recuerdan al mecanismo de
notificación de IMS LD. Sin embargo, a diferencia de las notificaciones de
LAMS, las de IMS LD pueden modificar el número de actividades que un
alumno debe realizar.
191
Figura 6.3.3.d. Notación visual para distintos elementos de control avanzados
utilizados en las secuencias de actividades. 1) Notación visual las actividades de
ramificación. 2) Notación visual para la definición de secuencias opcionales.
Las condiciones juegan un papel importante en las ramificaciones y en las puertas, ya
que permiten personalizar la secuencia de las actividades teniendo en cuenta la
participación y contribución del alumno en las actividades. Las condiciones LAMS son
expresiones que, como resultado de su evaluación, generan los valores cierto
indicando que la condición se cumple y falso en caso contrario. A modo de ejemplo,
durante la creación de una actividad de ramificación el profesor crea condiciones y las
asigna a cada una de las ramas. Cuando el alumno llega a la actividad de ramificación
LAMS evalúa las condiciones y automáticamente asigna al alumno la ramificación
cuya condición es cierta.
Las condiciones tienen en cuenta los resultados generados en las actividades, por
ejemplo, la nota que ha obtenido un alumno en una actividad de tipo Opción Múltiple.
LAMS proporciona una interfaz amigable para definir condiciones basadas en los
resultados que generan las actividades. LAMS distingue dos tipos de resultados de
actividades:
§
Resultados específicos. Los creadores de LAMS han identificado algunas
medidas que pueden ser útiles para medir el rendimiento o desempeño del
alumno en la actividad. Un ejemplo es la actividad de tipo Foro que permite
crear condiciones en base al número de contribuciones del alumno en dicho
foro. Otro ejemplo es la actividad de tipo Opción Múltiple que permite definir
condiciones en base a la puntuación que ha obtenido el alumno en el test o
simplemente si ha acertado todas las preguntas o no. En la versión 2.2 de
LAMS sólo las actividades de tipo Foro y Opción Múltiple ofrecen resultados
específicos que se pueden utilizar en la creación de condiciones. No
obstante, los propios desarrolladores fomentan la participación de la
comunidad para identificar nuevas medidas que sean útiles a la hora de
crear estas condiciones.
§
Resultados textuales. Existen varias actividades dentro del repertorio que
ofrece LAMS donde el resultado que genera el alumno es texto. Estos
resultados textuales permiten la creación de condiciones basadas en la
192
búsqueda de palabras clave, fragmentos de frases, etc. Los tipos de
actividades que generan resultados textuales y que, por tanto, permiten
crear condiciones basadas en texto son: Encuesta, Foro, Preguntas y
Respuestas, Anotador, Chat y Foro.
6.3.4. Configuración y uso básico de LAMS
A lo largo de esta sección se introducen los conceptos básicos y se describen los
primeros pasos necesarios para trabajar con LAMS versión 2.2 y abordar así el caso
de estudio de la sección 6.4.
A modo de repaso de algunos conceptos ya introducidos a lo largo del capítulo y como
base para introducir nuevos, se definen, a continuación, los conceptos básicos
necesarios para trabajar con LAMS:
§
Clases. Una clase en LAMS puede verse como una asignatura o curso.
Desde el punto de vista LAMS una clase es un mecanismo para asociar un
grupo de estudiantes con uno o más profesores. Dentro de una clase se
pueden crear grupos de estudiantes. Nótese que estos grupos de alumnos
no están relacionados con los grupos que se pueden incluir dentro de una
secuencia.
§
Roles. Los roles permiten definir las funcionalidades de LAMS a las que
tiene acceso un usuario. Los roles se asignan dentro de una clase (o grupo)
de modo que es posible que un usuario pueda tener distintos roles en
distintas clases (o grupos). Los roles disponibles dentro de LAMS son:
§
-
Autor. Este rol permite crear secuencias de actividades con la
herramienta de autoría y permite publicarlas en alguna de las clases o
grupos en los que el profesor tiene rol de autor. El rol de autor es uno
de los roles que típicamente tiene asignado un profesor.
-
Monitor. Este rol da acceso a la herramienta de seguimiento. La
herramienta de seguimiento es utilizada por los profesores para
monitorizar el progreso de los alumnos, corregir trabajos enviados por
los alumnos, creación de agrupaciones de estudiantes, abrir puertas,
etc. El rol de monitor está asociado a los profesores y ayudantes del
profesor.
-
Alumno. Este rol da acceso al reproductor de secuencias. El
reproductor de secuencias permite interactuar con las actividades que
el profesor ha definido en una secuencia.
-
Roles administrativos. LAMS ofrece un conjunto adicional de roles que
habitualmente son asignados a los profesores. Estos roles permiten
realizar tareas típicamente administrativas, como la creación de grupos,
usuarios y asignación de usuarios a grupos. No obstante, las tareas
administrativas están restringidas a una clase concreta y no al servidor
completo.
Actividades. Desde el punto de vista del profesor, las actividades son las
distintas herramientas que puede utilizar en la herramienta de autoría para
193
crear secuencias de actividades. Desde el punto de vista del alumno, las
actividades son las tareas educativas que debe realizar como parte del
proceso de aprendizaje.
§
Secuencias de actividades. Las secuencias de actividades son un
conjunto de actividades para las que se ha definido un orden concreto. Un
profesor puede crear progresivamente varias secuencias que residen en un
espacio de trabajo privado al que únicamente tiene acceso dicho profesor.
§
Publicación de secuencias de actividades. Las secuencias de
actividades pueden ser consideradas como plantillas en las que los
participantes concretos no están definidos. El proceso de publicación
permite al profesor crear una instancia concreta de la plantilla para un
conjunto concreto de alumnos. Es posible publicar una plantilla en una
clase o en un grupo particular que se haya definido dentro de la clase.
Nótese que es posible tener publicadas múltiples secuencias dentro de una
clase o grupo de modo que el alumno puede ir progresando en cada una de
ellas.
Como paso previo a la puesta en práctica del caso de estudio de la sección 6.4, es
necesario tener acceso a un servidor LAMS donde se puedan realizar las pruebas,
para ello se puede:
§
Instalar el servidor LAMS. La documentación de la Wiki del proyecto
LAMS (ver sección 6.3.1) describe cómo obtener e instalar el servidor
LAMS, así como integrar LAMS con otros LMS.
§
Utilizar el servidor LAMS de demostración. La Fundación LAMS
proporciona
un
servidor
de
demostración
(disponible
en
http://demo.lamscommunity.org/) que se puede utilizar para realizar pruebas
básicas. Se puede solicitar una cuenta de usuario que tiene asignada los
roles de autor, monitor y estudiante en un grupo que existe por defecto en
ese servidor de demostración.
Para un primer contacto con LAMS es recomendable el uso del servidor de
demostración para poder realizar las primeras pruebas, no obstante, si finalmente se
desea poner en práctica una secuencia con alumnos reales es recomendable la
instalación de un servidor LAMS propio.
Si se opta por la instalación del servidor LAMS, en la sección 6.3.4.1 se proporciona
una guía básica de configuración de dicho servidor. Tanto si se ha optado por la
instalación del servidor LAMS como si se utiliza el servidor de demostración, la sección
6.3.4.2 describe brevemente las características principales de la interfaz gráfica de la
herramienta de autoría y la publicación de secuencias previamente creadas.
Finalmente, la sección 6.3.4.3 proporciona una breve introducción a la herramienta de
seguimiento utilizada para la monitorización y para realizar el seguimiento en las
secuencias publicadas.
194
6.3.4.1. Administración básica de LAMS
Una vez instalado el servidor LAMS 2.2 se puede acceder utilizando un navegador
(con las opciones de instalación por defecto) a través de la dirección web
http://localhost:8080/lams.
La instalación por defecto de LAMS permite el uso de la mayoría de características
que ofrece LAMS. No obstante, se recomienda llevar a cabo los siguientes pasos:
1. Configurar las opciones de correo. Con el objetivo de enviar notificaciones
desde el servidor de LAMS, es necesario configurar el servidor de correo saliente
(servidor SMTP) que utilizará LAMS para enviar notificaciones.
2. Verificar las herramientas habilitadas. El administrador del servidor puede
habilitar o deshabilitar las herramientas que ofrece LAMS. Por ejemplo, el
administrador puede deshabilitar la herramienta de chat si no se tiene acceso a
ningún servidor de chat. El conjunto de herramientas habilitadas serán las
herramientas que están disponibles a través de la herramienta de autoría.
3. Crear clases y grupos de ejemplo. Como paso previo a la puesta en práctica del
caso de estudio del seminario de Iniciación a la Cata descrito a lo largo del capítulo
2, es recomendable crear una nueva clase de ejemplo con dos grupos.
4. Crear cuentas de usuario para la clase de ejemplo. Para poder probar las
distintas perspectivas que ofrece LAMS es recomendable crear al menos un par de
cuentas de usuario: una como profesor y otra como alumno. No obstante, por
completitud, más adelante se crearán cuentas de usuario para todos los
personajes que se describen en el caso de estudio.
5. Asignación de usuarios a una clase (o grupo) y su rol. Una vez creadas las
clases, grupos y las cuentas de usuario hay que asignar (matricular) las cuentas de
usuario a la clase (o grupo) correspondiente. Además, como parte de la asignación
de usuarios a clases (o grupos) es necesario asignar el rol (o roles) con el que
participará el usuario en la clase (o grupo).
Para configurar las opciones del servidor es necesario conectarse al sistema como
administrador (nombre de usuario sysadmin, contraseña sysadmin en la instalación
por defecto). Una vez que el administrador se ha conectado al sistema es necesario:
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).
2. Seleccionar la opción Editar Configuración de Sistema (ver Figura 6.3.4.1.b).
3. Introducir el nombre del servidor SMTP que utilizará LAMS para enviar
notificaciones. El nombre del servidor SMTP (o servidor de correo saliente)
puede consultarse en las opciones de cuenta de correo en las aplicaciones de
gestión de correo electrónico como Microsoft Outlook o Mozilla Thunderbird
(ver Figura 6.3.4.1.c).
195
Figura 6.3.4.1.a. Captura de pantalla con la página inicial del administrador del
sistema.
Figura 6.3.4.1.b. Captura de pantalla de parte de las opciones disponibles en la
Administración de Sistema.
196
Figura 6.3.4.1.c. Captura de pantalla parcial del editor de configuración del sistema.
Los valores que aparecen son meramente informativos.
Para verificar las herramientas que están habilitadas en el servidor LAMS es
necesario:
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).
2. Seleccionar la opción Administración de Actividades de Enseñanza (una de las
últimas opciones disponibles).
3. Comprobar el valor de la columna Función (columna más a la derecha de la Figura
6.3.4.1.d). Las actividades que tienen valor Desactivado, se encuentran
actualmente activadas. Las actividades que tienen valor Activado, se encuentran
actualmente desactivadas. Todas las actividades que aparecen en la Figura
6.3.4.1.d menos la herramienta de Escriba se encuentran actualmente activadas.
Con la configuración por defecto, sólo están desactivadas las actividades de
Escriba y DimDim. Para activar o desactivar una herramienta, simplemente hay
que hacer clic sobre el valor correspondiente de la columna Función, de modo que
si el valor que aparece es Activado la herramienta se activará. Del mismo modo, si
el valor que aparece es Desactivado, al hacer clic sobre el valor la herramienta se
desactivará.
197
Figura 6.3.4.1.d. Captura de pantalla parcial de la opción de Administración de
Actividades de Enseñanza.
Tras realizar la configuración básica del servidor, es conveniente crear una clase para
realizar las pruebas con las secuencias de actividades. Como complemento también
pueden crearse grupos de alumnos dentro de la clase.
LAMS ofrece dos posibilidades para crear nuevas clases y grupos: mediante un
formulario web o utilizando un documento de hoja de cálculo. Para simplificar el
proceso de creación de la clase de prueba, se describirán los pasos necesarios para
crear la clase de prueba Iniciación a la Cata (utilizada en el caso de estudio de la
sección 6.4) usando un documento de hoja de cálculo. Al igual que el resto de tareas
administrativas es necesario conectarse al servidor como administrador y seguir los
siguientes pasos:
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).
2. Seleccionar la opción Importar Clases y descargar el documento de hoja de cálculo
lams_groups_template.xls. Dentro de esta opción se describe brevemente la
sintaxis que deben seguir los datos del documento de hoja de cálculo para que se
puedan procesar correctamente. Una vez descargado este documento se puede
editar con cualquier herramienta que soporte el formato de archivos .xls como, por
ejemplo, Microsoft Excel, Open Office Calc o incluso Google Docs.
3. Una vez editado el documento de hoja de cálculo el contenido del mismo debería
ser similar al que aparece en la figura Figura 6.3.4.1.e. La primera línea del
documento proporciona una cabecera para las columnas útiles del documento. El
resto de filas del documento están agrupadas en bloques separados por una fila en
198
blanco. Cada bloque representa la definición de una clase y de grupos dentro de la
clase. La primera fila del bloque representa la definición de la clase (en la Figura
6.3.4.1.e se está definiendo la clase Iniciación a la Cata) y las filas restantes
representan definiciones de grupos dentro de dicha clase (en la Figura 6.3.4.1.e se
definen los grupos Nuevos alumnos y Antiguos alumnos). El significado de las
columnas es el siguiente:
§
Name(250). Nombre de la clase (o grupo) a crear con una longitud máxima de
250 caracteres.
§
Code(20). Código de la clase (o grupo) a crear con una longitud máxima de 20
caracteres.
§
Description(250). Descripción de la clase (o grupo) a crear con una longitud
máxima de 250 caracteres.
§
Locale_id. Entero que identifica el idioma que tiene asociada la clase (o grupo).
El valor 1 equivale al idioma inglés y el valor 2 equivale al idioma español.
§
admin_add_new_users, admin_browse_all_users, admin_change_status. Son
columnas relativas a permisos de administración dentro de la clase. Se
recomienda asignar el valor "0" a estas columnas.
Figura 6.3.4.1.e. Captura de pantalla del documento de hoja de cálculo utilizado
para crear la clase de prueba Iniciación a la Cata.
Tras crear la clase de prueba, también es necesario crear cuentas de usuarios para
los participantes ficticios del seminario Iniciación a la Cata que fue descrito a lo largo
del capítulo 2. Al igual que el resto de tareas administrativas es necesario conectarse
al servidor como administrador y seguir los siguientes pasos:
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).
2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de
cálculo lams_users_template.xls. Dentro de esta opción se describe brevemente la
sintaxis que deben seguir los datos del documento de hoja de cálculo para que
puedan ser procesados correctamente.
3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería
ser similar al que aparece en la Figura 6.3.4.1.f. La primera línea del documento
proporciona una cabecera para las columnas útiles del documento. El resto de filas
199
del documento representan nuevas cuentas de usuarios que serán creadas en el
servidor LAMS. En la Figura 6.3.4.1.f se están definiendo cuentas de usuario para
cada uno de los usuarios ficticios que aparecen en la Figura 2.5.2.c del capítulo 2.
Las columnas marcadas con un asterisco representan las columnas para las que
obligatoriamente se debe proporcionar un valor. El significado de las columnas
obligatorias es el siguiente:
§
login. Nombre de la cuenta de usuario con la que se accederá a LAMS. Todas
las cuentas de usuario deben tener nombres distintos.
§
password. Contraseña de acceso a LAMS.
§
First_name. Nombre real del usuario.
§
Last_name. Apellidos del usuario.
§
Email. Dirección
comunicaciones.
de
correo
electrónico
utilizada
para
el
envío
de
Figura 6.3.4.1.f. Captura de pantalla del documento de hoja de cálculo utilizado
para crear las cuentas de usuario para los usuarios ficticios del caso de estudio del
capítulo 2.
Finalmente, una vez creadas la clase y las cuentas de usuario, es necesario asignar
las cuentas de usuario a la clase (o grupo) y además asignarle el rol (o roles) que
tendrá el usuario dentro de la clase (o grupo). Al igual que en el resto de tareas
administrativas es necesario conectarse al servidor como administrador y seguir los
siguientes pasos:
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).
2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de
cálculo lams_roles_template.xls. Dentro de esta opción se describe brevemente la
sintaxis que deben seguir datos del documento de hoja de cálculo para que se
puedan procesar correctamente.
200
3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería
ser similar al que aparece en la Figura 6.3.4.1.g. La primera línea del documento
proporciona una cabecera para las columnas útiles del documento. El resto de filas
del documento representan la asignación de roles por usuario y clase (o grupo). En
la Figura 6.3.4.1.g se están asignando los permisos a cada una de las cuentas de
usuario y grupos definidos anteriormente. En particular, todas las cuentas de
usuario tienen asignado el rol learner (estudiante) salvo la cuenta del profesor
Corbinus Bodeguero que tiene además asignados los roles: author (autor) y
monitor (monitor). Las columnas marcadas con un asterisco representan las
columnas para las que obligatoriamente se debe proporcionar un valor. El
significado de las columnas obligatorias es el siguiente:
§
login. Nombre de la cuenta de usuario a la que se le va a asignar un rol.
§
organisation. Identificador de la clase o grupo donde se va asignar el rol. El
identificador de clase o grupo puede consultarse en el listado de clases a
través de la opción Administración de Cursos y Clases que se encuentra
accesible desde la página inicial de las opciones de administración (ver Figura
6.3.4.1.a).
§
roles. Lista de roles (separados por el carácter "|") que serán asignados a la
cuenta de usuario en la clase (o grupo) especificado. Los posibles valores para
los roles son: learner, author y monitor.
Figura 6.3.4.1.g. Captura de pantalla del documento de hoja de cálculo utilizado
para asignar los roles a los usuarios ficticios del caso de estudio del capítulo 2.
201
6.3.4.2. Autoría y publicación de secuencias LAMS
En esta sección se proporcionará una introducción a las herramientas que
habitualmente maneja un profesor dentro de LAMS para crear nuevas secuencias de
actividades y para publicarlas en alguna de sus clases.
La Figura 6.3.4.2.a muestra la página inicial del Profesor Corbinus cuando se conecta
a LAMS. Ya que el profesor Corbinus tiene asignado el rol de autor, esta página
contiene la opción Diseño de ... [ver Figura 6.3.4.2.a 1)] que permite acceder a la
herramienta de autoría.
Figura 6.3.4.2.a. Captura de pantalla de la página inicial del Profesor Corbinus al
conectarse a LAMS. 1) Botón para abrir la herramienta de autor. 2) Botón para publicar
una secuencia creada.
Una vez que se hace clic sobre el botón Diseño de ... se abre una nueva ventana que
incluye la herramienta de autoría (ver Figura 6.3.4.2.c). Utilizando esta herramienta,
Corbinus puede crear secuencias para representar cada uno de los escenarios
educativos que tiene en mente (ver sección 3.2).
En la parte superior de la herramienta se puede encontrar el menú de opciones y justo
debajo una barra de botones de acceso rápido. Algunas de las funcionalidades que se
ofrecen a través del menú Archivo son:
§
Las opciones Abrir, Guardar y Guardar como ofrecen las funciones básicas
para poder abrir, guardar y crear una nueva secuencia de actividades
dentro del espacio privado de trabajo que cada usuario tiene asignado.
Estas opciones también están disponibles a través de la barra de botones.
202
§
La opción Exportar permite exportar la secuencia que actualmente se está
editando. La exportación de secuencias facilita que la secuencia pueda ser
reutilizada por otro profesor. LAMS ofrece la posibilidad de exportar una
secuencia utilizando el formato interno de LAMS o utilizando IMS LD (sólo
nivel A).
§
La opción Importar permite importar secuencias que han sido creadas por
otro profesor, sin embargo, sólo se admiten secuencias en formato LAMS.
§
La opción de Insertar permite insertar una secuencia previamente guardada
en la secuencia que se está editando actualmente.
§
La opción Salir permite salir de la herramienta de autoría, también es
posible cerrar el editor cerrando directamente la ventana del navegador. En
cualquiera de los casos, la herramienta verifica si la secuencia se ha
guardado, ofreciendo la posibilidad de realizarlo si todavía no se había
hecho.
El menú Editar contiene las opciones habituales para Copiar y Pegar actividades,
además de ofrecer la posibilidad de Deshacer y Rehacer las operaciones que se han
realizado en el editor. Aunque no aparezca en el menú editar de manera explícita, los
comandos copiar, pegar y deshacer pueden invocarse con las teclas de acceso rápido
habituales.
Al seleccionar alguna de las opciones Abrir o Guardar se abre una ventana (ver Figura
6.3.4.2.b) similar al explorador de archivos del sistema operativo, que permite
gestionar el espacio personal del profesor. Este espacio personal tiene una parte
privada (identificada por el nombre del usuario) donde el profesor almacena las
secuencias que ha creado e importado. Además, el profesor también tiene acceso a
las secuencias que han sido publicadas en cada una de las clases (y grupos) en las
que es profesor, las haya creado o no él mismo. A través del explorador se permiten
gestionar carpetas y archivos (secuencias de actividades) del espacio privado del
profesor.
En el ejemplo de la Figura 6.3.4.2.b aparece el espacio de trabajo de Corbinus con
tres secuencias (UACata1, UACata1_1 y UACata2) dentro de su espacio privado, sin
embargo no aparece ninguna secuencia en el espacio de trabajo para la clase de
Iniciación a la Cata ya que todavía no se ha publicado ninguna.
203
Figura 6.3.4.2.b. Interfaz gráfica del gestor de espacio de trabajo del usuario.
En la parte central de la herramienta de autoría [ver Figura 6.3.4.2.c 1)] se encuentra
el espacio de trabajo donde se crean las secuencias de actividades. En la parte
izquierda de la herramienta de autoría [ver Figura 6.3.4.2.c 2)] se encuentra la librería
de actividades donde se listan todas las actividades que pueden ser incluidas en las
secuencias de actividades, en particular, las básicas y las combinadas descritas en la
sección 6.3.3. Para añadir una actividad simplemente hay que arrastrarla desde la
librería al espacio de trabajo. Dentro del espacio de trabajo también hay una papelera
que se usa para borrar elementos de la secuencia (tanto actividades como
transiciones). Para borrar un elemento de la secuencia hay que arrastrarlo a la
papelera.
En la barra de botones [ver Figura 6.3.4.2.c 3)] también se ofrece acceso a (de
izquierda a derecha):
§
La herramienta de transición. Esta herramienta se usa para definir el
orden entre las actividades. Una vez pulsado el botón Transición el puntero
del ratón cambia a un lápiz para advertir que se va a crear una transición. Si
se desea crear una transición entre las actividades A y B (de modo que la
actividad A se lleva a cabo antes que la B) hay que hacer clic sobre A y
arrastrar el puntero del ratón hasta que esté sobre B. Una vez creada la
transición aparece una flecha entre las actividades A y B.
204
§
Actividades y secuencias opcionales. Al pulsar el botón Opcional se
despliega una lista que incluye las opciones de creación de una actividad o
secuencia opcional. Al seleccionar cualquiera de las dos opciones el
puntero del ratón cambia indicando que la herramienta está activa, para
crear el elemento simplemente hay que hacer clic sobre el espacio de
trabajo.
§
Elementos de control de flujo. Al pulsar el botón Flujo se despliega una
lista que incluye las opciones de creación de una puerta o una actividad de
ramificación. Al seleccionar cualquiera de las dos opciones el puntero del
ratón cambia indicando que la herramienta está activa, para crear el
elemento simplemente hay que hacer clic sobre el espacio de trabajo.
§
Previsualización. Utilizando esta opción es posible previsualizar y probar
la secuencia que se está creando desde la propia herramienta de autoría.
Figura 6.3.4.2.c. Interfaz gráfica de la Herramienta de Autoría. 1) Espacio de
trabajo. 2) Librería de actividades. 3) Herramienta de transición, actividades de
adaptación y previsualización. 4) Botón de expansión de la sección de propiedades.
205
Una vez creada una actividad es necesario precisar los detalles de la misma (e.g.
nombre, descripción, si se aplica a grupos, etc.). La personalización de una actividad
se lleva a cabo a través de las Propiedades de la actividad. Las propiedades de una
actividad pueden modificarse en dos lugares:
§
§
Inspector de propiedades. El inspector de propiedades incluye las
propiedades más comunes. El inspector de propiedades de una actividad
puede abrirse seleccionando la actividad en el espacio de trabajo (hacer clic
sobre la actividad) y pulsando el icono con forma de ventanas [ver Figura
6.3.4.2.c 4)] que se encuentra en la parte inferior derecha de la herramienta
de autoría. El resultado será similar al mostrado en la Figura 6.3.4.2.d. Las
propiedades que comúnmente se pueden modificar a través del inspector
de propiedades son:
-
Título. Permite editar el nombre de la actividad que aparece dentro
del icono de cada actividad que hay en el espacio de trabajo.
-
Grupos. Permite seleccionar si hay una única actividad para toda la
clase (valor ninguno) o si hay una actividad por cada grupo. Nótese
que en la lista desplegable aparecerán los nombres de las
agrupaciones disponibles. La Figura 6.3.4.2.e muestra un ejemplo
de secuencia con una actividad (Introducción) y tres actividades de
agrupación (Agrupación 1, Agrupación 2 y Agrupación 3). En el
ejemplo, sólo las actividades de agrupación: Agrupación 1 y
Agrupación 2, participan en la secuencia, por lo que sólo estas dos
aparecerán entre las posibilidades ofertadas en la propiedad Grupos
para la actividad Introducción.
-
Actividad Offline. Permite marcar una actividad como actividad a
realizar fuera de LAMS, por ejemplo, una clase presencial.
-
Definir en seguimiento. Una actividad que tiene marcada esta
propiedad puede ser modificada mientras la secuencia se está
ejecutando. El profesor puede cambiar el contenido de la actividad a
través de la herramienta de seguimiento.
-
Conectar objetivos. A partir de LAMS 2.2 es posible definir una lista
de objetivos educativos que el autor de la secuencia desea cubrir
con las actividades de la secuencia. El profesor puede crear y editar
esta lista a través del editor de objetivos educativos que puede
abrirse seleccionando el menú Herramientas, Editor de Objetivos
(Figura 6.3.4.2.f). Una vez que la lista de objetivos ha sido creada,
las actividades de la secuencia pueden conectarse a los objetivos
educativos a través de la opción Conectar objetivos del inspector de
propiedades (ver Figura 6.3.4.2.g), que permite al profesor marcar
aquellos objetivos educativos que son cubiertos total o parcialmente
por la actividad.
Página de propiedades. La página de propiedades permite modificar el
contenido y el comportamiento de las actividades. Para acceder a la página
de propiedades de una actividad es necesario hacer doble clic sobre la
actividad. Las opciones de la página de propiedades se describirán más
adelante.
206
Figura 6.3.4.2.d. Detalle de las propiedades de una actividad y de la edición de
objetivos educativos.
Figura 6.3.4.2.e. Detalle de la edición de la propiedad Grupos para una actividad.
207
Figura 6.3.4.2.f. Editor de Objetivos Educativos.
Figura 6.3.4.2.g. Diálogo de conexión de objetivos educativos con actividades.
La página de propiedades de una actividad permite configurar su contenido y su
comportamiento. Al hacer doble clic sobre una de las actividades que se encuentra
dentro del espacio de trabajo de la herramienta de autor, aparece una ventana similar
a Figura 6.3.4.2.h. Esta página contiene un conjunto de propiedades que son comunes
a todas las actividades LAMS e incluso permite editar propiedades que son
particulares de cada una de las actividades. La página de propiedades se encuentra
divida en tres secciones:
§
Básico. Dentro de este apartado se permite editar el contenido de la
actividad. Todas las actividades permiten dar un título y redactar una
descripción (que puede incluir contenidos multimedia) de la actividad. Este
título y el contenido se muestran a los alumnos, de modo que pueden ser
utilizados para describir la actividad. Además, cada tipo de actividad puede
208
incluir dentro de esta sección contenidos adicionales, por ejemplo, en la
actividad de tipo Compartir Recursos se permite añadir los recursos (e.g
archivos, enlaces) que van a ser compartidos en la actividad.
§
Avanzado. Dentro de esta sección se pueden editar algunas propiedades
relacionadas que modifican el comportamiento de la actividad. Una
propiedad que siempre está disponible es la de Añadir Anotaciones. Al
activar Añadir Anotaciones el alumno tiene la posibilidad de, tras finalizar la
actividad, anotar el proceso que ha seguido para completar la actividad. De
forma adicional, cada actividad tiene otras propiedades, por ejemplo, la
actividad de tipo Compartir Recursos incluye propiedades que pueden ser
activadas para permitir a los alumnos compartir sus propios recursos (e.g.
archivos y enlaces) con sus compañeros.
§
Instrucciones. Dentro de esta sección se permite al autor de la secuencia
incluir las pautas que se deben seguir para llevar a cabo esta actividad,
tanto si la actividad se realiza dentro de LAMS como si la actividad es
externa (actividad offline). Estas instrucciones sólo están disponibles para
los profesores (y ayudantes del profesor). De este modo, las instrucciones
pueden servir para que el profesor que ha creado la secuencia pueda
documentar su diseño pedagógico y describir las instrucciones o pautas
que considere oportunas para llevar a cabo la actividad.
Figura 6.3.4.2.h. Página de propiedades de la actividad Introducción.
209
Una vez que Corbinus ha creado las secuencias que ha considerado oportunas, debe
publicarlas para ponerlas en práctica con los alumnos del seminario de Iniciación a la
Cata. Corbinus puede publicar la secuencia utilizando la opción Agregar Lecciones
que aparece en su pantalla inicial [ver Figura 6.3.4.2.a 2)]. Al seleccionar Agregar
Lecciones aparece una ventana similar al explorador de archivos (ver Figura 6.3.4.2.i),
en la que se puede seleccionar alguna de las secuencias a las que Corbinus tiene
acceso. Estas secuencias pueden ser privadas, es decir, secuencias que todavía no
ha publicado o puede ser alguna secuencia publicada de alguno de los cursos en los
que está registrado como profesor (con rol autor). En el ejemplo mostrado en la Figura
6.3.4.2.i aparecen tres secuencias privadas: UACata1, UACata1_1 y UACata2, junto a
las secuencias que están publicadas en las clases en las que Corbinus está registrado
como profesor (cursos MATH111 e Iniciación a la Cata).
Figura 6.3.4.2.i. Diálogo de selección de secuencias utilizado al añadir secuencias a
clases y grupos.
210
Una vez que Corbinus selecciona la secuencia UACata1 para ser publicada, al pulsar
el botón Continuar aparece un nuevo diálogo en el que Corbinus puede seleccionar a
los estudiantes y ayudantes del profesor que participarán en la secuencia. La Figura
6.3.4.2.j muestra todos los usuarios que están registrados en la clase Iniciación a la
Cata divididos en los grupos Antiguos alumnos y Nuevos alumnos. Corbinus
selecciona a todos los alumnos y a él mismo para participar dentro de la secuencia
que está publicando.
Figura 6.3.4.2.j. Diálogo de selección de participantes.
Una vez que Corbinus ha seleccionado a los participantes y pulsa el botón Continuar,
aparece el último cuadro de diálogo del proceso de publicación (ver Figura 6.3.4.2.k).
Este último diálogo, permite dar un nombre y una descripción a la secuencia que se
está publicando. De manera complementaria, se puede seleccionar si se permitirá
editar la secuencia durante su ejecución (edición en vivo) utilizando la herramienta de
seguimiento y si los alumnos podrán guardar el trabajo que han realizado a lo largo de
la secuencia (exportar porfolio). Finalmente se puede decir si la secuencia estará
211
disponible inmediatamente para los alumnos (opción por defecto) o si estará disponible
a partir de una fecha y horas concretas.
Figura 6.3.4.2.k. Diálogo utilizado para ultimar los detalles de publicación de la
secuencia de actividades.
Una vez publicada la secuencia, ésta aparece (identificada por el título que le hemos
dado en Figura 6.3.4.2.k) dentro de la clase o grupo donde ha sido creada. En la
Figura 6.3.4.2.l aparece la secuencia UACata1 que Corbinus acaba de publicar dentro
de la clase de Iniciación a la Cata. Se incluyen, además, los enlaces para participar
dentro de la secuencia [ver Figura 6.3.4.2.l 1)] y para monitorizar la secuencia [(ver
Figura 6.3.4.2.l 2)].
212
Figura 6.3.4.2.l. Página inicial de Corbinus una vez publicada la secuencia
UACata1. 1) Enlace que permite a Corbinus interactuar con la secuencia como un
alumno. 2) Enlace que permite abrir la herramienta de seguimiento.
6.3.4.3. Monitorización y Seguimiento.
El objetivo de la herramienta de seguimiento es triple: permitir al profesor monitorizar
el progreso de los estudiantes, realizar tareas administrativas dentro de la secuencia
publicada y evaluar los trabajos de los alumnos. La herramienta de seguimiento está
divida en tres secciones:
§
Lección. Dentro de esta pestaña pueden realizarse tareas administrativas
respecto a la secuencia publicada (ver Figura 6.3.4.3.a), por ejemplo, se
puede acceder a la lista de estudiantes que actualmente participan en la
secuencia y editarla. Dentro de esta sección también se encuentra una lista
de las actividades que obligatoriamente requieren la intervención del
profesor (o de un ayudante). En la Figura 6.3.4.3.a aparecen tres
actividades que requieren la intervención del profesor. Estas actividades
corresponden a tres puertas que están incluidas dentro de la secuencia. Al
seleccionar la opción Ir de la actividad Permiso Corbinus se abre una nueva
ventana (ver Figura 6.3.4.3.b) que permite administrar la puerta,
permitiendo la apertura de la misma para toda la clase o para alumnos
concretos.
213
§
Secuencia. Dentro de la pestaña secuencia, se tiene acceso a una vista
similar al espacio de trabajo de la herramienta de autor (ver Figura
6.3.4.3.c). Esta vista permite realizar un seguimiento de la secuencia desde
el punto de vista de las actividades. Al hacer doble clic sobre alguna de las
actividades se abre una ventana que permite:
-
Acceder a información acerca del número de alumnos que ya han
finalizado la actividad.
-
Acceder a las instrucciones que el autor de la secuencia ha podido
incluir durante la creación de la secuencia.
-
Acceder a los trabajos enviados por los alumnos para que puedan
ser evaluados por el profesor.
-
Permitir la creación de grupos en las actividades de grupo y la
asignación de estudiantes a ramas dentro de actividades de
ramificación.
-
Edición en vivo del contenido de la actividad. La edición del
contenido debería de estar restringida a eliminar erratas dentro de la
descripción o enunciado de la actividad, ya que la actividad puede
haber sido comenzada por algún alumno.
De manera adicional, también es posible realizar una edición en vivo de la
propia secuencia, es decir, se pueden modificar las actividades existentes
dentro de la secuencia o añadir nuevas actividades. Nótese que esta
edición de una secuencia está restringida, de modo que no se pueden
modificar actividades que ya han sido comenzadas por alumnos.
Finalmente, dentro de la secuencia aparecen unos iconos que representan
a los participantes de la secuencia (ver región resaltada en Figura
6.3.4.3.c). Estos iconos pueden ser desplazados a otras actividades de
modo que el profesor puede forzar el avance del estudiante hasta una
actividad concreta.
§
Estudiantes. En esta sección (ver Figura 6.3.4.3.d) se muestra una
representación lineal gráfica de la secuencia de cada uno de los
estudiantes que están participando. Esta sección permite observar el
progreso de los estudiantes dentro de la secuencia, mostrando si el alumno
ha completado la actividad (círculos azules), cuál es la actividad que
actualmente está realizando (cuadrado rojo) y cuáles son las actividades
que le quedan (triángulo verde). También se permite, dentro de esta
sección, que el profesor pueda exportar las contribuciones de un alumno en
una o varias actividades.
214
Figura 6.3.4.3.a. Pestaña Lección de la herramienta de seguimiento.
215
Figura 6.3.4.3.b. Opciones de administración de la puerta Permiso Corbinus.
216
Figura 6.3.4.3.c. Pestaña secuencia de la herramienta de seguimiento.
217
Figura 6.3.4.3.d. Pestaña de estudiantes de la herramienta de seguimiento.
En las siguientes secciones 6.4 y 6.5 se pone en práctica la unidad de aprendizaje
utilizada como caso de estudio a lo largo de todo el capítulo 2 empleando la
herramienta LAMS (sección 6.4) y haciendo uso de herramientas de soporte para IMS
LD (sección.6.5). A modo de resumen, en el caso de estudio del capítulo 2 se
proponen tres escenarios educativos entorno a un seminario/taller de Iniciación a la
Cata (ver Figura 2.3.b) donde cada escenario es una evolución del anterior:
§
UACata1. Describe un proceso de enseñanza tradicional presencial que
incluye algunas actividades soportadas por las TICs. El resumen de los
componentes principales y el método pedagógico se pueden encontrar en
las figuras: Figura 2.5.5.a, Figura 2.5.5.b, Figura 2.5.5.c y Figura 2.5.5.d.
§
UACata2. En base al escenario 1, se personaliza el método pedagógico en
base a las necesidades particulares de los alumnos. El resumen de los
componentes principales y el método pedagógico se pueden encontrar en
las figuras: Figura 2.6.9.a, Figura 2.6.9.b, Figura 2.6.9.c, Figura 2.6.9.d,
Figura 2.6.9.e, Figura 2.6.9.f y Figura 2.6.9.g.
218
§
UACata3. En base al escenario 2, se incluye un mecanismo de notificación
de la entrega de trabajos. El resumen de los componentes principales y el
método pedagógico se pueden encontrar en las figuras: Figura 2.7.3.a y
Figura 2.7.3.b.
6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON
LAMS
En esta sección se codificarán los escenarios educativos UACata1, UACata2 y el
escenario UACata3. Nótese que para el escenario UACata2 es necesario tener acceso
a un servidor de LAMS 2.1 o superior y que para crear el escenario UACata3 es
necesario tener acceso a un servidor de LAMS 2.2 o superior.
Una vez que ya se ha instalado LAMS o se tiene acceso a un servidor LAMS propio,
los pasos a seguir son:
1. Diseñar la secuencia. Es necesario conectarse a LAMS como profesor (con
rol de autor). Una vez creada la secuencia, ésta se almacena en el espacio
privado del profesor.
2. Publicar las secuencia. Mediante este proceso el profesor configura una
secuencia para una clase y alumnos concretos. Es posible configurar varias
secuencias para los mismos alumnos, de modo que puedan llevar a cabo
varias tareas a la vez. También es posible configurar la disponibilidad de una
secuencia publicada a partir de una fecha y hora concretas.
3. Realizar las actividades de la secuencia. Una vez que una secuencia de
actividades se ha publicado y se encuentra activa, tanto el alumno como los
profesores pueden acceder a ella. De este modo:
-
Los alumnos podrán llevar a cabo las actividades propuestas en la
secuencia.
-
Los profesores pueden monitorizar y gestionar ciertas actividades de la
secuencia. En particular, las tareas habituales de gestión son la creación de
grupos, el control de puertas y la asignación de estudiantes a ramas dentro
de una actividad de ramificación.
6.4.1. Diseño de las unidades de aprendizaje / secuencias de actividades
LAMS para el caso de estudio
Utilizando secuencias de actividades LAMS se pueden poner en práctica los
escenarios educativos UACata1, UACata2 y UACata3. No obstante, el
comportamiento no será exactamente el mismo a las UA creadas con IMS LD (que
fueron descritas a lo largo del capítulo 2). A continuación se describen algunas pautas
para traducir (si es posible) los elementos de IMS LD a LAMS:
§
Actividades Educativas y Entornos. Las actividades LAMS representan
las actividades educativas de IMS LD junto a un entorno preconfigurado.
219
Las actividades IMS LD contenían una información básica (e.g. título,
descripción, etc.) que se complementa con el entorno donde se realiza la
actividad. Estos entornos necesitan ser configurados uno a uno. En el caso
de LAMS, las actividades ya contienen un entorno preconfigurado, de modo
que la configuración a realizar es mínima.
§
Actividades de Soporte. El concepto de actividad de soporte no existe
como actividad separada en LAMS. No obstante, existen diversas
actividades que requieren de la participación de un profesor como, por
ejemplo, la actividad de tipo Enviar Archivos, en la que el profesor evalúa
los trabajos que han enviado los alumnos.
§
Roles. Los roles no existen directamente en LAMS. Un concepto similar
son las clases y grupos. Dentro de las clases (o grupos) pueden crearse
pequeños grupos de alumnos y publicar secuencias de actividades para
cada uno de los grupos de manera independiente. Sin embargo, no se
pueden asignar actividades específicas a grupos de una clase. Una manera
de simular el comportamiento de los roles y actuaciones es adelantar a los
alumnos de un grupo concreto (utilizando la herramienta de seguimiento)
hasta la actividad o actividades que es preciso que lleven a cabo.
§
Actividades Estructuradas. Las actividades estructuradas de IMS LD se
pueden simular con las actividades opcionales:
-
Actividades estructuradas de tipo selección. Se pueden simular con las
actividades opcionales de LAMS. Todas las actividades educativas que
eran referenciadas en la actividad estructurada se incluyen dentro de la
actividad opcional.
-
Actividades estructuradas de tipo secuencia. Se pueden simular con las
secuencias opcionales de LAMS con una única secuencia. No obstante,
este uso es demasiado complejo ya que se pueden obtener resultados
similares utilizando actividades simples y la herramienta de transición
para definir el orden entre las mismas.
§
Método, Guiones y Actos. Estos elementos de IMS LD permitían a los
creadores de unidades de aprendizaje definir el orden de las actividades
simples. Los actos servían como mecanismos de sincronización entre los
participantes de la unidad de aprendizaje. En LAMS no existen elementos
equivalentes, sin embargo, se pueden diseñar secuencias de actividades
con el mismo comportamiento utilizando actividades y definiendo las
transiciones entre ellas. En particular, el uso de las puertas permite simular
el comportamiento de sincronización entre participantes. Un problema que
surge cuando se crean secuencias complejas es que se ofrecen muy pocos
mecanismos para estructurar una secuencia, de hecho, el único mecanismo
que permite la estructuración de las secuencias es la posibilidad de insertar
secuencias previamente creadas en la secuencia que se está editando
actualmente.
§
Actuaciones. Las actuaciones de IMS LD asocian tipos de participantes
(roles) con las actividades que deben realizar estos participantes. En LAMS
no existe el concepto de rol como tal y, por tanto, no tienen sentido las
actuaciones. Todas las actividades de una secuencia LAMS pueden ser
consideradas como si estuvieran asignadas a un rol de alumno de IMS LD.
220
§
Propiedades. El concepto de propiedad no existe como tal en LAMS. En
IMS LD los diseñadores de las unidades de aprendizaje deben definir las
propiedades que habitualmente representan medidas de rendimiento del
alumno y se utilizan dentro de las condiciones para adaptar el flujo de
aprendizaje en base a estas medidas. No obstante, ciertas actividades
LAMS ofrecen acceso a medidas del rendimiento del alumno en la
actividad, por lo que podrían ser consideradas como propiedades
predefinidas.
§
Condiciones. Las condiciones no tienen un equivalente directo en LAMS.
Sin embargo, las actividades de ramificación pueden utilizarse para simular
el comportamiento para el que habitualmente se usan las condiciones:
adaptar el flujo de aprendizaje en base a resultados previos.
§
Notificaciones. A partir de LAMS 2.2 se incluye el concepto de notificación
que es similar al de las notificaciones de IMS LD. LAMS puede enviar
mensajes de notificación cuando suceden ciertos eventos durante la
ejecución de una secuencia. Durante el diseño de la secuencia, el profesor
puede seleccionar si desea que se envíen notificaciones o no. La diferencia
principal entre las notificaciones de LAMS y de IMS LD es que en IMS LD
una notificación puede hacer visible una actividad que inicialmente estaba
oculta, sin embargo, LAMS no ofrece esta posibilidad.
Finalmente, un concepto que afecta a las actividades de una UA en IMS LD es el
concepto de finalización. En IMS LD las actividades (simples o estructuradas),
actuaciones, actos y guiones pueden finalizar de las siguientes maneras:
§
A elección del participante. Las actividades simples, actos y guiones
pueden finalizar por elección del participante. Este comportamiento es
similar al que tienen las actividades LAMS ya que el alumno elige cuándo
finaliza la actividad.
§
Transcurrido un lapso de tiempo. Las actividades, actos y guiones IMS
LD pueden finalizar automáticamente transcurrido un lapso de tiempo. Este
comportamiento puede simularse en LAMS utilizando una puerta. Sin
embargo, esta solución requiere que se establezca una puerta por cada
actividad LAMS y, adicionalmente, la definición del lapso de tiempo se
define respecto al instante en el que comenzó la secuencia completa, por lo
que puede ser engorrosa la definición de varias puertas en diferentes partes
de la secuencia de actividades.
§
En base a la finalización de los elementos anidados. Los elementos de
IMS LD se pueden anidar durante la definición de la unidad de aprendizaje.
Este anidamiento concreta una relación entre los distintos elementos de la
unidad de aprendizaje que en IMS LD puede utilizarse para definir la
finalización del elemento externo en base a los elementos que contiene. Por
ejemplo, la finalización de un acto puede definirse en base a la terminación
de las actuaciones que contiene. En LAMS sólo existe esta relación de
anidamiento para las actividades opcionales y las actividades de
ramificación. Para el resto de situaciones en las que es necesario
sincronizar actividades se recurre habitualmente al uso de puertas
controladas por el profesor.
221
En los escenarios IMS LD planteados para el caso de estudio del capítulo 2 existen
numerosas actividades cuya finalización se define utilizando lapsos de tiempo. Ya que
en LAMS el uso de esta sincronización requiere un elevado esfuerzo durante la
creación de la secuencia, y que desde el punto de vista del alumno puede ser poco
intuitivo, se ha optado por utilizar el mecanismo por defecto de LAMS para acabar las
actividades, es decir, a elección del usuario. En casos puntuales, se han definido
puntos de control (equivalentes a los actos de IMS LD) para sincronizar a los
participantes de la secuencia.
La Figura 6.4.1.a muestra la secuencia de actividades LAMS creada por Corbinus para
implementar el escenario UACata1. Las actividades (incluyendo el orden en el que son
llevadas a cabo) son:
1. Presentación. Es una actividad de tipo Cartelera que Corbinus ha utilizado
para saludar a los nuevos alumnos del seminario y para indicarles que la
primera actividad será una clase presencial. En particular, ha sido necesario
introducir esta actividad que no se incluía en el escenario IMS LD ya que una
actividad LAMS marcada como offline no muestra ni su título ni su contenido a
los alumnos, sino que muestra un mensaje indicando a los alumnos que
contacten con su profesor para más instrucciones.
2. Clase Presencial. Actividad de tipo Cartelera que representa la primera clase
presencial del curso. Ya que esta actividad no será realizada en LAMS se ha
marcado como actividad offline. LAMS presenta las actividades offline con
colores invertidos para diferenciarlas del resto de actividades.
3. Puerta de permiso. Esta puerta es controlada por Corbinus para permitir
avanzar a los alumnos una vez que haya finalizado la clase presencial.
4. Autoaprendizaje. Actividad opcional que incluye tres actividades:
-
Artículo Bebo. Actividad de tipo Compartir Recursos en la que se comparte
el artículo de la profesora Bebo.
-
Artículo Birra. Actividad de tipo Compartir Recursos en la que se comparte
el artículo del profesor Birra.
-
Visionado de vídeo. Actividad de tipo Compartir Recursos en la que se
comparte el vídeo del profesor Bacus.
La actividad ha sido marcada para que termine cuando las tres actividades
incluidas hayan finalizado. Nótese que esta actividad se ha traducido como una
actividad opcional utilizando las pautas de traducción descritas anteriormente.
Sin embargo existen otras formas de implementar esta actividad, por ejemplo,
empleando una única actividad de tipo Compartir Recursos y compartir todos
los recursos a la vez (especificando en las propiedades avanzadas de la
actividad, que hay que visitar todos los recursos compartidos). Finalmente, si
se aplicaran estrictamente las pautas de traducción se llegaría a una secuencia
similar a la mostrada en la Figura 6.4.1.b donde la actividad opcional
Autoaprendizaje y la actividad Examen del sitio web han sido fusionadas en
una sola de tipo Secuencia Opcional con una única secuencia, donde la
primera actividad es la actividad opcional Autoaprendizaje y la segunda (y
última) actividad es el Examen del sitio web.
222
5. Examen del sitio web. Actividad de tipo Compartir Recursos donde se
comparte el enlace al sitio web www.lacatadelvinotinto.org.
6. Puerta sincronizada. Esta puerta simula la finalización de un acto de IMS LD,
de modo que la puerta no se abrirá hasta que todos los estudiantes hayan
terminado la actividad anterior.
7. Debate. Actividad de tipo Chat, donde los alumnos debaten acerca de los
contenidos educativos visionados y la lectura de los artículos.
8. Puerta de permiso. Puerta que controla Corbinus para marcar el avance a la
siguiente actividad del seminario.
9. Entrega de trabajos. Actividad de tipo Enviar Archivos, que será utilizada por
los alumnos de Corbinus para enviarle los trabajos escritos.
10. Puerta de permiso. Puerta que controla Corbinus que sirve para marcar el
final del seminario.
Figura 6.4.1.a. Estructura final de la secuencia LAMS completa que formaliza la
descripción de unidad de aprendizaje UACata1.
223
Figura 6.4.1.b. Estructura final de la secuencia LAMS completa que formaliza la
descripción de la unidad de aprendizaje UACata1. La actividad estructurada
Autoaprendizaje se ha definido como una secuencia opcional.
Al igual que en las unidades de aprendizaje IMS LD, Corbinus crea las secuencias de
actividades de manera incremental. Tras guardar la secuencia de actividades
correspondiente al escenario UACata1, puede modificar esta secuencia para las
nuevas características del escenario UACata2, que podrá guardar de manera
independiente. La Figura 6.4.1.c muestra la secuencia de actividades que implementa
el escenario UACata2, el tipo y orden de las actividades es el siguiente:
1. Presentación. Esta actividad es la misma que se ha descrito para implementar
el escenario UACata1.
2. Clase Presencial. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
3. Puerta de permiso. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
4. Test. Actividad de tipo Opción Múltiple utilizada como examen tipo test para
evaluar los conocimientos previos del alumno.
5. Evaluación de conocimientos. Actividad de tipo ramificación que utiliza la
nota que se ha generado en la actividad Test para redirigir al alumno a una
rama concreta dentro de la actividad. Las ramas de la actividad pueden
editarse haciendo doble clic sobre la actividad, de modo que aparecerá un
nuevo espacio de trabajo particular para la actividad de ramificación (Figura.
6.4.1.d). En el espacio de trabajo de una ramificación aparecen dos iconos
especiales con forma de puerta. Estos dos iconos representan: el punto de
entrada a la actividad de ramificación (puerta verde), donde se crearán las
distintas ramas de la secuencia, y el punto de salida (puerta roja), que es el
punto donde se vuelven a unir las ramificaciones para proseguir a la siguiente
actividad. En el ejemplo mostrado en la Figura. 6.4.1.d aparecen definidas dos
ramas:
224
-
Conocimientos suficientes. Esta rama representa la secuencia de
actividades que debe seguir el alumno si demuestra que tiene
conocimientos suficientes de enología. Contiene la actividad opcional
Autoaprendizaje descrita en la implementación del escenario UACata1.
-
Conocimientos insuficientes. Esta rama representa la secuencia de
actividades que debe seguir el alumno que no tenga los conocimientos
mínimos de enología para desarrollar las actividades posteriores. Esta
rama incluye la lectura del libro Enología Básica escrito por Corbinus y,
posteriormente, la realización de la actividad Autoaprendizaje. Nótese
que esta actividad ha sido copiada en ambas ramas ya que no puede
haber transiciones entre actividades de distintas ramas.
Una vez creadas las ramas Corbinus crea un par de condiciones, utilizando el
editor de condiciones accesible desde el inspector de propiedades. La Figura
6.4.1.e muestra dos condiciones: la primera con nombre Suficientes cuya
condición es que los puntos totales del estudiante sean mayor o igual que 5 y la
segunda, con nombre Insuficientes, cuya condición es que los puntos totales
del estudiante estén en el rango 0 a 4. Finalmente, Corbinus asocia las
condiciones con las ramas de secuencias. La Figura. 6.4.1.f muestra como la
rama Conocimientos suficientes está asignada a la condición Suficientes y la
rama Conocimientos insuficientes está asignada a la condición Insuficientes.
6. Examen del sitio web. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
7. Puerta sincronizada. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
8. Debate. Esta actividad es la misma que se ha descrito para implementar el
escenario UACata1.
9. Puerta de permiso. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
10. Entrega de trabajos. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
11. Evaluación de trabajos. Actividad de tipo ramificación en la que Corbinus
redirige a los alumnos a la rama correspondiente tras corregir los trabajos que
los alumnos han entregado en la actividad anterior. Nótese que esta asignación
de alumnos a ramas debe hacerse manualmente ya que la actividad de tipo
Enviar Archivos no genera ningún valor que pueda ser utilizado en una
condición. La Figura 6.4.1.g muestra las dos ramas que incluye esta actividad:
-
Trabajo suficiente. Por esta rama serán encauzados los alumnos cuyo
trabajo cumpla los requisitos mínimos exigidos por Corbinus. Como
puede observarse, en esta rama no hay ninguna actividad, de modo que
el alumno simplemente finalizará automáticamente la actividad.
-
Trabajo insuficiente. Por esta rama pasarán todos los alumnos cuyo
trabajo no cumpla los requisitos mínimos exigidos por Corbinus. Dentro
de esta rama aparece una secuencia de tres actividades: Necesitas
Repasar, Repaso y Revisión del trabajo. La actividad Necesitas
Repasar es de tipo Cartelera donde se informa al estudiante de que
debe revisar el material y rehacer el trabajo de nuevo (adicionalmente
puede revisar los comentarios acerca del trabajo volviendo a la
225
actividad Evaluación de Trabajos). La actividad Repaso es opcional y
contiene tres actividades de tipo Compartir Recursos donde cada una
de estas actividades propone el repaso de los contenidos más
relevantes: libro del profesor Corbinus, artículo del profesor Birra y visita
al sitio web www.lacatadelvinotinto.org. Finalmente, en la actividad
Revisión del trabajo el alumno debe enviar de nuevo el trabajo
incluyendo las correcciones que considere oportunas.
12. Puerta de permiso. Esta actividad es la misma que se ha descrito para
implementar el escenario UACata1.
Figura 6.4.1.c. Estructura final de la secuencia LAMS completa que formaliza la
descripción de la unidad de aprendizaje UACata2.
226
Figura. 6.4.1.d. Detalle de la actividad de ramificación Evaluación de conocimiento.
227
Figura. 6.4.1.e. Detalle del editor de condiciones asociado a la actividad Evaluación
de conocimiento.
Figura. 6.4.1.f. Detalle del diálogo utilizado para asignar condiciones a ramas de la
actividad Evaluación de conocimiento.
228
Figura 6.4.1.g. Detalle de la actividad de ramificación Evaluación de trabajos.
En último lugar, la secuencia que implementa el escenario UACata3 es una ligera
modificación de la secuencia de actividades que implementa el escenario UACata2. En
particular sólo se han modificado las propiedades de las actividades Entrega de
Trabajos y Revisión del Trabajo, de modo que se notifique a Corbinus mediante un
mensaje de correo electrónico que un alumno ha enviado su trabajo (ver Figura
6.4.1.h). Como complemento, también se ha configurado que los alumnos sean
notificados cuando Corbinus haya evaluado los trabajos y que los alumnos puedan
revisar tanto su nota como los comentarios que Corbinus haya añadido a la corrección.
229
Figura 6.4.1.h. Página de propiedades de la actividad Entrega de Trabajos. Las
propiedades de notificación a profesores y alumnos se encuentran activadas.
Como se mencionó en la sección 6.3.4.2, es posible exportar una secuencia de
actividades LAMS desde la herramienta de autoría. La secuencia exportada se
empaqueta en un archivo comprimido en formato zip que contiene una descripción de
la secuencia de actividades y todos los archivos de contenidos que se utilizan en las
actividades de la secuencia. La Figura 6.4.1.i muestra el contenido (en formato XML)
del archivo que representa la secuencia de actividades. A diferencia del formato XML
de IMS LD, que tiene como objetivo ser un formato simple de intercambio para
unidades de aprendizaje que incluso puede ser editado directamente por un profesor,
el formato XML de LAMS no está pensado para ser modificado directamente, ya que
incluye numerosos detalles técnicos como, por ejemplo, las coordenadas dentro del
espacio de trabajo donde se encuentra cada una de las actividades, el instante en el
que se creó la actividad, etc.
Figura 6.4.1.i. Extracto del contenido del documento XML donde se define la
secuencia de actividades del escenario UACata2.
230
<org.lamsfoundation.lams.learningdesign.dto.LearningDesignDTO>
<learningDesignID>36</learningDesignID>
<title>UACata2</title>
<firstActivityID>525</firstActivityID>
<firstActivityUIID>34</firstActivityUIID>
<maxID>118</maxID>
<validDesign>true</validDesign>
<readOnly>false</readOnly>
<editOverrideLock>false</editOverrideLock>
<userID>10</userID>
<copyTypeID>1</copyTypeID>
<createDateTime class="sql-timestamp">
2008-12-03 13:27:53.0</createDateTime>
<version>2.1.0.200806131057</version>
<designVersion>1</designVersion>
<workspaceFolderID>50</workspaceFolderID>
<lastModifiedDateTime class="sql-timestamp">2008-12-03
16:35:17.0</lastModifiedDateTime>
<contentFolderID>ff8080811ded4e44011def28de5a006c</contentFolderID>
<groupings/>
<activities>
<org.lamsfoundation.lams.learningdesign.dto.AuthoringActivityDTO>
<activityID>514</activityID>
<activityUIID>1</activityUIID>
<description>Tool for displaying HTML content including external
sources such as images and other media.</description>
<activityTitle>Clase Presencial</activityTitle>
<helpText>Displays formatted text and links to external sources
on a read only page.</helpText>
<helpURL>
http://wiki.lamsfoundation.org/display/lamsdocs/lanb11</helpURL>
<xCoord>166</xCoord>
<yCoord>43</yCoord>
<activityTypeID>1</activityTypeID>
<defineLater>false</defineLater>
<learningDesignID>36</learningDesignID>
<createDateTime class="sql-timestamp">
2008-12-03 13:27:53.0</createDateTime>
<runOffline>true</runOffline>
<toolSignature>lanb11</toolSignature>
<toolID>2</toolID>
<toolContentID>452</toolContentID>
<toolDisplayName>NoticeboardX</toolDisplayName>
<toolVersion>20070524</toolVersion>
<authoringURL>tool/lanb11/authoring.do</authoringURL>
<monitoringURL>tool/lanb11/monitoring.do</monitoringURL>
<activityCategoryID>4</activityCategoryID>
<applyGrouping>false</applyGrouping>
<groupingSupportType>2</groupingSupportType>
<libraryActivityUIImage>
tool/lanb11/images/icon_htmlnb.swf</libraryActivityUIImage>
<readOnly>false</readOnly>
<initialised>false</initialised>
<stopAfterActivity>false</stopAfterActivity>
<inputActivities/>
<languageCode></languageCode>
<supportsOutputs>false</supportsOutputs>
</org.lamsfoundation.lams.learningdesign.dto.AuthoringActivityDTO>
...
231
Para finalizar esta sección, la Figura 6.4.1.j muestra el curso de Moodle que Corbinus
utiliza como apoyo al curso de Enología Presencial que imparte en la de Escuela
Estudios y Prospecciones Vinícolas (EEPV). Moodle es el LMS utilizado dentro de los
diferentes cursos de la EEPV, sin embargo, ya que Corbinus ha dedicado un gran
esfuerzo al desarrollo de secuencias de actividades, la instalación de Moodle de la
escuela se encuentra integrada con el servidor de LAMS. De este modo, Corbinus
puede utilizar la herramienta de autoría y publicar secuencias LAMS desde la propia
interfaz de Moodle.
Figura 6.4.1.j. Publicación de la secuencia de actividades UACata1 dentro de
Moodle.
6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON IMS
LD
Existen numerosas iniciativas, en particular en el ámbito de la investigación, para crear
herramientas de autoría y herramientas de reproducción entre otras, que faciliten el
uso de los lenguajes de modelado educativo con énfasis en IMS LD. Entre estas
iniciativas se encuentra el proyecto RELOAD (http://www.reload.ac.uk) que ofrece
varias herramientas para dar soporte a las especificaciones ADL SCORM e IMS LD.
232
Las herramientas que el proyecto RELOAD ofrece para IMS LD son dos:
§
RELOAD LD Editor. Esta herramienta permite crear una UA compatible
con IMS LD. RELOAD LD Editor fue una de las primeras herramientas de
autoría compatible con los tres niveles de la especificación IMS LD.
§
RELOAD LD Player. Esta herramienta es un reproductor de unidades de
aprendizaje IMS LD pensado para complementar a RELOAD LD Editor.
Este reproductor permite reproducir unidades de aprendizaje desde el
ordenador del propio creador de las unidades de aprendizaje. Proporciona
una interfaz simple para publicar una UA y crear usuarios de prueba.
Internamente, RELOAD LD Player utiliza el intérprete CopperCore para
reproducir las unidades de aprendizaje.
En la actualidad los desarrolladores de RELOAD participan en el proyecto
internacional TENCompetence (http://www.tencompetence.org) desarrollando una
nueva versión de RELOAD LD Editor, llamada ReCourse, que tiene como objetivo
proporcionar una herramienta más amigable y simple de usar para un usuario que no
sea experto en IMS LD. No obstante, en la actualidad, ReCourse soporta la
expresividad de IMS LD nivel A, aunque según los autores (Griffiths et al., 2008) en
poco tiempo estará disponible una versión de ReCourse que soporte la expresividad
de los niveles B y C de IMS LD.
La especificación de IMS LD propone la aplicación de la metodología Análisis, Diseño,
Desarrollo, Implementación y Evaluación (ADDIE) (Dick y Carey, 1996) ampliamente
utilizada en la creación y desarrollo de materiales educativos y cursos. Esta
metodología se compone de 5 fases, cuyos objetivos son:
§
Análisis. En esta fase se analiza un escenario educativo concreto teniendo
en cuenta los distintos tipos de participantes que están involucrados en el
escenario educativo. El objetivo de esta fase es crear un documento en
lenguaje natural en el que se narre brevemente cómo se pondría en
práctica el caso de estudio. En particular, este documento narrativo podría
incluir una lista con todas las tareas a llevar a cabo en el escenario
educativo.
§
Diseño. En la fase de diseño se propone que, utilizando el documento
narrativo como entrada, se cree un diagrama de actividad UML (OMG,
2007). Los diagramas de actividad UML son un tipo de diagrama utilizados
habitualmente en el desarrollo de aplicaciones informáticas y en la
descripción de procesos de negocio, por ejemplo, para describir
gráficamente el orden de las tareas que intervienen en un proceso de
negocio. Este diagrama se utiliza como base para generar el documento
XML que represente la UA compatible con IMS LD. Durante esta fase del
desarrollo, se puede utilizar la herramienta RELOAD LD Editor para facilitar
la creación de este documento XML sin tener que trabajar directamente con
el archivo XML.
§
Desarrollo. Durante esta fase se crean los recursos necesarios para la UA.
Estos recursos se tienen que haber declarado en los Entornos utilizados en
las actividades. Una vez creados estos recursos, se puede utilizar RELOAD
LD Editor para incluirlos dentro de la UA.
233
§
Implementación. Durante esta fase, se publica la UA con alumnos
concretos para su puesta en práctica. Para esto es necesario crear un
paquete IMS que incluya tanto la UA como todos los recursos necesarios.
Reload LD Editor permite crear y validar un paquete IMS para que pueda
ser utilizado en un reproductor compatible con IMS LD.
§
Evaluación. Esta fase tiene como objetivo evaluar la UA para que se pueda
mejorar para una ejecución posterior.
Como se ha descrito, RELOAD LD Editor se puede usar durante la fase de diseño
para crear la UA compatible con IMS LD. El proceso de creación de una UA utilizando
RELOAD LD Editor es el siguiente:
1. Crear un nuevo diseño de aprendizaje (del inglés learning design). Un diseño de
aprendizaje puede ser considerado como un proyecto de UA.
2. Crear las actividades. A partir de la descripción narrativa del escenario educativo,
pueden identificarse las actividades de la UA. Las actividades educativas y de
soporte pueden agregarse en actividades estructuradas más complejas.
3. Crear los entornos donde se llevarán a cabo las actividades y asociarlos a sus
correspondientes actividades. La definición de las actividades sólo incluye una
descripción de la tarea a realizar. Esta definición de actividades se complementa
con la definición de entornos y su asociación a las actividades.
4. Crear los roles de los participantes del diseño de aprendizaje. El escenario
educativo puede incluir distintos tipos de participantes, por lo que será necesario
definir un rol por cada uno de los tipos de personaje identificados.
5. Crear el método de la unidad del diseño de aprendizaje. En el método se define el
orden, la sincronización y la asignación de las actividades individuales (definidas
en el paso 2) a roles identificados en el escenario educativo. Además, si la UA
incluye aspectos de personalización, es necesario definir las distintas propiedades
que se utilizarán en dicha personalización.
6. Importación y vinculación de los recursos a los entornos. Como parte de la fase de
desarrollo, el profesor creará los distintos materiales educativos que serán
enlazados desde los distintos entornos. Una vez creados los recursos educativos,
el profesor importará los recursos en RELOAD LD Editor, en particular los objetos
educativos u objetos de aprendizaje (learning objects en inglés) y reeditará los
entornos para enlazar los materiales educativos importados.
7. Verificación del diseño de aprendizaje. Una UA compatible con IMS LD debe
cumplir ciertas restricciones para que pueda ser ejecutada en un reproductor
compatible. RELOAD LD Editor permite que el creador de una UA pueda validarla
respecto a estas restricciones. En caso de que alguno de los elementos no cumpla
los requisitos mínimos, se proporciona un mensaje de error con una pequeña
ayuda que indica cómo arreglar el fallo.
8. Exportación del diseño de aprendizaje. Una vez creada y validada la UA, ésta está
lista para ser exportada. La UA junto a todos los recursos necesarios serán
empaquetados en un archivo comprimido (con formato zip) listo para ser ejecutado
en un reproductor compatible con IMS LD.
234
Una vez creada la UA es recomendable que el profesor la pruebe antes de ponerla en
práctica con usuarios reales y más si la UA es adaptativa. RELOAD Player puede
utilizarse para probar una UA compatible con IMS LD. Sin embargo, RELOAD LD
Player es un reproductor completo y real de IMS LD, de modo que al probar la UA será
necesario cumplir con todas las restricciones que se especifiquen en ella. En
particular, las actividades educativas de los escenarios de ejemplo pasarán a estar
completadas transcurrido un lapso de tiempo, de modo que el profesor tendría que
esperar dicho lapso de tiempo durante las pruebas, lo que no es efectivo. Para facilitar
el proceso de prueba de la UA que se está creando, es recomendable crear una UA
"trucada", donde:
§
Las actividades deberían configurarse para ser completadas a elección del
usuario. De este modo, el profesor podrá ir completando las actividades y
probando las adaptaciones incluidas en la UA.
§
El profesor debería poder modificar el valor de las propiedades que
modifican el proceso de adaptación. Por tanto, es necesario crear recursos
de tipo imsldcontent que incluyan los elementos globales de IMS LD
necesarios para ver y modificar el valor de las propiedades que afecten al
proceso de adaptación.
Una vez que se ha probado la UA, las actividades pueden configurarse con los
mecanismos de finalización que inicialmente se habían ideado, y los recursos
accesorios que se habían creado para la prueba y que ya no son necesarios se
pueden eliminar.
La interfaz gráfica de RELOAD LD Editor ofrece una pestaña por cada uno de los
diferentes aspectos relativos a la edición de una UA. Cada pestaña proporciona el
soporte necesario para cada uno de los ocho pasos anteriormente descritos.
Las unidades de aprendizaje que ponen en práctica los escenarios educativos
descritos en el capítulo 2 han sido creadas y probadas con las últimas versiones
(hasta la fecha de escritura del presente trabajo) de las siguientes herramientas:
§
RELOAD LD Editor versión 2.1.3 (herramienta de autoría).
§
RELOAD LD Player versión 2.1.3 (herramienta de pruebas).
§
CopperCore Runtime Environment (CCRT) versión 3.1.1 + SLeD versión
3.0 (herramienta de pruebas).
A continuación, se describe brevemente el proceso de creación de la UA para el
escenario de aprendizaje UACata3 descrito en el capítulo 2. El caso de estudio
UACata3 se ha modificado mínimamente para poder probarlo completamente. Las
modificaciones realizadas son:
§
La finalización de actividades se ha configurado para que el usuario elija
cuando finalizan.
§
Se ha añadido la propiedad global personal email. Esta propiedad es
necesaria para crear las notificaciones para profesores.
235
La Figura 6.5.a muestra la interfaz de RELOAD LD Editor que permite editar el
resumen de la UA que se está creando. Esta interfaz permite definir:
§
Un título (title). Este título es utilizado habitualmente por las herramientas
de reproducción para mostrar el listado de unidades de aprendizaje
publicadas. En el ejemplo el título es Seminario de introducción a la cata.
§
Una URI y versión. La URI proporciona un identificador único para la UA.
Este identificador puede utilizarse para hacer referencia a la UA que se está
creando desde otra UA, por ejemplo, para ejecutar una UA como parte de
otra UA. En el ejemplo, la URI de la UA es http://www.e-ucm.es/uacata3/1
que tiene la estructura habitual de la dirección de una página web, sin
embargo, en el caso de las URI esta dirección es meramente descriptiva y
no tiene por qué existir una página web con dicha dirección.
§
Nivel. Este atributo especifica cuál es la compatibilidad mínima que debe
soportar un reproductor para reproducir la unidad de aprendizaje que se
está editando.
§
Objetivos de aprendizaje. Editor que permite asociar una lista de recursos
para definir el conjunto de objetivos de aprendizaje que se cubren en la
unidad de aprendizaje. Estos recursos pueden ser tanto archivos como
enlaces web.
§
Prerequisitos. Editor que permite asociar una lista de recursos para definir
el conjunto de prerrequisitos que se cubren en la unidad de aprendizaje.
Estos recursos pueden ser tanto archivos como enlaces web.
236
Figura 6.5.a. Pestaña de edición del resumen de una unidad de aprendizaje.
237
La Figura 6.5.b muestra la interfaz que permite definir la jerarquía de roles de la unidad
de aprendizaje. En la parte izquierda se encuentra el editor, en forma de árbol, para
los dos tipos de roles principales de la unidad de aprendizaje: rol alumno (Learners) y
rol plantilla (Staff). A través de este editor se pueden añadir nuevos sub-roles tanto de
los roles principales como de alguno particular que se haya definido. En la parte
derecha se permite editar los detalles particulares del rol que actualmente se
encuentre seleccionado. En concreto, se puede asociar una lista de recursos para
describir la finalidad del rol dentro de la unidad de aprendizaje. En el ejemplo mostrado
en la Figura 6.5.b se aprecian los dos roles de estudiante Alumno de nueva promoción
y Alumno de promociones antiguas, además del rol del tipo plantilla Profesor del
seminario.
Figura 6.5.b. Pestaña de creación de los roles de la unidad de aprendizaje.
238
La Figura 6.5.c muestra la interfaz que permite crear y editar las actividades
individuales de la unidad de aprendizaje. En la parte izquierda se encuentra un editor
donde se pueden crear nuevas actividades y, para el caso particular de las actividades
estructuradas, es posible crear las referencias a las actividades que se incluirán.
Además también es posible crear las referencias al entorno donde se llevará a cabo la
unidad de aprendizaje. En la parte derecha se permiten editar los detalles particulares
de la actividad que se encuentre seleccionada, en concreto, establecer la visibilidad de
la actividad, el mecanismo de finalización de la actividad y configurar la notificación de
finalización de la actividad.
Figura 6.5.c. Pestaña de creación de las actividades de la unidad de aprendizaje.
239
La Figura 6.5.d muestra la interfaz para crear los entornos de la unidad de aprendizaje.
Como parte de los entornos pueden definirse los objetos educativos y, en particular,
configurar los servicios de comunicación. En el ejemplo mostrado en la Figura 6.5.d se
está configurando el servicio de comunicación que se utilizará en la actividad de
debate. Este servicio de comunicación está configurado como servicio de
comunicación síncrono (i.e. un chat) y tiene asignados a los roles de alumnos como
participantes activos del chat y el rol de profesor como observador, moderador y
administrador de la sesión de chat.
Figura 6.5.d. Pestaña de creación de los entornos de la unidad de aprendizaje.
240
La Figura 6.5.e muestra la interfaz para crear el método de la unidad de aprendizaje.
En la parte izquierda se encuentra el editor donde se pueden añadir nuevos guiones,
actos y actuaciones. Al seleccionar alguno de los elementos del editor, en la parte
derecha pueden editarse los detalles del elemento. En el caso particular del método,
parte de los detalles que se pueden definir son las condiciones del método.
Figura 6.5.e. Pestaña de creación del método de la unidad de aprendizaje.
241
La Figura 6.5.f muestra el diálogo que permite crear las condiciones de la unidad de
aprendizaje. En el ejemplo mostrado, aparecen las dos condiciones que permiten la
adaptación de la unidad de aprendizaje dependiendo del test previo y de los resultados
en el trabajo (ver Figura 2.6.9.f).
Figura 6.5.f. Diálogo de creación de las condiciones de la unidad de aprendizaje.
242
La Figura 6.5.g muestra la interfaz del editor para crear las propiedades de la unidad
de aprendizaje. En la parte izquierda aparece la lista de propiedades definidas y en la
parte de la derecha se pueden editar los detalles particulares de la propiedad que
actualmente se encuentre seleccionada. En el ejemplo de la Figura 6.5.g se muestra la
edición de detalles de la propiedad email. Ya que ésta es una propiedad global
personal, su definición global (opción Global Definition) puede crearse a través del
editor, o se puede hacer referencia a una propiedad global ya existente (opción
Existing).
Figura 6.5.g. Pestaña de creación de propiedades de la unidad de aprendizaje.
243
La Figura 6.5.h muestra la interfaz del editor para gestionar los recursos de la unidad
de aprendizaje. A través de esta pestaña se muestran los archivos que actualmente
están dentro del directorio content del directorio del proyecto que se ha creado para la
unidad de aprendizaje. A través de esta interfaz el profesor puede importar otros
recursos dentro del proyecto de la unidad de aprendizaje. No obstante, el profesor
puede utilizar el explorador de archivos de su sistema operativo para copiar archivos y
recursos en el directorio content.
Figura 6.5.h. Pestaña de gestión de archivos de la unidad de aprendizaje.
244
En último lugar, la Figura 6.5.i muestra la interfaz de exportación del editor de
unidades de aprendizaje. El objetivo de esta sección del editor es triple:
§
Asignar un tipo a los recursos de la unidad de aprendizaje. A través del
apartado de Validación de Recursos (Check Resources) el profesor verifica
los recursos que actualmente tiene disponibles en la unidad de aprendizaje
y adicionalmente puede asignar un tipo (opción Type...) al recurso que esté
seleccionado. En particular, imsldcontent es el tipo de recurso que se utiliza
en los recursos web que incluyan elementos globales de IMS LD.
§
Validación de la unidad de aprendizaje. A través del apartado de Lista de
tareas (Checklist) el profesor verifica la unidad de aprendizaje respecto a
todas las reglas y restricciones que impone la especificación IMS LD. En
caso de error se mostrará un mensaje indicando el error y proporcionando
alguna pista acerca de cómo se puede solucionar el problema. Es
recomendable que la unidad de aprendizaje se valide cada cierto tiempo
para comprobar que los nuevos elementos introducidos se han configurado
adecuadamente.
§
Exportación. Una vez que la unidad de aprendizaje ha sido validada, ya
está lista para ser empaquetada. El apartado de exportación (Export)
permite exportar la unidad de aprendizaje y todos los recursos asociados en
un paquete IMS.
245
Figura 6.5.i. Pestaña de validación, asignación de tipos a recursos y exportación de
la unidad de aprendizaje.
Para finalizar este capítulo se muestran algunas capturas de la ejecución de las
unidades de aprendizaje utilizando el motor de ejecución CopperCore junto a la
herramienta de reproducción SLeD (ambas herramientas están descritas en el capítulo
1). SLeD es una herramienta web de reproducción de unidades de aprendizaje
compatibles con IMS LD que utiliza el motor de ejecución CopperCore para interpretar
las unidades de aprendizaje.
246
Nótese que para emplear SLeD es necesario tener instalado y funcionando el motor
CopperCore (disponible gratuitamente en: http://www.coppercore.org/). Una vez
instalado, es necesario instalar SLeD (que también se puede obtener de manera
gratuita en: http://sled.open.ac.uk/). En ambos sitios web se encuentra la
documentación necesaria para instalar ambas herramientas informáticas (en inglés).
La Figura 6.5.j muestra la reproducción de la unidad de aprendizaje UACata1 para un
usuario con rol Nuevo Alumno.
Figura 6.5.j. Captura de pantalla de la reproducción de la unidad de aprendizaje
UACata1 dentro de SLeD.
Además de CopperCore existen otros reproductores de unidades de aprendizaje
compatibles con IMS LD, entre ellos, destaca la iniciativa GRAIL (Escobedo del Cid et
al., 2007) desarrollado por el Grupo de Aplicaciones y Servicios Telemáticos (GAST)
de la Universidad Carlos III de Madrid. GRAIL es un reproductor de unidades de
aprendizaje que se encuentra integrado dentro de la plataforma educativa .LRN
(http://dotlrn.org) y que, por tanto, permite reproducir unidades de aprendizaje como
una herramienta más de la plataforma educativa, además de estar integrada con los
servicios que ofrece .LRN.
247
Para utilizar el reproductor, se puede:
§
Utilizar el servidor de pruebas que ofrece el grupo GAST. Este servidor
permite publicar unidades aprendizaje propias y reproducirlas. Este servidor
está disponible en:
https://gradient.it.uc3m.es/xowiki/main_page
§
Descargar una máquina virtual, compatible con VMWare, en la que se
encuentra instalado el LMS .LRN y el reproductor de IMS LD. Esta máquina
virtual contiene un sistema operativo configurado con todos los requisitos
para poder utilizar .LRN utilizando un reproductor de máquina virtual como
VMWare, QEMU, VirtualBox o Virtual PC entre otros. El Observatorio
Tecnológico del ITE (antiguo CNICE) ofrece un monográfico de Máquinas
Virtuales que se encuentra disponible en:
http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag
e&pageid=63
248
7. 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 en general 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. Esto es todavía más cierto si cabe en los aspectos de modelado
educativo donde, como hemos comentado previamente, todavía no existen consensos
ni prácticas comúnmente aceptadas. 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.
•
•
•
•
•
•
•
•
•
•
•
Adell, J. (2004). Internet en el aula: las WebQuest. Edutec: Revista Electrónica
de Tecnología Educativa [en línea] 17, pp. 3-4. Disponible en:
[2008, 5 de
http://www.uib.es/depart/gte/edutec-e/revelec17/adell_16a.htm
diciembre].
ADL SCORM (2009). Sharable Course Object Reference Model 2004 4th
Edition Documentation Suite Public Draft, [en línea]. Disponible en:
http://adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM 2004 4th
Ed V1.1/Documentation Suite/SCORM_2004_4ED_v1_1_Doc_Suite.zip [2009,
12 de noviembre].
AICC (2004). CMI guidelines for interoperability AICC revision 4.0. Technical
Report CMI001, Aviation Industry CBT Committee -AICC Subcommittee.
AICC Aviation Industry CBT Committee. Disponible en: http://www.aicc.org
[2008, 27 de noviembre].
ALFANET. Alfanet project (2007). Disponible en: http://alfanet.ia.uned.es [2007,
16 de mayo].
ARIADNE Alliance of Remote Instructional Authoring and Distribuion Networks
for Europe. Disponible en: http://www.ariadne-eu.org/ [2008, 27 de noviembre]
Balatsoukas, P., Morris, A. et al. (2008). Learning Objects Update: Review and
Critical Approach to Content Aggregation. Educational Technology & Society 11
(2), 119-130.
Berggreen, A., Burgos, D., Fontana, J. M., Hinkelman, D., Hung, V., Hursh, A. y
Tielemans, G. (2005). Practical and pedagogical issues for teacher adoption of
ims learning design standards in moodle LMS. Journal of Interactive Media in
Education, 2005 (2), 1-24.
Berlanga, A. J. y García, F. J. (2005). IMS ld reusable elements for adaptive
learning designs. Journal of Interactive Media in Education, 11, 1-16.
Botturi, L. (2006). E2ML: A visual language for the design of instruction.
Educational Technology Research and Development, 54 (3), 265-293.
Brickley, D. (1998). Tutorial Markup Language (TML), [en línea]. Bristol:
Institute for Learning and Research Technology, University of Bristol.
Disponible en: http://www.ilrt.bris.ac.uk/netquest/about/lang/ [2008, 27 de
noviembre].
249
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Britain, S. (2004). A review of learning design: Concept, specification and tools.
JICS E-learning Pedagogy Programme report, [en línea]. Disponible en:
www.jisc.ac.uk/uploaded_documents/ACF83C.doc [2008, 27 de noviembre].
Buendia, F., Agustí, M. Benlloch, J.V., Bisbal, E. y Lluesma, M (2003). Xedu, a
proposal of learning management system implementation. In International
Conference on Network Universities and e-Learning, Valencia (España), Mayo
8-9 2003.
Buendía, F., Agustí, F., Benlloch, J. V., Bisbal, E. y Lluesma, M. (2004). Xedu,
a proposal of learning management system implementation. Journal of
Information Technology Impact, 4 (1), 12.
Burgos, D. y Grif?ths, D. (2005). The unfold project. Understanding and using
learning design. Herleen: Open University of The Netherlands.
Caeiro Rodríguez, M., Marcelino, M. J., Llamas-Nistal, M., Anido Rifón, L. E.,
Mendes, A. J. (2007). Supporting the Modeling of Flexible Educational Units
PoEML: A Separation of Concerns Approach, [en línea]. Disponible en: J. UCS
13 (7), 980-990.
CopperAuthor
(2007).
Disponible
en:
http://sourceforge.net/projects/copperauthor [2008, 17 de mayo].
CopperCore (2008). Disponible en: http://www.coppercore.org [2008, 27 de
noviembre]
Dalziel, J. (2003). Implementing learning design: The learning activity
management system (lams). En G. Crisp, D. Thiele, I. Scholten, S. Barker & J.
Baron (Eds.), 20th Annual Conference of the Australasian Society for
Computers in Learning in Tertiary Education (ASCILITE 2003). Adelaide,
Australia.
Dalziel, J. (2005). From re-usable e-learning content to re-usable learning
designs: Lessons from lams. LAMS Foundation.
Dick, W. y Carey, L. (1996). The Systematic Design of Instruction (4a. ed.).
Nueva York: Haper Collins College Publishers.
Dick, W., Carey, L. y Carey, J. O. (2000). The Systematic Design of Instruction
(5a ed.). Allyn & Bacon.
Dodero, J. M., Tattersall, C., Burgos, D. y Koper, R. (2006). Nonrepresentational authoring of learning designs: from idioms to model-driven
development, [en línea]. Disponible en: http://hdl.handle.net/1820/783. [2008,
27 de mayo].
Dodge, B. (1995). Some thoughts about WebQuests, [en línea]. Disponible en:
http://webquest.sdsu.edu/about_webquests.html [2008, 5 de diciembre].
Escobedo del Cid, J. P., de la Fuente Valentín, L., Gutiérrez, S., Pardo, A. y
Delgado Kloos, C. (2007). Implementation of a Learning Design Run-Time
Environment for the LRN Learning Management System. Journal of Interactive
Media in Education.
Fernández Carballo-Calero, M. V. (2008). WebQuests: Un modelo educativo
basado en el uso de internet. Revista de Formación e Innovación Educativa
Universitaria, 1 (2), 58-60.
Fernández-Manjón, B., Moreno-Ger, P., Sierra, J.L. y Martínez-Ortiz, I. (2007).
Uso de estándares aplicados a TIC en Educación. Informe Nº 16. CNICE.
Griffiths, D., Beauvoir, P. y Sharples, P. (2008). Advances in Editors for IMS LD
in the TENCompetence Project. En Proc. of 8th IEEE International Conference
on Advanced Learning Technologies (ICALT 08), pp. 1045-1047.
250
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Hernández-Leo, D., Villasclaras-Fernández, E. D., Asensio-Pérez, J. I.,
Dimitriadis, Y., Jorrín-Abellán, I. M., Ruiz-Requies, I. y Rubia-Avi, B. (2006).
Collage: A collaborative learning design editor based on patterns. Educational
Technology & Society, 9 (1), 58–71.
HR-XML Consortium (2004). Competencies Schema, [en línea]. Disponible en:
http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/Competencies.html [2008, 27 de
noviembre].
IEEE (2007). 1484.20.1/Draft Standard for Learning Technology— Data Model
for Reusable Competency Definitions (último borrador publicado de acceso
público y gratuito). Disponible en: http://www.ieeeltsc.org:8080/Plone/workinggroup/competency-data-standards-working-group20/IEEE_1484.20.1.D5.WD11.zip [2008, 12 de noviembre].
IEEE LOM (2002). IEEE Standard for Learning Object Metadata. IEEE
Standard 1484.12.1-2002. Autor.
IEEE RCD (2008). IEEE Standard for Learning Technology - Data Model for
Reusable Competency Definitions, IEEE Std 1484.20.1-2007. Autor.
IMS CP (2004). IMS Content Packaging Specification v 1.1.4. [en línea].
Disponible en www.imsglobal.org/content/packaging/ [2008, 15 de noviembre].
IMS Global Consortium (2002). IMS Reusable Definition of Competency or
Educational Objective Specification, Version 1.0 Final Specification, [en línea].
Disponible en: http://www.imsglobal.org/competencies/index.html [2008, 27 de
noviembre].
IMS Global Consortium (2003). IMS Learner Information Package Accessibility
for LIP, Version 1.0 Final Specification, [en línea]. Disponible en:
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].
IMS Global Consortium (2004). IMS AccessForAll Meta-data, Version 1.0 Final
Specification,
[en
línea].
Disponible
en:
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].
IMS Global Consortium (2005). IMS Guidelines for Developing Accessible
Learning Applications, Version 1.0 White Paper, [en línea]. Disponible en:
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].
IMS Global Consortium (2005). IMS Learner Information Package, Version
1.0.1
Final
Specification,
[en
línea].
Disponible
en:
http://www.imsglobal.org/profiles/index.html [2008, 27 de noviembre].
IMS
Global
Learning
Consortium
(2008).
Disponible
en:
http://www.imsproject.org [2008, 27 de noviembre].
IMS LD (2003). IMS Learning Design, [en línea]. Disponible en:
http://www.imsglobal.org/learningdesign/ [2008, 27 de noviembre].
IMS META (2006). IMS Meta-Data Version 1.3., [en línea]. Disponible en:
www.imsglobal.org/metadata/#version1.3. [2008, 15 de noviembre].
IMS QTI (2005). IMS Question & Test Interoperablity Specification, Version 2.0
Final
Specification,
[en
línea].
Disponible
en:
http://www.imsglobal.org/question/index.html [2008, 27 de noviembre].
IMS QTI (2006). IMS Question & Test Interoperability Specification v2.1. , [en
línea]. Disponible en: www.imsglobal.org/question [2008, 15 de noviembre].
IMS RDCEO (2002). IMS Reusable Definition of Competency or Educational
Objective
Specification
v
1.,
[en
línea].
Disponible
en:
www.imsglobal.org/competencies [2008, 15 de noviembre].
IMS SS (2003). IMS Simple Sequencing Specification v1.0., [en línea].
Disponible en: www.imsglobal.org/simplesequencing [2008, 15 de noviembre].
251
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Institute of Electrical and Electronics Engineers (IEEE) Learning Technology
Standards Committee (LTSC) (2008). Disponible en: http://ltsc.ieee.org [2008,
27 de noviembre].
Karampiperis, P. y Sampson, D. (2004). A ?exible authoring tool supporting
adaptive learning activities. En Proceedings of IADIS International Conference
on Cognition and Exploratory Learning in Digital Age. Lisboa, Portugal.
Koch, M. (2002). Interoperable community platforms and identity management
in the university domain. International Journal on Media Management, 4 (1),
21–30.
Koper, R. (2000). From change to renewal: Educational technology foundations
of electronic learning environments. Holanda: Open University of the
Netherlands.
Koper, R. (2001). Modelling units of study from a pedagogical perspective: the
pedagogical meta-model behind EML. Holanda: Educational Technology
Expertise Centre (OTEC), Open University of the Netherlands.
Li, X. (1991). What's So Bad About Rule-Based Programming?. IEEE Software
8, 103-105.
Martínez-Ortiz, I., Moreno-Ger, P., Sancho-Thomas, P., y Fernández-Manjon,
B. (2005). Using docbook to aid in the creation of learning content. En A.
Rettberg & C. Bobda (Eds.), New Trends and Technologies in Computer-Aided
Learning for Computer-Aided Design, (pp. 11–23). Springer.
Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2006).
Using docbook and xml technologies to create adaptive learning content.
International Journal of Computer Science and Applications, 3 (2), 91–108.
Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2008).
A Flow-Oriented Visual Language for Learning Designs. En Proceedings of the
7th International Conference on Web-based Learning (ICWL 2008). Jinhua,
China. Lecture Notes in Computer Science 5145, pp 486-496.
Mayes, T., de Freitas, S. (2004). Stage 2: Review of e-learning theories,
frameworks and models. JICS E-learning Model Desk Study, [en línea].
Disponible
en:
http://www.jisc.ac.uk/uploaded_documents/Stage%202%20Learning%20Model
s%20(Version%201).pdf [2008, 27 de noviembre].
McAndrew, P., Woods, W. I. S., Little, A., Weller, M. J., Koper, R. y Vogten, H.
(2004). Implementing learning design to support web-based learning. En
Proceedings of the Australasian World Wide Web Conference (AusWeb04).
MedBiquitous Competencies Working Group (2008). Disponible en:
http://www.medbiq.org/working_groups/competencies/index.html [2008, 27 de
noviembre].
Merrill, M. D. (1994) Instructional Design Theory. Educational Technology
Publications. Englewood Cliffs.
Miao, Y. (2005). Cosmos: Facilitating learning designers to author units of
learning using ims ld. En D. Jonassen & I. Mitsuru (Eds.), International
Conference on Computers in Education (pp. 275–282). Singapore: IOS Press.
Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I. y Fernández-Manjón, B. (2007).
A Documental Approach to Adventure Game Development. Science of
Computer Programming 67 (1), 3-31.
Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I., Fernández-Manjón, B. (2008).
A Content-Centric Development Process Model. IEEE Computer 41 (3), 24-30.
252
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
OMG (2007). Unified Modeling Language: Superstructure version 2.1.1, [en
línea]. Disponible en: http://www.omg.org/cgi-bin/doc?formal/07-02-05 [2008,
27 de noviembre].
Paquette, G. (2004). Educational modeling languages, from an instructional
engineering perspective. En McGreal, R. (ed.), Online education using learning
objects (pp 331–246). Londres: Routledge/Falmer.
Paquette, G., Teja, I., Leonard, M., Lundgren-Cayrol, K. y Marino, O. (2005).
An Instructional engineering method and tool for design of Units of Learning. En
Learning Design, a Handbook on Modelling and Delivering Networked
Education and Training (pp 161–184). Heidelberg: Springer.
Polsani, P. (2003). Use and Abuse of Reusable Learning Objects. En Journal of
Digital Information 3 (4).
Rawlings, A., van Rosmalen, P., Koper, R., Artacho-Rodriguez, M. y Lefrere, P.
(2002). Survey of educational modelling languages (EML). En CEN/ISSS
WS/LT Learning Technologies Works-hop, September 19.
Redondo Templado, F. M. (2006). Sistema Binario [en línea]. Disponible en:
http://clic.xtec.net/db/act_es.jsp?id=3259 [2008, 5 de diciembre].
Reigeluth, C. M. (1983). Instructional Design Theories and Models: An
Overview of Their Current Status. Lawrence Erlbaum Associates.
[2008, 27 de
RELOAD (2008). Disponible en: http://www.reload.ac.uk
noviembre].
Rodríguez-Artacho, M., Verdejo, M. F., Mayorga, J. I. y Calero, M. Y. (1999).
Using high-level language to describe and create web-based learning
scenarios. En IEEE Frontiers In Education FIE ’99 (pp 10-13). San Juan, Puerto
Rico.
SCORM (2004). Scorm 2004 overview 2nd edition. Advanced Distributed
Learning.
Sierra, J. L., Moreno-Ger, P., Martínez-Ortiz, I. y Fernández-Manjón, B. (2006).
A highly modular and extensible architecture for an integrated ims based
authoring system: The <e-aula> experience. Software-Practice & Experience,
37 (4), 441–461.
Van Durm, R., Duval, E., Verhoeven, B., Cardinaels, K. y Olivié, H. (2001).
Extending the ariadne web-based learning environment. En World Conference
on Educational Multimedia, Hypermedia & Telecommunications (ED-MEDIA
2001) (pp 1932–1937). Tampere, Finlandia.
Vantroys, T. (2003). Du langage métier au langage technique, une plateforme
?exible déxécution de scénarios pédagogiques. Lille: Computer sciences,
Université des Sciences et Technologies de Lille.
Verbert, K. y Duval, E. (2004). Towards a global component architecture for
learning objects: A comparative analysis of learning object content models. En
P. Kommers & G. Richards (Eds.), World Conference on Educational
Multimedia, Hypermedia and Telecommunications 2004 (pp. 202–208),
Chesapeake, VA: AACE.
Walsh, N. y Muellner, L. (1999). DocBook: The De?nitive Guide (1a ed.).
Sebastopol, CA, EE.UU.: O’Reilly.
Weitl, F., Süß, Ch., Kammerl, R. y Freitag, B. (2002). Presenting Complex eLearning Content on the Web: A Didactical Reference Model. En Proc. e-learn
2002 world conference on E-Learning in Corporate, Government, Healthcare,
and Higher Education.
253
•
•
Weller, M., Little, A., McAndrew, P. y Woods, W. (2006). Learning design,
generic service descriptions and universal acid. Educational Technology &
Society, 9 (1), 138–145.
XML Schema (2004). W3C Recommendation: XML Schema (2a ed.) [en línea].
Disponible en: www.w3.org/TR [2008, 15 de noviembre].
254