Descargar PDF - Portal educativo
Descargar PDF - Portal educativo
Descargar PDF - Portal educativo
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
ESTANDARIZACIÓN Y DISEÑO EDUCATIVO
DIRECCIÓN DE LA SERIE<br />
Instituto de Tecnologías Educativas (ITE)<br />
Dirección: Antonio Pérez Sanz y Alfonso Berlanga<br />
Coordinación: María Luisa Gutiérrez de la Concepción, Nieves<br />
Gutiérrez de la Concepción y Antonio Galisteo del Valle<br />
Corrección y revisión: Antonio Galisteo del Valle, Pamela<br />
Fernández Sánchez y Antonio Estévez Funes<br />
AUTORES<br />
Dirección del Informe: Baltasar Fernández Manjón, José Luis<br />
Sierra Rodríguez, Iván Martínez Ortiz y Pablo Moreno Ger<br />
PUBLICACIÓN<br />
Dirección: Antonio Pérez Sanz<br />
Producción ejecutiva: Antonio Galisteo del Valle, Mª Luisa<br />
Gutiérrez de la Concepción y Nieves Gutiérrez de la Concepción<br />
Diseño gráfico: Aurelio Lorenzo Pérez y Mercedes Moral Maroto<br />
Edición web: Antonio Estévez Funes y Pamela Fernández<br />
Sánchez<br />
2
Resumen Ejecutivo<br />
Este informe aborda los aspectos de especificación, sistematización y estandarización<br />
de los modelos <strong>educativo</strong>s utilizados en la enseñanza que emplea como ayuda y<br />
soporte las Tecnologías de la Información y la Comunicación (TIC). Todo este conjunto<br />
de diseños o estrategias instruccionales, basados a su vez en diversos modelos<br />
pedagógicos, es lo que se engloba bajo el término de “diseño <strong>educativo</strong>” (en inglés<br />
Learning Design). La idea subyacente es que las primeras iniciativas de<br />
estandarización (e.g. IMS Content Packaging, IEEE LOM) se han basado<br />
principalmente en la organización y descripción de los contenidos (para una<br />
descripción mas completa se puede consultar el informe 16 de esta misma colección<br />
Uso de estándares aplicados a TIC en Educación que aunque resuelven el problema<br />
de la interoperabilidad y portabilidad, no son suficientes para abordar y describir<br />
completamente procesos <strong>educativo</strong>s complejos como los que se utilizan de forma<br />
habitual en las clases para lograr un aprendizaje efectivo. Por tanto se ha<br />
evolucionado tratando de proporcionar formas de descripción de los procesos<br />
<strong>educativo</strong>s que vayan más allá de los contenidos y contemplen también los aspectos<br />
dinámicos (e.g. actividades, secuenciación, interacciones) que son una parte<br />
fundamental de los procesos de aprendizaje y que hacen posible la creación de<br />
aplicaciones mas avanzadas como, por ejemplo, las basadas en competencias o las<br />
colaborativas. La formalización de estas descripciones de modo que sean<br />
automatizables y reproducibles por una computadora es lo que se ha denominado<br />
Lenguajes de Modelado Educativo (en inglés, Educational Modelling Languages).<br />
Es necesario destacar que este modelado <strong>educativo</strong> y en general la utilización de las<br />
TIC para la educación y aprendizaje que englobamos bajo el término e-learning no<br />
implica necesariamente una modalidad de formación a distancia ya que su uso es más<br />
amplio, siendo frecuente su empleo como apoyo a clases presenciales o incluso un<br />
modelo mixto de clases semipresenciales (lo que se ha denominado blended learning<br />
o b-learning). De hecho, por ejemplo, en las actividades modeladas pueden implicar<br />
algún tipo de interacción entre los usuarios que, a su vez, puede ser realizado con<br />
apoyo de las TIC o de forma presencial.<br />
Este documento se basa, además de en la revisión bibliográfica y de los propios<br />
estándares, en la experiencia en investigación, implementación y desarrollo que han<br />
adquirido los autores en su trabajo como miembros del grupo de investigación en elearning<br />
(, http://www.e-ucm.es) de la Facultad de Informática de la<br />
Universidad Complutense de Madrid.<br />
El propósito principal de este estudio es presentar una visión general sobre las<br />
iniciativas y estándares de facto para modelado <strong>educativo</strong> que han surgido en el<br />
mundo del e-learning y que son aplicables a distintos enfoques y contextos <strong>educativo</strong>s.<br />
No obstante hay que destacar que es una visión desde el punto de vista más técnico y<br />
de aplicación, no siendo objetivo del trabajo un análisis en profundidad de las teorías<br />
educativas subyacentes. Se presentan sus fundamentos y sus aplicaciones de la<br />
forma más simple posible, pero tratando de no perder el rigor, de modo que pueda ser<br />
comprensible y útil para los educadores. La amplitud, diversidad y continua evolución<br />
de este campo hace que un estudio de este tipo no pueda ser exhaustivo, es decir que<br />
cubra todas las iniciativas existentes, de modo que se ha tenido que limitar su<br />
3
contenido para que únicamente considere aquellas iniciativas que son más utilizadas<br />
actualmente o que consideramos que son más prometedoras.<br />
Después de realizar una revisión general del modelado <strong>educativo</strong>, así como de las<br />
iniciativas y herramientas más representativas, se realiza una revisión en profundidad<br />
del estándar de facto que actualmente es más completo y versátil para el modelado<br />
<strong>educativo</strong>: IMS Learning Design. Mediante un ejemplo sencillo pero a la vez<br />
suficientemente significativo se introducen los distintos elementos necesarios para<br />
entender un estándar tan expresivo (y por tanto, en algunos casos, complejo de<br />
entender).<br />
También se presentan otros estándares relacionados con la información sobre los<br />
usuarios como es IMS Learner Information Profile (IMS LIP). IMS-LIP es una<br />
especificación para expresar la información personal de los alumnos, su historial<br />
dentro del sistema (incluyendo su porfolio de trabajos realizados) y las preferencias<br />
que tengan estos usuarios. El tema de la información de los usuarios y su<br />
estandarización aunque es muy importante plantea problemas de muy diversa índole,<br />
desde legales (debido a que la Ley de Protección de Datos Personales en Europa y<br />
España es más estricta que en otros países –aunque este tema no se aborda en este<br />
estudio- ) a culturales o de madurez de la propia especificación. A pesar del avance<br />
que supone disponer de IMS-LIP, éste es un tema complejo en el que sigue habiendo<br />
competencia comercial y falta de suficiente consenso.<br />
No obstante, se están realizando avances en temas relacionados pues ya se ha<br />
llegado al suficiente acuerdo para estandarizar una forma básica de definición de<br />
competencias y capacidades de los estudiantes. Este aspecto se trata en la<br />
especificación IMS RDCEO (y en su estándar oficial IEEE RCD asociado).<br />
En este informe también se analizan las especificaciones que tratan de lograr que el elearning<br />
sea accesible a personas con diversidad funcional. AccessForAll es la<br />
denominación genérica empleada por el consorcio IMS para designar sus iniciativas y<br />
esfuerzos relacionados con potenciar la accesibilidad de los contenidos <strong>educativo</strong>s a<br />
personas con necesidades especiales derivadas de su entorno, circunstancias o<br />
discapacidades.<br />
En el capítulo final se ponen ejemplos de uso práctico de herramientas de edición de<br />
diseños <strong>educativo</strong>s con IMS-LD por ser el estándar y con LAMS por ser actualmente el<br />
modelado, que aunque no sigue el estándar parece contar con mayor aceptación.<br />
La organización de este trabajo está pensada para diferentes públicos. Si el lector está<br />
interesado en tener solamente una visión general del modelado <strong>educativo</strong> en elearning<br />
podrá adquirirla mediante la lectura de los dos primeros capítulos. Un lector<br />
que ya tenga un cierto conocimiento de este modelado <strong>educativo</strong> en e-learning y de<br />
cómo se ve afectado por la estandarización, pero que quiera profundizar en aspectos<br />
más técnicos de IMS-LD o de alguno de los estándares abordados (IMS LIP, IMS<br />
RDCEO, IMS A4A) podrá obtenerlo mediante la lectura de los capítulos posteriores al<br />
segundo. Aunque estos capítulos son más técnicos, hasta donde ha sido posible, se<br />
ha tratado de hacerlos comprensibles y de poner ejemplos simplificados siempre<br />
tratando de no perder el rigor técnico.<br />
Este campo tiene además la particularidad de su juventud y cambio continuo. Como<br />
incesantemente surgen o bien nuevas especificaciones o bien correcciones o<br />
añadiduras a las existentes, la bibliografía existente queda rápidamente superada por<br />
4
la realidad. Esto hace que gran parte de las referencias que aparecen en este trabajo<br />
lo sean a páginas web de las instituciones implicadas en la estandarización,<br />
publicaciones electrónicas o documentos que están disponibles en Internet.<br />
5
Mensaje de comunicación corporativa<br />
Este informe ha sido encargado por el Instituto de Tecnologías Educativas del<br />
Ministerio de Educación a los profesores Baltasar Fernández Manjón, José Luis Sierra<br />
Rodríguez, Ivan Martinez Ortiz y Pablo Moreno Ger del grupo de Investigación de<br />
Ingeniería del Software aplicado al e-learning (, www.e-ucm.es)<br />
perteneciente al Departamento de Ingeniería del Software e Inteligencia Artificial de la<br />
Universidad Complutense de Madrid. El encargo se realizó en el año 2008, a raíz de<br />
sus investigaciones relacionadas con el modelado <strong>educativo</strong> y en cómo estos aspectos<br />
estaban viéndose reflejados en los estándares emergentes en e-learning y en los<br />
sistemas e-learning. El tema central del informe es la situación actual del modelado<br />
<strong>educativo</strong> y cómo dicho modelado puede utilizarse en la mejora de los procesos<br />
<strong>educativo</strong>s. El objetivo es descubrir a los lectores de este informe las principales<br />
características, incluyendo cualidades y limitaciones, del modelado <strong>educativo</strong> y cómo<br />
se refleja dicho modelado en los sistemas actuales de e-learning. Por completitud se<br />
presentan también especificaciones relacionadas con el modelado <strong>educativo</strong> (e.g.<br />
cómo se representa al estudiante o cómo se tienen en cuenta sus características<br />
especiales o sus competencias) y cómo este modelado <strong>educativo</strong> se refleja en<br />
sistemas concretos de e-learning que consideramos especialmente prometedores<br />
como, por ejemplo, LAMS.<br />
Baltasar Fernández Manjón es Doctor en Ciencias Físicas por la Universidad<br />
Complutense de Madrid donde actualmente es profesor en la Facultad de Informática.<br />
Es el codirector del grupo de Investigación de Ingeniería del Software aplicado al elearning<br />
(, www.e-ucm.es). Ha dirigido distintos proyectos de investigación<br />
relacionados con los usos <strong>educativo</strong>s de las nuevas tecnologías y es miembro del<br />
Working Group 3.3 "Research on the Educational uses of Communication and<br />
Information Tecnlogies" de la International Federation for Information Processing<br />
(IFIP), del Subcomité 36 de Tecnologías de la Información y la Comunicación para el<br />
aprendizaje (SC36), de la Asociación Española de Normalización y Certificación<br />
(AENOR CTN71/SC36) y del Capítulo Español para la Sociedad de la Educación de<br />
IEEE (Red CESEI). Ha publicado más de 90 artículos de investigación en revistas y<br />
congresos y ha participado en la organización de diversas conferencias del área (e.g.<br />
SCORM, ICALT, SIIE). Sus áreas principales de investigación son las tecnologías y los<br />
estándares de e-learning, las aplicaciones educativas de la web, la aplicación de los<br />
videojuegos a la educación y los sistemas adaptativos (incluyendo modelado de<br />
usuario y aspectos de accesibilidad).<br />
José-Luis Sierra-Rodríguez es Doctor en Informática por la Universidad Complutense<br />
de Madrid, donde actualmente ocupa una plaza de Profesor Titular de Universidad. El<br />
Dr. Sierra es coautor de más de 70 artículos de investigación publicados en revistas y<br />
actas de conferencias internacionales. Sus intereses investigadores incluyen la<br />
Ingeniería del Software orientada a lenguajes, los lenguajes de marcado y el desarrollo<br />
dirigido por lenguajes de Sistemas e-learning.<br />
Ivan Martínez es licenciado en Informática por la Universidad Complutense de Madrid.<br />
Desde 2007 trabaja como profesor Colaborador en la Facultad de Informática de la<br />
dicha universidad donde está completando su doctorado en modelado <strong>educativo</strong> y<br />
estándares de e-learning. Ha participado en diversos proyectos relacionados en el<br />
área de la educación asistida por computador tanto en el ámbito nacional como<br />
6
internacional. Además ha publicado más de 25 artículos en conferencias y revistas<br />
internacionales. Sus áreas principales de investigación son el modelado <strong>educativo</strong>, los<br />
estándares de e-learning, las aplicaciones educativas de la web y la aplicación de los<br />
videojuegos a la educación.<br />
Pablo Moreno Ger es Doctor en Informática por la Universidad Complutense de Madrid<br />
y en la actualidad trabaja como Profesor Ayudante Doctor en el Departamento de<br />
Ingeniería del Software e Inteligencia Artificial de la UCM. Ha participado en diversos<br />
proyectos relacionados con el área de la educación asistida por computador tanto en<br />
el ámbito nacional como internacional. Además ha publicado más de 30 artículos en<br />
conferencias y revistas internacionales. Sus intereses de investigación abarcan todo<br />
tipo de tecnologías educativas, centrándose en el desarrollo e integración de<br />
contenidos altamente interactivos en los entornos de aprendizaje y sistemas elearning,<br />
especialmente en juegos <strong>educativo</strong>s, así como la adaptación y la evaluación<br />
de los procesos de aprendizaje.<br />
7
Deseamos mostrar nuestro agradecimiento al resto de miembros del Grupo de elearning<br />
de la Facultad de Informática de la Universidad Complutense de Madrid así<br />
como a los responsables del Campus Virtual de nuestra Universidad coordinados por<br />
el profesor Alfredo Fernández-Valmayor. Algunas de las pruebas se han realizado en<br />
dicho Campus Virtual.<br />
Parte de los resultados reflejados en este trabajo se han obtenido en la investigación<br />
realizada en los proyectos AdaptaLearn y OdA Virtual que han sido parcialmente<br />
financiados por la Comisión Ministerial de Ciencia y Tecnología (TIN2007-68125-C02-<br />
01, TIN2005 08788 C04-01) y con ayudas de la Comunidad de Madrid y de la<br />
Universidad Complutense de Madrid para el grupo de Investigación Ingeniería del<br />
Software y e-learning (, 921340 UCM-CAM). También se han reutilizado<br />
algunos de los resultados logrados en el proyecto Avanza Flexo (TSI-020301-2008-19)<br />
realizado en colaboración con otras universidades y fundaciones (U. Carlos III, U. de<br />
Cádiz, U de Santiago de Compostela, U de Harvard, LAMS-Australia y Sidar) y<br />
empresas (Atos Origin, Indra, CEPAL) y en el proyecto Cenit INREDIS liderado por<br />
Technosite y en el que participan mas de 25 univesidades y empresas españolas.<br />
Finalmente este trabajo se ha beneficiado del contraste internacional proporcionado<br />
por la participación del grupo en el proyecto CID – Comunidad Intercultural<br />
para el Desarrollo y Uso de Objetos de Aprendizaje (liderado por la U. de Chile y en el<br />
que participan 8 universidades europeas e iberoamericanas). El proyecto CID<br />
pertenece al programa europeo Alfa (II-0511-A).<br />
8
1. LENGUAJES DE MODELADO EDUCATIVO........................... 13<br />
1.1. INTRODUCCIÓN................................................................. 13<br />
1.2. EL CONCEPTO DE MODELADO EDUCATIVO................ 13<br />
1.3. LENGUAJES DE MODELADO EDUCATIVO.................... 15<br />
1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS ............. 17<br />
1.4.1. Lenguajes Especí?cos .................................................. 18<br />
1.4.2. Lenguajes de Estructuración de Contenidos ................ 19<br />
1.4.3. Lenguajes de Actividades ............................................. 22<br />
1.5. IMS LEARNING DESIGN ................................................... 24<br />
1.6. HERRAMIENTAS DE SOPORTE A IMS-LD ..................... 27<br />
1.6.1. Herramientas de Autoría de IMS-LD............................. 28<br />
1.6.2. Motores de ejecución compatibles con IMS-LD ........... 33<br />
1.6.3. Reproductores de IMS-LD ............................................ 34<br />
1.6.4. Otras iniciativas y proyectos de investigación<br />
relacionados con IMS-LD........................................................... 36<br />
1.7. A MODO DE CONCLUSIÓN .............................................. 38<br />
2. LA ESPECIFICACIÓN IMS LEARNING DESIGN .................... 39<br />
2.1. INTRODUCCIÓN................................................................. 39<br />
2.2. UN CASO DE ESTUDIO..................................................... 39<br />
2.3. VISIÓN CONCEPTUAL DE IMS LD................................... 41<br />
2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES ........ 46<br />
2.4.1. IMS Content Packaging e IMS LD ................................ 46<br />
2.4.2. Niveles en la Especificación ......................................... 49<br />
2.5. EL NIVEL A......................................................................... 50<br />
2.5.1. Estructura de alto nivel de un Diseño Educativo .......... 50<br />
2.5.2. Descripción de los Componentes: Roles, Actividades y<br />
Entornos ..................................................................................... 52<br />
2.5.3. Descripción del método <strong>educativo</strong> ................................ 60<br />
2.5.4. Modelo de Ejecución..................................................... 62<br />
2.5.5. Ejemplo de Diseño de Nivel A ...................................... 63<br />
2.6. EL NIVEL B......................................................................... 68<br />
2.6.1. Propiedades .................................................................. 69<br />
2.6.2. Expresiones................................................................... 71<br />
2.6.3. Acciones........................................................................ 73<br />
2.6.4. Condiciones................................................................... 74<br />
2.6.5. Extensión de las condiciones de finalización de<br />
actividades, actos, guiones y métodos ...................................... 76<br />
9
2.6.6. Extensión de las acciones tras la finalización para<br />
actividades, actos, guiones y métodos ...................................... 76<br />
2.6.7. Elementos globales y monitores ................................... 76<br />
2.6.8. Modelo de Ejecución..................................................... 77<br />
2.6.9. Ejemplo de diseño de nivel B........................................ 77<br />
2.7. EL NIVEL C......................................................................... 84<br />
2.7.1. Notificaciones ................................................................ 84<br />
2.7.2. Extensiones en IMS LD nivel C .................................... 85<br />
2.7.3. Ejemplo de diseño de nivel C ....................................... 85<br />
2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS... 87<br />
2.8.1. Codificación de la Estructura de Alto nivel del Diseño . 87<br />
2.8.2. Codificación de los roles ............................................... 89<br />
2.8.3. Codificación de las actividades..................................... 91<br />
2.8.4. Codificación de los entornos......................................... 94<br />
2.8.5. Codificación de los métodos ......................................... 95<br />
2.8.6. Codificación de las propiedades ................................... 99<br />
2.8.7. Codificación de las expresiones, acciones y condiciones<br />
101<br />
2.8.8. Codificación de elementos globales y servicio de<br />
monitorización .......................................................................... 103<br />
2.8.9. Codificación de notificaciones..................................... 103<br />
3. IMS LEARNER INFORMATION PACKAGE........................... 104<br />
3.1. INTRODUCCIÓN............................................................... 104<br />
3.2. VISIÓN CONCEPTUAL .................................................... 104<br />
3.2.1. Categorías de datos.................................................... 105<br />
3.2.2. Metadatos.................................................................... 107<br />
3.3. UN CASO DE ESTUDIO................................................... 108<br />
3.4. ESTRUCTURA XML ......................................................... 109<br />
3.4.1. Metadatos y otros elementos comunes ...................... 109<br />
3.4.2. El elemento learnerInformation................................... 113<br />
3.4.3. El elemento identification ............................................ 115<br />
3.4.4. El elemento qcl............................................................ 117<br />
3.4.5. El elemento activity ..................................................... 120<br />
3.4.5.1. Descripción de Actividades: definition............... 123<br />
3.4.5.2. Productos Generados en Actividades: product. 125<br />
3.4.5.3. Informes sobre Actividades: testimonial............ 127<br />
3.4.5.4. Evaluación de Actividades: evaluation.............. 128<br />
3.4.6. El elemento affiliation .................................................. 131<br />
3.4.7. El elemento transcript ................................................. 133<br />
10
3.4.8. El elemento accessibility ............................................. 134<br />
3.4.8.1. Accesibilidad idiomática: language ................... 136<br />
3.4.8.2. Preferencias de acceso: preference ................. 138<br />
3.4.9. El elemento goal.......................................................... 139<br />
3.4.10. El elemento competency............................................. 141<br />
3.4.11. El elemento interest .................................................... 143<br />
3.4.12. El elemento securitykey .............................................. 145<br />
3.4.13. El elemento relationship.............................................. 146<br />
4. IMS REUSABLE DEFINITION OF COMPETENCY OR<br />
EDUCATIONAL OBJECTIVE ....................................................... 148<br />
4.1. INTRODUCCIÓN............................................................... 148<br />
4.2. VISIÓN CONCEPTUAL DE LA DEFINICIÓN DE<br />
COMPETENCIAS ....................................................................... 151<br />
4.3. EJEMPLOS DE POSIBLES APLICACIONES................. 152<br />
4.3.1. Casos de uso .............................................................. 152<br />
4.3.2. Ejemplo de uso............................................................ 153<br />
4.4. ESTRUCTURA XML ......................................................... 154<br />
4.4.1. El elemento rdceo ....................................................... 154<br />
4.4.2. El elemento identifier................................................... 157<br />
4.4.3. El elemento title........................................................... 157<br />
4.4.4. El elemento description............................................... 157<br />
4.4.5. El elemento definition.................................................. 157<br />
4.4.6. El elemento metadata ................................................. 159<br />
4.5. EXTENSIBILIDAD............................................................. 159<br />
5. IMS ACCESS FOR ALL .......................................................... 160<br />
5.1. INTRODUCCIÓN............................................................... 160<br />
5.1.1. Una problemática compleja ........................................ 161<br />
5.1.2. Tres aspectos de un mismo problema........................ 162<br />
5.2. IMS ACCESSIBILITY FOR LIP ........................................ 163<br />
5.2.1. Definición de Preferencias .......................................... 164<br />
5.2.2. Solicitud de servicios adicionales ............................... 166<br />
5.3. IMS ACCESSFORALL METADATA................................ 168<br />
5.3.1. Descripción general .................................................... 169<br />
5.3.2. Metadatos para recursos primarios ............................ 171<br />
5.3.3. Metadatos para recursos equivalentes....................... 173<br />
6. HERRAMIENTAS DE SOPORTE PARA LOS DISEÑOS<br />
EDUCATIVOS................................................................................ 175<br />
11
6.1. WEBQUEST...................................................................... 176<br />
6.2. JCLIC ................................................................................ 178<br />
6.3. LAMS................................................................................. 183<br />
6.3.1. Introducción................................................................. 183<br />
6.3.2. La herramienta LAMS ................................................. 185<br />
6.3.3. Actividades, secuencias de actividades y mecanismos<br />
de adaptación........................................................................... 187<br />
6.3.4. Configuración y uso básico de LAMS ......................... 193<br />
6.3.4.1. Administración básica de LAMS........................ 195<br />
6.3.4.2. Autoría y publicación de secuencias LAMS ...... 202<br />
6.3.4.3. Monitorización y Seguimiento. .......................... 213<br />
6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON<br />
LAMS .......................................................................................... 219<br />
6.4.1. Diseño de las unidades de aprendizaje / secuencias de<br />
actividades LAMS para el caso de estudio.............................. 219<br />
6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON<br />
IMS LD ........................................................................................ 232<br />
7. BIBLIOGRAFÍA ....................................................................... 249<br />
12
1. LENGUAJES DE MODELADO EDUCATIVO<br />
1.1. INTRODUCCIÓN<br />
En la enseñanza apoyada por la tecnología, y que globalmente se denomina por el<br />
término en inglés e-learning, se ha producido una gran revolución con la nueva forma<br />
de crear contenidos que suponen los objetos de aprendizaje (OA, en inglés learning<br />
objects). Aunque los objetos de aprendizaje tienen múltiples definiciones una de las<br />
más aceptadas es la utilizada en el estándar LOM donde se definen como “cualquier<br />
entidad que puede ser usada, reutilizada o referenciada durante un proceso de<br />
aprendizaje apoyado por la tecnología”. La principal ventaja es que permite crear<br />
cursos mediante combinación de contenidos previamente existentes es decir potencia<br />
la reusabilidad y la interoperabilidad (para una descripción más completa se puede<br />
consultar el informe 16 de esta misma colección Uso de estándares aplicados a TIC en<br />
Educación). No obstante, y a pesar de las ventajas que aportan los OA en e-learning,<br />
existe también un amplio consenso entre los educadores de que la creación y<br />
presentación de materiales <strong>educativo</strong>s de gran calidad no es su?ciente para obtener<br />
una experiencia educativa plena y satisfactoria. Es igualmente importante la<br />
plani?cación de las otras actividades (tutorías, exámenes, lectura de libros, etc.) que el<br />
estudiante debe llevar a cabo para conseguir los objetivos <strong>educativo</strong>s propuestos por<br />
el profesor.<br />
De este análisis surge el concepto de Lenguaje de Modelado Educativo (EML) (del<br />
inglés Educational Modeling Language) como nueva piedra angular del e-learning, ya<br />
que con este tipo de lenguajes se pretende que puedan ser utilizados por los<br />
profesores para formalizar los procesos de enseñanza, de manera que las<br />
descripciones resultantes puedan ser interpretadas por las computadoras.<br />
No obstante, antes de seguir adelante es necesario destacar que estos lenguajes de<br />
modelado <strong>educativo</strong> a pesar de su potencial se encuentran todavía más en los<br />
aspectos de investigación y prueba académica que en los aspectos de aplicación<br />
directa e inmediata a gran escala. Hay varias razones de diversa índole que justifican<br />
esta situación, desde educadores que siguen teniendo dudas sobre su aplicabilidad<br />
práctica hasta la falta de herramientas suficientemente maduras y sencillas de usar por<br />
profesores que no tengan un previo conocimiento técnico. No obstante, parece<br />
ampliamente aceptado que cualquier avance que se produzca en este campo sería<br />
muy relevante y que, por tanto, a pesar de sus limitaciones actuales es necesario<br />
continuar en esta línea. Aún así, como ya se ha mencionado en la introducción, hay<br />
que destacar que este informe pretende dar una visión desde el punto de vista más<br />
técnico y de aplicación, no siendo su objetivo un análisis en profundidad de las teorías<br />
educativas subyacentes (un estudio más en esta línea es el de Mayes y de Freitas,<br />
2004).<br />
1.2. EL CONCEPTO DE MODELADO EDUCATIVO<br />
El concepto de modelado <strong>educativo</strong> es muy amplio y es previo a su uso en el campo<br />
del e-learning. Ya sea en enseñanza presencial como en enseñanza a distancia ha<br />
13
habido muchos esfuerzos para planificar y documentar el proceso utilizado para<br />
enseñar a los alumnos. No obstante, en la mayoría de los casos, se han realizado<br />
descripciones informales (a veces descritas como “recetas”) o mediante fichas<br />
(patrones o plantillas) pero no ha habido iniciativas exitosas ampliamente aceptadas<br />
de formalización y documentación rigurosa y estándar del proceso <strong>educativo</strong>. En ese<br />
sentido se pueden distinguir, por lo menos, tres categorías de diseños:<br />
Los diseños informales donde sólo se proporcionan unas indicaciones sobre el<br />
proceso <strong>educativo</strong> y que normalmente contemplan los contenidos, el contexto y<br />
las estrategias a utilizar, pero en esas descripciones no siguen un patrón<br />
común ni tienen por qué abordar todas los mismos aspectos.<br />
Los diseños estructurados en base a plantillas que tienen un conjunto fijo de<br />
aspectos a describir y que se cumplimentan en todos los casos. De esta forma<br />
se tienen descripciones más regulares pero donde normalmente no se ponen<br />
limitaciones o normas muy estrictas sobre cómo rellenar dichos apartados. En<br />
el mejor de los casos se acompañan de una guía metodológica sobre cómo<br />
rellenarlos que incluso en algunos campos proporciona un conjunto de valores<br />
fijos entre los que seleccionar.<br />
Los diseños formales en los que, normalmente mediante un lenguaje<br />
específico, se proporciona una sintaxis que clarifica qué se puede describir y<br />
una gramática que determina el significado de dichas descripciones. Estas<br />
descripciones formales, aunque mucho más trabajosas de crear, son<br />
susceptibles de automatización. Esto significa, por ejemplo, que se puede<br />
comprobar que las descripciones son correctas y que es factible crear un<br />
sistema informático que las ejecute automáticamente.<br />
Desde el punto de vista del alcance del modelado se pueden distinguir los modelados<br />
especializados, que pretenden cubrir sólo un ámbito o tipo determinado de actividades<br />
educativas (e.g. WebQuest) y los modelados genéricos que pretenden cubrir cualquier<br />
tipo de situación educativa tanto por el dominio como por el tipo de actividades o<br />
medios utilizados.<br />
En e-learning se comienza a hablar de modelado <strong>educativo</strong> cuando se deja de<br />
considerar que los contenidos (y por tanto los objetos de aprendizaje) son el centro y<br />
elemento principal del aprendizaje en el que sólo se tiene en cuenta el escenario de un<br />
alumno individual accediendo al contenido. De ahí se ha pasado a una visión más<br />
global en la que se tratan de especificar los procesos <strong>educativo</strong>s de una forma más<br />
completa en base a las condiciones en las que se realiza y a las actividades que<br />
tienen que llevar a cabo, tanto los alumnos como los profesores, para lograr unos<br />
determinados objetivos de aprendizaje. La idea es pasar de sistemas basados o<br />
centrados en contenidos a sistemas orientados a actividades y aprendizajes activos<br />
(aunque la calidad de los contenidos sigue siendo imprescindible) que permitan<br />
incrementar las posibilidades que ofrecen los entornos de gestión de e-learning. Las<br />
ideas subyacentes a este enfoque son (Britain, 2004):<br />
Las personas aprenden mejor cuando están implicadas activamente en la<br />
realización de una actividad (actividad de aprendizaje). El aprendizaje es un<br />
proceso activo, que requiere esfuerzo, y en el cual no todos los alumnos tienen<br />
la misma capacidad de aprender por sí mismos. Este aprendizaje puede verse<br />
facilitado si se proporciona algún tipo de guiado o soporte (estrategia didáctica<br />
14
o método de aprendizaje) que implique o motive a los alumnos (trabajo<br />
colaborativo, aprendizaje basado en problemas, etc).<br />
Las actividades de aprendizaje se pueden secuenciar y organizar para lograr<br />
un aprendizaje más efectivo. Este secuenciamento es lo que se ha<br />
denominado flujo de aprendizaje. El aprendizaje se mejora no sólo si se tienen<br />
actividades que impliquen a los estudiantes si no también si se diseña de forma<br />
cuidadosa su secuenciación en el tiempo o el tiempo que tienen asignado. De<br />
esta forma se pueden considerar, por ejemplo, distintas “rutas” de aprendizaje,<br />
tareas que puedan ser realizadas en paralelo o trabajos que deben<br />
completarse en subgrupos antes de continuar con el desarrollo del curso.<br />
Los diseños <strong>educativo</strong>s se pueden describir de una forma consistente (formal)<br />
y transferible para facilitar que se puedan compartir y reutilizar. Aquí surge el<br />
problema de cómo describir una estrategia de enseñanza de modo lo<br />
suficientemente abstracto como para que sea útil en un contexto que no sea<br />
igual que en el que se ha creado, pero que a la vez sea suficientemente<br />
detallada como para que se pueda reproducir sin perder su valor pedagógico.<br />
Además, dicha descripción debe ser procesable automáticamente por una<br />
computadora.<br />
Parece ampliamente aceptado que el modelado <strong>educativo</strong>, a pesar de sus dificultades,<br />
tiene una serie de ventajas. Por un lado permite que los profesores formalicen sus<br />
diseños <strong>educativo</strong>s de modo que quede reflejado qué actividades se realizan y cómo<br />
se organizan dichas actividades. La otra ventaja es que cuando un diseño ha probado<br />
su eficacia puede ser compartido con otros docentes o archivado para un uso o<br />
consulta posterior.<br />
1.3. LENGUAJES DE MODELADO EDUCATIVO<br />
La generalización del término EML en e-learning proviene del trabajo desarrollado en<br />
la Universidad Abierta de los Países Bajos (OUNL) durante ?nales de los años 90. El<br />
grupo de investigación liderado por el Profesor Rob Koper analizó los sistemas de<br />
gestión de la enseñanza (LMSs de su término en inglés Learning Management<br />
Systems) que existían y que eran los más utilizados en aquella época, intentando<br />
identi?car los problemas y defectos de dichos sistemas de e-learning. En particular se<br />
identi?có como principal problema la falta de aplicación de la teoría instruccional y del<br />
aprendizaje dentro de los mismos. Como resultado desarrolló y puso en práctica una<br />
propuesta basada en la de?nición de un Lenguaje especí?co de dominio llamado<br />
Educational Modelling Language (OUNL-EML) (para evitar ambigüedades se<br />
denominará a este lenguaje OUNL-EML a lo largo de este capítulo, en lugar de<br />
simplemente EML).<br />
En un estudio realizado por el CEN/ISSS WS/LT Learning Technology Workshop<br />
acerca de los Lenguajes de Modelado Educativo se de?nió el concepto de EML como:<br />
Modelo de información semántico y su vinculación, que describen el contenido<br />
y el proceso dentro de una “Unidad de Aprendizaje” desde una perspectiva<br />
pedagógica y con el objetivo de dar soporte a la reutilización y la<br />
interoperabilidad (Rawlings et al., 2002).<br />
15
De esta de?nición pueden extraerse los siguientes conceptos principales:<br />
Modelo de Información Semántico. Un modelo de información semántico es un<br />
meta-modelo (conceptualización) de un dominio de discurso. En este caso se<br />
trata de un meta-modelo que describe el proceso de enseñanza/aprendizaje.<br />
Modelo de información y vinculación. La “vinculación” de un EML es una<br />
formalización lingüística del modelo semántico. Habitualmente, esta<br />
formalización se realiza mediante la de?nición de un Lenguaje Especí?co de<br />
Dominio basado en las tecnologías XML a ?n de conseguir una vinculación o<br />
representación directamente procesable en el ordenador.<br />
Unidad de Aprendizaje. El concepto de Unidad de Aprendizaje (UOL) es el<br />
punto clave de los EMLs. En palabras del profesor Koper (2001): “Una UOL<br />
(también conocida como unidad de estudio) es la menor unidad que<br />
proporciona eventos <strong>educativo</strong>s a los estudiantes, satisfaciendo uno o más<br />
objetivos <strong>educativo</strong>s interrelacionados”.<br />
En los EMLs se pasa del concepto de OA como elemento constructivo básico y<br />
atómico a otro de mayor granularidad que es la UOL y que no sólo agrupa<br />
contenidos. Por tanto, una UOL no puede dividirse sin perder su propia<br />
semántica orientada al logro de los objetivos <strong>educativo</strong>s. Una UOL puede ser<br />
un curso, un taller, una práctica, una titulación completa, etc. Cada UOL de?ne<br />
el modelo instructivo, y el entorno donde se realiza. Este entorno está<br />
caracterizado por los recursos materiales (que pueden ser OAs) y los servicios<br />
(v.g. foro, chat, videoconferencia, e-mail) que serán utilizados durante la puesta<br />
en ejecución de la UOL.<br />
Perspectiva Pedagógica. Un EML debe ser relativamente independiente de las<br />
teorías instruccionales, de manera que el profesor o el diseñador instruccional<br />
pueda decidir cuál de estas teorías desea aplicar. Una vez más los estándares<br />
<strong>educativo</strong>s no tratan de limitar la expresividad del docente o de imponer una<br />
visión determinada de cómo debe realizarse la enseñanza.<br />
Reutilización e Interoperatibilidad. La idea detrás de los EMLs no es sólo<br />
permitir a las aplicaciones informáticas interpretar los guiones creados<br />
mediante dichos lenguajes. Además tienen como objetivo promover la<br />
reutilización de aquellas UOLs que hayan tenido una aplicación exitosa, así<br />
como permitir el intercambio de estas unidades de aprendizaje entre distintos<br />
sistemas de e-learning sin tener en cuenta cómo el sistema de información<br />
implementará ?nalmente la semántica del modelo de?nido.<br />
Además de estos conceptos básicos de los EMLs, el profesor Koper (2000) identi?ca<br />
las siguientes características deseables que debería cumplir un EML:<br />
Un Lenguaje de Modelado Educativo debe estar de?nido formalmente y tiene<br />
que poder ser procesable en el ordenador, de manera que los guiones creados<br />
con dicho lenguaje puedan ser interpretados por aplicaciones informáticas.<br />
Un Lenguaje de Modelado Educativo tiene que ser pedagógicamente neutral.<br />
Como ya se ha indicado anteriormente, el lenguaje no debe imponer<br />
restricciones a la forma de enseñar y, por tanto, debe permitir la aplicación de<br />
distintas estrategias pedagógicas que el educador considere oportunas en la<br />
concepción de las UOLs.<br />
16
Un Lenguaje de Modelado Educativo debe permitir a los diseñadores crear<br />
UOLs completas que incluyan actividades a realizar por el estudiante (¿qué<br />
hacer?), las personas involucradas en dichas actividades (¿con quién?) y el<br />
entorno donde se llevarán a cabo las actividades (¿qué materiales son<br />
necesarios?, ¿qué herramientas?, etc.).<br />
Una UOL creada utilizando un EML debería ser perdurable, es decir, resistente<br />
a los cambios y evoluciones tecnológicas, así como a cambios de plataformas,<br />
puesto que su propósito es facilitar la reusabilidad e interoperabilidad entre<br />
sistemas y herramientas distintas.<br />
A modo de resumen, los EMLs son lenguajes que permiten describir UOLs, las cuáles<br />
a su vez describen el proceso de aprendizaje como un todo (y no sólo centrado en los<br />
contenidos como se hace en los objetos de aprendizaje).<br />
Además, otra característica añadida de estos lenguajes es que proporcionan un<br />
mecanismo para la comunicación entre el personal técnico de soporte y el personal no<br />
técnico (normalmente los educadores) dentro de una organización durante la<br />
operacionalización del EML. Ahora las UOLs son completas de modo que el personal<br />
técnico puede saber qué es lo que está planificado y ayudar a resolver las incidencias<br />
que pudieran producirse (e.g. no disponibilidad de un recurso).<br />
1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS<br />
A partir de las diferentes iniciativas desarrolladas en base a los principios de los<br />
Lenguajes de Modelado Educativo previamente mencionados y a los EMLs descritos<br />
en (Rawlings et al., 2002), es posible crear una clasi?cación para los mismos similar a<br />
la propuesta en (Vantroys, 2003):<br />
Lenguajes Especí?cos. En esta categoría se encuentran los lenguajes que, aún<br />
sin cumplir estrictamente todas las características de un EML, permiten a los<br />
diseñadores describir las etapas del proceso de aprendizaje utilizando una<br />
metodología especí?ca. En particular, dentro de esta categoría podemos<br />
destacar aquellos lenguajes aplicados a la metodología de enseñanza basada<br />
en la resolución de problemas mediante el planteamiento de preguntas y a la<br />
recolección de soluciones y respuestas.<br />
Lenguajes de estructuración de contenidos. Esta categoría está formada por<br />
aquellos lenguajes que permiten a los diseñadores organizar los recursos<br />
<strong>educativo</strong>s en una secuencia, siempre teniendo en cuenta las necesidades del<br />
estudiante y la interacción con el propio contenido, a ?n de mejorar la<br />
experiencia educativa.<br />
Lenguajes de Actividad. En esta categoría se encuentran los lenguajes que<br />
están enfocados principalmente a la organización de actividades en general<br />
(utilizando computadoras o no) durante el proceso de aprendizaje.<br />
En la tabla Tabla 1.4.a. se clasi?can diversos EMLs de acuerdo a estas tres<br />
categorías. En los siguientes puntos se darán más detalles acerca de cada uno de<br />
estos lenguajes.<br />
17
Tabla 1.4.a. Clasi?cación de Alto nivel de algunos Lenguajes de Modelado Educativo.<br />
Tipo Lenguage Sitio web<br />
Tutorial Markup Language http://www.ilrt.bris.ac.uk/netquest<br />
Lenguajes<br />
Especí?cos<br />
(TML)<br />
IMS Question and<br />
Interoperability (IMS-QTI)<br />
Test http://imsglobal.org/question<br />
http://edventure.e-ucm.es<br />
TArgeted Reuse and GEne<br />
ration of TEAching Mate-rials<br />
(Targeteam)<br />
http://www.targeteam.net<br />
Learning Material Mark-up<br />
No Disponible<br />
Lenguajes de<br />
Estructuración<br />
de<br />
Contenidos<br />
Language (LMML)<br />
ARIADNE Course (Curriculum)<br />
Description Format (A-CDF)<br />
AICC Course Data Model<br />
(AICC/CMI)<br />
IMS Simple Sequencing (IMS<br />
SS)<br />
http://www.ariadne-eu.org/<br />
http://www.aicc.org<br />
http://www.imsglobal.org/simplesequencing/<br />
ADL Sharable Content Object http://www.adlnet.gov/scorm/<br />
Reference<br />
(SCORM)<br />
Model 2004<br />
http://e-docbook.e-ucm.es/<br />
PALO http://sensei.ieec.uned.es/palo/<br />
Educational Environment http://www.istituti.usilu.net/botturil/<br />
Modeling Language (EEML)<br />
XEDU<br />
publications.htm<br />
Méthode d’ingénierie d’un http://www.licef.teluq. uquebec.ca/gp/<br />
système d’apprentissage<br />
Lenguajes de (MISA)<br />
Actividad Educational Modeling http://eml.ou.nl<br />
Language -Open University of<br />
the Netherlands (EML-OUNL<br />
http://e-ld.e-ucm.es/<br />
PoEML http://wwwgist.det.uvigo.es/~mcaeiro/thesis/<br />
IMS Learning Design (IMS LD) http://www.imsglobal.org/learningdesign/<br />
1.4.1. Lenguajes Especí?cos<br />
Tutorial Markup Language (TML) (Brickley, 1998) es una extensión de HTML para<br />
crear preguntas. TML esta diseñado para separar por un lado la semántica del<br />
contenido asociado a la distribución de la pregunta y por otro la semántica del<br />
contenido de la pregunta en sí. El formato de los archivos TML es texto plano,<br />
pudiendo ser generados a partir de otros formatos y otras preguntas que se<br />
encuentren almacenadas en una base de datos.<br />
IMS Question and Test Interoperability (IMS-QTI) es una propuesta llevada a cabo por<br />
el consorcio internacional IMS (Instructional Management Systems – Global Learning<br />
Consortium) para crear bancos de preguntas y de evaluaciones (IMS QTI, 2006). El<br />
18
principal objetivo de IMS-QTI es permitir el intercambio de evaluaciones y de la<br />
información asociada a las evaluaciones entre distintos LMSs. En las evaluaciones<br />
creadas con IMS-QTI existe una división clara entre las preguntas en sí mismas (¿qué<br />
es lo que se pregunta?) y la forma en la que se presentan dichas preguntas al alumno<br />
y en la que se evalúan las respuestas dadas por el mismo. IMS-QTI permite crear test<br />
interactivos, los cuáles pueden incluir pistas (información para ayudar a los alumnos).<br />
También es posible crear plantillas de exámenes que pueden ser utilizadas cuando los<br />
estudiantes llevan a cabo el examen, creando diferentes exámenes a partir de la<br />
misma plantilla. En el Informe número 16 de esta misma colección se puede encontrar<br />
una presentación completa y detallada de este estándar (Fernández-Manjón et al.,<br />
2007).<br />
(Moreno-Ger, 2007) es un proyecto que propone un modelo de<br />
desarrollo de videojuegos <strong>educativo</strong>s que son directamente desplegables en un LMS<br />
(siempre que el LMS cumpla con los estándares de IMS Content Packaging). Con es posible crear aventuras grá?cas y simulaciones con estructura de juego<br />
que tengan un objetivo <strong>educativo</strong>. Esta iniciativa está compuesta por dos conceptos<br />
principales: el motor y el lenguaje . Características<br />
distintivas de este enfoque es que tanto el motor como el lenguaje <br />
permiten crear juegos adaptativos e incluyen mecanismos que monitorizan e informan<br />
acerca de la actividad de los estudiantes dentro del juego.<br />
El motor de ejecuta los juegos que están representados (o codificados)<br />
mediante el lenguaje . Este motor es capaz de comunicarse con un<br />
sistema de e-learning o LMS permitiendo que el juego pueda informar al LMS acerca<br />
del progreso del alumno al interactuar con el mismo.<br />
El lenguaje es un lenguaje especí?co de dominio ya que permite a un<br />
profesor con pocos conocimientos tecnológicos definir juegos <strong>educativo</strong>s (Moreno-Ger,<br />
2008). Este lenguaje permite la codi?cación del storyboard del juego, así como la<br />
de?nición de los personajes y objetos con los que podrá interactuar el alumno. De la<br />
misma manera, también es posible de?nir de manera simple las condiciones de las<br />
que dependen las distintas acciones que pueden llevarse a cabo en el juego.<br />
Finalmente, el lenguaje también incluye construcciones que permiten la monitorización<br />
de características importantes desde el punto de vista pedagógico (e.g. si el alumno se<br />
queda bloqueado en alguna parte del juego o si toma decisiones erróneas que<br />
implican algún error de concepto) e incluso la creación de juegos que se adaptan a las<br />
características específicas del usuario.<br />
1.4.2. Lenguajes de Estructuración de Contenidos<br />
Targeted Reuse and Generation of Teaching Materials (Targeteam) permite la<br />
creación y el mantenimento (uso y reutilización) de contenidos <strong>educativo</strong>s (Koch,<br />
2002). Este EML permite el uso de los materiales en diferentes situaciones y dominios<br />
pedagógicos (primaria, secundaria y nivel universitario). Haciendo uso de Targeteam,<br />
es posible crear las notas de clase, además de otros contenidos, como aclaraciones,<br />
explicaciones y ejemplos. Este lenguaje está enfocado al uso de tecnologías XML,<br />
como TeachML, e introduce el concepto de tema (issue) como UOL.<br />
19
Learning Material Markup Language (LMML) está basado en un meta-modelo que<br />
puede encajar en distintos dominios de aplicación. LMML ha sido diseñado como<br />
aplicación del meta-lenguaje XML para la descripción de los contenidos <strong>educativo</strong>s<br />
(Weitl et al., 2002). Estos contenidos <strong>educativo</strong>s están estructurados en módulos, que<br />
a su vez pueden estar estructurados en submódulos. LMML se basa en una<br />
estructuración del contenido <strong>educativo</strong> de manera jerárquica y modular, donde los<br />
contenidos creados con LMML pueden ser adaptados a diferentes situaciones de<br />
aprendizaje y a distintos tipos de estudiantes. Utiliza el concepto de curso (course)<br />
como UOL.<br />
ARIADNE Course Description Format (A-CDF) es un EML que permite la creación de<br />
cursos en línea (Verbert y Duval, 2004). Un curso en A-CDF consiste en documentos<br />
XML que serán utilizados conjuntamente con una herramienta LMS que será la que<br />
finalmente generará los cursos (Van Durm et al., 2001). A-CDF pone especial interés<br />
en el contenido y en su agregación, siendo además lo su?cientemente expresivo como<br />
para describir el proceso de aprendizaje de acuerdo con un modelo pedagógico. El<br />
desarrollo con A-CDF se realiza a través de un conjunto de herramientas construidas<br />
en el seno del consorcio ARIADNE (editores curriculares, LMS, KPS). Este lenguaje<br />
establece el concepto de curso (course) como UOL.<br />
AICC Course Data Model (AICC/CMI) contiene toda la información necesaria para<br />
describir un curso (AICC, 2004). Este formato puede intercambiarse entre distintos<br />
LMSs mediante herramientas de importación / exportación, utilizando el concepto de<br />
Unidades de Asignación (Assignable Units) como unidad de intercambio. La<br />
información generada durante la interacción del alumno con las unidades de<br />
asignación también es almacenada por el LMS. Desde la descripción AICC/CMI es<br />
posible hacer referencia a esta información para decidir qué datos se envían a las<br />
unidades de asignación en tiempo de ejecución. La secuenciación dentro del curso se<br />
controla mediante el uso de los prerequisitos que deben satisfacer los estudiantes<br />
antes de acceder a una nueva unidad de asignación. AICC/CMI utiliza el concepto de<br />
curso (course) como UOL.<br />
IMS Simple Sequencing (IMS-SS) de?ne métodos para poder representar el<br />
comportamiento dentro de una experiencia educativa, de manera que un LMS pueda<br />
secuenciar actividades discretas de forma consistente (IMS SS, 2003). Los<br />
diseñadores instruccionales o los desarrolladores de contenido declaran el orden<br />
relativo en el cuál se presentan al alumno los elementos de contenido, y las<br />
condiciones bajo las cuáles una pieza de contenido se selecciona, se muestra o se<br />
omite durante la presentación. Utiliza el concepto de actividad de aprendizaje (learning<br />
activity) como UOL.<br />
ADL Sharable Content Object Reference Model (SCORM) representa un modelo de<br />
coordinación que tiene el objetivo de proporcionar una colección de prácticas<br />
estandarizadas susceptibles de ser ampliamente aceptadas y ampliamente<br />
implementadas en entornos de e-learning (SCORM, 2004). De hecho, el modelo<br />
SCORM puede ser considerado como un “per?l de aplicación” (en inglés application<br />
profile) de estas prácticas ya que se apoya en otras especificaciones más generales<br />
como, por ejemplo, las proporcionadas por IMS, pero además concreta algunos<br />
aspectos que no están fijados en dichas especificaciones. La iniciativa SCORM pone<br />
en práctica diferentes desarrollos tecnológicos de las iniciativas propuestas por grupos<br />
como IMS, AICC, ARIADNE y IEEE-LTSC, todos ellos agrupados en un único modelo<br />
20
de referencia para especi?car una implementación consistente que pueda ser utilizada<br />
por toda la comunidad de e-learning.<br />
SCORM de?ne los fundamentos técnicos de un LMS basado en tecnologías web,<br />
estableciendo:<br />
Un Modelo de agregación de Contenidos que describe los componentes<br />
utilizados dentro de una experiencia educativa, cómo empaquetar estos<br />
componentes para su intercambio y cómo describir estos componentes<br />
mediante el uso de los metadatos para permitir su búsqueda y descubrimiento.<br />
Además también de?ne los requisitos para la construcción de agregaciones de<br />
contenidos (e.g. cursos, lecciones, módulos, etc.). Este modelo da lugar a un<br />
concepto de OA denominado Shareable Content Object (SCO).<br />
Un Entorno de ejecución dinámico para la reproducción de los SCOs,<br />
proporcionando de esta forma, un modelo instruccional adaptativo basado en<br />
OAs. Normalmente dicho entorno de ejecución se servirá a los distintos clientes<br />
que acceden al sistema.<br />
Un Mecanismo de interoperabilidad entre los SCOs que se ejecutan en el<br />
citado entorno y el resto de componentes que se ejecutan en el LMS, que<br />
habitualmente reside en el lado del servidor.<br />
De forma adicional, en SCORM 2004 (anteriormente conocido como SCORM 1.3) se<br />
ha introducido un Modelo de Secuenciación y Navegación para permitir la<br />
presentación dinámica de los contenidos <strong>educativo</strong>s en función de las necesidades de<br />
aprendizaje. Está basado en la propuesta IMS Simple Sequencing (IMS-SS) y describe<br />
cómo se puede secuenciar el contenido compatible con el modelo SCORM utilizando<br />
una secuencia de eventos de navegación, donde estos eventos pueden ser iniciados<br />
por el estudiante o por el sistema. El control de las bifurcaciones y el ?ujo puede ser<br />
descrito utilizando un conjunto prede?nido de actividades que normalmente se deben<br />
fijar en el momento del diseño del curso. Además, también describe cómo los LMSs<br />
compatibles con SCORM tienen que interpretar estas reglas de secuenciación<br />
expresadas por el desarrollador de contenidos, acompañadas por el conjunto de<br />
eventos de navegación iniciados por el estudiante o por el sistema, y cuáles son sus<br />
efectos sobre el entorno en tiempo de ejecución. SCORM utiliza el concepto de<br />
“organización de contenido” (en inglés content organization) como UOL.<br />
es una metodología y un conjunto de herramientas ideadas para<br />
simpli?car el proceso de creación de materiales <strong>educativo</strong>s adaptativos basados en el<br />
concepto de OAs (Martinez-Ortiz, 2005, 2006). Esta iniciativa utiliza una extensión de<br />
DocBook (Walsh, 1999), un lenguaje XML usado en entornos técnicos para la creación<br />
de manuales.<br />
La metodología propuesta por se basa en la metáfora de escritura de un<br />
manual, proceso al que habitualmente están acostumbrados los docentes (aunque<br />
para e-learning los contenidos deberían ser concebidos de forma diferente, en base a<br />
los conceptos que se quieren enseñar y su relación con los OAs, y no sólo como un<br />
libro que se publica en la red). A partir del manual generado y aplicando las<br />
herramientas proporcionadas por se pueden obtener distintos productos:<br />
un curso, módulos de curso basados en OAs, trasparencias para ser utilizadas como<br />
notas de clase, etc.<br />
21
En ambos casos el resultado ?nal será agregado en un paquete IMS Content<br />
Packaging (IMS-CP) para poder simpli?car el intercambio de los contenidos entre<br />
sistemas de e-learning. Además, las herramientas proporcionadas permiten la<br />
generación de los contenidos en formatos HTML, PS, <strong>PDF</strong>, RTF, archivos de ayuda de<br />
Eclipse y ?nalmente archivos de ayuda de Windows.<br />
1.4.3. Lenguajes de Actividades<br />
PALO es un lenguaje de modelado desarrollado en la Universidad Nacional de<br />
Enseñanza a Distancia (UNED) (Rodriguez-Artacho et al., 1999). PALO permite<br />
describir cursos organizados mediante módulos que contienen actividades educativas,<br />
contenido y un plan de enseñanza. Utilizando PALO el diseñador puede crear plantillas<br />
para de?nir tipos de escenarios de aprendizaje. Utilizando las características del<br />
lenguaje, es posible secuenciar tareas de aprendizaje y módulos. Como complemento,<br />
se pueden añadir restricciones sobre los cursos, permitiendo de?nir tiempos y fechas<br />
límite, así como dependencias entre módulos y tareas. Utiliza el concepto de módulo<br />
como UOL.<br />
Educational Environment Modeling Language (E2ML) es una propuesta de EML que<br />
proporciona un lenguaje visual con el objetivo de permitir diseñar entornos <strong>educativo</strong>s<br />
en el ámbito universitario (Botturi, 2006). Dicho lenguaje permite crear una de?nición<br />
explícita del proceso de aprendizaje y de las actividades educativas. En particular<br />
aborda los siguientes aspectos:<br />
Facilita la comunicación entre los diferentes interesados dentro del proceso<br />
(diseñadores de unidades de aprendizaje, personal técnico, profesores, etc).<br />
Para ello propone una representación visual del diseño, que se puede utilizar<br />
de manera similar a como se utilizan los planos de un edi?cio que va a<br />
construir.<br />
El diseño de una UOL puede utilizarse como base de otra UOL, no sólo por<br />
parte del mismo diseñador, sino por toda la comunidad educativa.<br />
E2ML utiliza el concepto de curso (course) como UOL.<br />
XEDU está ideado para ofrecer a los diseñadores instruccionales un marco de trabajo<br />
para la especi?cación de cualquier aplicación educativa, tanto desde el punto de vista<br />
de las teorías instruccionales como desde el punto de vista de la ingeniería del<br />
software (Buendía et al., 2003, 2004). Los principales conceptos de?nidos en XEDU<br />
son:<br />
Per?l de alumno. Almacena toda la información relevante acerca del<br />
estudiante, incluyendo el resultado del proceso de aprendizaje.<br />
Escenario <strong>educativo</strong>. Consta de actividades y condiciones en un contexto<br />
<strong>educativo</strong> especí?co.<br />
Estructura didáctica. Organiza el contenido <strong>educativo</strong> con un objetivo didáctico<br />
especí?co.<br />
22
El concepto de estructura didáctica representa una UOL en XEDU.<br />
MISA introduce una nueva aproximación denominada “ingeniería instruccional” (en<br />
inglés Instructional Engineering) (Paquette, 2004). La ingeniería instruccional está<br />
basada en las teorías del Diseño Instruccional (en inglés Instructional Design)<br />
(Reigeluth, 1983; Merrill, 1994; Dick, 2000) junto a la ingeniería cognitiva y la ingeniería<br />
del software. Para ello proporciona una metodología que da soporte a la plani?cación,<br />
análisis, diseño y entrega de un sistema de aprendizaje y comparte los principios de<br />
los EMLs. MISA permite el diseño de sistemas de aprendizaje a través de 35 tareas,<br />
produciendo 35 entregables denominados elementos de documentación. La creación<br />
de estos documentos está dividida en fases bien de?nidas. El concepto de Escenario<br />
de aprendizaje representa una UOL en MISA.<br />
OUNL-EML ha sido desarrollado por la OUNL para su aplicación en e-learning. La<br />
versión 1.0 de dicho lenguaje y su modelo XML fue distribuida en el año 2000 (Koper,<br />
2000, 2001). OUNL-EML fue seleccionado como base de la especi?cación IMS-LD,<br />
integrando OUNL-EML con la especi?cación IMS-CP e IMS-SS. OUNL-EML ha sido<br />
utilizado y puesto en práctica en diversas aplicaciones de e-learning, y, en particular,<br />
en la Universidad Complutense de Madrid en las primeras versiones del proyecto (Sierra et al., 2006). OUNL-EML permite la de?nición de “diseños de<br />
aprendizaje” (diseños instructivos) con el objetivo de permitir la creación de<br />
herramientas avanzadas de e-learning, (e.g. herramientas que permitan la de?nición<br />
de un modelo educacional basado en competencias, en portafolio o en el aprendizaje<br />
colaborativo).<br />
En OUNL-EML el concepto de “diseño de aprendizaje” (learning design) representa el<br />
concepto de UOL. Un diseño de aprendizaje es una instancia concreta de un modelo<br />
pedagógico, el cual a su vez es una instancia de un meta-modelo pedagógico. Este<br />
meta-modelo no fuerza a los usuarios de OUNL-EML a utilizar un modelo pedagógico<br />
concreto, sino que les permite crear y describir sus propios modelos de manera<br />
expresiva. El meta-modelo ofrecido por OUNL-EML ha sido desarrollado a partir del<br />
análisis de los modelos existentes basados en las aproximaciones constructivistas<br />
(sociales), de comportamiento y cognitivas.<br />
es una iniciativa que trata de simplificar la autoría y reutilización de diseños<br />
<strong>educativo</strong>s mediante la aplicación de conceptos de flujos de trabajo (en inglés<br />
workflows) (Martínez-Ortiz et al., 2008). La idea es proponer un lenguaje específico de<br />
dominio orientado a flujo (a secuenciamiento de actividades) que es más comprensible<br />
para los docentes. La compatibilidad con otros estándares como IMS-LD se obtiene<br />
mediante procesos de exportación automática. Además proporciona herramientas para<br />
ayudar a la compresión de diseños previamente creados con IMS-LD de los que<br />
únicamente se dispone de su representación en XML (permitiendo, por ejemplo, la<br />
visualización de dependencias entre tareas o entre tareas y condiciones).<br />
PoEML (Perspective-oriented EML) es un lenguaje basado en IMS-LD que se define a<br />
partir de la propuesta de separación de asuntos o aspectos (Caeiro et al., 2007). El<br />
lenguaje tiene una estructura modular con la que se pretende mejorar los problemas<br />
de capacidad expresiva, complejidad y usabilidad identificados en los EMLs actuales.<br />
Finalmente entre las diferentes propuestas de especi?caciones, IMS Learning Design<br />
ha emergido como el estándar de-facto para la representación de cualquier UOL ya<br />
que en principio permite utilizar cualquier teoría de aprendizaje. Debido a su<br />
23
importancia tanto en el ámbito del e-learning como para este trabajo, se realiza una<br />
presentación breve de esta especificación en la siguiente sección (el siguiente capítulo<br />
está dedicado a realizar una presentación completa y con ejemplos de IMS-LD).<br />
1.5. IMS LEARNING DESIGN<br />
IMS Learning Design está basado en el lenguaje OUNL-EML. Esta especi?cación ha<br />
sido elaborada por el grupo de trabajo IMS/LDWG enmarcado dentro de las iniciativas<br />
desarrolladas por el IMS Global Learning Consortium (IMS LD, 2003). El punto de<br />
partida de este grupo de trabajo fue la especi?cación OUNL-EML. El resultado ?nal ha<br />
sido el desarrollo de una nueva especi?cación adaptada en aquellas partes en las que<br />
existía un solapamiento con el resto de especi?caciones propuestas por IMS, junto a<br />
una adaptación de la propia especi?cación para poder dividirla en varios niveles, al<br />
estilo del modelo de capas en una arquitectura de software, para hacerla más<br />
comprensible.<br />
Una de las adaptaciones más relevantes llevada a cabo ha sido la adopción de la<br />
especi?cación IMS Content Packaging como formato y medio de transmisión e<br />
intercambio entre distintos LMSs y herramientas. Asimismo, otras partes de?nidas en<br />
OUNL-EML no han sido reutilizadas (por ejemplo, el formato XML para la descripción<br />
de los contenidos <strong>educativo</strong>s, que era un dialecto del formato DocBook (Walsh y<br />
Muellner, 1999).<br />
Además de la adaptación al entorno de especi?caciones de IMS, otro objetivo ha sido<br />
la inclusión de otros trabajos y especi?caciones que no se solapaban con el trabajo<br />
realizado. Por ejemplo, IMS-SS ha sido incluido dentro del ámbito de trabajo de IMS<br />
Learning Design para llevar a cabo el secuenciamiento de los OAs dentro de las<br />
actividades que se llevan a cabo en el contexto de la UOL. Otro ejemplo ha sido IMS<br />
Question and Test Interoperability, de manera que los exámenes y preguntas<br />
presentadas con IMS QTI pueden utilizarse dentro de las actividades. De esta manera,<br />
la puntuación obtenida en estas pruebas puede provocar que aparezcan nuevas<br />
actividades o que desaparezcan otras.<br />
En la Figura 2.3.a puede observarse la estructura de alto nivel de una UOL expresada<br />
en IMS-LD.<br />
Además, para facilitar el aprendizaje y la implementación de la especi?cación, el<br />
modelo conceptual de IMS-LD (Figura 1.5.b) está dividido en tres niveles (A, B y C)<br />
donde cada nivel está construido encima del modelo y de la semántica de?nida en los<br />
niveles previos:<br />
Nivel A. Contiene el núcleo de los componentes de la especi?cación. Cuando<br />
se crea una UOL con IMS-LD, se debe especi?car un modelo estático y un<br />
modelo dinámico.<br />
Nivel B. Añade los conceptos de propiedades y condiciones al nivel anterior.<br />
Las propiedades de?nen un modelo de datos para el alumno y las condiciones<br />
se utilizan para personalizar las UOLs en base a los conocimientos previos de<br />
los alumnos y a su interacción con dichas UOLs.<br />
24
Nivel C. Añade el concepto de noti?cación al nivel anterior. Las noti?caciones<br />
proporcionan un nuevo mecanismo de noti?cación de sucesos que ocurren<br />
durante la ejecución de una UOL.<br />
Figura 1.5.a. Estructura de alto nivel de una unidad de aprendizaje en IMS-LD.<br />
El modelo estático de IMS-LD permite de?nir qué es lo que se va llevar a cabo en la<br />
UOL, qué tipos de usuarios (e.g. profesores, alumnos, etc.) participan en la UOL y con<br />
qué recursos se llevarán a cabo las actividades (e.g. páginas HTML, <strong>PDF</strong>, etc.). El<br />
modelo estático está compuesto por los siguientes conceptos:<br />
Título. Permite dar un título para la UOL.<br />
Objetivos <strong>educativo</strong>s. De?nición de los objetivos <strong>educativo</strong>s de la UOL. Esta<br />
descripción habitualmente se realiza en lenguaje natural.<br />
Prerrequisitos. De?nición de los conocimientos previos que debe tener un<br />
alumno para que pueda llevar a cabo las actividades de la UOL. La descripción<br />
de los prerrequisitos también se realiza en lenguaje natural.<br />
Metadatos. Esta meta-información permite la indexación de las UOLs, de<br />
manera que se simpli?que su posterior clasi?cación, catalogación y<br />
recuperación.<br />
Roles. De?nición de los diferentes tipos de usuario que aparecerán en la UOL.<br />
Actividades. De?nición de las actividades que se llevarán a cabo dentro de las<br />
UOLs. En la de?nición de las actividades se incluyen los objetivos y los<br />
prerrequisitos de las actividades. Además, también se incluye una descripción<br />
textual de cuáles son los objetivos de la actividad. Finalmente, se incluye una<br />
referencia al entorno donde se llevará a cabo la actividad.<br />
25
Entornos. De?nen los contenidos <strong>educativo</strong>s (OAs) y las herramientas<br />
(servicios de aprendizaje) que se utilizarán en las distintas actividades de la<br />
UOL.<br />
Figura 1.5.b. Estructura conceptual de IMS-LD.<br />
El modelo dinámico de IMS Learning Design permitir de?nir el quién y el cúando. El<br />
modelo dinámico hace uso de los conceptos de?nidos en el modelo estático<br />
anteriormente descrito.<br />
El modelo dinámico permite de?nir qué tipo de usuario (rol) llevará a cabo una<br />
actividad concreta y también permite de?nir la sincronización y las dependencias que<br />
existirán entre las distintas actividades que componen la UOL.<br />
El modelo dinámico puede verse como la esceni?cación de una obra teatral. El método<br />
(method) consiste en una o varias representaciones (play) que son interpretadas en<br />
paralelo. Cada una de las obras está formada por uno o más actos (acts) que serán<br />
interpretados uno tras otro (ver Figura 1.5.c).<br />
Dentro de cada acto se realiza la distribución de papeles (role-parts), es decir, se<br />
de?ne qué actividades serán llevadas a cabo por cada uno de los tipos de usuario<br />
involucrados en el proceso de aprendizaje (ver Figura 1.5.c).<br />
Utilizando los niveles B y C podemos crear secuenciaciones dinámicas más<br />
complejas. En particular podemos incluir dependencias entre actividades (por ejemplo,<br />
para indicar que un profesor debe desempeñar una actividad en la que corrija un<br />
examen después de que el alumno lo termina).<br />
26
Figura 1.5.c. Representación de un método con tres actos secuenciales (a) y<br />
representación de un método en el que se incluyen los roles de los usuarios en las<br />
actividades y se muestra que puede haber actividades en paralelo (b).<br />
1.6. HERRAMIENTAS DE SOPORTE A IMS-LD<br />
Aunque la aplicación práctica de IMS-LD sigue siendo muy limitada sí existen diversas<br />
iniciativas que proporcionan herramientas para trabajar con IMS-LD.<br />
En esta sección se realiza una breve presentación de algunas de las iniciativas que<br />
debido a su relevancia o madurez se han considerado como más prometedoras<br />
actualmente.<br />
Podemos encontrar tres tipos de herramientas:<br />
Herramientas de Autoría. Son herramientas que permiten la creación de las<br />
UOLs.<br />
Motores de Ejecución. Son herramientas que, dada una UOL codi?cada con<br />
IMS-LD, interpretan el proceso de aprendizaje, monitorizando la realización de<br />
las actividades y actualizando el per?l del alumno según los resultados que se<br />
vayan obteniendo en las actividades que tienen asignadas. Este tipo de<br />
herramientas residen habitualmente en un servidor de aplicaciones y son<br />
utilizadas tanto por los profesores como por los alumnos a través de una<br />
interfaz web adecuada.<br />
Reproductores. Estas herramientas son utilizadas por los actores que<br />
interactúan con la UOL, tanto en el proceso de ejecución de la misma, como<br />
27
durante el proceso de publicación de la UOL (es decir, el proceso de<br />
preparación de la misma para su puesta en ejecución). De esta forma, estas<br />
herramientas proporcionan la citada interfaz web con los motores de ejecución.<br />
1.6.1. Herramientas de Autoría de IMS-LD<br />
En esta sección se hace un breve análisis de distintas iniciativas de desarrollo de<br />
herramientas de autoría compatibles con la especi?cación IMS-LD. Esta sección no<br />
pretende realizar un análisis exhaustivo de todas las iniciativas existentes (para mayor<br />
detalle se puede consultar Berggreen et al., 2005; Burgos y Griffiths, 2005; Dodero et<br />
al., 2006; Berlanga y García, 2005) sino de las que en el momento de escritura del<br />
documento hemos considerado más relevantes, como son ALFANET, CopperAuthor,<br />
RELOAD, CoS-MoS, Collage, MOT+, ASK-LDT y LAMS.<br />
ALFANET (Active Learning for Adaptive Internet) es una iniciativa europea que tiene<br />
como objetivo el desarrollo de nuevos métodos y servicios para llevar a cabo un<br />
proceso de aprendizaje activo y adaptado al alumno (http://alfanet.ia.uned.es). El<br />
editor de IMS-LD de ALFANET representa los conceptos de IMS-LD mediante<br />
elementos gráficos que conforman la interfaz. Esta herramienta sólo permite la<br />
creación y el desarrollo de diseños <strong>educativo</strong>s IMS-LD de nivel A (este proyecto ya<br />
está concluido y no parece claro que se haya seguido con este desarrollo).<br />
CopperAuthor (Figura 1.6.1.a) es una herramienta desarrollada en paralelo al motor de<br />
ejecución CopperCore. Esta herramienta permite a los diseñadores construir y navegar<br />
sobre la estructura del diseño <strong>educativo</strong> mediante una interfaz basada en tablas<br />
(CopperAuthor, 2007). En su versión actual la interfaz es un tanto primitiva y sólo<br />
permite el desarrollo de diseños <strong>educativo</strong>s IMS-LD de nivel A.<br />
28
Figura 1.6.1.a. Interfaz de CopperAuthor.<br />
29
RELOAD (Reusable E-Learning Object Authoring & Delivery) (Figura 1.6.1.b) es un<br />
editor desarrollado en el seno de un proyecto patrocinado por la iniciativa JISC del<br />
Reino Unido (http://www.reload.ac.uk). Este editor permite la edición de una UOL<br />
mediante la interacción con múltiples formularios y estructuras en forma de árbol que<br />
representan la estructura de agregación de los conceptos de IMS-LD implícita en el<br />
formato XML utilizado para representar las UOL de IMS-LD. Con esta herramienta se<br />
pueden crear diseños <strong>educativo</strong>s IMS-LD de los tres niveles (del nivel A al nivel C).<br />
Figura 1.6.1.b. Interfaz del editor de IMS-LD de RELOAD.<br />
30
CoSMoS (Collaboration Script Modelling System) (Figura 1.6.1.c) es una herramienta<br />
de autoría ideada inicialmente para dar soporte a la formalización de procesos de<br />
aprendizaje colaborativos (Miao, 2005). Posteriormente la herramienta fue modi?cada<br />
para dar soporte a los conceptos de IMS-LD. La edición de la UOL se basa en la<br />
navegación sobre la estructura en árbol de la misma y la edición de los conceptos<br />
mediante formularios. Con esta herramienta se pueden crear diseños <strong>educativo</strong>s IMS-<br />
LD de nivel B.<br />
Figura 1.6.1.c. Interfaz del editor de IMS-LD de CoSMoS.<br />
Collage es una herramienta de autoría de alto nivel y de autoría colaborativa basada<br />
en el concepto de los patrones de ?ujo colaborativos (Collaborative Learning Flow<br />
Patterns), que son plantillas que de?nen el ?ujo de tareas para dirigir de manera<br />
adecuada el proceso de aprendizaje (Hernandez-Leo et al., 2006). Esta herramienta<br />
ha sido desarrollada sobre RELOAD y con ella sólo se pueden crear diseños<br />
<strong>educativo</strong>s IMS-LD de nivel A.<br />
MOT+ es una herramienta desarrollada en el centro de investigación LICEF de<br />
Canadá, con el objetivo inicial de estructurar mapas conceptuales para la<br />
representación de conocimiento en diversos dominios (Paquette et al., 2005). MOT+<br />
utiliza una notación grá?ca para representar las entidades de conocimiento con las que<br />
trabaja la herramienta. MOT+ fue extendida para soportar la edición de IMS-LD, de<br />
manera que la herramienta permite representar y editar los conceptos que están<br />
31
de?nidos en IMS-LD. Con esta herramienta se pueden crear diseños <strong>educativo</strong>s IMS-<br />
LD de nivel A y se están realizando trabajos para soportar los niveles B y C.<br />
ASK-LDT (Advanced e-Services for the Knowledge Society Research Unit) (Figura<br />
1.6.1.d) es una herramienta que proporciona una notación grá?ca para los conceptos<br />
de IMS-LD (Karampiperis y Sampson, 2004). ASK-LDT de?ne una notación grá?ca para<br />
un conjunto de tipos de actividades prede?nidas como, por ejemplo, lecciones,<br />
discusiones, exámenes, etc. Además, también proporciona una notación grá?ca para<br />
poder de?nir el ?ujo entre dichas actividades. Con esta herramienta podemos crear<br />
diseños <strong>educativo</strong>s IMS-LD de nivel A y parcialmente de nivel B.<br />
Figura 1.6.1.d. Interfaz del editor de ASK-LDT.<br />
Finalmente, Learning Activity Management system (LAMS) es una herramienta que<br />
permite el diseño, gestión y distribución de actividades colaborativas para e-learning<br />
(Dalziel, 2003, 2005). LAMS proporciona una herramienta de autoría visual muy<br />
intuitiva (Figura 1.6.1.e) que permite crear las secuencias de actividades de<br />
aprendizaje. En los cursos de LAMS se pueden encontrar diferentes actividades:<br />
individuales, para pequeños grupos de usuarios o para clases completas. Estas<br />
actividades pueden incluir el trabajo con contenidos <strong>educativo</strong>s o tareas de trabajo<br />
colaborativo.<br />
32
Figura 1.6.1.e. Interfaz del editor de LAMS.<br />
1.6.2. Motores de ejecución compatibles con IMS-LD<br />
Quizá el motor IMS-LD más popular sea CooperCore. CopperCore es un motor de<br />
ejecución de UOLs formalizadas con IMS-LD desarrollado por la OUNL. Como<br />
características principales de CopperCore podemos destacar:<br />
Es un proyecto de software libre.<br />
Soporta la ejecución de UOLs hasta el nivel C de IMS-LD.<br />
CopperCore está desarrollado sobre la plataforma Java EE, y su puesta en<br />
funcionamiento es relativamente simple.<br />
CopperCore proporciona una Interfaz de Programación de Aplicaciones (API)<br />
que permite extender sus funcionalidades, así como controlar el motor de<br />
ejecución desde otra herramienta.<br />
Proporciona una capa de abstracción, CopperCore Service Integration (CCSI),<br />
que permite integrar de forma sencilla diversos servicios de aprendizaje, como,<br />
por ejemplo, herramientas compatibles con IMS-QTI.<br />
33
1.6.3. Reproductores de IMS-LD<br />
CopperCore Player (Figura 1.6.3.a) es una aplicación web simple que permite<br />
interactuar con el motor de ejecución CopperCore. Esta herramienta fue creada como<br />
herramienta simple para realizar las pruebas necesarios durante el desarrollo del<br />
motor CopperCore.<br />
Figura 1.6.3.a. Reproductor CopperCore.<br />
SLeD Player (Figura 1.6.3.b) es un nuevo cliente web para el motor de ejecución<br />
CopperCore (McAndrew et al., 2004; Weller et al., 2006). Las principales características<br />
de SLeD Player son:<br />
1. Proporciona una interfaz web para la gestión de usuarios y de las ejecuciones<br />
de las UOLs.<br />
2. Permite la personalización del diseño y de la distribución de la interfaz de<br />
reproducción de la UOL mediante el uso de tecnologías XML.<br />
3. Proporciona implementaciones para los servicios de búsqueda y foro que<br />
pueden ser referenciados dentro de los entornos de una UOL codi?cada con<br />
IMS-LD.<br />
4. Proporciona soporte a la capa de abstracción CCSI. Como ejemplo de uso de<br />
CCSI, SLeD integra los servicios de foro y de búsqueda.<br />
34
Figura 1.6.3.b. Reproductor SLeD.<br />
RELOAD Player (Figura 1.6.3.c) ha sido desarrollado por Paul Sharples y Phillip<br />
Beauvoir en la Universidad de Bolton. RELOAD Player ha sido construidO sobre la<br />
plataforma Eclipse y hace uso de CopperCore como motor de ejecución de IMSLD.<br />
Esta herramienta proporciona una interfaz simple para la publicación de UOLs<br />
compatibles con IMS-LD y la creación de usuarios de prueba que pueden ser<br />
utilizados para probar las UOLs. RELOAD Player está pensada principalmente para<br />
probar de manera simple las UOLs que se están diseñando con el correspondiente<br />
editor.<br />
35
Figura 1.6.3.c. Reproductor de IMS-LD de RELOAD.<br />
Otro entorno de ejecución es GRAIL (Gradient-lab RTE for Adaptive IMS-LD in .LRN)<br />
desarrollado en la Universidad Carlos III de Madrid que permite la ejecución de UOL<br />
en el LMS de código libre .LRN (Escobedo del Cid et al., 2007). GRAIL ejecuta OULs<br />
de los tres niveles que permite la especificación y es una de las pocas herramientas<br />
disponibles que se integra completamente en un LMS ampliamente difundido y<br />
utilizado.<br />
1.6.4. Otras iniciativas y proyectos de investigación relacionados con<br />
IMS-LD<br />
Como este campo del modelado <strong>educativo</strong> no está suficientemente maduro para su<br />
aplicación industrial y generalizada, una forma de mantenerse al corriente de los<br />
avances es considerar los proyectos de investigación relacionados. Aunque los<br />
proyectos que tratan, al menos en parte, estos aspectos son muy numerosos nos<br />
quedaremos con algunos que por su volumen y número de socios implicados son<br />
susceptibles de tener un cierto impacto, bien en la evolución de las especificaciones o<br />
bien en el desarrollo de herramientas.<br />
Hay dos proyectos europeos del sexto programa marco que están relacionados con<br />
IMS-LD y que tienen como objetivos avanzar en el uso de dicha especificación y, hasta<br />
cierto punto, producir herramientas que simplifiquen su aplicación. Uno de ellos es<br />
Prolix (http://www.prolixproject.org/) donde se ha creado una herramienta de autoría<br />
denominada Prolix LD authoring tool que traduce un diseño de alto nivel a dicha<br />
especificación (aunque en el momento de escribir este documento no está<br />
36
públicamente disponible y no existen muchos detalles al respecto). Otro proyecto<br />
europeo muy relacionado con el modelado <strong>educativo</strong> y las competencias es<br />
TENCompetence (http://www.tencompetence.org), donde el mismo equipo que ha<br />
participado en el desarrollo de RELOAD, está desarrollando un editor más amigable<br />
para IMS-LD denominado ReCourse (Figura 1.6.4.a). No obstante a fecha de<br />
redacción de este informe todavía no tenían ningún software públicamente disponible<br />
mas allá de capturas de pantalla como la presentada.<br />
Figura 1.6.4.a. Editor de ReCourse.<br />
Otro punto de referencia en la red relativo a estándares <strong>educativo</strong>s es el observatorio<br />
de estándares de tecnologías educativas (CEN/ISSS Learning Technology Standards<br />
Observatory) mantenido en la Universidad de Vigo (http://www.cen-ltso.net) que a<br />
partir del verano de 2008 ha sido incluido en la red europea de buenas prácticas<br />
ASPECT que busca mejorar la adopción de especificaciones y estándares de elearning.<br />
El sitio web del JISC en el Reino Unido (http://www.jisc.ac.uk/) mantiene<br />
mucha información actualizada de los usos <strong>educativo</strong>s de las tecnologías y financia,<br />
por ejemplo, el proyecto LD4P (Learning Design for Practicioners) sobre la aplicación<br />
práctica de IMS-LD (http://bsd1.phosphorix.co.uk/ld4p/index.php) dentro de su<br />
iniciativa más general sobre diseño <strong>educativo</strong><br />
(http://www.jisc.ac.uk/elp_desinglearn.html).<br />
El proyecto canadiense IDLD (www.idld.org) está dedicado a la diseminación del<br />
diseño <strong>educativo</strong> y al uso de IMS-LD proporcionando acceso a información<br />
metodológica sobre cómo aplicar dicho modelado y a un almacén (repositorio) de<br />
diseños <strong>educativo</strong>s.<br />
37
Otro sitio web donde se puede encontrar mucha información relacionada con elearning<br />
y el modelado <strong>educativo</strong>, tanto en sus aspectos más técnicos como en sus<br />
aspectos más <strong>educativo</strong>s, es la Edutech wiki mantenida en la Universidad de Ginebra<br />
(http://edutechwiki.unige.ch/en/Main_Page).<br />
1.7. A MODO DE CONCLUSIÓN<br />
Los EMLs permiten a profesores y educadores el diseño, la formalización y el<br />
intercambio de cursos basados en el concepto general de unidad de aprendizaje.<br />
Estas unidades de aprendizaje, debidamente formalizadas y descritas mediante<br />
metadatos (e.g. IEEE LOM) pueden realmacenarse en una base de datos (también<br />
llamada repositorio) para su reutilización posterior, tanto para repetir el proceso de<br />
aprendizaje, como para la creación de unidades de aprendizaje nuevas tomando ésas<br />
como punto de partida.<br />
Además, los EMLs tienen también otro uso y es que sirven como medio de<br />
comunicación entre el personal técnico y el personal docente. El personal docente es<br />
responsable de la descripción de las experiencias educativas mientras que el personal<br />
técnico es responsable de la creación de intérpretes que permitan ejecutar<br />
automáticamente las UOLs creadas y su integración dentro del LMS que se utilice.<br />
Al integrar el intérprete del EML dentro del LMS estamos proporcionando al personal<br />
docente la posibilidad de adaptar y personalizar el propio LMS, teniendo en cuenta sus<br />
necesidades educativas especí?cas, y sin demandar de ellos conocimientos de<br />
programación profundos (aunque, a día de hoy, sí exige tener mucho conocimiento del<br />
propio estándar IMS-LD debido a la ausencia de herramientas de autoría sencillas y<br />
maduras para usuarios finales).<br />
La especi?cación IMS-LD se ha convertido en el estándar de facto como medio de<br />
incorporación en las herramientas de gestión de e-learning de aspectos más<br />
avanzados de metodologías educativas, lo que permite que los LMS transciendan la<br />
concepción simplista de ser meros artefactos de distribución de contenidos <strong>educativo</strong>s.<br />
Sin embargo, IMS-LD está en un punto medio entre un modelo puramente educacional<br />
y un modelo puramente tecnológico. En nuestra opinión, para poder aplicar esta<br />
especi?cación de manera efectiva necesitamos movernos simultáneamente hacia<br />
ambos extremos. Efectivamente:<br />
Desde el punto de vista <strong>educativo</strong>, se necesita diseñar y documentar el proceso de<br />
enseñanza de manera cuidadosa, con el objetivo de que el diseño pueda ser analizado<br />
y/o reutilizado por otros docentes y que, ?nalmente, este diseño pueda ponerse en<br />
práctica (ejecutarse) automáticamente en un LMS. Por tanto es necesario elevar el<br />
nivel de abstracción proporcionado por las herramientas de autoría de UOL para que<br />
los docentes no tengan que conocer todos los detalles y complejidades del modelo<br />
subyacente impuesto por IMS-LD.<br />
Desde el punto de vista tecnológico, es necesario formalizar todos los detalles<br />
relativos a la ejecución de la UOL diseñada, por ejemplo, cuando se interpreta en un<br />
LMS. La especi?cación IMS-LD deja claramente fuera de su alcance los detalles<br />
especí?cos de ejecución de una UOL de modo que sería necesario un perfil de<br />
38
aplicación ampliamente aceptado que fijara dichos detalles y simplificara el desarrollo<br />
de entornos de ejecución (del mismo modo que SCORM ha fijado detalles no incluidos<br />
en las especificaciones IMS en las que se basa para simplificar su implementación en<br />
sistemas comerciales).<br />
2. LA ESPECIFICACIÓN IMS LEARNING DESIGN<br />
2.1. INTRODUCCIÓN<br />
Disponer de contenidos digitales de calidad y de servicios informáticos de alta<br />
tecnología (por ejemplo, sofisticados programas de comunicación) no es suficiente, por<br />
sí mismo, para dar lugar a aplicaciones e-learning totalmente funcionales. Además se<br />
necesita indicar la forma en la que los distintos participantes en el proceso de<br />
aprendizaje deben utilizar dichos recursos a fin de lograr los objetivos <strong>educativo</strong>s<br />
perseguidos. Dicho de otra forma, es necesario diseñar las distintas pedagogías en las<br />
que se basan las citadas aplicaciones. La especificación IMS Learning Design (IMS<br />
LD) surge, precisamente, como un mecanismo básico que permite describir dichas<br />
pedagogías.<br />
IMS LD proporciona un lenguaje de dominio específico que permite diseñar las<br />
experiencias educativas a las que se expondrán a los usuarios de las aplicaciones de<br />
e-learning. Aún siendo un lenguaje informático artificial, el lenguaje de IMS Learning<br />
Design contiene primitivas y conceptos que pueden ser fácilmente entendidos por los<br />
educadores. De esta forma, su uso no demanda conocimientos muy avanzados de<br />
informática, programación o desarrollo de aplicaciones web. Por el contrario, con un<br />
poco de entrenamiento y con un mínimo de herramientas de soporte (por ejemplo,<br />
editores específicos para IMS LD), un educador motivado podrá utilizar el lenguaje<br />
para plasmar sus diseños <strong>educativo</strong>s. Estos diseños servirán como base para la<br />
generación automática de las aplicaciones finales utilizando herramientas informáticas<br />
adecuadas (por ejemplo, reproductores de IMS LD). De esta forma, el principal<br />
potencial de IMS LD es permitir que sean los propios educadores, que son los que<br />
realmente entienden las necesidades y objetivos finales de las aplicaciones<br />
educativas, los que realmente lideren el desarrollo y mantenimiento de dichas<br />
aplicaciones.<br />
En este capítulo se analiza con detalle la especificación IMS LD. Para ello, se<br />
comienza planteando un caso de estudio sencillo que será utilizado a lo largo del<br />
mismo para ilustrar los distintos aspectos introducidos. Seguidamente se presentan los<br />
principales conceptos y estructuras subyacentes a la especificación. Para finalizar, se<br />
muestra cómo dichos conceptos y estructuras se describen en XML.<br />
2.2. UN CASO DE ESTUDIO<br />
El Profesor Corbinus, primo segundo del conocido Profesor Eméritus (Fernandez-<br />
Manjón et al., 2007) dicta clases de Enología Aplicada en la prestigiosa Escuela de<br />
Estudios y Prospecciones Vinícolas (EEPV), en Villanueva del Tintorro. Corbinus<br />
imparte un seminario de Iniciación a la Cata que, con los años, ha adquirido bastante<br />
39
prestigio entre la comunidad de la EEPV. Parte de este éxito se debe a las grandes<br />
dotes que Corbinus, siempre preocupado por las mejoras de sus procesos<br />
pedagógicos, posee como docente.<br />
Este año, Corbinus, que ha seguido un curso intensivo de verano en e-learning, se ha<br />
planteado introducir en su seminario diversas mejoras con ayuda de las tecnologías de<br />
la Información y las Comunicaciones (TICs). Consciente como es de que el éxito<br />
último de la aplicación satisfactoria de estas tecnologías radica en basar las<br />
aplicaciones en diseños pedagógicos bien fundados, Corbinus baraja los siguientes<br />
escenarios <strong>educativo</strong>s para la articulación de su seminario:<br />
Escenario 1. Un proceso de enseñanza tradicional, que incluye algunas<br />
actividades soportadas por las TICs. Inicialmente Corbinus impartirá una<br />
serie de clases presenciales. A continuación pondrá a disposición de los<br />
alumnos distinto material complementario sobre el Arte de la Cata. Este<br />
material incluye: (i) un vídeo de 10 minutos de duración en el que el insigne<br />
Profesor Bacus (de la Universidad de Uva Dulce) analiza la importancia del<br />
retrogusto en la evaluación de los matices del vino de Rueda, variedad<br />
Verdejo; (ii) un artículo escrito por el conocido experto italiano Giorgio Birra,<br />
en el que se realiza un estudio comparativo entre las tonalidades de los<br />
caldos de la Baja Toscana y (iii) un estudio llevado a cabo por la Profesora<br />
Yoyo Bebo sobre el efecto de los sulfitos en el regusto y en el postgusto del<br />
vino de mesa común. De la misma manera, Corbinus también quiere<br />
recomendar a sus alumnos la visita del sitio www.lacatadelvinotinto.org.<br />
Por último, Corbinus quiere fomentar también el aprendizaje colaborativo<br />
mediante la organización de un debate on-line en el que, aparte de los<br />
alumnos matriculados en el seminario, participarán también alumnos de<br />
anteriores promociones. Una vez finalizadas todas estas actividades, los<br />
alumnos deben preparar un trabajo escrito, que Corbinus evaluará a fin de<br />
decidir las notas finales de los mismos.<br />
Escenario 2. Introducción de mecanismos de adaptación del proceso a las<br />
necesidades particulares de los alumnos. Este escenario se basa en el<br />
anterior. No obstante, antes de iniciar las actividades complementarias,<br />
Corbinus somete a sus alumnos a un examen tipo test. En función de los<br />
resultados obtenidos en este examen y como paso previo al inicio de las<br />
actividades complementarias, Corbinus puede decidir recomendar a los<br />
alumnos repasar el material básico contenido en su libro Introducción a la<br />
Esencia de la Cata (Corbinus tiene una versión electrónica en formato <strong>PDF</strong><br />
de este libro que, a pesar de su carácter autoeditado, ha llegado a ganar un<br />
merecido renombre entre los miembros especializados de la comunidad<br />
vinícola). Asimismo, Corbinus también desea introducir una fase de<br />
recuperación para aquellos alumnos cuyo trabajo no haya superado ciertos<br />
umbrales mínimos de calidad. Esta fase consiste en el repaso del libro<br />
Introducción a la Esencia de la Cata, del artículo de Birra y del material<br />
contenido en el sitio www.lacatadelvinotinto.org. Seguidamente el alumno<br />
deberá revisar y mejorar su trabajo, trabajo que de nuevo será evaluado por<br />
Corbinus.<br />
Escenario 3. En este escenario Corbinus desea mejorar el proceso de<br />
entrega de trabajos, permitiendo que se le notifique cada entrega, a fin de<br />
facilitar el solapamiento del período de corrección con el período de<br />
40
edacción de trabajos para aquellos trabajos que se hayan entregado antes<br />
de la expiración de la fecha de entrega.<br />
2.3. VISIÓN CONCEPTUAL DE IMS LD<br />
La especificación IMS LD permite diseñar las pedagogías de componentes <strong>educativo</strong>s<br />
denominados “unidades de aprendizaje”. Una unidad de aprendizaje es un concepto<br />
abstracto con el que se denota cualquier pieza utilizada con un propósito <strong>educativo</strong> o<br />
de entrenamiento como, por ejemplo, un curso, un módulo, una lección, etc. Es<br />
importante notar que, desde el punto de vista de IMS LD, una unidad de aprendizaje<br />
no es una mera organización de recursos de soporte al aprendizaje (v.g. contenidos<br />
<strong>educativo</strong>s tales como textos, diagramas, ejercicios, enunciados de prácticas o<br />
servicios informáticos y telemáticos tales como e-mail, foros, chats, etc.), sino que<br />
también integra las actividades necesarias que los distintos participantes en el proceso<br />
deben llevar a cabo con ayuda de dichos recursos a fin de lograr una experiencia<br />
educativa satisfactoria (v.g. realización de prácticas, resolución de ejercicios,<br />
realización y corrección de exámenes, exposiciones y debates, etc.). Los recursos, las<br />
actividades y los participantes concretos dependen de cada unidad de aprendizaje<br />
particular. De hecho, la identificación y la adecuada orquestación de estos<br />
componentes constituyen el núcleo fundamental de todo diseño <strong>educativo</strong>.<br />
En el caso de estudio cada uno de los escenarios planteados dará lugar a una unidad<br />
de aprendizaje, integrando distintos recursos, participantes y actividades.<br />
41
Figura 2.3.a. Recursos, participantes y actividades en las unidades de aprendizaje<br />
derivadas del caso de estudio.<br />
Impartición<br />
Clase Presencial<br />
bacus.avi<br />
Chat<br />
Visionado<br />
Video<br />
Evaluación<br />
Trabajo<br />
Profesor Alumnos<br />
Efectivamente:<br />
(a) UACata1<br />
Lectura<br />
Articulo<br />
Birra<br />
Examen<br />
Sitio Web<br />
Realización<br />
Trabajo<br />
birra.pdf bebo.pdf<br />
www.<br />
Servidor<br />
Archivos Tablón<br />
Lectura<br />
Articulo Bebo<br />
Antiguos<br />
Alumnos<br />
Debate<br />
(c) UACata3<br />
(b) UACata2<br />
ACTIVIDADES<br />
Consulta<br />
Resultados<br />
lacatadelvinotinto.<br />
org<br />
42<br />
Evaluación<br />
Test<br />
Realización<br />
Test<br />
PARTICIPANTES<br />
RECURSOS<br />
Lectura<br />
Libro<br />
Corbinus<br />
test.zip<br />
Revisión y<br />
Mejora del<br />
Trabajo<br />
Repaso<br />
Sitio Web<br />
Repaso<br />
Libro<br />
Corbinus<br />
Repaso<br />
Artículo<br />
Birra<br />
libroCorbinus.pdf<br />
Consulta<br />
Resultados<br />
Repesca<br />
Re-evaluación<br />
Trabajo<br />
En el escenario 1 surge una unidad de aprendizaje (UACata1)<br />
caracterizada por los siguientes componentes − Figura 2.3.a (a):<br />
- Recursos: Los recursos incluyen todos los contenidos digitales<br />
utilizados por Corbinus en la articulación de las actividades<br />
complementarias: el vídeo con la charla del Prof. Bacus, el artículo de<br />
Giorgio Birra (v.g. contenido en un archivo <strong>PDF</strong>), el estudio de la Profª.<br />
Bebo (otro <strong>PDF</strong>) e incluso la propia web www.lacatadelvinotinto.org. Del<br />
mismo modo, también es necesario incluir recursos adicionales en<br />
forma de herramientas telemáticas de soporte al proceso: un chat que<br />
permita articular el debate entre los alumnos de nueva promoción y los<br />
alumnos de promociones anteriores, un servidor de archivos en el que<br />
los alumnos puedan depositar sus trabajos para que estos puedan ser
corregidos por Corbinus y un tablón de notas en el que Corbinus<br />
publicará los resultados.<br />
- Participantes: El propio Corbinus, los alumnos de nueva promoción y<br />
los alumnos de promociones anteriores.<br />
- Actividades: Impartición de la clase presencial, Visionado del vídeo de<br />
Bacus, Lectura del artículo de Birra, Lectura del artículo de Bebo,<br />
Examen del sitio web, Debate, Realización del Trabajo, Evaluación del<br />
Trabajo y Consulta Resultados.<br />
En el escenario 2 la unidad de aprendizaje anterior se extiende con nuevos<br />
recursos y actividades, para dar lugar a la Unidad de Aprendizaje UACata2<br />
− Figura 2.3.a (b):<br />
- Recursos: Todos los de UACata1. Se incluye además el test previo a<br />
las actividades complementarias (codificado en la especificación de<br />
representación de exámenes IMS QTI: ver IMS QTI, 2006), así como el<br />
libro de Corbinus (un <strong>PDF</strong>).<br />
- Participantes: Los mismos que en UACata1.<br />
- Actividades: Todas las de UACata1. Además se añaden las siguientes:<br />
Realización de Test, Evaluación de Test, Lectura del libro de Corbinus,<br />
Repaso del libro de Corbinus, Repaso del Artículo de Birra, Repaso del<br />
material del sitio web, Revisión y Mejora del Trabajo, Revaluación del<br />
Trabajo y Consulta Resultados Repesca.<br />
Los componentes de la unidad de aprendizaje que surge en el escenario 3<br />
(UACata3) son los mismos que los de la unidad de aprendizaje UACata2 −<br />
Figura 2.3.a (c).<br />
Es importante notar que la especificación de los componentes no es suficiente para<br />
caracterizar completamente una Unidad de Aprendizaje. Efectivamente, también es<br />
preciso especificar la forma en la que dichos componentes interactúan entre sí durante<br />
el proceso <strong>educativo</strong>. O, lo que es lo mismo, diseñar el método pedagógico seguido en<br />
cada unidad de aprendizaje. En el caso de estudio, el método seguido en cada unidad<br />
de aprendizaje queda capturado a grosso modo en las narraciones de cada uno de los<br />
escenarios y supone, en gran medida, decidir qué participantes llevan a cabo qué<br />
actividades, así como el orden de realización de dichas actividades:<br />
Método seguido en la unidad UACata1 − Figura 2.3.b (a): Corbinus lleva a<br />
cabo la Impartición de la Clase Presencial. Una vez finalizada dicha clase,<br />
los alumnos deben llevar a cabo el Visionado del vídeo de Bacus, la Lectura<br />
del artículo de Birra y la Lectura del artículo de Bebo (el orden es<br />
indiferente). Seguidamente los alumnos deben realizar el Examen del sitio<br />
web. A continuación, los alumnos participan junto con los de las<br />
promociones anteriores en el Debate (aquí Corbinus puede jugar el papel<br />
de moderador). Una vez finalizado el debate, los alumnos proceden a la<br />
Realización del Trabajo. Pasada la fecha de entrega, Corbinus lleva a cabo<br />
la Evaluación del Trabajo. Finalizada esta evaluación, los alumnos pueden<br />
consultar los resultados.<br />
43
Método seguido en la unidad UACata2 − Figura 2.3.b (b): Lo mismo que en<br />
la unidad UACata1, Corbinus lleva a cabo la Impartición de la Clase<br />
Presencial. Una vez finalizada dicha clase, los alumnos llevan a cabo la<br />
Realización del Test y Corbinus la Evaluación del Test. Si la nota obtenida<br />
en el test es menor que 5, el alumno debe llevar a cabo la Lectura del libro<br />
de Corbinus antes de pasar a realizar el resto de actividades (visionado del<br />
vídeo, lectura de artículo e informe, etc). Si no, puede pasar a realizar<br />
directamente dichas actividades. Asimismo, una vez corregido el trabajo, si<br />
la nota obtenida en el mismo es menor que 5, el alumno debe llevar a cabo<br />
el Repaso del libro de Corbinus, el Repaso del Artículo de Birra, el Repaso<br />
del material del sitio web así como la Revisión y Mejora del Trabajo. Por su<br />
parte, Corbinus deberá llevar a cabo la Revaluación del Trabajo. Finalizada<br />
la revaluación, los alumnos pueden consultar los resultados.<br />
Método seguido en la unidad UACata3 − Figura 2.3.b (c): Idéntico al<br />
seguido en la unidad UACata2, salvo que ahora, cuando el alumno finaliza<br />
el trabajo notifica este hecho a Corbinus, lo que evita que éste tenga que<br />
estar mirando de vez en cuando el espacio de archivos compartidos.<br />
44
(a)<br />
(b)<br />
(c)<br />
Figura 2.3.b. Métodos pedagógicos asociados con las unidades derivadas del caso<br />
de estudio.<br />
Impartición<br />
Clase Presencial<br />
Impartición<br />
Clase Presencial<br />
Lectura<br />
Articulo<br />
Birra<br />
Lectura<br />
Articulo Bebo<br />
Realización<br />
Test<br />
Nota ≥5<br />
Visionado<br />
Video<br />
Lectura<br />
Articulo<br />
Birra<br />
Lectura<br />
Articulo Bebo<br />
Examen<br />
Sitio Web<br />
Re-evaluación<br />
Trabajo<br />
Consulta<br />
Resultados<br />
Repesca<br />
Visionado<br />
Video<br />
Evaluación<br />
Test<br />
Examen<br />
Sitio Web<br />
Realización<br />
Trabajo<br />
Revisión y<br />
Mejora del<br />
Trabajo<br />
45<br />
Debate<br />
Nota < 5<br />
Revisión y<br />
Mejora del<br />
Trabajo<br />
Profesor<br />
Todos los<br />
alumnos<br />
Realización<br />
Trabajo<br />
Lectura Libro<br />
Corbinus<br />
Debate Realización<br />
Trabajo<br />
Repaso<br />
Libro<br />
Corbinus<br />
Alumno<br />
Todos los alumnos<br />
antiguos<br />
Evaluación<br />
Trabajo<br />
Repaso<br />
Artículo<br />
Birra<br />
Repaso<br />
Sitio Web<br />
Consulta<br />
resultados<br />
Consulta<br />
resultados<br />
Evaluación<br />
Trabajo<br />
Nota < 5
IMS LD permite formalizar de manera rigurosa la estructura y el método pedagógico de<br />
las unidades de aprendizaje, de manera que el diseño <strong>educativo</strong> resultante pueda ser<br />
interpretado por un programa informático apropiado (un reproductor de IMS LD),<br />
haciendo posible, por tanto, la automatización del proceso <strong>educativo</strong>. Las siguientes<br />
secciones proporcionan más detalle sobre dicho proceso de formalización.<br />
2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES<br />
Desde un punto de vista técnico, las unidades de aprendizaje pueden representarse<br />
como paquetes IMS, siguiendo la especificación IMS Content Packaging (IMS CP).<br />
Esta especificación se organiza en niveles de complejidad creciente, cada uno de los<br />
cuáles permite expresar diseños <strong>educativo</strong>s más sofisticados. A continuación se<br />
analizan estos aspectos de empaquetado y de organización en niveles.<br />
2.4.1. IMS Content Packaging e IMS LD<br />
Tal y como se detalla en (Fernández-Manjón et al., 2007), la especificación IMS CP<br />
dicta la forma de encapsular contenidos <strong>educativo</strong>s interrelacionados en piezas de<br />
información denominadas “paquetes”. En la Figura 2.4.1.a (a) se muestra la estructura<br />
de alto nivel de un paquete IMS.<br />
46
Figura 2.4.1.a. En la parte (a) se muestra el esquema de la estructura de un<br />
paquete IMS;En la parte (b) se muestra una unidad de aprendizaje representada<br />
como un paquete IMS: es un paquete en el que la organización está descrita de<br />
acuerdo con la especificación IMS LD.<br />
(a) (b)<br />
Organizaciones Subpaquetes<br />
Recursos<br />
Archivos<br />
internos<br />
Archivos<br />
externos<br />
47<br />
Diseño <strong>educativo</strong><br />
expresado en IMS LD
Figura 2.4.1.b. Esbozo del paquete IMS asociado con la unidad UACata1.<br />
rbacus<br />
bacus.avi birra.pdf bebo.pdf<br />
Otros archivos<br />
rbirra rbebo<br />
Tal y como se esquematiza en la Figura:<br />
Diseño <strong>educativo</strong> descrito en IMS<br />
LD<br />
48<br />
rweb<br />
www.lacatadelvinotintotinto.org<br />
Otros archivos externos<br />
El paquete puede involucrar archivos internos y archivos externos. Los<br />
archivos internos son archivos digitales que forman parte del paquete y<br />
pueden estar físicamente organizados en carpetas. En el caso de estudio,<br />
el vídeo, los artículos, el libro, el examen tipo test son todos ellos archivos<br />
internos. Los archivos externos, por su parte, son elementos que no forman<br />
parte del paquete pero que se refieren desde el mismo utilizando una URL<br />
(una dirección estándar de Internet). En el caso de estudio, el sitio web<br />
puede considerarse un archivo externo.<br />
Los archivos internos pueden agruparse en recursos internos. En dichas<br />
agrupaciones siempre se distingue un “archivo primario”. El resto de los<br />
archivos son “archivos secundarios”. En el caso de estudio los recursos se<br />
corresponden directamente con archivos. No obstante, existen otros casos<br />
en los que es conveniente agrupar varios archivos interrelacionados en un<br />
único recurso. Un ejemplo típico es el de una página HTML. Dicha página<br />
constará, por una parte, de un archivo HTML pero también de todos<br />
aquellos elementos referidos desde la página (v.g. imágenes). En este<br />
caso, el recurso en sí es toda una colección de archivos: el archivo HTML<br />
(que será el archivo primario) y los archivos asociados con todos los<br />
elementos referidos desde el mismo (que serán los archivos secundarios).<br />
A modo de ejemplo, si Corbinus hubiera ofertado su libro en formato HTML,<br />
probablemente tendría que haber considerado una colección de archivos en
el recurso asociado con dicho libro (el texto HTML en sí y todos los<br />
elementos multimedia referidos desde el mismo).<br />
Los archivos externos están asociados con recursos externos. En el caso<br />
de estudio, el sitio web dará lugar a un recurso externo.<br />
Los recursos pueden, a su vez, organizarse siguiendo un determinado<br />
convenio a efectos de su presentación, dando lugar a distintas<br />
organizaciones.<br />
Por último, el paquete puede incluir, además, otros subpaquetes con la<br />
misma estructura descrita.<br />
La conexión entre IMS CP e IMS LD se lleva a cabo a través de las organizaciones.<br />
Efectivamente, IMS LD permite sustituir el formalismo descriptivo de organizaciones<br />
básico introducido por IMS CP (que, a grandes rasgos, se reduce a organizar<br />
jerárquicamente los contenidos) con un formalismo de diseño pedagógico mucho más<br />
rico y sofisticado. De hecho, desde el punto de vista de IMS LD, un paquete IMS<br />
puede considerarse como una unidad de aprendizaje si y sólo si incluye una<br />
descripción en IMS LD en la parte de organizaciones del paquete − Figura 2.4.1.a (b).<br />
A modo de ejemplo, en la Figura 2.4.1.b se esboza el encapsulado de la unidad<br />
UACata1 como un paquete IMS. Para mayor detalle sobre la especificación IMS CP<br />
puede consultarse (IMS CP, 2004).<br />
2.4.2. Niveles en la Especificación<br />
La especificación IMS LD se estructura en tres niveles de complejidad creciente. Cada<br />
nivel se construye sobre el anterior, añadiendo al mismo nuevas características que<br />
pueden utilizarse para expresar diseños <strong>educativo</strong>s más sofisticados. En concreto:<br />
El nivel A de la especificación introduce los principales elementos<br />
estructurales (recursos y servicios, participantes -roles-, actividades, etc.) y<br />
dinámicos (aquellos correspondientes al método pedagógico) de IMS LD.<br />
No obstante, este nivel no permite describir métodos pedagógicos cuyo<br />
comportamiento varía dependiendo de la propia ejecución de dichos<br />
métodos. Efectivamente, los métodos pedagógicos que pueden ser<br />
descritos a nivel A se ejecutarán siempre de la misma manera. Esto<br />
permite, por ejemplo, modelar el diseño <strong>educativo</strong> que surge en el<br />
escenario A del caso de estudio (unidad UACata1), pero no así los que<br />
surgen en los escenarios B y C (en los cuáles la ejecución depende de<br />
resultados dinámicos tales como la puntuación obtenida por los<br />
participantes en el examen y en el trabajo).<br />
El nivel B de la especificación introduce un mecanismo sencillo que permite<br />
representar el estado de la ejecución del método pedagógico: las<br />
propiedades. Los valores de las propiedades pueden modificarse durante la<br />
reproducción de la unidad de aprendizaje. Del mismo modo, el nivel B<br />
permite expresar condiciones sobre los valores de las propiedades,<br />
condiciones cuya verdad o falsedad puede provocar la visibilidad o<br />
invisibilidad de nuevas actividades y, por tanto, la adaptación del flujo de<br />
aprendizaje a las necesidades de cada participante. El nivel B permite, por<br />
49
ejemplo, representar el diseño pedagógico que surge en el escenario B del<br />
caso de estudio (unidad UACata2), manteniendo propiedades que<br />
almacenen los resultados de las evaluaciones y utilizando dichos valores en<br />
condiciones que permitan determinar qué actividades deben proponerse a<br />
continuación.<br />
El nivel C, por último, introduce un mecanismo de notificación que ofrece<br />
paradigmas alternativos para controlar el flujo de aprendizaje. Utilizando<br />
este mecanismo de nivel C es posible, por ejemplo, modelar fácilmente el<br />
diseño <strong>educativo</strong> asociado con la unidad de aprendizaje del escenario C<br />
(unidad UACata3).<br />
Las siguientes secciones analizan con más detalle cada uno de estos niveles.<br />
2.5. EL NIVEL A<br />
El nivel A de la especificación permite describir diseños <strong>educativo</strong>s no adaptativos, en<br />
el sentido de que el método pedagógico siempre exhibirá el mismo comportamiento,<br />
independientemente del resultado de las distintas actividades. No obstante, en este<br />
nivel se introducen los principales constructores del lenguaje. A continuación se<br />
analizan las principales características de este nivel. La sección termina ejemplificando<br />
el uso de estas características mediante el modelado de la unidad de aprendizaje<br />
UACata1.<br />
2.5.1. Estructura de alto nivel de un Diseño Educativo<br />
La Figura 2.5.1.a esquematiza la estructura de alto nivel de la especificación de un<br />
diseño <strong>educativo</strong> de nivel A.<br />
Figura 2.5.1.a. Estructura de un diseño <strong>educativo</strong> de nivel A<br />
Diseño <strong>educativo</strong><br />
0..1<br />
0..1<br />
0..1<br />
1<br />
1<br />
0..1<br />
.<br />
50<br />
Título<br />
Objetivos de Aprendizaje<br />
Prerequisitos<br />
Componentes<br />
Método<br />
Metadatos
De acuerdo con esta figura, la especificación del diseño consta de:<br />
Un título opcional que describe brevemente el diseño <strong>educativo</strong> y que<br />
puede utilizarse, a efectos informativos, durante la inspección de alto nivel<br />
de la unidad de aprendizaje.<br />
Opcionalmente, los objetivos de aprendizaje de la unidad asociada con el<br />
diseño. Estos objetivos hacen referencia a los logros de aprendizaje que se<br />
espera que consigan los distintos alumnos que cursen la unidad. Es<br />
importante indicar que IMS LD no proporciona mecanismos específicos<br />
para formalizar dichos objetivos. Este elemento de información permite<br />
únicamente referir a un recurso que contendrá una descripción (informal o<br />
formal) de tales objetivos. De hecho, en el caso más simple los objetivos<br />
harán referencia a recursos que expliquen textualmente dichos objetivos.<br />
Por ejemplo, en nuestro caso de estudio Corbinus podría preparar un<br />
recurso adicional (v.g. un archivo <strong>PDF</strong>) en el que planteara los objetivos<br />
generales del seminario. IMS también ha propuesto otras especificaciones<br />
alternativas para la descripción de tales objetivos como, por ejemplo, IMS<br />
RDCEO (Reusable Definition of Compentency or Educational Objectives –<br />
veáse IMS RCDEO, 2002 y también el capítulo sobre RDCEO en este<br />
informe).<br />
Opcionalmente, los prerrequisitos necesarios para cursar la unidad. De<br />
nuevo debe indicarse que IMS LD no proporciona mecanismos específicos<br />
para formalizar tales requisitos. El elemento de información permitirá<br />
únicamente referir a un recurso (v.g. un archivo con un documento<br />
apropiado) que describa dichos requisitos. Si se desea un grado mayor de<br />
formalización, puede utilizarse también IMS RDCEO para este propósito.<br />
Los componentes del diseño <strong>educativo</strong>. Dichos componentes enumeran<br />
los participantes, las actividades y los materiales involucrados en el proceso<br />
de aprendizaje.<br />
El método pedagógico que se sigue en la unidad de aprendizaje. Esta<br />
característica (la posibilidad de formalizar explícitamente el método más<br />
apropiado para cada unidad / escenario de aprendizaje) es uno de los<br />
elementos distintivos de IMS LD y suele calificarse normalmente de<br />
neutralidad pedagógica. Efectivamente, IMS LD no se compromete con<br />
ninguna pedagogía concreta, sino que se sitúa al metanivel, permitiendo a<br />
los diseñadores describir la pedagogía más apropiada para cada dominio /<br />
aplicación.<br />
Los metadatos son un componente esencial de cualquier material<br />
<strong>educativo</strong> informatizado con mínimas aspiraciones de permitir su<br />
descubrimiento y reutilización por terceros. Dichos metadatos son<br />
información adicional que se añade a los contenidos y que describen<br />
distintas características semánticas de los mismos. En este caso se podría<br />
describir quién ha codificado el diseño <strong>educativo</strong>, quién ha sido el último<br />
revisor del mismo, cómo puede clasificarse el diseño <strong>educativo</strong> en una<br />
taxonomía de diseños, etc. Para ello, la especificación permite utilizar<br />
cualquier convenio de descripción de metadatos (por ejemplo la Norma<br />
española UNE 71361:2010 Perfil de Aplicación LOM-ES v1.0), aunque<br />
51
ecomienda el uso de la especificación Learning Object Metadata (LOM)<br />
para tal fin. Para una descripción detallada de LOM puede consultarse<br />
(IEEE LOM, 2002; IMS META, 2006; Fernández-Manjón et al., 2007).<br />
Además, como se verá a lo largo de este capítulo, existen otros muchos<br />
lugares de la especificación donde pueden utilizarse metadatos.<br />
La diferencia entre componentes y método es esencial para entender la estructura<br />
formal de un diseño <strong>educativo</strong>. En palabras de la propia especificación, esta diferencia<br />
es la misma que existe en una receta de cocina entre la lista de ingredientes (los<br />
componentes) y la descripción de los pasos que hay que seguir para preparar el plato<br />
(el método). Para aquellos lectores con conocimientos de programación, una analogía<br />
útil puede ser considerar la sección de componentes como la sección de declaraciones<br />
y la sección de método como la sección de instrucciones.<br />
2.5.2. Descripción de los Componentes: Roles, Actividades y Entornos<br />
La Figura 2.5.2.a muestra la estructura de la especificación de los componentes del<br />
diseño <strong>educativo</strong>. Dicha Figura introduce también la terminología utilizada en IMS LD<br />
en relación con los participantes (en IMS LD: roles) y con los contenidos y servicios<br />
utilizados en las actividades (en IMS LD: entornos).<br />
Figura 2.5.2.a. Estructura de la especificación de los componentes.<br />
Componentes<br />
1<br />
52<br />
0..1<br />
0..1<br />
Roles<br />
Actividades<br />
Entornos<br />
En la Figura 2.5.2.b se esquematiza la estructura de la especificación de los roles. Tal<br />
y como muestra dicha figura, IMS LD introduce dos tipos predefinidos de roles:<br />
aprendiz y plantilla (en inglés, staff). Cada rol puede, a su vez, especializarse en<br />
nuevos subroles, tal y como indican los ciclos introducidos en la Figura 2.5.2.b. Por<br />
ejemplo, en nuestro caso de estudio el rol aprendiz se especializará en el subrol<br />
alumno de nueva promoción y alumno de promociones antiguas, mientras que el rol<br />
plantilla se especializará en el subrol profesor del seminario − Figura 2.5.2.c (a).
Figura 2.5.2.b. Estructura de la especificación de los roles.<br />
Roles<br />
0..∞<br />
0..∞<br />
Aprendiz<br />
Plantilla<br />
53<br />
0..1<br />
0..1<br />
0..∞<br />
0..1<br />
0..1<br />
0..1<br />
0..∞<br />
0..1<br />
Título<br />
Información<br />
Metadatos<br />
Título<br />
Información<br />
Metadatos<br />
Figura 2.5.2.c. (a) Roles en el caso de estudio; (b) hipotética asignación de usuario<br />
a roles durante la ejecución de la unidad de aprendizaje.<br />
(a) (b)<br />
Aprendiz<br />
Alumno de nueva<br />
promoción<br />
Plantilla<br />
Profesor del<br />
Seminario<br />
Alumno de<br />
promociones<br />
antiguas<br />
Alumno de nueva promoción <br />
José Botella<br />
Ana Brandy<br />
Pedro Rioja<br />
Alumno de promociones antiguas <br />
Anselmo Cacique<br />
María Valdepeñas<br />
Profesor del Seminario <br />
Corbinus Bodeguero<br />
Es importante señalar que los roles no introducen participantes concretos, sino tipos<br />
de participantes. Por ejemplo, supongamos que José Botella es un alumno de nueva<br />
promoción matriculado en el curso de Corbinus. El rol, identificado en tiempo de<br />
diseño, será alumno de nueva promoción. Por su parte, José Botella será un usuario<br />
concreto de la unidad de aprendizaje, asignado al rol alumno de nueva promoción. En<br />
general cada rol podrá tener asignados múltiples usuarios en tiempo de ejecución,<br />
aunque, por supuesto, también pueden concebirse roles que tengan asignados un
único usuario (v.g. Corbinus es el único usuario asignado al rol profesor del seminario).<br />
Qué usuarios están asignados a qué roles es un aspecto que no se describe en el<br />
diseño <strong>educativo</strong> (es decir, no se describe usando IMS LD), sino que se decide<br />
posteriormente, en tiempo de explotación, administración y ejecución de la unidad de<br />
aprendizaje −por ejemplo, mediante una herramienta de administración que permite<br />
asignar usuarios a roles, como se sugiere en la Figura 2.5.2.c (b). En lo que se refiere<br />
al resto de los elementos de información en sí introducidos en la Figura 2.5.2.b, su<br />
significado es directo:<br />
Cada rol puede tener asociado un título descriptivo breve.<br />
Asimismo, cada rol puede tener asociado un elemento de información, que<br />
permite hacer referencia a recursos que describen de manera detallada<br />
dicho rol. Por ejemplo, Corbinus podría usar esta característica para enlazar<br />
documentos descriptivos de cada uno de los roles asociados con los<br />
alumnos.<br />
Por último, cada rol puede tener asociados metadatos. Entre las múltiples<br />
posibilidades que ofrece esta característica puede pensarse en la<br />
disposición de una biblioteca externa de roles y en la selección de dichos<br />
roles en la biblioteca utilizando esta sección de metadatos (aunque, por<br />
supuesto, estos usos no están ni deben estar normativizados en IMS LD).<br />
Figura 2.5.2.d. Estructura de la especificación de las actividades. Las llaves quieren<br />
decir que puede elegirse entre cualesquiera de los elementos de información que<br />
agrupan.<br />
Actividades<br />
1..∞<br />
54<br />
Actividad de Aprendizaje<br />
Actividad de Soporte<br />
Actividad Estructurada<br />
La estructura de las actividades se esquematiza en la Figura 2.5.2.d. Como puede<br />
observarse en dicha Figura, se distinguen los siguientes tres tipos de actividades:<br />
Actividades de aprendizaje: estas actividades deben ser realizadas<br />
individualmente por cada participante, que logrará alcanzar ciertos objetivos<br />
<strong>educativo</strong>s mediante la realización de las mismas. Por ejemplo, en nuestro<br />
caso de estudio, las actividades Lectura Artículo Birra y Realización Trabajo<br />
son ejemplos de actividades de aprendizaje<br />
Actividades de soporte: actividades que permiten a un rol proporcionar<br />
algún tipo de soporte a otro rol. Un ejemplo típico son las actividades de<br />
evaluación. Aquí, el profesor proporciona un soporte de evaluación a cada<br />
uno de los miembros de un rol alumno. Por ejemplo, en nuestro caso de<br />
estudio, la actividad Evaluación Trabajo es una actividad de soporte.<br />
Actividades estructuradas: estas actividades permiten agrupar otras<br />
actividades más simples. El resultado puede considerarse como una
actividad individual a efectos de su uso en el método pedagógico. En<br />
nuestro caso de estudio, las actividades Lectura Artículo Birra, Visionado<br />
Vídeo y Lectura Artículo Bebo pueden agruparse en una actividad<br />
estructurada, ya que el grupo resultante se trata como un todo en la<br />
especificación del método pedagógico. Estas actividades estructuradas<br />
pueden, además, configurarse de dos formas diferentes:<br />
- En modo secuencia. Este modo indica que la realización de la actividad<br />
estructurada supondrá realizar consecutivamente, una detrás de la otra,<br />
las actividades constituyentes.<br />
- En modo selección. Este modo indica que el orden de realización de las<br />
actividades componentes puede ser elegido por el usuario. En el caso<br />
de la actividad estructurada puesta como ejemplo, tendrá sentido<br />
configurar la misma en modo selección.<br />
Figura 2.5.2.e. Estructura de la especificación de una actividad de aprendizaje.<br />
Actividad de Aprendizaje<br />
0..1<br />
0..1<br />
0..1<br />
0..∞<br />
1<br />
0..1<br />
0..1<br />
0..1<br />
55<br />
Titulo<br />
Objetivos de Aprendizaje<br />
Prerequisitos<br />
Entorno (referencia)<br />
Descripción<br />
Condición de Finalización<br />
Acción tras la finalización<br />
Metadatos<br />
La Figura 2.5.2.e esquematiza la estructura de la descripción de una actividad de<br />
aprendizaje. Los elementos de información explicitados en esta figura son:<br />
Un breve título descriptivo opcional.<br />
Opcionalmente, descripción de los objetivos de aprendizaje y de los<br />
prerrequisitos de la actividad. La naturaleza de estos elementos es análoga<br />
a la de los asociados con el diseño <strong>educativo</strong> global, aunque esta vez<br />
referida a la actividad concreta.<br />
Referencias a los distintos entornos que caracterizan los materiales<br />
<strong>educativo</strong>s y servicios requeridos por la actividad (más adelante se<br />
ampliarán los detalles sobre estos componentes). Es importante notar que<br />
los entornos en sí no se describen aquí, sino que en este campo se sitúan
únicamente referencias a los mismos. Esto permite reutilizar un mismo<br />
entorno en múltiples actividades.<br />
Descripción de la actividad. Referencias a recursos que describen la<br />
actividad. Por ejemplo, en la actividad Visionado de Vídeo, aparte del<br />
entorno conteniendo el material concreto a utilizar (v.g. el vídeo), Corbinus<br />
podrá incluir una referencia a un recurso asociado con un <strong>PDF</strong> explicando<br />
la actividad.<br />
Descripción opcional sobre la forma de finalizar la actividad. En IMS LD una<br />
actividad de aprendizaje se puede finalizar, bien porque así lo decida el<br />
aprendiz (v.g. pulsando un botón de finalización asociado con la actividad<br />
en el reproductor), bien porque se haya superado el tiempo límite asignado<br />
por el diseñador <strong>educativo</strong> para su finalización. Es importante indicar que, si<br />
no se especifica esta descripción, por defecto la actividad se asume<br />
finalizada (es decir, la actividad estará finalizada desde el comienzo mismo<br />
de la reproducción).<br />
Descripción opcional de la acción a llevar a cabo una vez que se ha<br />
completado la actividad. A nivel A dicha acción puede ser, únicamente,<br />
mostrar un recurso proporcionando información de realimentación al<br />
aprendiz. Por ejemplo, Corbinus podría utilizar esta opción en Visionado de<br />
Vídeo para visualizar un texto resumen con los principales puntos<br />
expuestos en el vídeo, una vez que dicho vídeo hubiera finalizado.<br />
Un elemento con metadatos acerca de la actividad.<br />
La estructura de la especificación de una actividad de soporte es, por su parte, similar<br />
a la de una actividad de aprendizaje, tal y como se muestra en la Figura 2.5.2.f. La<br />
principal diferencia es que en este tipo de actividades pueden identificarse<br />
explícitamente los roles a los que se da soporte (rol soportado).<br />
Figura 2.5.2.f. Estructura de la especificación de una actividad de soporte.<br />
Actividad de Soporte<br />
0..1<br />
0..∞<br />
0..1<br />
0..1<br />
0..∞<br />
1<br />
0..1<br />
0..1<br />
0..1<br />
56<br />
Titulo<br />
Rol soportado (referencia)<br />
Objetivos de Aprendizaje<br />
Prerequisitos<br />
Entorno (referencia)<br />
Descripción<br />
Condición de finalización<br />
Acción tras la finalización<br />
Metadatos
La Figura 2.5.2.g esboza cómo se especifica una actividad estructurada en IMS LD.<br />
Los elementos de información involucrados son:<br />
Título descriptivo opcional.<br />
Referencia a recursos que describen la actividad. Al contrario que con el<br />
elemento de descripción de una actividad simple, este elemento es opcional<br />
(ya que, en última instancia, las actividades estructuradas podrán<br />
entenderse descritas por sus actividades constituyentes). No obstante,<br />
puede haber muchos casos donde desee puntualizarse mejor el propósito<br />
de la actividad estructurada. Por ejemplo, Corbinus podría explicar que el<br />
propósito de la actividad estructurada formada por Lectura Artículo Birra,<br />
Visionado Vídeo y Lectura Artículo Bebo es clarificar una serie de<br />
conceptos (v.g. la función de la papila gustativa en el proceso de la cata, y<br />
la importancia del retrogusto frutal en la apreciación de la variedad de uva<br />
Malvasía), a fin de guiar al alumno en la realización de las distintas<br />
actividades constituyentes.<br />
Referencia a los entornos necesarios para llevar a cabo esta actividad<br />
estructurada. Por ejemplo, es posible referir un entorno con un vídeo o un<br />
texto introductorios o preparatorios de / para la actividad, que puede ser<br />
presentado al usuario antes de que éste aborde la consecución de las<br />
actividades constituyentes.<br />
Referencias a las actividades constituyentes. Nótese que dichas actividades<br />
constituyentes pueden ser actividades de aprendizaje, actividades de<br />
soporte, otras actividades estructuradas, e, incluso, otras unidades de<br />
aprendizaje. De nuevo el uso de referencias permite reutilizar una misma<br />
actividad en múltiples actividades estructuradas.<br />
Metadatos asociados con la actividad.<br />
Figura 2.5.2.g. Estructura de la especificación de una actividad estructurada.<br />
Actividad Estructurada<br />
0..1<br />
0..1<br />
0..∞<br />
0..1<br />
1..∞<br />
Titulo<br />
57<br />
Información<br />
Entorno (referencia)<br />
Actividad de aprendizaje (referencia)<br />
Metadatos<br />
Actividad de soporte (referencia)<br />
Unidad de aprendizaje (referencia)<br />
Actividad estructurada (referencia)
La estructura de los entornos se esboza en la Figura 2.5.2.h. Como evidencia dicha<br />
estructura, un entorno agrupa los recursos <strong>educativo</strong>s necesarios para llevar a cabo<br />
una actividad. IMS LD discrimina entre dos tipos básicos de recursos <strong>educativo</strong>s:<br />
Los objetos de aprendizaje. Recursos reproducibles y referenciables,<br />
normalmente, aunque no necesariamente, digitales, que se utilizan en la<br />
realización de una actividad. En nuestro caso de estudio, los artículos, el<br />
libro o el vídeo son buenos ejemplos de este tipo de objetos. El elemento de<br />
información en sí permitirá referir a tales recursos, que estarán disponibles<br />
en el contexto de uso del diseño <strong>educativo</strong> (v.g. en el paquete IMS utilizado<br />
para representar la unidad de aprendizaje). IMS LD contempla también la<br />
extensión del lenguaje básico con otros sublenguajes que permitan<br />
describir in situ tipos concretos de objetos de aprendizaje (v.g. descripción<br />
de la estructura de un examen utilizando IMS QTI).<br />
Los servicios. Herramientas y programas de soporte a las actividades de<br />
aprendizaje. En nuestro caso, el Chat es un buen ejemplo de servicio.<br />
Figura 2.5.2.h. Estructura de la especificación de los entornos.<br />
Entornos<br />
1..∞<br />
Entorno<br />
0..1<br />
0..1<br />
58<br />
0..∞<br />
Titulo<br />
Objeto de Aprendizaje<br />
Servicio<br />
Entorno (referencia)<br />
Metadatos<br />
El cometido de los elementos de información en la Figura 2.5.2.h es directo:<br />
Un título descriptivo opcional.<br />
Los objetos de aprendizaje y los servicios.<br />
La posibilidad de referir y reutilizar entornos previamente definidos.<br />
Una sección de metadatos.<br />
Merece la pena profundizar un poco más en la diferencia entre objeto de aprendizaje y<br />
servicio. De nuevo podemos apelar aquí a criterios estrictamente formales.<br />
Efectivamente, IMS LD concibe los objetos de aprendizaje como recursos que pueden<br />
reproducirse de forma incontextual, independientemente del contexto particular de<br />
cada ejecución. Por ejemplo, para visualizar una serie de archivos, únicamente es<br />
necesario conocer el formato de dichos archivos y esto puede decidirse en tiempo de
diseño. Por su parte, los servicios requieren información del contexto de ejecución de<br />
la unidad de aprendizaje para su correcta reproducción. Así, el envío de un correo<br />
electrónico a todos los usuarios asignados a un determinado rol depende de los<br />
usuarios concretos asociados con dicho rol y esto no se decide, como ya se ha dicho,<br />
en tiempo de diseño, sino que es una característica que dependerá de la puesta en<br />
marcha y la reproducción de la unidad de aprendizaje. IMS LD contempla la existencia<br />
de distintos tipos de servicios. La Figura 2.5.2.i muestra la estructura de la<br />
especificación de estos servicios en IMS LD.<br />
Figura 2.5.2.i. Estructura de la especificación de los servicios.<br />
Servicio<br />
59<br />
Correo Electrónico<br />
Conferencia<br />
Búsqueda<br />
Otro servicio<br />
Dicha figura incluye la posibilidad de configurar servicios de los siguientes tipos:<br />
Servicio de correo electrónico. Su configuración permite identificar los<br />
destinatarios del e-mail (un grupo de usuarios identificados por uno o varios<br />
roles). Esta descripción se interpretará como una orden para invocar a un<br />
servicio de correo electrónico que, previsiblemente, permitirá editar el<br />
mensaje y dirigirlo a los destinatarios.<br />
Servicio de conferencia. Este servicio permite articular conferencias<br />
virtuales. Su configuración permite fijar los siguientes aspectos de uso del<br />
servicio:<br />
- La lista de participantes. Cada participante se refiere a un rol.<br />
- La lista de observadores (usuarios que observan, pero que no pueden<br />
participar). Cada observador se asocia con un rol.<br />
- El moderador de la conferencia. Una conferencia puede tener más de<br />
un moderador. De hecho, los moderadores se identifican mediante<br />
referencias a roles.<br />
- El administrador de la conferencia. Un administrador de conferencia<br />
puede crear nuevas sub-conferencias (por ejemplo, asignando<br />
dinámicamente subgrupos de usuarios a las mismas), así como destruir<br />
dichas sub-conferencias. No puede, no obstante, destruir la conferencia<br />
base (ésta será liberada automáticamente por el entorno de ejecución).<br />
Servicio de búsqueda. Este servicio permite configurar un buscador que<br />
actúa sobre la información contenida en la unidad de aprendizaje. Para ello<br />
es posible acotar los fragmentos de la unidad de aprendizaje sobre los que
se realizará la búsqueda (es decir, definir los índices de la misma), así<br />
como seleccionar el tipo de búsqueda que se llevará a cabo: por texto libre<br />
o distintos estilos de búsqueda guiada.<br />
Aparte de estos servicios, IMS LD ofrece un mecanismo de extensión que permite la<br />
inclusión de nuevos servicios para cada escenario particular de aplicación. Por<br />
ejemplo, los administradores de la infraestructura e-learning de Corbinus podrían<br />
utilizar este mecanismo para incorporar los servicios de archivística y de publicación<br />
de anuncios utilizados por Corbinus en sus diseños. No obstante, por motivos de<br />
simplicidad no contemplaremos esta posibilidad, tratando como objetos de aprendizaje<br />
todas aquellas herramientas telemáticas no incluidas por defecto como servicios.<br />
2.5.3. Descripción del método <strong>educativo</strong><br />
IMS LD introduce una metáfora basada en una obra de teatro para la descripción de<br />
los métodos <strong>educativo</strong>s. De esta forma, la descripción de uno de estos métodos se<br />
equipara a la descripción de la estructura de una obra que consta de un guión (o<br />
incluso de varios guiones alternativos). El guión se estructura, a su vez, en una<br />
secuencia de actos. Cada acto se caracteriza, por último, por un conjunto de<br />
actuaciones. Cada actuación consiste en la realización de una actividad por parte de<br />
un rol. La dinámica resultante de esta metáfora supone la ejecución simultánea de<br />
todos los guiones, la ejecución en secuencia de cada acto dentro de cada guión y la<br />
ejecución simultánea de todas las actuaciones dentro de cada acto.<br />
Figura 2.5.3.a. Estructura de la especificación de un método.<br />
Metodo<br />
1..∞<br />
0..1<br />
0..1<br />
60<br />
Guión<br />
Condición de finalización<br />
Acción tras finalización<br />
La Figura 2.5.3.a esquematiza la estructura de la descripción de un método. Dicha<br />
descripción se ajusta a la metáfora teatral e incluye:<br />
Uno o más guiones.<br />
Una condición que dicta la finalización de la ejecución del método. Dicha<br />
condición puede ser: (i) la finalización de uno de los guiones o (ii) la<br />
superación de un tiempo límite. Es importante notar que, si esta condición<br />
no se especifica, se asume que el método está finalizado.<br />
Una acción a realizar una vez que dicho método ha finalizado. En el nivel A<br />
dicha acción puede consistir únicamente en proporcionar material de<br />
realimentación al usuario.<br />
La Figura 2.5.3.b muestra la estructura de la descripción de un guión. Dicha estructura<br />
contempla la existencia de:
Un título opcional.<br />
Uno o más actos.<br />
Opcionalmente, una condición de finalización del guión. Dicha condición<br />
puede ser: (i) la finalización del último acto del guión o (ii) la superación de<br />
un tiempo límite. Es importante señalar que si esta condición no se<br />
especifica, se asume que el guión está finalizado.<br />
Opcionalmente, una acción a realizar tras la finalización del guión. En el<br />
nivel A, dicha acción consiste, al igual que en otras situaciones, en<br />
proporcionar realimentación al usuario.<br />
Un cuerpo opcional de metadatos.<br />
Figura 2.5.3.b. Estructura de la especificación de un guión.<br />
Guión<br />
0..1<br />
1..∞<br />
0..1<br />
0..1<br />
0..1<br />
Título<br />
Acto<br />
Condición de finalización<br />
Acción tras finalización<br />
Metadatos<br />
Figura 2.5.3.c. Estructura de la especificación de un acto.<br />
Acto<br />
0..1<br />
1..∞<br />
0..1<br />
0..1<br />
0..1<br />
Título<br />
Actuación<br />
Condición de finalización<br />
Acción tras finalización<br />
Metadatos<br />
La Figura 2.5.3.c muestra la estructura de la descripción de un acto. Dicha descripción<br />
incluye:<br />
Un título opcional.<br />
Una o más actuaciones.<br />
61
Opcionalmente, una condición de finalización. Dicha condición puede ser:<br />
(i) la finalización de una actuación o (ii) la superación de un tiempo límite. Si<br />
esta condición no se especifica, se asume que el acto habrá finalizado.<br />
Opcionalmente, una acción de finalización (a nivel A, mostrar información<br />
de realimentación al usuario).<br />
Figura 2.5.3.d. Estructura de la especificación de una actuación.<br />
Actuación<br />
0..1<br />
0..1<br />
62<br />
Título<br />
rol (referencia)<br />
actividad (referencia)<br />
Metadatos<br />
Por último, la Figura 2.5.3.d muestra cómo se describe una actuación. Básicamente<br />
dicha descripción consiste en referir el rol involucrado, así como la actividad<br />
involucrada. Una restricción importante impuesta por IMS LD es que en un mismo acto<br />
cada rol puede participar, a lo sumo, en una actuación. Las actividades estructuradas<br />
constituyen, de esta forma, un mecanismo fundamental para agrupar actividades más<br />
simples en una única, a fin de que todas ellas puedan ser llevadas a cabo por un rol en<br />
un acto.<br />
2.5.4. Modelo de Ejecución<br />
Una vez introducidos los componentes de modelado, es interesante reflexionar sobre<br />
el modelo de ejecución de los métodos. Un aspecto relevante para entender este<br />
modelo es el aceptar que cada usuario tendrá una vista diferente de la ejecución, que<br />
dependerá del rol al que dicho usuario esté asignado, o, dicho de otra forma, su propia<br />
vista de la obra. Efectivamente:<br />
El usuario verá únicamente aquellas actividades asociadas a las<br />
actuaciones en las que interviene su rol.<br />
Asimismo, las actuaciones serán llevadas a cabo por cada uno de los<br />
miembros de un rol.<br />
La forma de sincronizar las actuaciones de los distintos usuarios es<br />
mediante los actos, ya que es posible hacer depender la finalización de un<br />
acto de la finalización de una actuación. De esta forma, el acto no finalizará<br />
hasta que no finalicen sus actuaciones todos los usuarios que juegan el<br />
papel especificado en la actuación.<br />
Otro aspecto importante a tener en cuenta es el relativo al secuenciamiento de las<br />
actividades en el interior de los actos. Efectivamente, dicho secuenciamiento no se
decide a nivel de acto, sino que debe especificarse a nivel de actividad, mediante la<br />
creación de actividades estructuradas adecuadas.<br />
2.5.5. Ejemplo de Diseño de Nivel A<br />
En este apartado se esboza el diseño <strong>educativo</strong> de la unidad de aprendizaje UACata1,<br />
utilizando para ello características de nivel A de IMS LD. A fin de simplificar el<br />
desarrollo, se omiten muchas de las características opcionales, características que se<br />
podrían incluir en sucesivas revisiones y mejoras del diseño.<br />
Figura 2.5.5.a. Fragmento de diseño con roles.<br />
Roles<br />
..Aprendiz<br />
....Título: Alumno de nueva promoción<br />
..Aprendiz<br />
....Título: Alumno de promociones antiguas<br />
..Plantilla<br />
....Título: Profesor del seminario<br />
El fragmento de diseño esbozado en la Figura 2.5.5.a muestra el diseño de los tres<br />
roles (los dos roles de tipo aprendiz: Alumno de nueva generación y Alumno de<br />
promociones antiguas, y el rol de tipo plantilla: Profesor de Seminario).<br />
El diseño de los entornos para las actividades se muestra en la Figura 2.5.5.b Este<br />
fragmento de diseño esboza los siguientes entornos:<br />
El entorno Artículo Birra, que refiere al artículo del Profesor Birra.<br />
El entorno Artículo Bebo, que hace referencia al artículo de la Profesora<br />
Bebo.<br />
El entorno Vídeo Bacus, que hace referencia al vídeo con la charla del<br />
Profesor Bacus.<br />
El entorno Sitio Web, que hace referencia al sitio web<br />
www.lacatadelvinotinto.org.<br />
El entorno Servicio Debate, que configura un servicio de conferencia a fin<br />
de articular el debate.<br />
El entorno Espacio de Archivos, que hace referencia a una URL que da<br />
paso a un servidor de archivos (se asume que dicha URL está asociada con<br />
el recurso archivos). Se supone que en la página accesible vía esta URL se<br />
pedirá el nombre y la contraseña del usuario concreto. Esto permite<br />
concebir el recurso como un objeto de aprendizaje, en lugar de cómo un<br />
servicio.<br />
El entorno Tablón, que hace referencia a una URL que permite consultar /<br />
editar un tablón de notas (recurso rtablon). Al igual que en el caso anterior,<br />
se supone que en la página correspondiente se pedirán los datos del<br />
usuario, lo que permite usar el recurso como un objeto de aprendizaje en<br />
lugar de como un servicio.<br />
63
Figura 2.5.5.b. Fragmento de diseño con la descripción de los entornos.<br />
Entornos<br />
..Entorno<br />
....Título: Artículo Birra<br />
....Objeto de Aprendizaje: <br />
..Entorno<br />
....Título: Artículo Bebo<br />
....Objeto de Aprendizaje: <br />
..Entorno<br />
....Título: Video Bacus<br />
....Objeto de Aprendizaje: <br />
..Entorno<br />
....Título: Sitio web<br />
....Objeto de Aprendizaje: <br />
..Entorno<br />
....Título: Servicio Debate<br />
....Servicio<br />
......Conferencia: Participantes:<br />
<br />
<br />
Moderador:<br />
<br />
..Entorno:<br />
....Título: Espacio de Archivos<br />
....Objeto de Aprendizaje: <br />
..Entorno:<br />
....Título: Tablón<br />
....Objeto de Aprendizaje: <br />
La Figura 2.5.5.c esquematiza el diseño de las actividades. Nótese que cada actividad<br />
hace referencia a un entorno apropiado, así como a un recurso que la describe (por<br />
simplicidad estos recursos no se listaron en la Figura 2.4.1.b). Más concretamente, se<br />
incluyen las siguientes actividades de aprendizaje:<br />
La actividad Lectura Artículo Birra hace referencia al entorno Artículo Birra.<br />
También hace referencia al recurso rdalectartbirra, que estará asociado con<br />
una descripción de esta actividad.<br />
Las actividades Lectura Artículo Bebo y Visionado Vídeo son análogas. Los<br />
entornos referidos son, respectivamente, Artículo Bebo y Vídeo Bacus,<br />
mientras que los recursos descriptivos referidos son, respectivamente,<br />
rdalectartbebo y rdavisvideo.<br />
Las actividades Examen sitio web, Realización trabajo y Consulta<br />
Resultados, por su parte, refieren a los entornos asociados con los recursos<br />
web externos correspondientes al sitio web (Sitio Web), al punto de entrada<br />
al servidor de archivos (Espacio de Archivos) y al punto de entrada al tablón<br />
de resultados (Tablón). Los recursos descriptivos son, respectivamente,<br />
rdaexweb, rdarealtrabajo y rdaconresultados.<br />
La actividad Debate, que representa el debate mantenido entre alumnos de<br />
nueva promoción y alumnos de promociones antiguas. En la descripción de<br />
64
dicha actividad se refiere al entorno que configura el servicio de conferencia<br />
para llevar a cabo el debate.<br />
La actividad Impartición Clase Presencial. El propósito de esta actividad es<br />
únicamente que, una vez impartida dicha clase, Corbinus pueda indicar la<br />
misma como finalizada, dando lugar a la parte on-line del diseño <strong>educativo</strong>.<br />
Nótese que esta actividad no involucra entorno alguno ya que, desde un<br />
punto de vista meramente operacional, su función es ofrecer únicamente el<br />
botón de arranque del proceso.<br />
65
Figura 2.5.5.c. Fragmento de diseño con la descripción de las actividades.<br />
Actividades<br />
..Actividad de Aprendizaje<br />
....Título: Lectura Artículo Birra<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Lectura Artículo Bebo<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Visionado Video<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Examen sitio web<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Realización Trabajo<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrida una semana<br />
..Actividad de Aprendizaje<br />
....Título: Consulta Resultados<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: finalizada por el usuario<br />
..Actividad de Aprendizaje<br />
....Título: Debate<br />
......Entorno: <br />
......Descripción: <br />
......Condición de finalización: una vez transcurridas dos horas<br />
..Actividad de Aprendizaje<br />
....Título: Impartición Clase Presencial<br />
....Descripción: <br />
....Condición de finalización: finalizada por el usuario<br />
..Actividad de Soporte<br />
....Título: Corrección de Trabajo<br />
....Rol soportado: <br />
....Entorno: <br />
....Entorno: <br />
....Condición de finalización: finalizada por el usuario<br />
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3)<br />
....Título: Examen materiales<br />
....Actividad de aprendizaje (referencia): Lectura Artículo Bebo<br />
....Actividad de aprendizaje (referencia): Lectura Artículo Birra<br />
....Actividad de aprendizaje (referencia): Visionado Video<br />
..Actividad Estructurada (tipo secuencia)<br />
....Título: Autoaprendizaje<br />
....Actividad estructurada (referencia): Examen materiales<br />
....Actividad de aprendizaje (referencia): Examen sitio web<br />
66
Figura 2.5.5.d. Fragmento de diseño con la descripción del método pedagógico.<br />
Método<br />
..Guión<br />
....Acto<br />
......Título: clase presencial<br />
.......Actuación<br />
.........Título: Actuación impartición<br />
.........Rol(referencia): <br />
.........Actividad(referencia): <br />
.......Actuación<br />
.........Título: Actuación asistencia<br />
.........Rol(referencia): <br />
.........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: período autoaprendizaje<br />
......Actuación<br />
........Título: Actuación autoaprendizaje<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: discusión<br />
......Actuación<br />
........Título: Actuación debate alumno nuevo<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Actuación<br />
........Título: Actuación debate alumno antiguo<br />
........Actividad(referencia): <br />
........Rol(referencia): <br />
......Actuación<br />
........Título: Actuación debate profesor<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: trabajo<br />
......Actuación<br />
........Título: Actuación trabajo<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: evaluación<br />
......Actuación<br />
........Título: Actuación evaluación<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: resultados<br />
......Actuación<br />
........Título: Actuación resultados<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Condición de finalización: finalizado último acto<br />
67
El diseño incluye, además, la actividad de soporte Evaluación de Trabajo. El papel<br />
soportado es el de los alumnos de nueva promoción. De esta forma, quien realice esta<br />
actividad deberá notificar, de alguna manera que dependerá del entorno de ejecución,<br />
que cada uno de los alumnos de nueva promoción han sido atendidos antes de que el<br />
entorno de ejecución decida que la actividad ha sido completada. La actividad en sí<br />
requiere tanto el espacio de archivos (donde Corbinus podrá encontrar los trabajos)<br />
como el tablón de anuncios (donde podrá publicar los resultados). Nótese, asimismo,<br />
cómo distintas actividades pueden compartir los mismos entornos.<br />
Para finalizar, se incluyen también las siguientes actividades estructuradas:<br />
Las actividades Lectura Artículo Birra, Visionado Vídeo y Lectura Artículo<br />
Bebo se agrupan en Examen Materiales.<br />
Por su parte, esta actividad se agrega con la actividad Examen sitio web<br />
para dar lugar a la actividad estructurada Autoaprendizaje.<br />
Esta estructuración permite situar todas estas actividades en un único acto en el<br />
método que se esboza en la Figura 2.5.5.d. Los actos incluidos en el método son:<br />
El acto clase presencial, que representa la impartición de la clase<br />
presencial (en realidad, y tal y como se ha indicado, el efecto de este acto<br />
será permitir decidir al profesor cuándo comenzar el proceso de aprendizaje<br />
on-line representado en este diseño).<br />
El acto periodo autoaprendizaje, que representa para el alumno el examen<br />
de todo el material <strong>educativo</strong> proporcionado por el profesor.<br />
El acto discusión, en el que se lleva a cabo el debate entre los alumnos de<br />
nueva promoción y los antiguos alumnos. Nótese que en este acto se<br />
incluye una actuación para cada uno de los roles involucrados, aunque<br />
dichas actuaciones incluyan todas ellas la misma actividad Debate.<br />
El acto trabajo, en el que el alumno realiza el trabajo.<br />
El acto evaluación, en el que el profesor evalúa el trabajo.<br />
El acto resultados, en el que el alumno consulta los resultados<br />
2.6. EL NIVEL B<br />
La ejecución de los diseños de nivel A está predeterminada por la estructura de los<br />
propios diseños y no puede ser alterada como consecuencia de la realización de las<br />
actividades. En muchas situaciones esta dinámica es bastante limitada, ya que no<br />
permite explotar una de las principales ventajas de un escenario e-learning: la<br />
personalización de los contenidos y de los intinerarios <strong>educativo</strong>s a las necesidades de<br />
cada participante en el proceso. Por ejemplo, en base al conocimiento previo del<br />
alumno (que puede venir descrito externamente, en su información curricular o bien<br />
puede determinarse durante el proceso, mediante algún tipo de evaluación previa) es<br />
posible ofrecer material más básico o más avanzado, así como incluir u omitir<br />
actividades. De hecho, en IMS LD nivel A es imposible modelar un escenario<br />
68
<strong>educativo</strong> tradicional típico donde, si un alumno aprueba en Junio, aprueba la<br />
asignatura, y si el alumno suspende, debe ir a Septiembre. En IMS LD este<br />
comportamiento adaptativo de los métodos pedagógicos requiere el uso de facilidades<br />
de nivel B. En esta sección se analizan dichas características. La sección termina<br />
ejemplificando el uso de las mismas mediante el modelado de la unidad de<br />
aprendizaje UACata2, donde los itinerarios de aprendizaje de cada alumno dependen<br />
de su rendimiento en las evaluaciones realizadas y, por tanto, no pueden<br />
predeterminarse completamente en tiempo de diseño.<br />
2.6.1. Propiedades<br />
IMS LD nivel B añade un nuevo tipo de componente <strong>educativo</strong> a los diseños: las<br />
propiedades. Dichas propiedades almacenan información relevante que se produce<br />
durante la ejecución del método <strong>educativo</strong> (v.g. puntuación del alumno en un test), o<br />
bien que se extrae del contexto <strong>educativo</strong> donde dicho método se ejecuta (v.g. lista de<br />
asignaturas que tiene aprobadas el alumno).<br />
Las propiedades constituyen una representación explícita del contexto y estado de los<br />
métodos pedagógicos. Su valor puede modificarse conforme avanza la ejecución para<br />
reflejar dicho estado y puede utilizarse para decidir la forma de llevar a cabo dicha<br />
ejecución. Desde un punto de vista informático, las propiedades son análogas a las<br />
variables en un lenguaje informático de programación convencional.<br />
Figura 2.6.1.a. El nivel B introduce las propiedades como nuevos componentes en<br />
el diseño.<br />
Componentes<br />
1<br />
69<br />
0..1<br />
0..1<br />
0..1<br />
Roles<br />
Propiedades<br />
Actividades<br />
Entornos
Figura 2.6.1.b. Estructura de la especificación de las propiedades.<br />
Propiedad local personal<br />
Propiedad local de rol<br />
Propiedades Propiedad local general<br />
1..∞<br />
70<br />
Propiedad global personal<br />
Propiedad global general<br />
La Figura 2.6.1.a ilustra la extensión de la descripción de los componentes de nivel A<br />
para incorporar la descripción de las propiedades de un diseño. Nótese que dichas<br />
propiedades pasan a ser componentes <strong>educativo</strong>s de pleno derecho, situándose al<br />
mismo nivel que roles, actividades y entornos. La Figura 2.6.1.b muestra, por su parte,<br />
la estructura de la descripción de las propiedades. Este esbozo hace patente la<br />
distinción de propiedades en distintas categorías. Una primera distinción hace<br />
referencia a la localidad o la globalidad de las propiedades:<br />
Las propiedades locales son aquéllas que se crean y se mantienen<br />
únicamente dentro de cada ejecución de la unidad de aprendizaje.<br />
Las propiedades globales son aquellas que se crean y se mantienen en el<br />
entorno en el que se ejecutan las unidades de aprendizaje. El valor de<br />
dichas propiedades sobrevivirá, por tanto, a las distintas ejecuciones y<br />
prevalecerá entre ejecuciones de la misma unidad y/o de unidades<br />
distintas.<br />
Esta categorización puede refinarse como sigue:<br />
Las propiedades locales pueden ser de tres tipos diferentes:<br />
- Propiedades locales personales: Propiedades cuyo valor puede ser<br />
distinto para cada participante (por ejemplo, la nota obtenida en un<br />
test).<br />
- Propiedades locales de rol: Propiedades cuyo valor es el mismo para<br />
todos los miembros de un mismo rol, pero que puede variar entre<br />
distintos roles (por ejemplo, el número de usuarios asignados al rol).<br />
- Propiedad local general: Propiedades cuyo valor es el mismo para<br />
todos los participantes (por ejemplo, el tiempo transcurrido desde que<br />
comenzó a ejecutarse la unidad).<br />
Las propiedades globales pueden ser de los dos tipos siguientes:<br />
- Propiedad global personal: Propiedad global cuyo valor varía para cada<br />
posible usuario (por ejemplo, el nombre de usuario en el sistema
2.6.2. Expresiones<br />
informático en el que está instalada la infraestructura de ejecución de<br />
IMS LD).<br />
- Propiedad global general: Propiedad global cuyo valor es el mismo para<br />
todos los usuarios (por ejemplo, el nombre y la versión del sistema<br />
operativo de la máquina en la que está instalada la infraestructura de<br />
ejecución de IMS LD).<br />
IMS LD nivel B incluye mecanismos para describir expresiones cuya evaluación da<br />
lugar a valores. Ejemplos de este tipo de expresiones son el sumar una serie de<br />
valores, comprobar si todos los valores de una serie son ciertos, comparar dos<br />
valores, etc. Estas expresiones podrán utilizarse en contextos y constructores de más<br />
alto nivel.<br />
IMS LD introduce los formatos de expresiones que se esquematizan en la Figura<br />
2.6.2.a y en la Figura 2.6.2.b. Más concretamente:<br />
Expresión de tipo “es miembro de rol”, que será cierta cuando el usuario<br />
pertenece al rol referido y falsa en otro caso.<br />
Expresión “es”, que permite comprobar si dos valores son iguales. Aparte<br />
de los entes tipificados como expresiones en IMS LD, también es posible<br />
utilizar propiedades y valores literales como argumentos en esta expresión<br />
(lo mismo ocurre con todas aquellas en las que se indica “operando” como<br />
argumentos en la Figura 2.6.2.a; ver también Figura 2.6.2.b).<br />
Expresión “no es”, que permite comprobar si dos valores son distintos.<br />
Expresión “y”, que es cierta cuando lo son todos sus argumentos.<br />
Expresión “o”, que es cierta cuando lo es alguno de sus argumentos.<br />
Expresión “suma”, que suma todos sus argumentos 1 .<br />
Expresión “resta”, que resta a su primer argumento el segundo.<br />
Expresión “mul”, que multiplica el primer argumento por el segundo.<br />
Expresión “div”, que divide el primer argumento entre el segundo.<br />
Expresión “mayor que”, que permite comprobar si el valor del primer<br />
argumento es mayor que el valor del segundo.<br />
Expresión “menor que”, que permite comprobar si el valor del primer<br />
argumento es menor que el valor del segundo.<br />
Expresión “usuarios en rol”, que restringe la aplicabilidad de la expresión a<br />
todos aquellos usuarios que pertenecen al rol indicado.<br />
1 La especificación únicamente permite un número par de argumentos para “suma” (2, 4, 8, etc.<br />
argumentos). Si bien los autores de este informe entienden que ésta es una errata en la<br />
especificación, han preferido constatarla en el informe a fin de ajustarse a la realidad de dicha<br />
especificación.<br />
71
expresión<br />
Expresión “no valor”, que es cierta sobre propiedades que no tienen valor<br />
asignado.<br />
Expresión “inicio unidad”, cuyo valor es el momento en el que comenzó a<br />
ejecutarse la unidad.<br />
Expresión “inicio actividad”, cuyo valor es el momento en el que comenzó a<br />
ejecutarse la actividad actualmente activa.<br />
Expresión “día y hora”, cuyo valor es el día y la hora actual.<br />
Expresión “finalizado”, que permite comprobar si un determinado<br />
componente (actividad, actuación, acto o guión) ha finalizado.<br />
Expresión “no”, que permite comprobar el incumplimiento de un<br />
determinado aserto.<br />
es<br />
es miembro de rol (referencia)<br />
no es<br />
y<br />
o<br />
suma<br />
resta<br />
mul<br />
div<br />
operando<br />
2..∞<br />
operando<br />
operando<br />
operando<br />
expresión<br />
expresión<br />
2..∞ operando<br />
mayor que<br />
1.∞<br />
operando<br />
operando<br />
operando<br />
operando<br />
operando<br />
operando<br />
usuarios en rol<br />
operando<br />
operando<br />
Figura 2.6.2.a. Expresiones.<br />
operando<br />
rol (referencia)<br />
expresión<br />
no valor propiedad (referencia)<br />
72<br />
inicio unidad<br />
inicio actividad<br />
día y hora<br />
finalizado<br />
no<br />
expresión<br />
actividad (referencia)<br />
unidad de aprendizaje (referencia)<br />
actuación (referencia)<br />
acto (referencia)<br />
guión (referencia)
2.6.3. Acciones<br />
operando<br />
Figura 2.6.2.b. Operandos.<br />
expresión<br />
propiedad (referencia)<br />
valor<br />
IMS LD nivel B también incluye mecanismos para expresar acciones que, al igual que<br />
la expresiones, podrán utilizarse en contextos de más alto nivel. La Figura 2.6.3.a<br />
esquematiza las posibles acciones expresables en IMS. Dichas acciones son:<br />
Mostrar algún componente <strong>educativo</strong> o recurso. Efectivamente,<br />
componentes como las actividades, los entornos de las actividades, etc.<br />
pueden ser o no ser visibles, estado que puede alterarse en IMS LD nivel B.<br />
Más concretamente y tal y como se sugiere en la Figura 2.6.3.a, es posible<br />
mostrar (hacer visibles):<br />
- Todos los recursos o entornos de una determinada clase.<br />
Efectivamente, los recursos de una actividad de aprendizaje, así como<br />
los entornos, pueden clasificarse semánticamente en clases. La acción<br />
mostrar puede actuar globalmente sobre todos los elementos así<br />
clasificados.<br />
- Un recurso concreto.<br />
- Un entorno concreto.<br />
- Una actividad concreta.<br />
- Un guión.<br />
- Toda una unidad de aprendizaje.<br />
Ocultar algún componente <strong>educativo</strong> o recurso. Los tipos de elementos que<br />
pueden ocultarse son los mismos que los que pueden mostrarse.<br />
Cambiar el valor de una propiedad. Nótese que el nuevo valor puede ser,<br />
bien un literal, bien el valor de otra propiedad, bien venir dado por una<br />
expresión.<br />
73
acción<br />
2.6.4. Condiciones<br />
Mostrar<br />
Ocultar<br />
Figura 2.6.3.a. Acciones.<br />
clase<br />
Cambiar valor de propiedad<br />
recurso (referencia)<br />
entorno (referencia)<br />
actividad (referencia)<br />
guión (referencia)<br />
unidad (referencia)<br />
74<br />
operando<br />
Propiedad (referencia)<br />
La introducción de propiedades tiene una repercusión importante a nivel de método.<br />
Efectivamente, IMS LD nivel B incluye un nuevo elemento descriptivo en los métodos<br />
<strong>educativo</strong>s: las condiciones. Dichas condiciones son reglas que, en función del<br />
cumplimiento de una determinada guarda (un aserto o condición sobre el estado de<br />
ejecución), permiten actualizar los valores de las propiedades. Las condiciones en sí<br />
se plasman en reglas tipo si entonces en otro caso<br />
, con el significado: si es cierta, realiza las acciones indicadas<br />
en y, si no, realiza las acciones indicadas en . Evaluar<br />
una condición supone, por tanto, evaluar su guarda y, dependiendo de si dicha guarda<br />
es cierta o falsa, ejecutar la acción correspondiente. Dado que la parte else es<br />
opcional, la evaluación de condiciones sin parte else no tendrá efecto cuando la<br />
guarda sea falsa.<br />
Es importante notar que el modelo de ejecución de estas reglas es reactivo u<br />
oportunista (al contrario del modelo de ejecución secuencial típico en lenguajes<br />
informáticos de programación más usuales). Efectivamente, las condiciones se<br />
evalúan:<br />
Al comienzo de la ejecución de la unidad.<br />
Siempre y cuando el valor de una propiedad haya cambiado.
Asimismo, dado que las acciones de las reglas pueden modificar valores de<br />
propiedades que, a su vez, afectan a las guardas de otras reglas, en general la<br />
ejecución de las reglas se encadenará, como sucede con los sistemas basados en<br />
reglas clásicos (Li, 1991) utilizados en campos específicos de la informática como, por<br />
ejemplo, la Inteligencia Artificial.<br />
La Figura 2.6.4.a esquematiza la extensión de la descripción de los métodos con la<br />
incorporación de las condiciones a nivel B. Nótese que puede haber varios conjuntos<br />
de condiciones, cada uno de los cuáles podrá incluir varias condiciones. La estructura<br />
de estos conjuntos de condiciones se especifica en la Figura 2.6.4.b.<br />
Figura 2.6.4.a. Extensión de la estructura para los métodos con condiciones.<br />
Metodo<br />
1..∞<br />
0..1<br />
0..1<br />
0..∞<br />
75<br />
Guión<br />
Condición de finalización<br />
Acción tras finalización<br />
Condiciones<br />
Figura 2.6.4.b. Estructura de la especificación de las condiciones.<br />
Condiciones<br />
0..1<br />
1..∞<br />
0..1<br />
Título<br />
Metadatos<br />
La descripción de tales conjuntos incluye:<br />
Un título opcional.<br />
0..1<br />
si<br />
entonces<br />
expresión<br />
en otro caso<br />
acción<br />
acción<br />
La secuencia de las condiciones en sí. Nótese que la parte en otro caso en<br />
cada condición es opcional. Obsérvese también que la estructura de la<br />
parte si se corresponderá con una expresión, mientras que las de las partes<br />
entonces y en otro caso se corresponderán con una acción.<br />
Un cuerpo de metadatos opcional.
2.6.5. Extensión de las condiciones de finalización de actividades, actos,<br />
guiones y métodos<br />
IMS LD nivel B extiende también las condiciones de finalización de actividades, actos,<br />
guiones y métodos, permitiendo que dicha finalización dependa de la asignación de<br />
cierto valor a cierta propiedad. Más concretamente, las condiciones de finalización<br />
pueden también tomar en el nivel B, el formato descrito en la Figura 2.6.5.a. La<br />
condición se hará cierta cuando la propiedad se actualice y, en caso de que se<br />
especifique valor adicional, cuando el valor de actualización coincida con el<br />
especificado.<br />
Figura 2.6.5.a. Extensión de las condiciones de finalización en IMS LD nivel B.<br />
Condición de finalización<br />
Propiedad actualizada<br />
76<br />
0..1<br />
Propiedad (referencia)<br />
operando<br />
2.6.6. Extensión de las acciones tras la finalización para actividades,<br />
actos, guiones y métodos<br />
En IMS LD nivel B la finalización de una actividad, acto, guión o método puede<br />
desencadenar la asignación de un valor a una propiedad, tal y como se sugiere en el<br />
esquema mostrado en la Figura 2.6.6.a. En conjunción con el condicionamiento de la<br />
terminación de elementos en términos de valores de propiedades, esta extensión<br />
permite llevar a cabo un secuenciamiento de actividades mucho más complejo, que<br />
depende de la forma en la que se ejecuta la unidad de aprendizaje, así como del<br />
contexto inicial de ejecución de la misma.<br />
Figura 2.6.6.a. Extensión de las acciones tras la finalización en IMS LD nivel B.<br />
Acción tras la finalización<br />
2.6.7. Elementos globales y monitores<br />
Cambiar valor de propiedad<br />
IMS LD nivel B contempla también la posibilidad de que durante la realización de una<br />
actividad se modifiquen los valores de las propiedades de la unidad. Dado que IMS LD<br />
no norma la forma concreta en la que se ejecutan las actividades elementales, sino<br />
únicamente cómo se integran éstas en el diseño <strong>educativo</strong>, dichas modificaciones
exceden el alcance de la especificación. No obstante, la especificación introduce<br />
artefactos descriptivos estándar que pueden utilizarse para declarar en la descripción<br />
de un determinado tipo de contenidos que dichos contenidos van a consultar y/o<br />
modificar propiedades de la unidad de aprendizaje. Dichos artefactos se denominan<br />
elementos globales.<br />
De igual manera, a nivel B se introduce un nuevo tipo de servicio (servicio de<br />
monitorización), que permite consultar y/o modificar los valores de las propiedades de<br />
la unidad de aprendizaje.<br />
2.6.8. Modelo de Ejecución<br />
El nivel B permite modular el modelo de ejecución por defecto introducido a nivel A.<br />
Efectivamente:<br />
Las actividades pueden ser visibles o no visibles (este criterio de visibilidad<br />
también se aplica a nivel A, aunque es a nivel B donde realmente adquiere<br />
sentido).<br />
Esta condición de visibilidad / invisibilidad puede alterarse mediante la<br />
ejecución de las condiciones, las cuales, como ya se ha indicado<br />
anteriormente, se consideran al comienzo de la ejecución, así como cada<br />
vez que cambia el valor de una propiedad. Dichas propiedades engloban<br />
tanto las definidas en la unidad de aprendizaje como aquellas cuyo valor se<br />
establece de manera automática (v.g. el estado de visibilidad o invisibilidad<br />
de las actividades).<br />
Es importante, no obstante, considerar también la interacción de este modelo de<br />
ejecución con algunas características de nivel A. En particular, la especificación<br />
establece que todas las actividades que forman parte de una actividad estructurada de<br />
tipo secuencia visible son visibles, independientemente de que éstas se hayan<br />
marcado como no visibles en su descripción, e independientemente de las<br />
condiciones. Dicho de otro modo, la visibilidad de las actividades que, en un acto, se<br />
ejecutan en secuencia viene predeterminada y no puede alterarse.<br />
2.6.9. Ejemplo de diseño de nivel B<br />
En este apartado se esboza el diseño <strong>educativo</strong> de la unidad de aprendizaje<br />
UACata2, utilizando para ello características de nivel B de IMS LD. Como en el<br />
esbozo del diseño para UACata1 y con el fin de simplificar el desarrollo se omiten<br />
muchas de las características opcionales. De este modo y dado que esta unidad es,<br />
en realidad, una extensión de UACata1, únicamente se describirán los nuevos<br />
elementos que deben añadirse así como aquellos que han de modificarse.<br />
La descripción del diseño introduce las siguientes propiedades:<br />
Propiedad nota en el test. Esta propiedad contendrá la puntuación obtenida<br />
por los alumnos en el test previo realizado.<br />
77
Propiedad nota en el trabajo. Esta propiedad contendrá la puntuación<br />
obtenida por cada alumno en el trabajo.<br />
Propiedad recuperación finalizada. Esta propiedad se actualizará a cierto<br />
cuando se haya finalizado la recuperación.<br />
Propiedad asignatura superada. Esta propiedad se actualizará a cierto<br />
cuando se haya superado la asignatura.<br />
Estas propiedades son ambas de tipo locales personales, ya que cada alumno tendrá<br />
las suyas propias, almacenando sus calificaciones y controlando la finalización de la<br />
recuperación. La Figura 2.6.9.a esboza su descripción:<br />
Figura 2.6.9.a. Fragmento de diseño con la descripción de las propiedades.<br />
Propiedades<br />
..Propiedad local personal: nota en el test<br />
..Propiedad local personal: nota en el trabajo<br />
..Propiedad local personal: recuperación finalizada<br />
..Propiedad local personal: asignatura superada<br />
Tal y como se muestra en la Figura 2.6.9.b, será necesario añadir los siguentes<br />
entornos a los ya existentes:<br />
Entorno test, que hará referencia a un sitio web que aloja una herramienta<br />
de realización de tests. En este sitio web, los alumnos podrán identificarse y<br />
realizar los tests asignados.<br />
Entorno libro Corbinus, que hará referencia al libro de Corbinus en formato<br />
electrónico.<br />
Figura 2.6.9.b. Nuevos entornos que aparecen en el diseño de UACata2.<br />
..Entorno<br />
....Título: Test<br />
....Objeto de Aprendizaje: <br />
..Entorno<br />
....Título: Libro Corbinus<br />
....Objeto de Aprendizaje: <br />
La Figura 2.6.9.c muestra las nuevas actividades que aparecen en este diseño. Se<br />
incluyen las siguientes actividades de aprendizaje y de soporte:<br />
Actividad de aprendizaje Realización Test, orientada a la resolución del test<br />
previo.<br />
Actividad de soporte Evaluación Test, orientada a la corrección del test<br />
previo.<br />
78
Actividad de aprendizaje Lectura libro Corbinus, en la que los alumnos que<br />
han obtenido peores notas en el test refuerzan sus conocimientos mediante<br />
la lectura del libro de Corbinus.<br />
Actividades de aprendizaje Repaso libro Corbinus, Repaso Artículo Birra,<br />
Repaso Sitio Web, orientadas al repaso de los distintos materiales<br />
propuestos en el curso.<br />
Actividad de aprendizaje Revisión y Mejora del Trabajo, en la que los<br />
alumnos podrán mejorar y corregir los defectos detectados en sus trabajos.<br />
Actividad de soporte Re-evaluación del Trabajo, en la que el profesor<br />
corregirá los trabajos revisados.<br />
Actividad de aprendizaje Consulta Resultados Repesca, en la que los<br />
alumnos podrán consultar los resultados definitivos de sus trabajos. Nótese<br />
que dicha actividad actualiza la propiedad recuperación finalizada tras su<br />
finalización.<br />
79
Figura 2.6.9.c. Nuevas actividades de soporte y de aprendizaje que aparecen en<br />
UACata2.<br />
..Actividad de Aprendizaje<br />
....Título: Realización test<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrida 1 hora<br />
..Actividad de Soporte<br />
....Título: Evaluación test<br />
....Rol soportado: <br />
....Entorno: <br />
....Condición de finalización: finalizada por el usuario<br />
..Actividad de Aprendizaje<br />
....Título: Lectura libro Corbinus<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Repaso libro Corbinus<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Repaso Artículo Birra<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Repaso sitio web<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrido un día<br />
..Actividad de Aprendizaje<br />
....Título: Revisión y mejora del trabajo<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: una vez transcurrida una semana<br />
..Actividad de Soporte<br />
....Título: Re-evaluación del Trabajo<br />
....Rol soportado: <br />
....Entorno: <br />
....Entorno: <br />
....Condición de finalización: finalizada por el usuario<br />
..Actividad de Aprendizaje<br />
....Título: Consulta Resultados Repesca<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: finalizada por el usuario<br />
....Acción tras finalización<br />
......Cambiar valor de propiedad<br />
........Propiedad(referencia): <br />
........valor: Cierto<br />
80
Además, tal y como muestra la Figura 2.6.9.d, se incluyen las siguientes actividades<br />
estructuradas:<br />
Autoaprendizaje con repaso que incluye la lectura del libro de Corbinus<br />
como paso previo al autoaprendizaje.<br />
Autoaprendizajes, actividad tipo selección que engloba los dos métodos de<br />
autoaprendizaje contemplados. Obsérvese que, para completar esta<br />
actividad, bastará con elegir una de las que engloba. En realidad, en el<br />
método de aprendizaje se incluirán condiciones que asegurarán que<br />
únicamente una de éstas sea visible, dependiendo de la nota obtenida en el<br />
test.<br />
Realización Repaso, que engloba las tres actividades básicas de repaso<br />
contempladas.<br />
Figura 2.6.9.d. Nuevas actividades estructuradas que aparecen en UACata2.<br />
..Actividad Estructurada (tipo secuencia)<br />
....Título: Autoaprendizaje con repaso<br />
....Actividad de aprendizaje (referencia): Lectura Libro Corbinus<br />
....Actividad estructurada (referencia): Autoaprendizaje<br />
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=1)<br />
....Título: Autoaprendizajes<br />
....Actividad estructurada (referencia): Autoaprendizaje con repaso<br />
....Actividad estructurada (referencia): Autoaprendizaje<br />
..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3)<br />
....Título: Realización Repaso<br />
....Actividad de aprendizaje (referencia): Repaso Libro Corbinus<br />
....Actividad de aprendizaje (referencia): Repaso Artículo Birra<br />
....Actividad de aprendizaje (referencia): Repaso Sitio Web<br />
La Figura 2.6.9.e esquematiza cómo se modifican los actos del método de UACata1<br />
en el contexto del nuevo diseño:<br />
Se añaden nuevos actos orientados a la realización y corrección del test<br />
(test previo y corrección test previo).<br />
81
Figura 2.6.9.e. Modificación y extensión de los actos.<br />
........................<br />
....Acto<br />
......Título: test previo<br />
......Actuación<br />
........Título: Actuación test previo<br />
........Rol(referencia): <br />
........Actividad(referencia): Realización de test<br />
......Condición de finalización: <br />
....Acto<br />
......Título: corrección test previo<br />
......Actuación<br />
........Título: Actuación corrección test previo<br />
........Rol(referencia): <br />
........Actividad(referencia): Corrección de test<br />
......Condición de finalización: <br />
....Acto<br />
......Título: período autoaprendizaje<br />
......Actuación<br />
........Título: Actuación autoaprendizaje<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
........................<br />
....Acto<br />
......Título: repaso<br />
......Actuación<br />
........Título: Actuación repaso<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: revisión<br />
......Actuación<br />
........Título: Actuación revisión<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: re-evaluación<br />
......Actuación<br />
........Título: Actuación re-evaluación<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
....Acto<br />
......Título: resultados2<br />
......Actuación<br />
........Título: Actuación resultados2<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
En este diseño es necesario, además, adaptar la ejecución dependiendo de los<br />
valores de las notas del test y del trabajo. Dicha adaptación se logra como sigue:<br />
82
Se incluyen condiciones que permiten adaptar el proceso de aprendizaje<br />
dependiendo de los resultados obtenidos en el test y en el trabajo (Figura<br />
2.6.9.f). La primera de dichas condiciones comprueba el resultado del test.<br />
Si éste es menor que 5 oculta la actividad Autoaprendizaje. En otro caso<br />
(es igual o supera el 5), oculta la actividad Autoaprendizaje con repaso.<br />
Como aspecto sutil cabe destacar que, aunque cuando la nota es menor<br />
que 5 se oculta la actividad Autoaprendizaje, dicha actividad estructurada<br />
se hará visible una vez alcanzada la actividad Autoaprendizaje con repaso,<br />
ya que dicha actividad es una actividad de tipo secuencia y, por tanto, hace<br />
visibles a todas las actividades secuenciadas independientemente del<br />
efecto de las condiciones. La segunda de las condiciones determina la<br />
finalización de la asignatura. Para ello debe haberse superado el trabajo o<br />
bien debe haberse terminado la recuperación.<br />
Se modifica la finalización del guión para que ésta dependa de que la<br />
asignatura haya finalizado (Figura 2.6.9.g).<br />
Figura 2.6.9.f. Condiciones para la adaptación del estilo de aprendizaje.<br />
..Condiciones<br />
.....si<br />
.......menor<br />
............propiedad(referencia): <br />
............valor: 5<br />
........entonces<br />
............ocultar: <br />
........en otro caso<br />
............ocultar: <br />
.....si<br />
........o<br />
..........o<br />
............mayor<br />
..............propiedad(referencia): <br />
..............valor: 5<br />
............es<br />
..............propiedad(referencia): <br />
..............valor: 5<br />
........ es<br />
...............propiedad(referencia): <br />
................valor: Cierto<br />
.....entonces<br />
...........fijar asignatura superada a cierto<br />
Método<br />
..Guión<br />
Figura 2.6.9.g. Condición de finalización del guión.<br />
........................<br />
....Condición de finalización<br />
......fijada propiedad asignatura superada a cierto<br />
Nótese que en este método no se especifica en ningún lugar dónde se actualizan las<br />
propiedades nota en el test y nota en el trabajo. Dicha actualización dependerá del<br />
entorno de ejecución del diseño. Por ejemplo, el reproductor podrá ofrecer a usuarios<br />
83
con suficiente privilegio la posibilidad de modificar los valores de las propiedades de<br />
otros usuarios. De esta forma, el profesor podrá fijar las notas de cada uno de sus<br />
alumnos durante las respectivas actividades de soporte. Del mismo modo,<br />
dependiendo del grado de integración de los materiales con el entorno de ejecución, la<br />
actualización de algunas propiedades podría llevarse a cabo automáticamente (v.g.<br />
como resultado de la corrección automática del test: en este caso, la actividad de<br />
soporte Corrección del test no sería necesaria).<br />
2.7. EL NIVEL C<br />
El nivel C añade un mecanismo que permite el envío de mensajes y la configuración<br />
de actividades dependiendo de la ocurrencia de determinados eventos. Dicho<br />
mecanismo está soportado por notificaciones e introduce un paradigma de ejecución<br />
guiado por eventos en IMS LD. Utilizando este mecanismo es posible, por ejemplo,<br />
hacer que se envíe un mensaje al profesor cada vez que un alumno concreto termine<br />
de realizar un trabajo.<br />
2.7.1. Notificaciones<br />
La Figura 2.7.1.a esquematiza la estructura de la descripción de una notificación.<br />
Figura 2.7.1.a. Estructura de la especificación de las notificaciones.<br />
Notificación<br />
De esta forma, la notificación incluye:<br />
0..1<br />
0..1<br />
84<br />
Dirigida a<br />
Actividad (referencia)<br />
Asunto<br />
Una identificación del o los destinatarios a los que se dirige la notificación.<br />
Dicha identificación pueden realizarse: (1) indicando un rol, de tal forma que<br />
la identificación se dirigirá a todos los usuarios de dicho rol, (2) una<br />
referencia a una propiedad que contiene el e-mail del usuario concreto al<br />
que se dirige la notificación y, opcionalmente, una propiedad que contiene<br />
el nombre de dicho usuario.<br />
Opcionalmente, una referencia a una actividad simple (de aprendizaje o de<br />
soporte). En el contenido de la notificación se incluirá un enlace a dicha<br />
actividad, que pasará a ser visible si no lo era ya.<br />
Opcionalmente, un campo de asunto con la descripción de la notificación.
2.7.2. Extensiones en IMS LD nivel C<br />
La inclusión de notificaciones afecta a:<br />
Las acciones de finalización de actividades, actos, guiones y unidades, que<br />
pueden incluir ahora múltiples notificaciones.<br />
La parte de acción de las condiciones, que pueden incluir también<br />
notificaciones.<br />
Los elementos globales, que pueden lanzar también notificaciones.<br />
2.7.3. Ejemplo de diseño de nivel C<br />
En este apartado se utilizará el mecanismo de notificaciones para mejorar el diseño de<br />
la unidad de aprendizaje UACata2. El objetivo es que cada vez que un alumno<br />
termine el trabajo, se envíe a Corbinus una notificación a fin de que pueda corregirlo.<br />
El diseño resultante se integrará en la unidad de aprendizaje UACata3.<br />
Para obtener el diseño <strong>educativo</strong> de UACata3, el primer paso es modificar ligeramente<br />
el método de UACata2 para que las actividades Evaluación del trabajo y Revaluación<br />
del trabajo se realicen en los mismos actos que las actividades Realización del trabajo<br />
y Revisión y mejora del trabajo (en otro caso, el comienzo de las mismas dependería<br />
de la finalización de las actividades de realización y revisión de trabajos por parte de<br />
todos los alumnos). La Figura 2.7.3.a esboza la modificación.<br />
85
Figura 2.7.3.a. En UACata3 el acto trabajo puede fundirse con el acto corrección, y<br />
el acto revisión con revaluación.<br />
........................<br />
....Acto<br />
......Título: trabajo y corrección<br />
......Actuación<br />
........Título: Actuación trabajo<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Actuación<br />
........Título: Actuación corrección<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
........................<br />
....Acto<br />
......Título: revisión y re-evaluación<br />
......Actuación<br />
........Título: Actuación revisión<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Actuación<br />
........Título: Actuación re-evaluación<br />
........Rol(referencia): <br />
........Actividad(referencia): <br />
......Condición de finalización: <br />
El segundo paso consiste, simplemente, en incluir notificaciones en las acciones de<br />
finalización de las actividades Realización del trabajo y Revisión y mejora del trabajo<br />
(también es necesario dejar que sea el alumno el que decida la terminación de estas<br />
actividades). Dichas notificaciones irán dirigidas a los miembros del rol profesor del<br />
seminario y portarán un enlace a la correspondiente actividad de corrección. La Figura<br />
2.7.3.b esboza estas extensiones.<br />
86
Figura 2.7.3.b. Modificaciones de las actividades Realización del Trabajo y Revisión<br />
y Mejora del Trabajo para permitir que se notifique al profesor del seminario cada vez<br />
que se finalicen dichas actividades.<br />
........................<br />
..Actividad de Aprendizaje<br />
....Título: Realización Trabajo<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: decidida por el usuario<br />
.... Acción de finalización<br />
......Notificación<br />
........dirigida a: rol <br />
........actividad (referencia): <br />
........................<br />
..Actividad de Aprendizaje<br />
....Título: Revisión y mejora del trabajo<br />
....Entorno: <br />
....Descripción: <br />
....Condición de finalización: decidida por el usuario<br />
.... Acción de finalización<br />
......Notificación<br />
........dirigida a: rol <br />
........actividad (referencia): <br />
2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS<br />
IMS LD utiliza XML para definir un lenguaje de marcado específico que permite<br />
describir los diseños <strong>educativo</strong>s. De esta forma, las estructuras descritas<br />
informalmente en las secciones anteriores tienen una representación formalizada en<br />
XML, representación que puede ser procesada automáticamente por las herramientas<br />
de edición y reproducción de diseños <strong>educativo</strong>s. En este apartado se describen los<br />
distintos tipos de elementos (las etiquetas) introducidos por dicho lenguaje y se<br />
ejemplifica su uso con el caso de estudio.<br />
2.8.1. Codificación de la Estructura de Alto nivel del Diseño<br />
La descripción del diseño se encierra en un elemento learning-design. Dicho<br />
elemento tiene los siguientes atributos:<br />
identifier. Atributo obligatorio que identifica unívocamente el elemento<br />
en el contexto del manifiesto de la unidad de aprendizaje.<br />
version. Atributo opcional que indica el número de versión de IMS LD.<br />
uri. Atributo obligatorio que asocia una URI al diseño (un identificador<br />
globalmente único).<br />
87
level. Atributo opcional que indica el nivel de IMS LD utilizado en el<br />
diseño (su valor puede ser A, B, C, a, b, c).<br />
sequence-used. Atributo obligatorio que, en caso de ser true, permite<br />
utilizar IMS Simple Sequencing (IMS SS, 2003) como mecanismo de<br />
secuenciamiento en lugar de IMS LD.<br />
El título del diseño se encierra en un elemento title. Los objetivos de aprendizaje se<br />
encierran en un elemento learning-objectives. Los prerrequisitos se encierran<br />
en un elemento prerequisites. El contenido de estos dos elementos, que identifica<br />
un recurso que describe los objetivos y prerrequisitos, se describe mediante los<br />
siguientes elementos:<br />
title. Elemento opcional, que encierra un título descriptivo.<br />
Una o más ocurrencias de item. Elemento que, a su vez, sigue el formato<br />
especificado en IMS CP, y que permite referir a un recurso descriptivo del<br />
objetivo o del prerrequisito (IMS CP, 2004).<br />
metadata. Elemento de metadatos opcional.<br />
Los componentes se describen mediante un elemento components. El método se<br />
describe mediante un elemento method. Los metadatos se encierran en un elemento<br />
metadata.<br />
La Figura 2.8.1.a esboza la codificación XML de la estructura de alto nivel del diseño<br />
para UACata1. Los identificadores han sido creados automáticamente utilizando una<br />
herramienta de autoría como las que se describirán en el capítulo dedicado a<br />
herramientas. Se ha añadido tambien una sección de objetivos de aprendizaje y de<br />
prerrequisitos para que se aprecie su codificación. Obsérvese que en el paquete IMS<br />
deberá haber sendos recursos identificados mediante robjetivoscurso y<br />
rprerequisitoscurso.<br />
88
Figura 2.8.1.a. Codificación XML de la estructura de alto nivel del diseño de<br />
UACata1.<br />
<br />
Seminario de introducción a la cata<br />
<br />
Objetivos del curso<br />
<br />
<br />
<br />
Prerequisitos del curso<br />
<br />
<br />
<br />
...<br />
<br />
<br />
...<br />
<br />
<br />
2.8.2. Codificación de los roles<br />
La descripción de los roles se delimita con un elemento roles. Dicho elemento<br />
contempla los siguientes atributos:<br />
identifier. Atributo obligatorio que identifica unívocamente el rol.<br />
En el interior de este elemento, los roles de tipo aprendiz se marcan con el elemento<br />
learner, mientras que los de tipo plantilla se marcan con staff. Ambos elementos<br />
contemplan los siguientes atributos:<br />
create-new. Atributo obligatorio que indica si es o no posible asociar<br />
múltiples usuarios con este rol cuando se ejecuta la unidad de aprendizaje.<br />
Si el valor es not-allowed, únicamente se permitirá asociar un actor con<br />
dicho rol. Si no, es posible asociar varios.<br />
href. Atributo opcional que asocia una URI con el rol, que permite<br />
identificar el rol como uno global definido a nivel institucional (v.g. un rol<br />
definido en un instituto).<br />
identifier. Atributo obligatorio que identifica unívocamente al rol en el<br />
manifiesto.<br />
match-persons. Atributo opcional que, en caso de existir varios subroles,<br />
permite decidir si el mismo usuario deberá asociarse de forma exclusiva a<br />
89
uno de los subroles (valor exclusively-in-roles) o bien si puede<br />
asociarse de manera no exclusiva a los distintos subroles (valor notexclusively).<br />
min-persons.Atributo opcional que indica el mínimo número de<br />
integrantes del rol. Si no está presente, se supone que el mínimo número<br />
de integrantes es 0.<br />
max-persons. Atributo opcional que indica el máximo número de<br />
integrantes del rol. Si no está presente, se supone que el máximo número<br />
de integrantes no está limitado.<br />
El contenido de estos elementos contiene un elemento title opcional (con el título<br />
del rol), un elemento information opcional (que hace referencia a recursos que<br />
detallan el rol, mediante elementos title, item y metadata, al estilo de<br />
learning-objectives y prerequisites), una secuencia de 0 o más elementos<br />
describiendo los subroles (de nuevo con learner o staff, dependiendo del tipo de<br />
rol) y un elemento opcional metadata.<br />
La Figura 2.8.2.a esboza la codificación XML de los roles para las unidades de<br />
aprendizaje de nuestro caso de estudio. Los identificadores también se han generado<br />
automáticamente con una herramienta de autor y se asume, además, que en el<br />
paquete IMS deberá haber recursos identificados con<br />
rrolAlumnoNuevaPromocion, rrolAlumnoPromocionesAntiguas y<br />
rrolProfesorDeSeminario.<br />
90
Figura 2.8.2.a. Codificación XML de los roles en las unidades de aprendizaje del<br />
caso de estudio.<br />
<br />
<br />
Alumno de nueva promoción<br />
<br />
<br />
<br />
<br />
<br />
Alumno de promociones antiguas<br />
<br />
<br />
<br />
<br />
<br />
Profesor de seminario<br />
<br />
<br />
<br />
<br />
<br />
2.8.3. Codificación de las actividades<br />
La descripción de las actividades se delimita con un elemento activities. Dentro de<br />
dicho elemento, cada actividad de aprendizaje se delimita mediante un elemento<br />
learning-activity, cada actividad de soporte mediante support-activity y<br />
cada actividad estructurada mediante activity-structure.<br />
Los elementos learning-activity contemplan los siguientes atributos:<br />
identifier. Atributo obligatorio que identifica unívocamente al elemento<br />
en el manifiesto.<br />
isvisible. Atributo obligatorio que permite controlar la visibilidad inicial<br />
de la actividad (si vale true la actividad será visible, si vale false será<br />
invisible).<br />
parameters. Atributo opcional que permite especificar una lista de<br />
parámetros, en caso de que dicha lista se precise para lanzar la actividad.<br />
Asimismo, en la descripción el título se encierra en un elemento title, los objetivos<br />
de aprendizaje en un elemento learning-objectives, los prerrequisitos en un<br />
elemento prerrequisites, los entornos se referencian mediante elementos<br />
91
environment-ref (estos elementos tienen un atributo ref que permite referir al<br />
entorno por su identificador único), la descripción de la actividad mediante un elemento<br />
activity-description (utilizando los ya familiares elementos title, item y<br />
metadata), la condición de finalización con un elemento complete-activity, la<br />
acción de finalización con un elemento on-completion y los metadatos asociados<br />
con un elemento metadata.<br />
Los elementos complete-activity pueden, a su vez, encerrar un elemento vacío<br />
user-choice (que indica que la finalización es decisión del usuario), un elemento<br />
time-limit (que indica la duración de la actividad de forma relativa al comienzo de<br />
la ejecución de la actividad, bien directamente, como contenido del elemento, bien<br />
haciendo referencia a una propiedad local que debe contener dicho valor, a través del<br />
atributo property-ref), o, a nivel B, un elemento when-property-value-is-set<br />
(que supedita la finalización a que una propiedad alcance un valor dado). El contenido<br />
de este último elemento se describirá mediante un elemento property-ref (este<br />
elemento tiene un atributo ref que refiere la propiedad por su nombre), así como<br />
mediante un elemento property-value, que indicará el valor que debe alcanzar la<br />
propiedad para que se cumpla la condición de finalización. Dicho valor puede indicarse<br />
de manera literal (delimitado el valor literal con un elemento langstring), mediante<br />
una expresión delimitada con calculate, o como el valor de otra propiedad, referida<br />
mediante otro elemento property-ref.<br />
Figura 2.8.3.a. Codificación XML de la actividad de aprendizaje Lectura Artículo<br />
Birra.<br />
<br />
Lectura Articulo Birra<br />
<br />
<br />
Descripcion<br />
<br />
<br />
<br />
P1D <br />
<br />
<br />
Por su parte, los elementos on-completion pueden encerrar un elemento<br />
feedback-description (proporciona realimentación al usuario, realimentación que<br />
se describe mediante la típica secuencia de elementos title, item y metadata). A<br />
nivel B, también puede encerrar la descripción del cambio de valor de una propiedad<br />
mediante un elemento change-property-value. El contenido de<br />
change-property-value es análogo al de property-value, aunque, por<br />
supuesto, la semántica difiere (ahora consiste en actualizar la propiedad referida al<br />
valor indicado). A nivel C puede encerrar también una notificación.<br />
La estructura de los elementos support-activity es análoga a la de los elementos<br />
learning-activity, salvo que también pueden incluir las referencias a los roles<br />
92
soportados. Dichas referencias se marcan con role-ref, elemento que tiene un<br />
atributo obligatorio ref que refiere al rol soportado nombrando el identificador único<br />
de dicho rol.<br />
Por último, los elementos activity-structure contemplan los siguientes<br />
atributos:<br />
identifier. Atributo obligatorio que identifica unívocamente al elemento<br />
en el manifiesto.<br />
structure-type. Atributo opcional que indica el tipo de la actividad<br />
estructurada (sequence, para las actividades tipo secuencia y selection,<br />
para las actividades tipo selección).<br />
number-to-select. Atributo que para las actividades de tipo selección<br />
permite indicar el número de actividades constituyentes que tienen que<br />
completarse para que la actividad total esté completada.<br />
sort. Atributo opcional que determina el orden en el que las actividades<br />
constituyentes aparecen en la bandeja del usuario. Si vale as-is (valor por<br />
defecto) las actividades se ordenarán según aparecen en la estructura. Si<br />
vale visibility-order las actividades se ordenan por el momento en el<br />
que se han hecho visibles.<br />
Figura 2.8.3.b. Codificación XML de la actividad de soporte Corrección de trabajo.<br />
<br />
Corrección de trabajo<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
En la descripción de las actividades estructuradas el título se marca mediante un<br />
elemento title, su descripción mediante un elemento information, la referencia a<br />
los entornos mediante environment-ref, las actividades refereridas mediante<br />
elementos de referencia apropiados y los metadatos mediante metadata. Los<br />
elementos de referencia a las actividades dependen del tipo de las mismas y todos<br />
ellos incluyen un atributo ref que permite referir a las actividades constituyentes por<br />
su identificador. Las actividades de aprendizaje se refieren mediante elementos<br />
learning-activity-ref, las actividades de soporte mediante<br />
93
support-activity-ref, y las estructuradas mediante<br />
activity-structure-ref.<br />
Figura 2.8.3.c. Codificación XML de la actividad estructurada Examen Materiales.<br />
<br />
Examen materiales<br />
<br />
<br />
<br />
<br />
La Figuras 2.8.3.a, la Figura 2.8.3.b y la Figura 2.8.3.c esbozan la codificación XML<br />
de: (i) la actividad de aprendizaje Lectura Artículo Birra, (ii) la actividad de soporte<br />
Corrección de Trabajo y (iii) la actividad estructurada Examen Materiales. Al igual que<br />
en los puntos anteriores, los identificadores también se han generado<br />
automáticamente y se asume que en el paquete IMS deberán estar los recursos<br />
referidos desde la codificación.<br />
2.8.4. Codificación de los entornos<br />
Los entornos se delimitan mediante environments. Cada entorno en sí se delimita<br />
con environment, elemento que puede exhibir los siguientes atributos:<br />
identifier. Atributo obligatorio que identifica unívocamente al elemento<br />
en el manifiesto.<br />
El título del entorno se delimita con title. Cada objeto de aprendizaje se delimita<br />
mediante learning-object. Este elemento contempla los siguientes atributos:<br />
class. Atributo opcional que etiqueta el objeto de aprendizaje con una<br />
clase o conjunto de clases, en el sentido de HTML 4.0 o XHTML.<br />
identifier. Atributo obligatorio que identifica unívocamente al elemento<br />
en el manifiesto.<br />
isvisible. Atributo obligatorio que determina la visibilidad o invisibilidad<br />
del entorno.<br />
parameters. Atributo opcional con los parámetros requeridos para activar<br />
el entorno.<br />
type. Atributo opcional que determina el tipo de objeto de aprendizaje.<br />
La estructura de dicho elemento puede seguir el patrón ya familiar title – item –<br />
metadata para referir los materiales del objeto de aprendizaje, aunque IMS LD<br />
contempla también el uso de cualquier otro formato de descripción de objetos de<br />
aprendizaje, mediante el uso de un vocabulario XML adecuado.<br />
94
Por su parte, cada servicio se delimita mediante un elemento service. Dicho<br />
elemento acepta atributos class, identifier, isvisible and parameters<br />
análogos a los de learning-object. Igualmente, para describir cada tipo de servicio<br />
se incluye un vocabulario de marcado adecuado (dicho vocabulario se omitirá aquí por<br />
simplicidad, relegando al lector interesado a la especificación, aunque sí se dará un<br />
ejemplo de descripción de servicio).<br />
La Figura 2.8.4.a muestra la descripción del entorno Artículo Birra, que ilustra el uso<br />
de un objeto de aprendizaje en un entorno. Por su parte, en la Figura 2.8.4.b<br />
ejemplificamos la prometida descripción de un servicio (en este caso, servicio de<br />
conferencia), en el contexto del entorno Servicio Debate. Aunque los identificadores y<br />
referencias a identificadores han sido generados automáticamente, el lector puede<br />
comprobar cómo los participantes, gestor de la charla y moderador se corresponden<br />
con los distintos roles introducidos en la Figura 2.8.2.a.<br />
Figura 2.8.4.a. Codificación XML del entorno Artículo Birra.<br />
<br />
Articulo Birra<br />
<br />
articulo<br />
<br />
<br />
<br />
Figura 2.8.4.b. Codificación XML del entorno Servicio Debate.<br />
<br />
Servicio Debate<br />
<br />
<br />
chat<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
2.8.5. Codificación de los métodos<br />
Los métodos se limitan con elementos de tipo method. Cada guión se marca mediante<br />
play. La condición de finalización del método (y por tanto, de la unidad de<br />
95
aprendizaje) se marca mediante complete-unit-of-learning. El contenido de<br />
este elemento puede ser de alguno de los tipos siguientes:<br />
Elemento when-play-completed. Este elemento hace referencia, a<br />
través de un atributo ref, al guión que ha de completarse para considerar<br />
que la unidad de aprendizaje ha terminado.<br />
Elemento time-limit. Al igual que en las actividades, este elemento<br />
permite especificar un tiempo máximo, transcurrido el cual la unidad se<br />
considerará terminada.<br />
Elemento when-property-value-is-set, que, con sentido y uso<br />
análogo al de las actividades, permite supeditar el final de un método a que<br />
una propiedad tome un determinado valor.<br />
Además, la acción a realizar tras la finalización del método se marca con oncompletion.<br />
La estructura es análoga a la ya descrita para las actividades.<br />
Cada elemento play puede tener asociado un identificador opcional (atributo<br />
identifier), así como un atributo isvisible obligatorio, que determina la<br />
visibilidad del guión. Asimismo, dentro de este tipo de elementos es posible utilizar los<br />
siguientes:<br />
Elemento title para marcar el título del guión.<br />
Elementos act para describir los actos<br />
Elemento complete-play para describir la condición de finalización.<br />
Dicha condición puede indicarse con un elemento when-last-actcompleted<br />
para indicar que el guión termina cuando termine su último<br />
acto, con time-limit, o con when-property-value-is-set.<br />
Elemento on-completion para describir la acción realizada tras la<br />
finalización. La estructura es análoga a la de las actividades y guiones.<br />
Elemento metadata para delimitar el cuerpo de metadatos asociado al<br />
guión.<br />
Por su parte, los actos pueden exhibir también identificadores opcionales (atributo<br />
identifier), así como encerrar los siguientes tipos de elementos:<br />
Elemento title con el título del acto.<br />
Elementos role-part con cada actuación del acto.<br />
Elemento complete-act con la condición de finalización. Dicha condición<br />
puede describirse como when-role-part-completed (elemento que, a<br />
través del atributo ref, hará referencia a la actuación que debe terminar<br />
para considerar el acto finalizado). También pueden usarse los ya familiares<br />
time-limit o when-property-value-is-set.<br />
Elemento on-completion indicando la acción de finalización. La<br />
estructrura es análoga a la ya descrita para los otros elementos.<br />
96
Elemento metadata con los metadatos asociados.<br />
Por último, las actuaciones también pueden tener un identificador opcional (atributo<br />
identifier). Su contenido incluye:<br />
Un título (elemento title).<br />
El rol que participa en la actuación. Dicho rol se refiere mediante el atributo<br />
ref de un elemento role-ref.<br />
La actividad que debe llevarse a cabo se refiere mediante learningactivity-ref<br />
(en caso de tratarse de una actividad de aprendizaje),<br />
support-activity-ref (en caso de tratarse de una actividad de<br />
soporte) o activity-structure-ref (en caso de ser una actividad<br />
estructurada). La referencia en sí se realiza mediante un atributo ref en el<br />
elemento correspondiente. IMS LD permite también referir directamente un<br />
entorno (a través de environment-ref) para abreviar actividades de<br />
aprendizaje muy simples que involucran únicamente el entorno referido.<br />
Como es habitual, también es posible asociar metadatos con la actuación,<br />
mediante metadata.<br />
La Figura 2.8.5.a ilustra la codificación en XML del método para la unidad de<br />
aprendizaje UACata1 (método que fue descrito más informalmente en la Figura<br />
2.5.5.d).<br />
97
Figura 2.8.5.a. Codificación XML del método de UCata1.<br />
<br />
<br />
Play<br />
<br />
clase presencial<br />
<br />
Actuacion Imparticion<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
periodo autoaprendizaje<br />
<br />
actuacion autoaprendizaje<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
discusion<br />
<br />
actuacion debate alumno nuevo<br />
<br />
<br />
<br />
<br />
actuacion debate alumno antiguo<br />
<br />
<br />
<br />
<br />
actuacion debate profesor<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
trabajo<br />
<br />
actuacion trabajo<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
evaluacion<br />
<br />
actuacion evaluacion<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
resultados<br />
<br />
Actuacion resultados<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
98
2.8.6. Codificación de las propiedades<br />
Las propiedades se delimitan mediante un elemento properties. La descripción de<br />
cada propiedad en sí depende de su tipo:<br />
Las propiedades locales generales se marcan mediante loc-property.<br />
Las propiedades locales personales se marcan mediante locpersproperty.<br />
Las propiedades locales de rol se marcan mediante locrole-property.<br />
Las propiedades globales generales se marcan como glob-property.<br />
Las propiedades globales personales se marcan como globpersproperty.<br />
Todos estos elementos tienen un identificador único (atributo identifier). Los<br />
elementos loc-property, locpers-property y locrole-property contienen, a<br />
su vez, los siguientes:<br />
title. Elemento opcional que delimita el título de la propiedad.<br />
role-ref (únicamente para locrole-property). Elemento obligatorio<br />
que refiere a través de un atributo ref al rol al que se refiere la propiedad<br />
local del rol.<br />
datatype. Elemento obligatorio que determina el tipo (el formato de los<br />
posibles valores) de la propiedad. Dicho elemento posee un atributo<br />
también llamado datatype que permite determinar el citado tipo. El tipo<br />
puede ser: boolean (el valor de la propiedad ha de ser un valor lógico: true<br />
–cierto- o false –falso-), integer (valor número entero), real (valor número<br />
real), string (valor cadena de caracteres), duration (valor duración<br />
temporal), text (valor texto), uri (valor dirección web) o other (valor de tipo<br />
no especificado).<br />
initial-value. Valor inicial de la propiedad (si no se especifica, el valor<br />
inicial es ).<br />
restriction. Este elemento, que puede ocurrir cero o más veces,<br />
constriñe el posible rango de valores que puede adoptar la propiedad. Para<br />
ello utiliza el atributo restriction-type, así como los convenios de<br />
descripción de restricciones de valores introducidos por la especificación<br />
XML Schema (véase XML Schema, 2004).<br />
metadata. Metadatos asociados con la propiedad.<br />
Por su parte, globpers-property y glob-property pueden contener, bien un<br />
elemento existing, bien un elemento global-definition:<br />
El elemento existing permite referir una propiedad global ya declarada<br />
en otra unidad de aprendizaje. Para ello utiliza un atributo href. Esto<br />
99
permite introducir en un diseño <strong>educativo</strong> propiedades globales ya<br />
declaradas en otros.<br />
El elemento global-definition permite definir una propiedad global en<br />
sí. Esta propiedad podrá entonces referirse desde otros diseños mediante<br />
elementos existing. El contenido de global-definition en sí viene<br />
dado por los elementos title, datatype, initial-value,<br />
restriction y metadata ya descritos anteriormente en relación con las<br />
propiedades locales.<br />
Por último, IMS LD también permite agrupar propiedades en grupos, a fin de permitir<br />
su edición conjunta (por ejemplo, a través de un formulario). Para ello las propiedades<br />
pueden agruparse mediante el elemento property-group. Dicho elemento tiene un<br />
identificador único (atributo identifier). Además, pueden contener los siguientes<br />
elementos:<br />
title. Opcional. Título del grupo.<br />
property-ref. Múltiples ocurrencias. Refiere a una propiedad que se<br />
incluye en el grupo (a través del atributo ref).<br />
property-group-ref. Múltiples ocurrencias. Refiere a un grupo de<br />
propiedades que se incluye en el grupo (a través del atributo ref).<br />
La Figura 2.8.6.a ilustra la codificación en XML de las propiedades para la unidad de<br />
aprendizaje UACata2.<br />
Figura 2.8.6.a. Codificación XML de las propiedades de la actividad UACata2.<br />
<br />
<br />
nota en el test<br />
<br />
<br />
<br />
nota en el trabajo<br />
<br />
<br />
<br />
recuperación finalizada<br />
<br />
false<br />
<br />
<br />
asignatura superada<br />
<br />
false<br />
<br />
<br />
100
2.8.7. Codificación de las expresiones, acciones y condiciones<br />
La codificación de las expresiones introducidas por IMS LD nivel B es como sigue:<br />
Las expresiones “es miembro de rol” se codifican mediante elementos ismember-of-role.<br />
Estos elementos refieren el rol en cuestión mediante un<br />
atributo ref.<br />
Las expresiones “es” se codifican mediante elementos is delimitando los<br />
dos operandos involucrados.<br />
Las expresiones “no es” se codifican mediante elementos not-is que<br />
delimitan los dos operandos involucrados.<br />
Las expresiones “y,” “o”, “suma”, “resta”, “mul”, “div”, “mayor que” , “menor<br />
que” y “no” se codifican respectivamente mediante elementos and, or, sum,<br />
substract, multiply, divide, greater-than, less-than, y not.<br />
Las expresiones “usuarios en rol” se codifican mediante elementos usersin-role.<br />
El atributo role-ref refiere el rol al que se aplica la expresión,<br />
mientras que la expresión en sí aparece como hija del elemento.<br />
Las expresiones “no valor” se codifican mediante no-value.<br />
Las expresiones “inicio unidad” se codifican mediante time-unit-oflearning-started<br />
(mediante el atributo unit-of-learning-uri se<br />
refiere la unidad en sí), las de tipo “inicio actividad” mediante daytimeactivity-started<br />
(mediante el atributo ref se refiere la actividad) y las<br />
de tipo “día y hora” mediante current-datetime.<br />
Las expresiones “finalizado” se codifican mediante elementos complete.<br />
Para referir el componente finalizado se usan alguno de los siguientes<br />
elementos: learning-activity-ref, support-activity-ref,<br />
unit-of-learning-href, activity-structure-ref, role-partref,<br />
act-ref o play-ref. En todos ellos se utiliza el atributo ref para<br />
realizar la referencia, excepto en unit-of-learning-href, donde se<br />
utiliza el atributo href con la dirección web de la unidad de aprendizaje<br />
referida.<br />
La Figura 2.8.7.a ejemplifica la codificación en XML de la primera de las condiciones<br />
esbozadas en la Figura 2.6.9.f.<br />
101
Figura 2.8.7.a. Codificación XML de una condición.<br />
<br />
<br />
<br />
<br />
5<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
En lo que se refiere a la codificación de las acciones:<br />
La visualización de los componentes <strong>educativo</strong>s o recursos se codifican<br />
mediante elementos show. La referencia al componente o recurso a<br />
visualizar se realiza mediante elementos hijo de los siguientes tipos: class,<br />
item-ref, environment-ref, learning-activity-ref, supportactivity-ref,<br />
activity-structure-ref, play-ref, unit-oflearning-href.<br />
En todos los elementos cuyo nombre termina por –ref<br />
se usa un atributo ref para realizar la referencia. En unit-oflearning-href<br />
se usa un atributo href. En class la referencia se lleva<br />
a cabo usando un atributo class. También es posible utilizar los atributos<br />
title y with-control para refinar la forma en la que se lleva a cabo la<br />
expansión y el colapso del componente.<br />
La ocultación de los componentes o recursos se lleva a cabo mediante<br />
elementos hide. Las referencias se realizan en los mismos términos<br />
utilizados en show (elementos class, item-ref, environment-ref,<br />
etc).<br />
El cambio del valor de propiedades se codifica mediante elementos<br />
change-property-value. Dentro de estos, mediante property-ref se<br />
refiere a la propiedad cuyo valor cambia (usando un atributo ref), y<br />
mediante property-value se delimita el nuevo valor que debe tomar la<br />
propiedad. Para ello es posible especificar un valor literal (delimitado<br />
mediante un elemento langstring), referir a otra propiedad (elemento<br />
property-ref) o especificar una expresión que debe utilizarse para llevar<br />
a cabo el cálculo (elemento calculate).<br />
Por último, las condiciones se delimitan mediante un elemento conditions. Este<br />
elemento encierra un grupo de condiciones, que puede tener un título (elemento<br />
102
title), así como un cuerpo de metadatos (elemento medatata). Cada condición en<br />
sí se describe mediante dos o tres elementos consecutivos:<br />
El primero, elemento if, representa la parte “si”.<br />
El segundo, elemento then, representa la parte “entonces”.<br />
El tercero, elemento else, representa la parte “en otro caso”.<br />
2.8.8. Codificación de elementos globales y servicio de monitorización<br />
IMS LD proporciona elementos globales para visualizar propiedades (viewproperty)<br />
y grupos de propiedades (view-property-group), así como para fijar el<br />
valor de propiedades (set-property) y de grupos de propiedades (set-propertygroup).<br />
Asimismo, proporciona un vocabulario de marcas para describir servicios de<br />
monitorización de propiedades (elemento monitor y su contenido). Dado que el uso<br />
de estas características es avanzado y radica (en el caso de los elementos globales)<br />
en características técnicas de las tecnologías XML, se dirige al lector interesado a la<br />
especificación.<br />
2.8.9. Codificación de notificaciones<br />
Las notificaciones se codifican mediante elementos de tipo notification. Dichos<br />
elementos pueden contener, a su vez, los siguientes:<br />
email-data. Utilizado para posibilitar la notificación a través de e-mail a<br />
distintos participantes. Este elemento incluye un atributo emailproperty-ref<br />
que hace referencia a una propiedad que debe contener la<br />
dirección del destinatario de la notificación. Por su parte, mediante<br />
username-property-ref puede referirse a una propiedad con el nombre<br />
de dicho destinatario.<br />
role-ref. Elemento que permite seleccionar el papel objetivo de la<br />
notificación.<br />
learning-activity-ref. Elemento que permite seleccionar la actividad<br />
de aprendizaje que se activará como resultado de la notificación.<br />
support-activity-ref. Elemento que permite seleccionar la actividad<br />
de soporte que se activará como resultado de la notificación.<br />
La Figura 2.8.9.a muestra la codificación de la notificación provocada por la actividad<br />
Revisión y Mejora del Trabajo en la Figura 2.7.3.b<br />
103
Figura 2.8.9.a. Codificación XML de una notificación.<br />
<br />
<br />
<br />
<br />
<br />
<br />
3. IMS LEARNER INFORMATION PACKAGE<br />
3.1. INTRODUCCIÓN<br />
La especificación Learner Information Package de IMS (de ahora en adelante, IMS<br />
LIP) permite el almacenamiento de información sobre los alumnos para su<br />
procesamiento, mantenimiento e interoperabilidad en distintos sistemas de gestión del<br />
aprendizaje (IMS Global Consortium, 2005).<br />
Partiendo de una estructura modular que permite su aplicación en distintos contextos,<br />
la especificación plantea un formato digital estándar para representar información<br />
relativa a todo el proceso de formación del alumno, incluyendo su historial <strong>educativo</strong>,<br />
experiencia profesional, calificaciones y certificados obtenidos, objetivos <strong>educativo</strong>s y<br />
habilidades adquiridas.<br />
En este capítulo se detallan las características de la especificación IMS LIP. Para ello,<br />
se comienza describiendo una visión conceptual de la especificación, haciendo<br />
especial énfasis en su estructura modular. Tras esto, se presenta un caso de estudio<br />
sencillo consistente en el modelado de un Curriculum Vitae empleando los distintos<br />
elementos de la especificación. Este caso de ejemplo será empleado para ilustrar las<br />
principales características de la especificación.<br />
3.2. VISIÓN CONCEPTUAL<br />
La idea de partida de la especificación es ofrecer un modelo de datos para almacenar<br />
los distintos datos de los alumnos que puedan ser relevantes para el proceso de<br />
aprendizaje. Dado que los posibles tipos de información son ricos y variados, los datos<br />
sobre el alumno pueden provenir desde fuentes distintas e incluso estar ubicados en<br />
sistemas de almacenamiento distintos. La especificación IMS LIP intenta maximizar su<br />
flexibilidad permitiendo que cada dato se guarde de manera aislada.<br />
En este contexto, un dato podría ser la información de contacto del alumno, un<br />
certificado de estudios obtenido anteriormente, una actividad educativa ya completada,<br />
un objetivo <strong>educativo</strong> a largo plazo, etc. Dada esta riqueza y variedad, cada dato se<br />
104
describe como perteneciente a una determinada categoría (actividades educativas,<br />
calificaciones, etc.) tal y como se describe en la sección 3.2.1.<br />
Similarmente, cada dato del perfil del alumno puede tener asociada su propia sección<br />
de metadatos, cuya estructura se detalla en la sección 3.2.2.<br />
También cabe señalar que, aunque cada dato individual se describe por separado en<br />
una jerarquía plana, es posible establecer conexiones entre datos que estén<br />
relacionados. Este modelo de organización se refleja en la Figura 3.2.a.<br />
Figura 3.2.a. Visión conceptual de un documento LIP. Los distintos datos del<br />
alumno se guardan de manera independiente, pudiendo añadir metadatos o establecer<br />
relaciones entre ellos.<br />
Alumno 1<br />
Dato 1<br />
Dato 2<br />
3.2.1. Categorías de datos<br />
metadatos metadatos metadatos metadatos<br />
Dato 3<br />
105<br />
relación<br />
Dato n<br />
La especificación IMS LIP propone once tipos de datos o categorías para almacenar la<br />
información del alumno. La especificación sigue un criterio de flexibilidad y de permitir<br />
que las distintas organizaciones usen estas categorías según sus necesidades. No es<br />
necesario usar todas estas categorías al crear los perfiles de alumno, algunas<br />
categorías incluso se pueden usar con distintos fines. Un documento IMS LIP constará<br />
por tanto de una serie de bloques de información desconectados, cada uno de ellos<br />
perteneciente a alguna de las categorías que se describen a continuación.<br />
Datos Personales<br />
La sección identification incluye información sobre los alumnos. Esta información<br />
puede incluir datos personales (nombre, edad, género, información demográfica, etc.)<br />
o datos de contacto (dirección, teléfono, email, etc.).<br />
Accesibilidad<br />
Aunque el término accesibilidad se emplea habitualmente en el contexto de facilitar el<br />
acceso a personas con discapacidades, el apartado accessibility de IMS LIP describe<br />
una mayor variedad de características relativas a la capacidad del alumno para<br />
interactuar con los entornos de aprendizaje. Así, esta sección incluye información<br />
sobre las habilidades idiomáticas del alumno, sus preferencias acerca de formatos de<br />
presentación, sus características cognitivas o, finalmente, sus limitaciones físicas que
equieran un trato especial. Para este último caso, la última versión de la<br />
especificación IMS LIP no detalla mecanismos concretos para expresar información<br />
relativa a discapacidades, limitándose a indicar que la especificación IMS ACCLIP<br />
(IMS Global Consortium, 2003) deberá ser empleada para completar dicha sección tal<br />
y como se describe en la sección 3.4.8.<br />
Calificaciones, Certificados y Licencias<br />
Esta sección, denominada qcl (del inglés, Qualifications, Certificates and Licenses),<br />
incluye aquellas acreditaciones oficiales de su formación, como pueden ser títulos<br />
obtenidos, licencias otorgadas. La especificación indica que se deberá añadir una de<br />
estas secciones para cada título, incluyendo información de los mismos tal como la<br />
agencia emisora, la fecha de obtención y posiblemente, una versión digitalizada de los<br />
mismos.<br />
Actividades<br />
Las secciones de tipo activity describen todo tipo de actividades realizadas por el<br />
alumno relativas al proceso <strong>educativo</strong> o de formación. También se incluyen como<br />
actividades los servicios prestados (militar, voluntariado, etc.) y productos creados<br />
(como trabajos o documentos). Cada actividad (por ejemplo, una asignatura) puede<br />
acompañarse de la calificación o evaluación correspondiente, con la excepción de los<br />
premios oficiales, que deben incluirse en secciones qcl.<br />
Objetivos<br />
Los objetivos <strong>educativo</strong>s y las aspiraciones de los alumnos se definen mediante<br />
secciones de tipo goal. Estas secciones pueden incluir, opcionalmente, información<br />
para la monitorización del progreso del alumno de cara a alcanzar dichos objetivos.<br />
Competencias<br />
Las secciones de tipo competency describen habilidades adquiridas por el alumno.<br />
Estas competencias pueden asociarse opcionalmente con elementos descritos en<br />
secciones qcl o activity, indicando que son el resultado de dichas certificaciones o<br />
actividades. En este caso, la versión actual de la especificación IMS LIP también<br />
queda abierta, indicando que deberán usarse las estructuras identificadas por el grupo<br />
de trabajo IMS Competency Definition. En la actualidad, este grupo de trabajo ha<br />
publicado ya la primera versión de la especificación IMS Reusable Definition of<br />
Competency or Educational Objective Specification (IMS Global Consortium, 2002),<br />
que posteriormente ha sido publicada como estándar por el Institute of Electrical and<br />
Electronics Engineers (IEEE) bajo el nombre Reusable Competency Definition (IEEE<br />
RCD). El capítulo 4 incluye una descripción detallada de esta nueva especificación.<br />
Intereses<br />
Las secciones de tipo interest describen aficiones u otras actividades recreativas<br />
practicadas por el alumno. Estas secciones pueden incluir productos asociados (como,<br />
por ejemplo, fotos) y los intereses también pueden asociarse con premios formales<br />
descritos en secciones qcl.<br />
Transcripciones<br />
Ciertas informaciones como, por ejemplo, un informe emitido por una entidad<br />
académica, no siguen una estructura fija. Para estos casos, las secciones de tipo<br />
transcript son las más flexibles al no forzar estructuras internas específicas.<br />
106
Afiliaciones<br />
Las secciones de tipo affiliation almacenan información de las organizaciones a las<br />
que el alumno está o ha estado asociado. La información a incluir en estas secciones<br />
contempla datos sobre la organización en cuestión, sobre la duración de dicha<br />
afiliación y sobre el rol del alumno en la organización.<br />
Códigos de Seguridad<br />
Las secciones securitykey se emplean para guardar claves y contraseñas para su uso<br />
en la comunicación con el alumno.<br />
Relaciones<br />
Como se ha mencionado en las descripciones de las estructuras anteriores, en<br />
muchos casos determinados elementos de distintas secciones están relacionados. Así,<br />
una determinada actividad educativa definida en una sección activity (por ejemplo,<br />
completar un curso de formación profesional), puede estar relacionada con la<br />
obtención de un certificado oficial descrito en una sección qcl y suponer la adquisición<br />
de una serie de habilidades descritas en una sección competency. Las secciones de<br />
tipo relationship indican relaciones entre estos elementos definidos en secciones<br />
distintas.<br />
3.2.2. Metadatos<br />
Tanto el documento principal como todas las secciones incluidas en el documento<br />
incluyen una serie de metadatos que aportan información sobre dicha sección. La<br />
información de estos bloques de metadatos se divide en tres bloques:<br />
Datos de identificación/referencia<br />
Información empleada para identificar el contenido de manera única dentro del<br />
documento, del entorno de enseñanza o de manera universal. La especificación no<br />
detalla los mecanismos a emplear para gestionar los identificadores únicos, dejando<br />
este aspecto en manos de las distintas implementaciones.<br />
Datos temporales<br />
Cada sección del documento puede tener información que describe su vigencia<br />
temporal. Esta información incluye, por ejemplo, el periodo de validez de cada<br />
información (por ejemplo, para indicar que una cierta licencia sólo es válida hasta una<br />
fecha determinada).<br />
Datos de privacidad<br />
Cada elemento del documento puede tener asociada información relativa a los<br />
permisos de acceso a la misma. Así, es posible indicar que determinadas<br />
informaciones (demográficas, por ejemplo) sólo son accesibles por el propio alumno,<br />
que otras informaciones sólo son accesibles por los instructores del propio sistema (y<br />
por tanto no deben ser incluidas en el documento si va a ser exportado) e indicar que<br />
otras informaciones son de dominio público. Es importante destacar que la<br />
especificación sólo provee mecanismos para indicar esta información. Es<br />
107
esponsabilidad de las distintas implementaciones asegurar la correcta gestión de los<br />
problemas de privacidad.<br />
3.3. UN CASO DE ESTUDIO<br />
Fulanito Pérez es un licenciado en informática que, para mantener sus conocimientos<br />
actualizados, decide inscribirse en una serie de cursos online dirigidos a complementar<br />
la formación de profesionales. Como parte de su proceso de inscripción, el Sr. Pérez<br />
entrega el siguiente currículum:<br />
Fulanito Pérez<br />
INFORMACIÓN PERSONAL<br />
• DNI: 12345678-A<br />
• Fecha de Nacimiento: 08-Abril-1981<br />
• Lugar de nacimiento: Madrid, España<br />
• Nacionalidad: Española<br />
• Teléfono: 912 345 678<br />
• Dirección postal: Calle del ejemplo 234, 28199 Villaejemplo, Madrid.<br />
• E-Mail: fulanito.perez@micorreo.com<br />
FORMACIÓN<br />
• 1999 – 2004: Ingeniero en Informática por la Universidad Complutense de<br />
Madrid<br />
RESUMEN DE CALIFICACIONES<br />
• Nota media en enseñanza secundaria y Selectividad: 8,40<br />
• Nota media en titulación universitaria (formato 1-4): 2,31<br />
IDIOMAS<br />
• Nivel de Inglés Escrito y Oral: Muy Alto<br />
• University of Cambridge Certificate of Proficiency in English (1997) Calificación:<br />
A<br />
CONOCIMIENTOS TÉCNICOS<br />
• Programación<br />
o Programación Imperativa: Pascal, C, Basic<br />
o Programación Orientada a Objetos: Java, C++, Div / Div 2<br />
o Programación Declarativa (Lógica y funcional): Haskell, Prolog, Clips<br />
• Experiencia con la plataforma J2EE<br />
o Arquitecturas J2EE<br />
o Tecnologías J2EE (JSP, JDBC, JNDI…)<br />
108
EXPERIENCIA LABORAL<br />
• 2006– … : Ejemplo Consulting Inc.<br />
o Jefe de diseño<br />
AFICIONES<br />
• Fotografía digital (http://www.misfotosdigitales.es/fulanito)<br />
Al darse de alta en el sistema, se crea la primera versión de su currículum formalizada<br />
mediante la especificación IMS LIP. Dado que el currículum sólo indica la obtención<br />
del título universitario, el sistema solicita a la universidad de origen información más<br />
detallada sobre la formación del alumno. La universidad remite esta información,<br />
indicando las asignaturas superadas y las calificaciones detalladas siguiendo también<br />
el formato de IMS LIP para su integración con la información ya disponible.<br />
A medida que Fulanito va superando cursos dentro del propio sistema de formación,<br />
estas calificaciones y habilidades quedan también reflejadas en su perfil IMS LIP. Si en<br />
un futuro éste decidiese inscribirse en otro entorno de aprendizaje virtual compatible<br />
con IMS LIP, toda esta información puede ser exportada directamente para su uso en<br />
el nuevo sistema.<br />
En las siguientes secciones se analiza la estructura concreta de la especificación IMS<br />
LIP indicando cómo se puede usar para formalizar todos los elementos de este caso<br />
de estudio.<br />
3.4. ESTRUCTURA XML<br />
El modelo de información de IMS LIP se puede expresar como lenguaje de marcado<br />
XML. En este apartado se describen los distintos tipos de elementos (las etiquetas)<br />
introducidos por dicho lenguaje. Para cada elemento discutido se muestra un ejemplo<br />
de cómo emplearlo para modelar fragmentos del caso de estudio anterior.<br />
3.4.1. Metadatos y otros elementos comunes<br />
Como ya se ha indicado en la sección 3.2.2, todas las secciones y elementos de la<br />
especificación IMS LIP pueden incluir una sección con metadatos que afectan a la<br />
sección en la que se incluyan. Estos metadatos se introducen siempre mediante un<br />
bloque contenttype cuya estructura se puede observar en la Figura 3.4.1.a. El resto<br />
de esta sección describe estos elementos así como otras construcciones comunes a<br />
toda la especificación IMS LIP.<br />
109
Figura 3.4.1.a. Estructura gramatical del elemento contenttype.<br />
contenttype<br />
0 o más<br />
ocurrencias<br />
Debe constar<br />
al menos<br />
uno de estos<br />
elementos<br />
Identificación/Referencia<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
Elemento<br />
opcional<br />
comment<br />
referential<br />
110<br />
0 .. 1<br />
0 .. 1<br />
temporal<br />
0 .. 1<br />
privacy<br />
sourceid<br />
indexid<br />
typename<br />
1 .. ∞ temporalfield<br />
0 .. 1<br />
typename<br />
1 .. ∞ privacyfield<br />
0 .. ∞ date<br />
ext_contenttype<br />
Uno de los<br />
dos<br />
En el bloque referential se incluye la información de identificación. Esta referencia<br />
puede ser única para el documento, para una determinada institución o incluso<br />
globalmente. El mecanismo de identificación emplea una de las dos siguientes<br />
etiquetas:<br />
Un elemento sourceid se emplea para identificar un registro de un alumno<br />
específico y consta de dos partes (source e id). La primera identifica de<br />
manera única un sistema de registro de alumnos (entorno virtual de<br />
enseñanza, universidad, escuela, etc.) mientras que la segunda especifica el<br />
indicador concreto del alumno.
Un elemento indexid se emplea para identificar elementos dentro del perfil de<br />
un alumno concreto como pueden ser una calificación o la descripción de una<br />
actividad educativa.<br />
Temporalidad<br />
El bloque temporal incluye la información relativa a la vigencia de los datos a los que<br />
describe. Contiene, a su vez, dos tipos de elemento:<br />
El elemento typename aparece en diversos campos de la especificación para<br />
indicar un tipo dentro de una cierta taxonomía (en este caso, se emplea para<br />
indicar el tipo de limitación temporal del dato). A su vez, este elemento se<br />
divide en dos elementos:<br />
- El elemento tysource indica el vocabulario de los tipos posibles. La<br />
especificación IMS LIP ofrece vocabularios por defecto para los<br />
distintos contextos en los que puede aparecer un elemento typename,<br />
denominado imsdefault. En el caso de los metadatos temporales,<br />
este vocabulario ofrece los términos Expiry, Creation, Update y Purge.<br />
- El elemento tyvalue indica el tipo en sí, escogido del vocabulario<br />
especificado en el elemento anterior.<br />
El elemento temporalfield incluye el dato temporal en sí en forma de un par<br />
atributo-valor compuesto por los elementos fieldlabel y fieldata.<br />
Privacidad<br />
El bloque privacy incluye los datos de privacidad que definen quién puede acceder a<br />
cada dato del documento e incluye los siguientes elementos:<br />
El elemento typename es similar al descrito en el apartado anterior. En este<br />
caso, indica qué personas pueden acceder al dato que se está definiendo,<br />
teniendo como vocabulario por defecto Creator, Owner, Steward, Learner,<br />
Default y All.<br />
Los elementos privacyfield se emplean para describir la política de<br />
privacidad en sí mediante pares atributo-valor compuestos por los elementos<br />
fieldlabel y fielddata.<br />
Se pueden incluir opcionalmente algunos elementos de tipo date para asociar<br />
fechas a la mencionada política de privacidad (por ejemplo, la fecha de<br />
implantación o expiración de la política de privacidad).<br />
Extensiones<br />
La especificación IMS LIP está diseñada para poder ser extendida para cubrir las<br />
necesidades emergentes de las distintas organizaciones que la adopten. En la<br />
terminología de IMS esto se denomina crear un Perfil de Aplicación (del inglés,<br />
Application Profile) tal y como se indica en (Fernández-Manjón et al., 2007).<br />
Así, en la Figura 3.4.1.a podemos observar también un elemento final denominado<br />
ext_contenttype. La especificación no indica el contenido de este elemento,<br />
111
dejando en manos de las distintas implementaciones expandirlo según crean<br />
conveniente.<br />
Como se puede observar en el resto de secciones, este mismo patrón lo encontramos<br />
en prácticamente todos los elementos de la especificación, permitiendo así introducir<br />
modificaciones en distintas ubicaciones según sea necesario.<br />
Descripciones<br />
Muchos de los elementos de la especificación pueden incluir un campo denominado<br />
description en el que se pueden incluir descripciones textuales o referencias a<br />
ficheros externos. Estas descripciones, cuya estructura se puede observar en la Figura<br />
3.4.1.b constan de los siguientes elementos:<br />
• El elemento short se emplea para incluir una descripción breve (inferior a 255<br />
caractéres) en formato textual.<br />
• El campo long se emplea en cambio para incluir descripciones textuales de<br />
longitud mayor.<br />
• El elemento full se emplea para hacer referencia a ficheros externos<br />
mediante el elemento media. El elemento comment se emplea para incluir en<br />
el fichero comentarios sobre el fichero en cuestión.<br />
Figura 3.4.1.b. Estructura gramatical del elemento description.<br />
description<br />
Debe constar<br />
al menos<br />
uno de estos<br />
elementos<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
short<br />
long<br />
full<br />
112<br />
0 .. 1<br />
1 .. ∞<br />
comment<br />
media
3.4.2. El elemento learnerInformation<br />
El elemento learnerInformation es el elemento raíz de los documentos marcados<br />
mediante la especificación IMS LIP. Toda la información de un documento IMS LIP se<br />
guarda por tanto dentro de este elemento, el cual se divide en subsecciones que se<br />
corresponden con los distintos tipos de información a almacenar. La Figura 3.4.2.a<br />
esquematiza la estructura gramatical del mismo.<br />
El primer elemento, de carácter opcional, es el elemento comment, empleado para<br />
añadir comentarios u observaciones sin formato formalizado para su interpretación por<br />
humanos. El siguiente elemento es el campo contenttype que, tal y como se<br />
describe en la sección 3.4.1, se emplea para indicar los metadatos del elemento<br />
activo. En este caso, el bloque contenttype del elemento learnerInformation<br />
incluye metadatos relativos al documento completo.<br />
Tras estos dos elementos opcionales, el elemento learnerInformation contiene<br />
una sucesión de secciones no ordenadas que se corresponden con las 11 categorías<br />
de datos descritas en la sección 3.2.1. Por último, encontramos el elemento<br />
ext_learnerinfo para que las distintas organizaciones puedan añadir aquellos<br />
elementos que consideren necesarios para extender la funcionalidad de la<br />
especificación.<br />
113
Figura 3.4.2.a. Estructura gramatical del elemento learnerInformation.<br />
learnerInformation<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
114<br />
comment<br />
contenttype<br />
identification<br />
goal<br />
qcl<br />
activity<br />
competency<br />
transcript<br />
accesibility<br />
interest<br />
affiliation<br />
securitykey<br />
relationship<br />
ext_learnerinfo<br />
En nuestro caso de estudio, la estructura general del documento es la descrita en la<br />
Figura 3.4.2.b. El formato del contenido concreto de cada sección (indicado en la<br />
figura en forma de elipsis) se describe en los siguientes apartados.
Figura 3.4.2.b. Estructura de alto nivel de un documento IMS LIP.<br />
<br />
<br />
Ejemplo de uso de IMS para almacenar datos de un alumno<br />
<br />
<br />
<br />
Sistema de Ejemplo<br />
12345678-A<br />
<br />
<br />
<br />
<br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
(…) <br />
<br />
(…) <br />
<br />
3.4.3. El elemento identification<br />
El propósito de la sección de contenido identification es incluir la información<br />
personal del alumno que no es directamente relevante para el proceso <strong>educativo</strong>,<br />
como pueden ser datos de contacto o información demográfica.<br />
115
Figura 3.4.3.a. Estructura gramatical del elemento identification.<br />
identification<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
116<br />
comment<br />
contenttype<br />
formname<br />
name<br />
address<br />
contactinfo<br />
demographics<br />
agent<br />
ext_identification<br />
Tal y como se observa en la Figura 3.4.3.a, el elemento identification incluye, al<br />
igual que el elemento raíz learnerinformation, elementos opcionales comment y<br />
contenttype. En este caso, los mencionados elementos contienen los comentarios y<br />
metadatos aplicables específicamente a la sección de datos personales. Aparte de<br />
estos elementos, que son comunes a todas las secciones de contenido de la<br />
especificación, la sección identification también puede incluir tantas instancias<br />
como sea necesario de los siguientes elementos:<br />
Los elementos formname se emplean para definir nombres completamente<br />
formateados, como por ejemplo “Sr. Fulanito Pérez”.<br />
Los elementos name, en cambio, se emplean para almacenar el nombre del<br />
alumno separado en campos (nombre de pila, apellidos, prefijos, etc.).<br />
En los elementos address se incluyen las posibles direcciones de contacto del<br />
alumno, usando los campos apropiados.<br />
Cada elemento contactinfo se emplea para listar un modo de contactar con<br />
el alumno, como puede ser un teléfono, un número de fax, un teléfono móvil o<br />
una dirección de correo electrónico. Es reseñable que la especificación emplea<br />
un elemento contactinfo para cada dato, de modo que si queremos incluir<br />
por ejemplo dos números de teléfono y una dirección de correo electrónico,<br />
deberemos introducir tres instancias de contactinfo.
El elemento demographics se emplea para registrar información demográfica<br />
como pueden ser la fecha de nacimiento, el género o una referencia a una<br />
fotografía.<br />
Los elementos agent se emplean para incluir información sobre los posibles<br />
representantes del alumno. El caso más común de representante en<br />
enseñanza reglada son los padres o tutores del alumno y en caso de entornos<br />
corporativos, la organización empleadora.<br />
La figura Figura 3.4.3.b muestra el uso de estos elementos para codificar la<br />
información correspondiente del caso de estudio. En esta figura podemos apreciar<br />
también el uso del elemento ext_identification para extender la especificación y<br />
añadir un nuevo campo para almacenar la nacionalidad.<br />
Figura 3.4.3.b. Marcado en XML de la información de identificación del alumno del<br />
caso de estudio.<br />
<br />
<br />
<br />
<br />
<br />
First<br />
<br />
Fulanito<br />
<br />
<br />
<br />
<br />
Last<br />
<br />
Pérez<br />
<br />
<br />
<br />
<br />
<br />
Private<br />
<br />
<br />
234<br />
<br />
Calle del ejemplo<br />
<br />
<br />
Villaejemplo<br />
Madrid<br />
28199<br />
<br />
3.4.4. El elemento qcl<br />
<br />
<br />
34<br />
91<br />
2345678<br />
<br />
<br />
<br />
<br />
fulanito.perez@micorreo.com<br />
<br />
<br />
<br />
<br />
<br />
<br />
Birth<br />
<br />
1981-04-08<br />
<br />
Madrid, España<br />
<br />
<br />
<br />
<br />
Nacionalidad<br />
<br />
<br />
Española<br />
<br />
<br />
Cada elemento de tipo qcl se emplea para incluir información sobre una certificación<br />
oficial, un título académico, una licencia o, en general, calificaciones de carácter<br />
117
general emitidas por organismos apropiados. Se debe emplear una sección qcl para<br />
cada certificación que se desee incluir.<br />
La Figura 3.4.4.a indica la estructura gramatical de un elemento qcl, cuyos campos<br />
más relevantes son los siguientes:<br />
El elemento typename se emplea para indicar el tipo de certificado o licencia<br />
referido. La especificación IMS LIP incluye un vocabulario por defecto para este<br />
campo, aunque se contempla la opción de extenderlo o adaptarlo por parte de<br />
las distintas implementaciones.<br />
El campo title se emplea para almacenar el título otorgado por la<br />
certificación.<br />
El campo organization describe a la agencia u organismo emisor de la<br />
calificación.<br />
En los casos en los que el certificado lleve asociado un número de serie o de<br />
licencia, se debe emplear el elemento registrationno para indicarlo.<br />
El elemento level se emplea para indicar si el certificado se corresponde con<br />
algún nivel en especial (“Primera Clase”, “Con Honores”, etc.).<br />
Se pueden incluir uno o varios elementos date, indicando, por ejemplo, la<br />
fecha en que fue obtenido o el vencimiento en el caso de licencias temporales.<br />
El elemento description permite incluir textos explicativos o asociar ficheros<br />
adicionales relativos a la certificación (por ejemplo, una copia escaneada de un<br />
título oficial).<br />
118
Figura 3.4.4.a. Estructura gramatical del elemento qcl.<br />
qcl<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
119<br />
typename<br />
comment<br />
contenttype<br />
title<br />
organization<br />
registrationno<br />
level<br />
date<br />
description<br />
ext_qcl<br />
La Figura 3.4.4.b muestra cómo usar secciones qcl para registrar el título universitario<br />
y el certificado de inglés del currículum del caso de estudio. Es interesante observar el<br />
uso de los campos date para mostrar las fechas de inicio y graduación del alumno en<br />
el caso del título universitario, mientras que en el segundo ejemplo sólo se indica la<br />
fecha en la que fue obtenido el certificado.
Figura 3.4.4.b. Marcado en XML del título universitario y la certificación de idiomas<br />
del caso de estudio.<br />
<br />
<br />
<br />
Degree<br />
<br />
Ingeniero en Informática<br />
<br />
<br />
<br />
Educational<br />
<br />
<br />
<br />
Universidad Complutense de Madrid<br />
<br />
<br />
<br />
<br />
<br />
<br />
Start<br />
<br />
1999<br />
<br />
<br />
<br />
<br />
Finish<br />
<br />
2004<br />
<br />
<br />
3.4.5. El elemento activity<br />
120<br />
<br />
<br />
<br />
Certification<br />
<br />
<br />
<br />
qcl_cpe<br />
<br />
<br />
Certificate of Proficiency in English<br />
<br />
<br />
<br />
Educational<br />
<br />
<br />
University of Cambridge<br />
<br />
<br />
<br />
<br />
<br />
Award<br />
<br />
1999<br />
<br />
<br />
La secciones más relevantes de los perfiles de alumno son las descripciones de las<br />
actividades educativas llevadas a cabo. Estas actividades se describen mediante<br />
secciones activity, las cuales a su vez se organizan en subsecciones que separan<br />
la descripción de la actividad, los productos creados por el alumno durante la<br />
actividad, las evaluaciones obtenidas y los posibles informes que describan el<br />
rendimiento del alumno durante la realización de la actividad.<br />
En la Figura 3.4.5.a se puede observar la estructura general de una sección<br />
activity, cuyos elementos principales son los siguientes:<br />
El elemento typename se emplea para indicar el tipo de informe o<br />
transcripción. La especificación IMS LIP incluye un vocabulario por defecto<br />
para este campo que incluye los términos Work, Service, Education, Training, y<br />
Military, aunque se contempla la opción de extenderlo o adaptarlo por parte de<br />
las distintas implementaciones.
Se pueden incluir uno o varios elementos date para indicar las fechas de inicio<br />
o finalización de la actividad.<br />
El elemento status refleja el estado actual de la actividad (Activa,<br />
Completada, etc.). Dentro de este elemento se pueden incluir, aparte del<br />
estado, la fecha en que se entró en dicho estado o una descripción más<br />
detallada del significado de dicho estado.<br />
El elemento units se emplea si se quiere asociar a la actividad algún tipo de<br />
unidad de medida (como, por ejemplo, créditos) para cuantificar las posibles<br />
evaluaciones asociadas.<br />
El campo learningactivityref se emplea para asociar un identificador<br />
único a la actividad correspondiente.<br />
El uso de la sub-sección definition se describe en la sección 3.4.5.1.<br />
El uso de la sub-sección product se describe en la sección 3.4.5.2.<br />
El uso de la sub-sección testimonial se describe en la sección 3.4.5.3.<br />
El uso de la sub-sección evaluation se describe en la sección 3.4.5.4.<br />
El elemento description permite incluir textos explicativos o asociar ficheros<br />
adicionales relativos a la afiliación.<br />
La posibilidad de incluir más elementos de tipo activity dentro de estas<br />
estructuras permite definir jerarquías de actividades y sub-actividades.<br />
121
Figura 3.4.5.a. Estructura gramatical del elemento activity.<br />
activity<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
122<br />
typename<br />
comment<br />
contenttype<br />
date<br />
status<br />
units<br />
learningactivityref<br />
definition<br />
product<br />
testimonial<br />
evaluation<br />
description<br />
activity<br />
ext_qcl<br />
La respresentación en XML de esta estructura se puede observar en la Figura 3.4.5.b,<br />
que muestra la versión abreviada de la descripción de la actividad educativa<br />
correspondiente a la carrera universitaria del alumno del caso de estudio. El formato<br />
concreto de las secciones definition, product, testimonial y evaluation se<br />
describe en los siguientes apartados.
Figura 3.4.5.b. Estructura general de una actividad describiendo el título<br />
universitario del alumno del caso de estudio.<br />
<br />
<br />
<br />
Education<br />
<br />
<br />
<br />
Universidad_Complutense_de_Madrid<br />
306-Ingeniero_en_Informatica<br />
<br />
<br />
(...) <br />
(...) <br />
(...) <br />
(...) <br />
<br />
3.4.5.1. Descripción de Actividades: definition<br />
Para la descripción detallada de las actividades se emplean secciones definition.<br />
Este elemento, aunque de estructura sencilla (ver Figura 3.4.5.1.a) permite crear<br />
definiciones complejas mediante anidamiento (ver Figura 3.4.5.1.a). Sus elementos<br />
más relevantes son los siguientes:<br />
El elemento typename se emplea para indicar el tipo de definición que<br />
describe la sección. La especificación IMS LIP incluye un vocabulario por<br />
defecto para este campo que incluye los términos Class, Course, Curriculum,<br />
Module, Topic y Unit, aunque se contempla la opción de extenderlo o adaptarlo<br />
por parte de las distintas implementaciones.<br />
Los elementos definitionfield se emplean para incluir pares atributo-valor<br />
que aportan los contenidos de la definición.<br />
En los casos en los que se prefiera emplear una descripción textual en lugar (o<br />
como complemento) de los pares atributo-valor, podemos emplear un elemento<br />
description para incluir textos explicativos o asociar ficheros relativos a la<br />
definción (por ejemplo, una copia escaneada de un título oficial).<br />
La presencia de nuevo del elemento definition permite crear estructuras<br />
jerárquicas. Por ejemplo, un bloque definition que describa un curso puede<br />
incluir sub-definiciones para cada una de las clases que lo componen.<br />
123
Figura 3.4.5.1.a. Estructura gramatical del elemento definition.<br />
definition<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
typename<br />
comment<br />
contenttype<br />
definitionfield<br />
description<br />
definition<br />
ext_definition<br />
124<br />
0 .. 1<br />
0 .. 1<br />
fieldlabel<br />
fielddata<br />
En el caso de estudio, cuando el alumno Fulanito Pérez se matricula en el sistema sus<br />
instructores requieren conocer en mayor profundidad el contenido concreto de los<br />
estudios del alumno. Para ello, solicitan a la universidad de origen una descripción<br />
formalizada mediante IMS LIP de los contenidos de la carrera estudiada empleando el<br />
identificador único descrito en el elemento learningactivityref (ver Figura<br />
3.4.5.b). La respuesta generada por los sistemas de información de la universidad de<br />
origen podría asemejarse al contenido de la Figura 3.4.5.1.b, que comienza<br />
empleando una serie de pares atributo-valor para definir algunas características de la<br />
titulación (el tipo, el número de años, etc.) y posteriormente emplea la estructura<br />
jerárquica del elemento definition para estructurar los cursos y las asignaturas<br />
correspondientes a cada curso.
Figura 3.4.5.1.b. Marcado en XML de la descripción detallada de la estructura del<br />
programa <strong>educativo</strong> de la titulación del caso de estudio.<br />
<br />
<br />
<br />
Curriculum<br />
<br />
<br />
<br />
<br />
Tipo de titulación<br />
<br />
<br />
Ingeniería Superior<br />
<br />
<br />
<br />
<br />
Número de años<br />
<br />
<br />
5<br />
<br />
<br />
<br />
<br />
<br />
Course<br />
<br />
<br />
Primer curso<br />
<br />
<br />
<br />
<br />
<br />
Class<br />
<br />
<br />
<br />
Introducción a la programación<br />
<br />
<br />
<br />
125<br />
<br />
<br />
<br />
Class<br />
<br />
<br />
Análisis Matemático<br />
<br />
<br />
(…)<br />
<br />
<br />
<br />
<br />
<br />
Course<br />
<br />
<br />
Segundo curso<br />
<br />
<br />
(…)<br />
<br />
<br />
<br />
<br />
<br />
Course<br />
<br />
<br />
Segundo curso<br />
<br />
<br />
(…)<br />
<br />
<br />
(…)<br />
<br />
3.4.5.2. Productos Generados en Actividades: product<br />
Los elementos de tipo product se emplean para incluir referencias a posibles<br />
productos generados por el alumno como parte de la actividad que está siendo<br />
descrita. La estructura de este elemento se puede observar en la Figura 3.4.5.2.a y<br />
estos son sus elementos principales:<br />
El elemento typename se emplea para indicar el tipo de producto. La<br />
especificación IMS LIP incluye un vocabulario por defecto para este campo
que incluye los términos Exam, Coursework, Portfolio y Participation,<br />
aunque se contempla la opción de extenderlo o adaptarlo por parte de las<br />
distintas implementaciones.<br />
Se pueden incluir uno o varios elementos date para indicar las fechas de<br />
ingreso o terminación del trabajo correspondiente.<br />
El elemento description permite incluir textos explicativos que aporten<br />
más información sobre el producto, así como ficheros digitales del mismo.<br />
Figura 3.4.5.2.a. Estructura gramatical del elemento product.<br />
product<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
126<br />
typename<br />
comment<br />
contenttype<br />
date<br />
description<br />
ext_product<br />
Para ejemplificar el uso de esta sección, tomamos la posibilidad de incluir junto con los<br />
datos del alumno, una copia de la memoria de su proyecto de fin de carrera tal y como<br />
se observa en la Figura 3.4.5.2.b.
Figura 3.4.5.2.b. Marcado en XML de la inclusión de un producto asociado a una<br />
actividad educativa.<br />
<br />
<br />
<br />
Coursework<br />
<br />
<br />
Memoria del proyecto de fin de carrera<br />
<br />
alumno/proyecto.pdf<br />
<br />
<br />
<br />
3.4.5.3. Informes sobre Actividades: testimonial<br />
La subsección testimonial se emplea para incluir posibles comentarios formales o<br />
informales sobre el rendimiento del alumno durante la realización de las actividades<br />
descritas. Estos testimonios pueden ser informes de los profesores, directores de<br />
estudios o de los superiores del alumno en el caso de actividades profesionales.<br />
Dado que el único objetivo de las subsecciones testimonial es la inclusión de estos<br />
informes, su estructura es realmente sencilla tal y como se puede observar en la<br />
Figura 3.4.5.3.a. Sus elementos principales son los siguientes:<br />
• El elemento typename se emplea para indicar el tipo de informe. La<br />
especificación IMS LIP incluye un vocabulario por defecto para este campo que<br />
incluye los términos Academic, Personal, Work, Military y Service, aunque se<br />
contempla la opción de extenderlo o adaptarlo por parte de las distintas<br />
implementaciones.<br />
• Se pueden incluir uno o varios elementos date para indicar las fechas<br />
relacionadas con el informe.<br />
• El elemento description se emplea para incluir el propio informe, bien como<br />
descripción textual dentro del propio documento o mediante una referencia a<br />
un fichero externo.<br />
127
Figura 3.4.5.3.a. Estructura gramatical del elemento testimonial.<br />
testimonial<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
128<br />
typename<br />
comment<br />
contenttype<br />
date<br />
description<br />
ext_testimonial<br />
Para ejemplificar el uso de esta sub-sección, añadimos al perfil del alumno de ejemplo<br />
una carta de recomendación escrita por su tutor durante la realización del proyecto de<br />
fin de carrera.<br />
Figura 3.4.5.3.b. Marcado en XML de la inclusión de un testimonio en forma de<br />
carta de recomendación.<br />
<br />
<br />
<br />
Academic<br />
<br />
<br />
Informe del tutor del proyecto de fin de carrera<br />
<br />
alumno/informeTutor.pdf<br />
<br />
<br />
<br />
3.4.5.4. Evaluación de Actividades: evaluation<br />
Las evaluaciones y notas obtenidas como parte de las actividades educativas se<br />
representan mediante sub-secciones evaluation. Aunque la estructura de estos<br />
apartados está muy relacionada con la especificación IMS Question and Test<br />
Interoperability (IMS Global Consortium, 2005), la descripción detallada de dichas<br />
relaciones queda fuera del ámbito de este informe concreto. Para mayor información,<br />
puede consultarse el informe número 16 de esta misma serie (Fernández-Manjón et
al., 2007). En cualquier caso, la estructura de estos elementos (detallada en la Figura<br />
3.4.5.4.a) se puede emplear también de manera independiente. Estos son sus<br />
elementos más relevantes:<br />
• El elemento typename se emplea para indicar el tipo de evaluación. El<br />
vocabulario inicial se centra en la especificación IMS QTI, presentando las<br />
opciones QTI_Assessment, QTI_Section y QTI_Item.<br />
• El elemento result incluye la puntuación concreta de la evaluación. Este<br />
resultado puede incluir información adicional para facilitar su interpretación.<br />
• Podemos emplear el campo description para incluir textos explicativos o<br />
asociar ficheros relativos a la evaluación.<br />
• La presencia de nuevo del elemento evaluation permite crear estructuras<br />
jerárquicas. Por ejemplo, una nota que es el resultado de ponderar diversas<br />
calificaciones puede incluir sub-evaluaciones con dichas calificaciones.<br />
129
Figura 3.4.5.4.a. Estructura gramatical del elemento evaluation.<br />
evaluation<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
130<br />
typename<br />
comment<br />
contenttype<br />
evaluationid<br />
date<br />
eval_metadata<br />
objectives<br />
status<br />
noofattempts<br />
duration<br />
result<br />
description<br />
evaluation<br />
ext_evaluation<br />
En el caso de estudio, el alumno indica en su currículum una calificación media en sus<br />
estudios universitarios. Esta calificación es el resultado de aplicar una media a las<br />
notas obtenidas durante la carrera y sigue un criterio de calificación entre 1 y 4 (1 =<br />
Aprobado, 2 = Notable, 3 = Sobresaliente, 4 = Matrícula de Honor). Toda esta<br />
información se puede formalizar mediante la especificación IMS LIP tal y como se<br />
ejemplifica en la Figura 3.4.5.4.b.
Figura 3.4.5.4.b. Marcado en XML de la calificación final del alumno junto con<br />
instrucciones para la interpretación del resultado.<br />
<br />
<br />
<br />
<br />
<br />
Aprobado<br />
<br />
<br />
1<br />
<br />
<br />
<br />
<br />
Notable<br />
<br />
<br />
2<br />
<br />
<br />
<br />
<br />
Sobresaliente <br />
<br />
<br />
3<br />
<br />
3.4.6. El elemento affiliation<br />
131<br />
<br />
<br />
<br />
<br />
<br />
<br />
Matrícula de Honor<br />
<br />
<br />
<br />
4<br />
<br />
<br />
<br />
<br />
<br />
<br />
Calificación Global<br />
<br />
<br />
<br />
2,31<br />
<br />
Las secciones de tipo affiliation se emplean para almacenar la información<br />
relativa a la pertenencia del alumno a distintos grupos profesionales, personales,<br />
militares o cívicos. Estas secciones son anidables, pudiendo incluir bloques<br />
affiliation dentro de otros para dar lugar a estructuras jerárquicas.<br />
La Figura 3.4.6.a indica la estructura gramatical de un elemento affiliation, cuyos<br />
campos más relevantes son los siguientes:<br />
El elemento typename se emplea para indicar el tipo de afiliación (Profesional,<br />
Personal, Militar, etc.). La especificación IMS LIP incluye un vocabulario por<br />
defecto para este campo, aunque se contempla la opción de extenderlo o<br />
adaptarlo por parte de las distintas implementaciones.<br />
El campo classification se emplea para almacenar el tipo de afiliación.<br />
Si la afiliación lleva asociado una referencia (un número de socio o un<br />
identificador de empleado), ésta se puede almacenar empleando el elemento<br />
affiliationid.<br />
Se pueden incluir varios campos role para almacenar los cargos que ha<br />
ocupado el alumno en la organización correspondiente. Cada uno de estos
campos incluye información adicional sobre las fechas de comienzo y<br />
finalización del cargo, así como otros datos relativos a las características del<br />
mismo.<br />
El campo organization describe a la agencia u organismo correspondiente.<br />
Se pueden incluir uno o varios elementos date para indicar las fechas de<br />
ingreso o terminación de la afiliación.<br />
El elemento description permite incluir textos explicativos o asociar ficheros<br />
adicionales relativos a la afiliación.<br />
La presencia de nuevo del elemento affiliation permite crear jerarquías de<br />
afiliaciones y sub-afiliaciones como, por ejemplo, la pertenencia a grupos<br />
específicos dentro de una organización.<br />
Figura 3.4.6.a. Estructura gramatical del elemento affiliation.<br />
affiliation<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
132<br />
typename<br />
comment<br />
contenttype<br />
classification<br />
affiliationid<br />
role<br />
organization<br />
date<br />
status<br />
description<br />
affiliation<br />
ext_affiliation
La Figura 3.4.6.b muestra una sección affiliation de ejemplo, describiendo la<br />
experiencia profesional del alumno del caso de estudio.<br />
Figura 3.4.6.b. Marcado en XML de la experiencia profesional del alumno del caso<br />
de estudio.<br />
<br />
<br />
<br />
Professional<br />
<br />
<br />
<br />
<br />
<br />
Start<br />
<br />
2005<br />
<br />
<br />
Jefe de Diseño<br />
<br />
<br />
<br />
<br />
Ejemplo Consulting Inc.<br />
<br />
<br />
<br />
3.4.7. El elemento transcript<br />
Las secciones de tipo transcript se emplean para guardar resúmenes acerca del<br />
rendimiento del alumno en diversas áreas o en determinadas instituciones. Son el<br />
elemento más flexible, presentando la estructura de la Figura 3.4.7.a cuyos elementos<br />
principales son los siguientes.<br />
El elemento typename se emplea para indicar el tipo de informe o<br />
transcripción. La especificación IMS LIP incluye un vocabulario por defecto<br />
para este campo que incluye los términos Academic, Vocational y Training,<br />
aunque se contempla la opción de extenderlo o adaptarlo por parte de las<br />
distintas implementaciones.<br />
El campo exrefrecord se emplea para indicar un fichero externo que<br />
contenga el informe correspondiente. Dentro de éste elemento se puede incluir,<br />
aparte del propio fichero, información adicional como fechas o una descripción<br />
del contenido del informe.<br />
El elemento description permite incluir textos explicativos que describan el<br />
informe.<br />
133
Figura 3.4.7.a. Estructura gramatical del elemento transcript.<br />
transcript<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
134<br />
typename<br />
comment<br />
contenttype<br />
exrefrecord<br />
description<br />
ext_transcript<br />
Dada la naturaleza abierta de las secciones transcript, es común utilizarlas para<br />
almacenar textos o ficheros que no terminen de encajar en otras secciones. En<br />
nuestro caso de estudio, empleamos una sección transcript para almacenar los<br />
datos de conocimientos técnicos del currículum de ejemplo, tal y como se muestra en<br />
la Figura 3.4.7.b.<br />
Figura 3.4.7.b. Marcado en XML del resumen de conocimientos técnicos del caso<br />
de estudio.<br />
<br />
<br />
Conocimientos Técnicos<br />
<br />
Programación<br />
Programación Imperativa: Pascal, C, Basic<br />
Programación Orientada a Objetos: Java, C++<br />
Programación Declarativa (Lógica y funcional): Haskell, Prolog, LISP<br />
Experiencia con la plataforma J2EE<br />
Arquitecturas J2EE<br />
Tecnologías J2EE (JSP, JDBC, JNDI…)<br />
<br />
<br />
<br />
3.4.8. El elemento accessibility<br />
Los elementos accessibility se emplean para almacenar información relativa a las<br />
necesidades y preferencias del alumno de cara a interactuar con el contenido<br />
<strong>educativo</strong>. A pesar de que el término “accesibilidad” (traducción literal de
accessibility) se emplea a menudo en el campo de las tecnologías de<br />
comunicación en referencia a facilitar el acceso a personas con discapacidades, en el<br />
caso de la especificación IMS LIP se emplea este concepto de una manera más<br />
amplia, cubriendo aspectos como los idiomas dominados por el alumno o sus<br />
preferencias personales en cuanto al formato de contenido.<br />
Como se puede observar en la figura Figura 3.4.8.a, el elemento accessibility<br />
consta de cuatro subsecciones que cubren los distintos aspectos de accesibilidad<br />
contemplados por la especificación.<br />
Los elementos language se emplean para incluir información sobre las<br />
capacidades lingüísticas del alumno. Debe incluirse un elemento de tipo<br />
language para la información de cada uno de los idiomas dominados por el<br />
alumno. Su uso se describe en la sección 3.4.8.1.<br />
El elemento eligibility se emplea para indicar posibles recursos<br />
adicionales que el alumno pueda requerir, como podrían ser atenciones<br />
especiales o criterios de corrección específicos. En la versión actual de la<br />
especificación IMS LIP este elemento queda pendiente de ser extendido en<br />
versiones futuras de la especificación. Tal y como se describe en el capítulo 5,<br />
la especificación IMS ACCLIP emplea este elemento para detallar los servicios<br />
especiales que los alumnos con discapacidades puedan requerir a la hora de<br />
realizar, por ejemplo, exámenes de evaluación.<br />
El propósito de los elementos preference es indicar las preferencias<br />
personales de acceso planteadas por el alumno y su uso se detalla en la<br />
sección 3.4.8.2.<br />
Las limitaciones ambientales o debidas a discapacidades del alumno se<br />
expresan dentro del elemento accessForAll. Cabe señalar que la<br />
especificación IMS LIP, en su versión actual, incluye en realidad el elemento<br />
disability. Tal y como se describe en el capítulo 5, la especificación IMS<br />
ACCLIP introduce en su lugar el elemento accessForAll dejando el<br />
elemento disability obsoleto.<br />
135
Figura 3.4.8.a. Estructura gramatical del elemento accessibility.<br />
accesibility<br />
Debe constar<br />
al menos<br />
uno de estos<br />
elementos<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. ∞<br />
0 .. 1<br />
3.4.8.1. Accesibilidad idiomática: language<br />
136<br />
comment<br />
contenttype<br />
language<br />
eligibility<br />
preference<br />
accessForAll<br />
ext_accesibility<br />
Dentro de una sección accessibility podemos incluir tantos elementos language<br />
como idiomas conozca el alumno. Para cada idioma se puede definir el nivel de<br />
habilidad en distintos aspectos siguiendo la estructura observable en la Figura<br />
3.4.8.1.a cuyos elementos principales son los siguientes:<br />
El elemento typename se emplea para indicar el lenguaje en cuestión. Como<br />
vocabulario por defecto se sugiere emplear los estándares ISO de<br />
denominación de lenguajes.<br />
Para indicar el nivel de habilidad del alumno en el idioma correspondiente<br />
emplearemos varios elementos de tipo proficiency. Estos elementos<br />
incluyen el atributo profmode, cuyos posibles valores son OralSpeak<br />
(hablar), OralComp (escuchar y comprender), Read (lectura) y Write<br />
(escribir).
Figura 3.4.8.1.a. Estructura gramatical del elemento language.<br />
language<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
137<br />
typename<br />
comment<br />
contenttype<br />
proficiency<br />
ext_language<br />
La Figura 3.4.8.1.b muestra el uso de estructuras language para indicar las<br />
habilidades idiomáticas del alumno de ejemplo. Aparte de su conocimiento del<br />
castellano como su idioma nativo, su elevado nivel de inglés queda también reflejado<br />
en el ejemplo.<br />
Figura 3.4.8.1.b. Marcado en XML de los conocimientos idiomáticos del alumno.<br />
<br />
<br />
<br />
Spanish<br />
<br />
Excelente<br />
Excelente<br />
Excelente<br />
Excelente<br />
<br />
<br />
<br />
<br />
English<br />
<br />
<br />
<br />
acc_ingles<br />
<br />
<br />
Excelente<br />
Bueno<br />
Excelente<br />
Bueno<br />
3.4.8.2. Preferencias de acceso: preference<br />
Independientemente de sus posibles discapacidades o limitaciones, los alumnos en<br />
estos sistemas pueden expresar sus preferencias sobre el proceso de aprendizaje,<br />
sobre los formatos a emplear, sus horarios, etc. Existe, además, una tendencia en los<br />
entornos virtuales de enseñanza consistente en adaptar los itinerarios de aprendizaje<br />
en función de los perfiles psicológicos de los alumnos para favorecer sus estilos<br />
individuales de enseñanza. Este tipo de factores se describen empleando elementos<br />
de tipo preference siguiendo la estructura de la Figura 3.4.8.2.a. y empleando los<br />
siguientes elementos:<br />
El elemento typename se emplea para indicar el tipo de preferencia. La<br />
especificación IMS LIP incluye un vocabulario por defecto para este campo que<br />
incluye los términos Cognitive, Physical, InputTech y OutputTech, aunque se<br />
contempla la opción de extenderlo o adaptarlo por parte de las distintas<br />
implementaciones.<br />
El campo principal de un bloque preference es el elemento prefcode.<br />
Dentro de este campo se incluye la referencia o descripción de la preferencia.<br />
El formato concreto a seguir para denominar dichas preferencias depende de<br />
las distintas implementaciones.<br />
El elemento description permite incluir textos explicativos que describan<br />
con mayor detalle la preferencia o incluyan material adicional sobre la misma.<br />
Figura 3.4.8.2.a. Estructura gramatical del elemento preferente.<br />
z preference<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
138<br />
typename<br />
comment<br />
contenttype<br />
prefcode<br />
description<br />
ext_preference<br />
Para ejemplificar el uso de estos elementos, se incluyen posibles preferencias del<br />
alumno del caso de estudio en relación a su estilo de aprendizaje (prefiere un proceso<br />
guiado en lugar de abierto) y su preferencia de formatos de contenido (prefiere recibir<br />
el contenido en formato <strong>PDF</strong> para imprimir los documentos) tal y como se observa en<br />
la Figura 3.4.8.2.b.
Figura 3.4.8.2.b. Marcado en XML de las preferencias del alumno para el proceso<br />
de aprendizaje.<br />
<br />
<br />
<br />
Cognitive<br />
<br />
Aprendizaje guiado<br />
<br />
3.4.9. El elemento goal<br />
139<br />
<br />
<br />
<br />
OutputTech<br />
<br />
Documentos <strong>PDF</strong><br />
<br />
Los distintos alumnos pueden tener distintos objetivos laborales, <strong>educativo</strong>s o incluso<br />
de realización personal. Estos objetivos se pueden representar en secciones de tipo<br />
goal. Las estructuras goal presentan la estructura descrita en la Figura 3.4.9.a,<br />
cuyos elementos principales son los siguientes.<br />
El elemento typename se emplea para indicar el tipo de objetivo. La<br />
especificación IMS LIP incluye un vocabulario por defecto para este campo que<br />
incluye los términos Work, Education, Personal, aunque se contempla la opción<br />
de extenderlo o adaptarlo por parte de las distintas implementaciones.<br />
Se pueden incluir varios elementos de tipo date describiendo las fechas<br />
relativas a dicho objetivo como, por ejemplo, la fecha en la que el alumno<br />
comenzó a perseguir dicho objetivo o el plazo propuesto para alcanzarlo.<br />
El campo priority se emplea para reflejar la prioridad relativa del objetivo.<br />
Este elemento carece de estructura predefinida y no se aporta un vocabulario<br />
concreto para su uso.<br />
El elemento status refleja el estado actual del objetivo (Activo, Conseguido,<br />
Pospuesto, etc.). Dentro de este elemento se pueden incluir, aparte del estado,<br />
la fecha en que se entró en dicho estado o una descripción más detallada del<br />
significado de dicho estado.<br />
El elemento description permite incluir textos explicativos que describan el<br />
objetivo en cuestión.<br />
La posibilidad de incluir más elementos de tipo goal dentro de estas<br />
estructuras permite definir jerarquías de objetivos y sub-objetivos que las<br />
componen.
Figura 3.4.9.a. Estructura gramatical del elemento goal.<br />
z goal<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
140<br />
typename<br />
comment<br />
contenttype<br />
date<br />
priority<br />
status<br />
description<br />
goal<br />
ext_goal<br />
Como se mencionaba en la descripción del caso de estudio en la sección 3.3, el<br />
objetivo del alumno al inscribirse en estos cursos es mantener sus conocimientos<br />
informáticos actualizados. Dada su especialización, al recibir su registro, los<br />
responsables del programa <strong>educativo</strong> analizan el objetivo principal y lo dividen en dos<br />
sub-objetivos que quedan registrados en el perfil del alumno tal y como se puede<br />
observar en la Figura 3.4.9.b
Figura 3.4.9.b. Marcado en XML de los objetivos <strong>educativo</strong>s del alumno del caso de<br />
estudio.<br />
<br />
<br />
<br />
Educational<br />
<br />
Objetivo Principal<br />
<br />
<br />
<br />
Active<br />
<br />
<br />
<br />
Mantener conocimientos actualizados<br />
<br />
<br />
<br />
Aprender nuevos lenguajes de programación<br />
<br />
<br />
<br />
<br />
Conocer las tendencias en el uso de J2EE<br />
<br />
<br />
<br />
3.4.10. El elemento competency<br />
El propósito de las secciones de tipo competency es incluir información sobre las<br />
habilidades obtenidas por el alumno como resultado de su proceso formativo. Cuando<br />
la primera versión de IMS LIP fue publicada, estas secciones tenían un carácter<br />
temporal a la espera de los resultados del grupo de trabajo sobre definición de<br />
competencias (IMS Competency Definition working-group), por lo que su estructura es<br />
muy sencilla tal y como se observa en la Figura 3.4.10.a, incluyendo como campos<br />
relevantes sólo los siguientes:<br />
El campo exrefrecord se emplea para indicar un fichero externo que<br />
contenga la descripción de las habilidades o competencias.<br />
El elemento description permite incluir textos explicativos que describan la<br />
competencia.<br />
141
Figura 3.4.10.a. Estructura gramatical del elemento competency.<br />
z competency<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
142<br />
typename<br />
comment<br />
contenttype<br />
exrefrecord<br />
description<br />
ext_competency<br />
Las definiciones de competencias pueden emplearse también para ofrecer una vista<br />
más detallada de la sección de “Conocimientos Técnicos” del currículum de ejemplo.<br />
Tal y como se ejemplificó en la sección 3.4.7, la experiencia previa del alumno se<br />
puede almacenar dentro de un elemento transcript, pero esas descripciones no<br />
siguen un formato estandarizado.<br />
Asimismo, la última versión de IMS LIP publicada en enero de 2005 (1.0.1) no<br />
contempla ninguna estructuración concreta del elemento competency para aumentar<br />
su funcionalidad (IMS Global Consortium, 2005).<br />
En su lugar, la especificación IMS Reusable Definition of Competency or Educational<br />
Objective (IMS Global Consortium, 2002), descrita en mayor detalle en el capítulo 4,<br />
sugiere emplear el campo description para incluir referencias a documentos XML<br />
con la descripción detallada de las competencias, tal y como se observa en la Figura<br />
3.4.10.b. La estructura detallada de este fichero externo con la definición de la<br />
competencia “Programación imperativa: Pascal” se puede encontrar más adelante en<br />
la sección 4.4.1.
Figura 3.4.10.b. Integración de documentos formalizados mediante la especificación<br />
IMS RDCEO en una sección competency.<br />
<br />
<br />
Programación imperativa: Pascal<br />
<br />
<br />
ficheros/competencia-pascal.xml<br />
<br />
<br />
<br />
<br />
3.4.11. El elemento interest<br />
Las secciones de tipo interest carecen, en principio, de significado <strong>educativo</strong>. Su<br />
propósito es reflejar intereses o aficiones del alumno trascendiendo el ámbito<br />
<strong>educativo</strong>. Tal y como se puede ver en la Figura 3.4.11.a, que describe la estructura<br />
de estas secciones, las aficiones se describen mediante los siguientes campos:<br />
El elemento typename se emplea para indicar el tipo de afición o actividad. La<br />
especificación IMS LIP incluye un vocabulario por defecto para este campo que<br />
incluye los términos Recreational, Vocational y Domestical, aunque se<br />
contempla la opción de extenderlo o adaptarlo por parte de las distintas<br />
implementaciones.<br />
En los casos en que las aficiones del alumno se quieran ejemplificar mediante<br />
trabajos u otros ejemplos, el campo product permite relacionar la definición<br />
de la afición con ficheros externos siguiendo la estructura descrita en la sección<br />
3.4.5.2.<br />
El elemento description permite incluir textos explicativos que aporten más<br />
información sobre la afición.<br />
143
Figura 3.4.11.a. Estructura gramatical del elemento interest.<br />
z goal<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
144<br />
typename<br />
comment<br />
contenttype<br />
product<br />
description<br />
ext_interest<br />
En el caso de estudio, el alumno de ejemplo mencionaba su afición por la fotografía e<br />
incluso aportaba la dirección URL de su álbum de fotos en Internet. La Figura 3.4.11.b<br />
muestra el uso de IMS LIP para registrar esta información mediante una sección<br />
interest.<br />
Figura 3.4.11.b. Uso de la sintaxis IMS LIP para almacenar información relativa a la<br />
afición por la fotografía del alumno del caso de estudio.<br />
<br />
<br />
<br />
Recreational<br />
<br />
<br />
<br />
Photo Album<br />
<br />
<br />
http://www.flickr.com/photos/fulanitoperez/<br />
<br />
<br />
<br />
<br />
<br />
Fotografía Digital<br />
<br />
3.4.12. El elemento securitykey<br />
Las secciones securitykey se emplean para almacenar las contraseñas o<br />
credenciales de acceso del alumno. Se debe emplear una de estas secciones para<br />
cada conjunto de credenciales. La estructura general del elemento securitykey se<br />
puede observar en la Figura 3.4.12.a y sus campos más relevantes son los siguientes:<br />
El elemento typename se emplea para indicar el tipo de credencial de acceso.<br />
El vocabulario por defecto incluye los términos Password, Certificates, PIN y<br />
Username, aunque se contempla la opción de extenderlo o adaptarlo por parte<br />
de las distintas implementaciones.<br />
El elemento keyfields se emplea para indicar una credencial concreta,<br />
incluyendo los campos fieldlabel y fielddata para almacenar<br />
respectivamente la etiqueta y el valor de la credencial.<br />
El elemento description permite incluir textos explicativos que describan el<br />
uso apropiado de la credencial.<br />
Figura 3.4.12.a. Estructura gramatical del elemento securitykey.<br />
securitykey<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. ∞<br />
0 .. 1<br />
0 .. 1<br />
typename<br />
comment<br />
contenttype<br />
keyfields<br />
description<br />
definition<br />
145<br />
0 .. 1<br />
0 .. 1<br />
fieldlabel<br />
fielddata<br />
En el caso de estudio, cuando el alumno se registra en el sistema de gestión del<br />
aprendizaje, éste recibe una contraseña para poder acceder al propio sistema. Esta<br />
contraseña se puede guardar junto con el resto de la información del alumno mediante<br />
la especificación IMS LIP tal y como se muestra en el ejemplo de la Figura 3.4.12.b.<br />
Nótese que, dado lo sensible de la información, se emplea el campo de metadatos
para indicar la privacidad de este dato empleando la sintaxis descrita en la sección<br />
3.4.1.<br />
Figura 3.4.12.b. Uso de la especificación IMS LIP para guardar contraseñas de los<br />
alumnos.<br />
<br />
<br />
<br />
Password<br />
<br />
<br />
<br />
<br />
<br />
Learner<br />
<br />
<br />
<br />
<br />
Access<br />
<br />
<br />
Read,Write,Delete<br />
<br />
<br />
<br />
<br />
<br />
<br />
Clave de acceso al sistema<br />
<br />
<br />
clave_de_ejemplo<br />
<br />
<br />
3.4.13. El elemento relationship<br />
Todos los tipos de sección vistos hasta este momento se emplean para almacenar<br />
distintos tipos de datos. En ocasiones, determinados hechos o datos que estén<br />
almacenados en secciones distintas pueden estar relacionados. El último tipo de<br />
sección, denominado relationship se encarga de establecer las conexiones entre<br />
estas secciones separadas. La estructura gramatical de este elemento se puede<br />
observar en la Figura 3.4.13.a y éstos son sus elementos más relevantes:<br />
El elemento typename se emplea para indicar el tipo de relación establecida.<br />
El vocabulario por defecto incluye los tipos de sección principales de la<br />
especificación IMS LIP (Activity, Accessibility, Affiliation, Competency, Goal,<br />
Identification, Interest, Qcl, SecurityKey y Transcript).<br />
El elemento tuple representa la asociación propiamente dicha, constando a<br />
su vez de los siguientes elementos:<br />
146
- tuplesource representa el origen de la relación y consta básicamente<br />
de una referencia al identificador del elemento que queremos<br />
relacionar.<br />
- tupledest representa el destino de la relación. Es interesante notar<br />
que puede haber más de un elemento tupledest, lo cual permite<br />
establecer relaciones desde un elemento de origen a varios elementos<br />
de destino.<br />
- Finalmente, el elemento tuplerelation se emplea para describir el<br />
tipo de asociación que estamos estableciendo, pudiendo usar para ello<br />
un elemento typename o un elemento text para incluir una cadena de<br />
texto libre.<br />
El elemento description permite incluir textos explicativos que describan<br />
con mayor detalle la relación entre los conceptos conectados.<br />
Figura 3.4.13.a. Estructura gramatical del elemento relationship.<br />
relationship<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
typename<br />
comment<br />
contenttype<br />
tuple<br />
description<br />
ext_relationship<br />
147<br />
1 .. 1<br />
1 .. 1<br />
1 .. ∞<br />
tuplesource<br />
tuplerelation<br />
tupledest<br />
En el caso de estudio, el alumno incluía referencia a la obtención de un certificado de<br />
idiomas (Certificate of Proficiency in English de la Universidad de Cambridge). La<br />
descripción de la certificación en sí la podemos encontrar en la Figura 3.4.4.b dentro<br />
de una estructura qcl. Similarmente, al definir su perfil de accesibilidad en la Figura<br />
3.4.8.1.b. empleamos una entrada en la que se definían precisamente sus habilidades<br />
idiomáticas con el inglés. Las habilidades descritas en la sección de accesibilidad se<br />
basaban precisamente en haber obtenido la certificación. La Figura 3.4.13.b<br />
representa precisamente esta relación, indicando que se empleó la información de la
certificación (con el identificador qcl_cpe, ver Figura 3.4.4.b) para establecer las<br />
habilidades idiomáticas del alumno (con el identificador acc_ingles, ver Figura<br />
3.4.8.1.b.).<br />
Figura 3.4.13.b. Uso de la especificación IMS LIP para representar una relación<br />
entre dos secciones separadas.<br />
<br />
<br />
<br />
acc_ingles<br />
<br />
<br />
<br />
obtenido_de<br />
<br />
<br />
<br />
qcl_cpe<br />
<br />
<br />
<br />
4. IMS REUSABLE DEFINITION OF COMPETENCY OR<br />
EDUCATIONAL OBJECTIVE<br />
4.1. INTRODUCCIÓN<br />
La especificación Reusable Definition of Competency or Educational Objective de IMS<br />
(de ahora en adelante, IMS RDCEO) permite la descripción, referencia e intercambio<br />
de definiciones de competencias principalmente orientadas al contexto de la<br />
enseñanza en línea y a distancia (IMS Global Consortium, 2002). El primer aspecto es<br />
qué se entiende por competencias ya que, aunque es el término habitualmente<br />
empleado como traducción de competency, ni siquiera aparece con esta acepción en<br />
el Diccionario de la Real Academia de la Lengua (www.rae.es). Una traducción<br />
alternativa sería “cualificación” que tiene el significado de preparación para ejercer<br />
determinada actividad o profesión. No obstante, y a pesar del abuso del lenguaje que<br />
supone, seguiremos utilizando el término competencia ya que en esta especificación<br />
se considera en un sentido muy general y engloba conceptos diversos como<br />
habilidades (en inglés skills), conocimientos, tareas, resultados aprendidos (en inglés<br />
learning outcomes) y objetivos del proceso <strong>educativo</strong>.<br />
El propósito de la especificación es representar formalmente las características clave<br />
de una competencia de forma general, es decir, independientemente de un uso<br />
particular determinado o de un contexto concreto de aplicación. De este modo se<br />
posibilita la interoperabilidad entre sistemas de enseñanza heterogéneos que<br />
148
contemplen competencias ya que proporciona un método estándar para referirse a las<br />
mismas de una forma común y con un mismo significado.<br />
El núcleo de la información contemplada en RDCEO es una definición textual no<br />
estructurada de la competencia que puede ser referenciada mediante un identificador<br />
único. Esta información puede ser refinada si se dispone de un modelo definido por el<br />
usuario que proporcione una determinada estructura a dicha competencia. De este<br />
modo esta especificación permite que una comunidad de práctica determinada (un<br />
grupo social con intereses comunes como por ejemplo, la comunidad médica)<br />
formalice e intercambie información de competencias según el modelo propio que ellos<br />
utilicen.<br />
La formalización propuesta por la especificación RDCEO proporciona una forma de<br />
crear un punto de vista común de las competencias que aparecen como parte de la<br />
descripción de un diseño <strong>educativo</strong> o de un plan de formación ya sea como<br />
prerrequisitos de conocimiento o como resultados a obtener. El modelo de información<br />
en esta especificación se puede utilizar con distintos propósitos como, por ejemplo,<br />
para intercambiar las definiciones de competencias entre sistemas de enseñanza,<br />
entre sistemas de gestión de personal o de recursos humanos, entre sistemas de<br />
almacenamiento de contenido <strong>educativo</strong> (repositorios) o entre sistemas de<br />
almacenamiento de habilidades o competencias. RDCEO proporciona referencias<br />
únicas para la descripción de competencias u objetivos educacionales que se puedan<br />
incluir en otros modelos de información (e.g. en la información de los alumnos en un<br />
documento que siga la especificación IMS Learner Information Package tal y como se<br />
describe en el capítulo 3).<br />
RDCEO se basa en un marco general de competencias que puede incluir datos sobre (ver<br />
Figura 4.1.a):<br />
Definición genérica y reusable de la competencia, incluyendo características clave<br />
como, por ejemplo, identificador, título y descripción, pero que no incluye aspectos<br />
contextuales de la competencia.<br />
Contexto en el que se define la competencia o que define dicha competencia. El<br />
contexto puede incluir competencias asociadas con una persona o con la<br />
clasificación de un trabajo.<br />
Evidencias de la competencia tales como resultados de evaluación, hora, fecha,<br />
método de evaluación o identificación de la autoridad de certificación de dicha<br />
competencia.<br />
Dimensiones relacionadas con el contexto, tales como el nivel de interés de la<br />
persona en dicha competencia o la importancia de una competencia para un<br />
puesto de trabajo, o con la propia evidencia, tal como el nivel de alcanzado en una<br />
competencia.<br />
149
Figura 4.1.a. Marco general de competencias de IMS RDCEO.<br />
Definición<br />
150<br />
Contexto<br />
Evidencia<br />
Dimensiones<br />
No obstante, aunque el modelo formal propuesto por RDCEO simplifica procesos de<br />
intercambio e integración de competencias también tiene algunas limitaciones debido<br />
principalmente a que se centra en el formato de los datos en vez de en cómo deben<br />
utilizarse dichos datos. Por ejemplo, permite el intercambio automático de la<br />
información entre sistemas diferentes pero la interpretación de dicha información debe<br />
ser realizada por una persona. Además la especificación no contempla la agregación<br />
de competencias simples en otras competencias de mayor nivel ni aborda cómo<br />
dichas competencias pueden ser contrastadas, certificadas, almacenadas o utilizadas<br />
como parte de un proceso de diseño instructivo o de gestión del conocimiento.<br />
Finalmente, tampoco especifica cómo se estructuran, almacenan o intercambian los<br />
registros de competencias asociados con un individuo.<br />
Esta especificación RDCEO está relacionada con otras especificaciones de IMS como<br />
son IMS LIP, IMS Meta-Data (o su estándar relacionado IEEE LOM) o IMS Simple<br />
Sequencing. Quizás el ejemplo más directo es su uso con IMS LIP ya que en un perfil<br />
determinado las entradas a los objetivos (goals) o competencias (competency) pueden<br />
ser referencias RDCEO. Otro uso indirecto es cuando se referencia un certificado<br />
desde LIP y dicho certificado puede a su vez hacer referencia a una instancia RDCEO<br />
concreta. La relación con LOM es doble: por un lado un registro o instancia RDCEO<br />
puede tener su parte opcional de metadatos asociados que identifiquen aspectos<br />
relativos, por ejemplo, al autor, al catálogo, a la fecha de creación, etc. Por otro lado,<br />
hay campos de LOM que pueden hacer referencia a instancias RDCEO como, por<br />
ejemplo, objetivo educacional o prerrequisito.<br />
Tomando como partida IMS RDCEO la asociación IEEE ha propuesto un nuevo<br />
estándar denominado Reusable Competency Definition (IEEE RCD) que ha sido<br />
formalmente aprobado como el estándar 1484.20.1 (IEEE RCD, 2008) y publicado<br />
definitivamente el 25 de enero de 2008.<br />
Aunque todavía no existen clasificaciones o jerarquías estándar de competencias ni<br />
representaciones o métodos ampliamente aceptados y usados en la industria para<br />
articular organizar e intercambiar competencias entre sistemas sí hay un creciente<br />
interés en el tema. Dos ejemplos de esta situación son los esquemas para la<br />
representación de competencias en el mundo de los recursos humanos desarrollado
por el consorcio HR-XML (http://ns.hr-xml.org/2_3/HR-XML-<br />
2_3/CPO/Competencies.html) y, en el mundo de la medicina, la iniciativa MedBiquitous<br />
(http://www.medbiq.org/working_groups/competencies/index.html) que trata de mejorar<br />
la educación en el campo médico mediante el desarrollo de estándares tecnológicos y<br />
tiene un grupo de trabajo centrado en competencias.<br />
En este capítulo se detallan las características de la especificación IMS RDCEO. Para<br />
ello, se comienza describiendo una visión conceptual de la especificación. Tras esto,<br />
siguiendo el caso de estudio planteado en la sección 3.3 se presenta un ejemplo de<br />
uso consistente en el modelado de una competencia del alumno de ejemplo.<br />
4.2. VISIÓN CONCEPTUAL DE LA DEFINICIÓN DE<br />
COMPETENCIAS<br />
El modelo de datos planteado por RDCEO es minimalista pero extensible. El objetivo<br />
es que permita representar las competencias de una forma simple pero que a la vez<br />
no imponga restricciones sobre qué modelo de competencias se considere o de cómo<br />
se pretendan utilizar. Esto permite que la especificación sea utilizada por diferentes<br />
grupos de interés o comunidades de práctica para intercambiar información de<br />
acuerdo a su propio modelo de competencias (por ejemplo, el modelo HR-XML para el<br />
caso de la gestión de recursos humanos).<br />
La extensibilidad se puede lograr de dos maneras: o bien mediante la propia definición<br />
de competencia u objetivo educacional o bien mediante la inclusión de metadatos<br />
(este aspecto se describe más adelante con mayor nivel de detalle).<br />
El modelo de información propuesto para una definición de competencia reutilizable es<br />
bastante simple y consta de cinco elementos principales (Figura 4.2.a):<br />
Identificador<br />
El campo identificador (identifier) es una etiqueta que identifica de forma unívoca una<br />
definición de competencia o un objetivo educacional. Este identificador es suficiente<br />
para poder hacer referencia a una competencia en cualquier sistema. Este<br />
identificador consta de dos partes: un catálogo y una entrada.<br />
Título<br />
El campo título (title) es una etiqueta obligatoria que identifica la competencia de forma<br />
que pueda ser comprensible para las personas. Habitualmente la referencia unívoca<br />
que es el identificador no da idea de lo que representa dicha competencia. El título<br />
puede repetirse en distintos idiomas.<br />
Descripción<br />
El campo descripción (description) es un campo de texto opcional que describe la<br />
competencia de forma que sea interpretable por una persona. Esta descripción puede<br />
repetirse en varios idiomas.<br />
Definición<br />
El campo definición (definition) es una descripción opcional y estructurada de la<br />
competencia, en la que normalmente se usan atributos tomados de un modelo<br />
151
específico sobre cómo deben estructurarse o definirse estas competencias u objetivos<br />
<strong>educativo</strong>s. Con este propósito una definición puede incluir un identificador opcional<br />
del modelo usado (model) y una colección arbitraria de asertos o expresiones<br />
(statements) que determinan dicha competencia. En una definición reutilizable pueden<br />
aparecer varias definiciones, por ejemplo, para describir una misma competencia de<br />
acuerdo con distintos modelos.<br />
Metadatos<br />
Los metadatos (metadata) son opcionales y corresponden a toda la definición. Se<br />
recomienda que para este campo se empleen los elementos que se consideren<br />
relevantes de los definidos por LOM.<br />
Figura 4.2.a. Estructura de una definición de competencia IMS RDCEO.<br />
competencia<br />
1<br />
1<br />
152<br />
0.. ∞<br />
0.. ∞<br />
0..1<br />
identificador<br />
título<br />
descripción<br />
definición<br />
Metadatos<br />
4.3. EJEMPLOS DE POSIBLES APLICACIONES<br />
Como ya se ha mencionado la especificación se centra en la representación de los<br />
datos de las competencias dentro de su marco general de referencia pero no entra en<br />
cómo deben usarse. No obstante en el documento de buenas prácticas y guía de<br />
implementación que se incluyen con la especificación también se describen algunas<br />
posibles formas en las que se puede aplicar RDCEO.<br />
4.3.1. Casos de uso<br />
Uno de los usos descritos es su aplicación como bloques constructivos para crear<br />
mapas o taxonomías de competencias. Estos mapas o taxonomías serían<br />
básicamente una colección organizada de referencias a definiciones de competencias<br />
RDCEO. Esto normalmente implica incluir información de relación y clasificación y la<br />
forma de realizarlo es mediante el uso del campo de metadatos para cada<br />
competencia.<br />
Un segundo ejemplo típico es el uso de RDCEO en el análisis de habilidades de una<br />
persona. Normalmente los registros de competencias personales contienen<br />
información sobre la evidencia de habilidades o conocimientos (o la ausencia de ellos)
conjuntamente con una referencia a una definición de competencia. Estas definiciones<br />
de competencia también se pueden referenciar desde un determinado modelo de<br />
competencias. Por tanto haciendo la correspondencia entre estos dos usos se puede<br />
generar una colección de referencias de definición de competencias donde se<br />
relacionan habilidades y competencias sin tener que repetir información. Además de<br />
este modo la información se almacena de una forma estándar y, por tanto, de una<br />
forma más interoperable. Este aspecto podría usarse, por ejemplo, en los sistemas de<br />
enseñanza que son capaces de adaptar y personalizar el comportamiento del sistema<br />
para cada usuario concreto, de modo que tener una descripción de sus conocimientos<br />
previos y sus objetivos es crucial en todo el proceso.<br />
Pero quizás el mayor campo de aplicación es en e-learning en relación con el nuevo<br />
modelo introducido con el modelo de objetos de aprendizaje (OA) (Polsani, 2003;<br />
Balatsoukas et al., 2008) y su evolución a unidades de aprendizaje (con el significado<br />
introducido por la especificación IMS LD descrita en la sección 1.5). Si el sistema de elearning<br />
que usa OA tiene incluidos procesos de evaluación del conocimiento<br />
adquirido al superar cada OA, entonces la relación con competencias RDCEO puede<br />
establecerse directamente. En el caso de unidades de aprendizaje que tienen un<br />
mayor tamaño las competencias y objetivos <strong>educativo</strong>s pueden agregarse en<br />
competencias de mayor complejidad.<br />
Esto permite crear nuevos escenarios de uso en el diseño de cursos ya que un<br />
educador podría comenzar el diseño de un curso especificando cuáles son sus<br />
objetivos <strong>educativo</strong>s (learning outcomes) para, a continuación, buscar o desarrollar los<br />
OA o unidades de aprendizaje que mediante su composición permiten obtener los<br />
objetivos <strong>educativo</strong>s deseados. Esto mismo se podría hacer con los procesos de<br />
evaluación formal de la adquisición de dichas competencias (si es que existen).<br />
Este enfoque permite también nuevas oportunidades para los usuarios ya que<br />
simplificaría la localización de cursos en función de los intereses que tengan, del<br />
conjunto de carencias que se quieran resolver o de las habilidades que se necesiten<br />
adquirir para resolver una determinada necesidad (por ejemplo, habilidades o<br />
capacidades laborales necesarias para obtener un mejor puesto de trabajo).<br />
4.3.2. Ejemplo de uso<br />
Para ejemplificar el uso de la especificación RDCEO en las siguientes secciones, se<br />
trata de complementar el caso de estudio propuesto en el capítulo 3. Dicho caso de<br />
estudio incluía un ejemplo de currículum vítae de un alumno con informaciones<br />
diversas que podían ser formalizadas empleando la especificación IMS Learner<br />
Information Package (IMS Global Consortium, 2005).<br />
Desde el punto de vista de la definición de competencias, resulta especialmente<br />
interesante el siguiente fragmento extraído del currículum de ejemplo de la sección<br />
3.3, que nos servirá para ejemplificar el uso de RDCEO para definir competencias.<br />
153
(…)<br />
CONOCIMIENTOS TÉCNICOS<br />
• Programación Imperativa: Pascal<br />
(…)<br />
En el caso de estudio, este fragmento correspondiente a los conocimientos técnicos<br />
del alumno se describía informalmente como parte un bloque de tipo transcript<br />
como se observa en la Figura 3.4.7.b. Tal y como se indicaba en la sección 3.4.10, el<br />
campo description de una definición de competencia en un documento IMS LIP<br />
puede incluir una referencia a un documento externo codificado de acuerdo con la<br />
especificación RDCEO (ver Figura 3.4.10.b). Este documento contiene una descripción<br />
más formal y estructurada de las competencias del alumno. La siguiente sección<br />
describe la estructura detallada de estos documentos de definición de competencias.<br />
4.4. ESTRUCTURA XML<br />
El modelo de información de IMS RDCEO se puede expresar como lenguaje de<br />
marcado XML. En este apartado se describen los distintos tipos de elementos (las<br />
etiquetas) introducidos por dicho lenguaje en el esquema documental (XML schema)<br />
propuesto en la especificación.<br />
En la definición de las competencias hay dos elementos comunes que se utilizan en<br />
distintas partes:<br />
Cadenas de caracteres. Las cadenas de caracteres representan frases<br />
orientadas a ser interpretadas por una persona. Se usa el elemento<br />
langstring que tiene el atributo xml:lang para permitir especificar el idioma<br />
en el que está dicha frase.<br />
Términos de un vocabulario. Los términos de un vocabulario vienen<br />
determinados por el elemento source que identifica el vocabulario fuente y por<br />
el elemento value que describe el término concreto (token) dentro de dicho<br />
vocabulario.<br />
4.4.1. El elemento rdceo<br />
El elemento rdceo es el elemento raíz de los documentos marcados mediante la<br />
especificación IMS RDCEO.<br />
El primer elemento, de carácter obligatorio, es el elemento identifier, que<br />
identifica de forma única a la competencia.<br />
El siguiente elemento es el campo title que debería ser una etique concisa<br />
para que una persona pueda saber de qué trata la competencia.<br />
154
El elemento description permite añadir una descripción en lenguaje natural<br />
que describa la competencia y puede aparecer varias veces, por ejemplo, en<br />
distintos idiomas.<br />
El elemento definition es opcional y contiene una definición estructurada<br />
de la competencia. Esta definición estructurada consiste en una posible<br />
referencia a un modelo y una serie de expresiones (como se describe más<br />
adelante). Si se repite el elemento cada ocurrencia debe corresponder a un<br />
modelo distinto.<br />
El elemento metadata es opcional y contiene metadatos globales a la<br />
competencia. Se recomienda que estos metadatos sigan el estándar LOM.<br />
La Figura 4.4.1.a esquematiza la estructura gramatical del elemento rdceo.<br />
Figura 4.4.1.a. Estructura gramatical del elemento rdceo.<br />
Siguiendo esta estructura, la competencia “Programación Imperativa: Pascal” del caso<br />
de estudio se puede describir con mucho detalle. En la figura Figura 4.4.1.b podemos<br />
encontrar la descripción de acuerdo con el Currículo Conjunto en Computación<br />
definido por el Institute of Electrical and Electronics Engineers (IEEE) y la Association<br />
for Computing Machinery (ACM)<br />
(http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf).<br />
155
Figura 4.4.1.b. Ejemplo de documento IMS RDCEO que define la competencia<br />
“Programación imperativa: Pascal” según el currículo propuesto por los organismos<br />
IEEE y ACM.<br />
<br />
<br />
<br />
http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf#PF1<br />
<br />
<br />
Programación Imperativa: Pascal<br />
<br />
<br />
<br />
Domina los conceptos de la programación imperativa estructurada y el lenguaje de<br />
programación Pascal<br />
<br />
<br />
<br />
IEEE and ACM Join Computing Curricula<br />
<br />
<br />
<br />
Ha superado un curso de Introducción a la Programación centrado en los principios<br />
de la programación estructurada<br />
<br />
<br />
<br />
<br />
<br />
<br />
Domina la sintaxis del lenguaje de programación Pascal<br />
<br />
<br />
<br />
<br />
<br />
<br />
Construcciones fundamentales de la programación imperativa<br />
<br />
<br />
<br />
<br />
<br />
Algoritmos y solución de problemas<br />
<br />
<br />
<br />
<br />
Fundamentos de estructuras de datos<br />
<br />
<br />
<br />
<br />
IMS RDCEO<br />
1.0<br />
<br />
<br />
<br />
<br />
156
4.4.2. El elemento identifier<br />
El propósito del elemento identifier es tener una identificación unívoca de la<br />
competencia. De hecho una vez publicada una competencia nunca debería ser<br />
modificada y si es necesario modificarla habría que crear una nueva o incluso una<br />
copia.<br />
Este identificador es obligatorio y está compuesto de un identificador de catálogo y una<br />
entrada en dicho catálogo que se concatenan con el carácter “#” formando una cadena<br />
única. La idea es que el identificador sea un URN (Universal Resource Name) o una<br />
URI (Universal Resource Indicator). Si no aparece el carácter “#” se asume que la<br />
cadena es la entrada del catálogo y el valor del catalogo es nulo. Por ejemplo, en la<br />
figura Figura 4.4.1.b encontramos la siguiente cadena:<br />
http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/<br />
cc2001/cc2001.pdf#PF1<br />
La primera parte es la dirección web del informe que describe los contenidos del<br />
currículo, mientras que la entrada concreta en dicho catálogo sería “PF1”.<br />
4.4.3. El elemento title<br />
El propósito del elemento title es tener una etiqueta de la definición de competencia<br />
que sea comprensible por una persona. Tiene que haber un único título para cada<br />
definición de competencia pero dicho título puede aparecer en distintos idiomas. Por<br />
ejemplo, una definición con un título tanto en inglés americano como en español sería:<br />
<br />
Imperative Programming: Pascal<br />
<br />
Programación Imperativa:<br />
Pascal<br />
<br />
4.4.4. El elemento description<br />
El propósito del elemento description es tener un campo de texto opcional que<br />
describe la competencia de forma más extensa y que sea entendible por una persona.<br />
Esta descripción también puede repetirse en varios idiomas.<br />
4.4.5. El elemento definition<br />
El elemento definition es opcional y su propósito es poder proporcionar una<br />
definición estructurada de la competencia. Como se observa en la Figura 4.4.5.a, una<br />
definición puede incluir un identificador opcional del modelo usado (model) y una<br />
colección arbitraria de asertos o expresiones (statements) que determinan dicha<br />
157
competencia. En una competencia pueden aparecer varias definiciones, por ejemplo,<br />
para describir esa misma competencia de acuerdo con distintos modelos.<br />
Figura 4.4.5.a. Estructura gramatical del elemento definition (omitiendo<br />
atributos).<br />
definition<br />
0..1<br />
1.. ∞<br />
model<br />
statement<br />
158<br />
0.. ∞<br />
0.. ∞<br />
statementtext<br />
statementtoken<br />
El elemento opcional model permite incluir una cadena que identifique qué modelo se<br />
utiliza como referencia para proporcionar la definición estructurada de la definición.<br />
Este modelo debe ser suficientemente específico para evitar conflictos de nombres,<br />
por tanto, se recomienda que sea una URI (Universal Resource Indicator).<br />
El elemento statement es una colección arbitraria de uno o más asertos o<br />
expresiones que determinan la definición de estructura de la competencia. Cada<br />
expresión es una descripción de una característica de la definición. Una expresión está<br />
compuesta de las siguientes partes:<br />
statementid, este atributo opcional es una cadena de texto que actúa como<br />
identificador local de la expresión dentro del modelo<br />
statementname, este atributo opcional es un token que se usa para etiquetar<br />
la expresión. Este token se toma del vocabulario fuente definido en el modelo<br />
identificado por el elemento model.<br />
statementtext, este elemento opcional es una descripción textual de los<br />
aspectos de la competencia. Este texto puede aparecer repetido en varios<br />
idiomas.<br />
statementtoken, este elemento opcional es un token que se obtiene de una<br />
fuente controlada como, por ejemplo, un vocabulario. Es un término de un<br />
vocabulario y como se ha descrito previamente, está compuesto por dos<br />
elementos que determinan el propio token (value) y la fuente de de la que<br />
proviene (source).<br />
Aunque propiamente dichos todos los elementos y atributos de una expresión son<br />
opcionales, en la práctica en una expresión debe aparecer por lo menos uno de dichos<br />
componentes para que la expresión sea útil. Normalmente si aparece el elemento<br />
statementtext entonces no aparece el elemento statementtoken y viceversa.
4.4.6. El elemento metadata<br />
El elemento metadata es opcional y su propósito es proporcionar un contenedor para<br />
cualquier tipo de metadatos (aunque se recomienda que para estos metadatos se use<br />
el estándar LOM). Los componentes de este elemento son:<br />
rdceoschema, es un elemento opcional que determina el esquema (schema)<br />
documental RDCEO utilizado en la definición de competencia. Si no aparece se<br />
asume que su valor es “IMS RDCEO”. Si aparece otro valor puede indicar que<br />
se está usando un perfil de aplicación concreto (eso sí, no debe usarse para<br />
indicar qué modelo concreto se está empleando).<br />
rdceoschemaversion, es un elemento opcional que permite especificar la<br />
versión del esquema RDCEO que se utiliza. Si no aparece se asume que es la<br />
versión 1.0.<br />
4.5. EXTENSIBILIDAD<br />
Esta especificación contempla desde un principio que, a pesar de la generalidad con la<br />
que se tratan de definir las competencias, puede darse el caso de aplicaciones que<br />
consideren que dichas definiciones son demasiado restrictivas y, por tanto, necesiten<br />
ampliarlas o extenderlas para lograr sus objetivos concretos.<br />
La extensibilidad se puede lograr de dos maneras: o bien mediante la ampliación de la<br />
propia definición de competencia con nuevos elementos y atributos, o bien mediante la<br />
utilización del elemento de metadatos. En la especificación se recomienda que se<br />
emplee la primera de las formas.<br />
La extensibilidad mediante la inclusión de elementos adicionales es posible en los<br />
siguientes elementos:<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Los elementos adicionales deben cumplir dos condiciones: la primera es que deben ir<br />
después de los elementos ya definidos en la especificación, y la segunda es que los<br />
elementos de extensión deben contener una declaración de espacio de nombres<br />
159
diferente a la del elemento contenedor. En este segundo caso el espacio de nombres<br />
puede ser expresado mediante mecanismos de bloque o de prefijo.<br />
Figura 4.5.a. Visualización del schema RDCEO en XMLSpy donde aparece el<br />
mecanismo de extensibilidad extelement para el elemento rdceo.<br />
5. IMS ACCESS FOR ALL<br />
5.1. INTRODUCCIÓN<br />
Una de las principales características de los entornos virtuales de enseñanza es que<br />
universalizan el acceso a la información y el conocimiento, facilitando los procesos de<br />
aprendizaje “en cualquier momento” y “en cualquier lugar”. Pero esta característica<br />
realmente no se extiende a “cualquier persona” ya que muchos de estos sistemas<br />
tienden a excluir a las personas con distintos tipos de discapacidad.<br />
Las más afectadas suelen ser las personas con ceguera total o parcial. Lo más<br />
habitual en estos casos es que los usuarios accedan a Internet empleando<br />
navegadores textuales con capacidad de leer el texto de las páginas web en voz alta,<br />
pero la mayoría de las aplicaciones web, en un intento de mejorar sus diseños y<br />
estética, tienden a ignorar este hecho y emplean elementos que resultan muy<br />
160
disruptivos para este tipo de navegadores (como interfaces realizadas con Flash u<br />
otros elementos activos no textuales).<br />
Existen distintos esfuerzos que intentan conseguir que la Web sea universalmente<br />
accesible, la mayoría de ellos encaminados a crear páginas limpias y organizadas<br />
empleando aquellos elementos del estándar HTML que casan mejor con el uso de<br />
navegadores adaptados para personas con discapacidad. Estándares y<br />
recomendaciones como los propuestos por el Consorcio W3C a través del Grupo de<br />
Trabajo para Guías de Accesibilidad del Contenido Web (Web Content Accessibility<br />
Guidelines Working Group o WCAG WG - http://www.w3.org/WAI/GL/) tratan este<br />
problema de una manera genérica, intentando mejorar la accesibilidad de la web en<br />
general.<br />
En el caso de los entornos virtuales de enseñanza el problema es incluso más<br />
acuciante. Muchos contenidos <strong>educativo</strong>s se basan en el uso de diagramas, imágenes<br />
y vídeos que no son aptos para personas ciegas. Similarmente, un vídeo en el que el<br />
sonido juegue un papel importante (por ejemplo, al incluir una voz que describe los<br />
eventos) no resulta accesible para personas sordas.<br />
Cuanto más ricos y variados son los formatos en los que se plasma el contenido<br />
<strong>educativo</strong>, más necesario se hace ir más allá de las recomendaciones publicadas por<br />
el Consorcio W3C para la generación de documentos accesibles.<br />
5.1.1. Una problemática compleja<br />
AccessForAll es la denominación genérica empleada por el consorcio IMS para<br />
designar sus iniciativas y esfuerzos relacionados con potenciar la accesibilidad de los<br />
contenidos <strong>educativo</strong>s a personas con necesidades especiales derivadas de su<br />
entorno, circunstancias o discapacidades.<br />
Es importante señalar que en aunque otros estándares y recomendaciones emplean el<br />
término “accesibilidad” para referirse a la habilidad de ciertos sistemas de información<br />
para ajustarse a las necesidades de personas con discapacidades, desde IMS se<br />
amplía la definición de este concepto defendiendo que, en ciertos contextos, cualquier<br />
usuario puede necesitar contenidos especialmente adaptados independientemente de<br />
su condición física (por ejemplo, una persona en un sitio público no puede acceder a<br />
contenidos sonoros independientemente de sus condiciones físicas) . Se redefine por<br />
tanto el concepto de “accesibilidad” para incluir cualquier desajuste entre las<br />
necesidades del alumno y las características del contenido <strong>educativo</strong> presentado. Un<br />
sistema se considera accesible si es capaz de modificar su comportamiento y<br />
contenido para ajustarse a las necesidades de los distintos alumnos en los distintos<br />
contextos de aprendizaje. Esto supone ampliar la noción específica de “discapacidad”<br />
por la noción de “diversidad funcional”.<br />
Esto añade una complejidad más en el proceso, al exigir que el proceso de adaptación<br />
para accesibilidad no se centre en alumnos concretos, sino en una combinación del<br />
alumno y el entorno. Para ejemplificar esta problemática, planteamos el siguiente<br />
ejemplo, adaptado a partir de uno de los casos de uso de la especificación IMS<br />
ACCLIP (IMS Global Consortium, 2003):<br />
161
Los técnicos de mantenimiento de una compañía aérea tienen<br />
acceso a un repositorio de materiales didácticos con información<br />
sobre los procesos de reparación y mantenimiento de los motores<br />
de los distintos aviones con los que trabajan. Los trabajadores<br />
suelen acceder a estos contenidos como parte de su programa de<br />
entrenamiento, habitualmente desde su casa. Por otro lado, durante<br />
muchos procedimientos, estos trabajadores emplean ordenadores<br />
portátiles para seguir los contenidos y tutoriales mientras realizan las<br />
reparaciones. Pero estos procedimientos se realizan en entornos<br />
ruidosos (como un hangar de un aeropuerto) y la normativa de<br />
seguridad exige que los trabajadores empleen protecciones<br />
auditivas. Por tanto, uno de estos trabajadores que accede al<br />
sistema desde su casa puede seguir sin dificultad contenidos en<br />
forma de, por ejemplo, video-tutoriales. Pero si el mismo trabajador<br />
accede desde el hangar, el sistema deberá adaptar o sustituir estos<br />
contenidos para permitir su consulta sin necesidad de escuchar los<br />
contenidos sonoros (por ejemplo, añadiendo subtítulos al vídeo).<br />
5.1.2. Tres aspectos de un mismo problema<br />
La idea de partida de la iniciativa IMS AccessForAll es que para garantizar que los<br />
alumnos con necesidades especiales (debidas a condiciones personales o de su<br />
entorno) puedan acceder a los contendos <strong>educativo</strong>s digitales es necesario un<br />
enfoque que ataque el problema desde varias perspectivas distintas (ver Figura<br />
5.1.2.a).<br />
En primer lugar, es necesario ser consciente durante la creación de los contenidos de<br />
aquellas características de los mismos que los pueden hacer poco accesibles, como<br />
por ejemplo el uso de materiales sonoros sin subtítulos descriptivos o el uso de<br />
diagramas que no puedan ser interpretados por sistemas sonoros para personas de<br />
visión limitada. Este primer tema, de gran importancia y complejidad, no es tratado por<br />
IMS a nivel de especificación al considerar que existen numerosos recursos y<br />
materiales con indicaciones sobre la creación de contenidos accesibles. Aún así, el<br />
grupo de trabajo AccessForAll ha publicado un documento con una descripción<br />
abreviada y muy general de algunas de las ideas que deberían aplicarse (IMS Global<br />
Consortium, 2005). Este documento incluye numerosas referencias a información<br />
sobre la creación de contenidos más accesibles.<br />
Pero este problema no es el principal desde el punto de vista de la creación de<br />
entornos virtuales de enseñanza. El problema que debe abordarse y en el que se<br />
centran los esfuerzos de AccessForAll es el de alinear las necesidades de los distintos<br />
usuarios y entornos con los materiales <strong>educativo</strong>s apropiados.<br />
Para cada alumno es necesario conocer sus necesidades personales concretas así<br />
como los posibles contextos que puedan añadir nuevas necesidades puntuales. Una<br />
vez se dispone de esta información, es necesario encontrar los contenidos apropiados<br />
para satisfacer estas necesidades concretas.<br />
Por este motivo, el grupo de trabajo IMS AccessForAll ha publicado dos<br />
especificaciones distintas, las cuales se describen en este capítulo. La especificación<br />
162
IMS Accessibility for LIP (IMS Global Consortium, 2003) extiende la especificación IMS<br />
LIP descrita en el capítulo 3, permitiendo registrar las preferencias y necesidades de<br />
accesibilidad de los alumnos registrados en el sistema en sus distintos contextos.<br />
La especificación IMS AccessForAll Metadata (IMS Global Consortium, 2004), por su<br />
parte, se centra en asociar metadatos relativos a la accesibilidad a los contenidos<br />
<strong>educativo</strong>s desplegados en el sistema.<br />
El proceso de permitir el acceso universal consiste por tanto en encontrar y servir<br />
contenidos cuyos metadatos sobre accesibilidad coincidan con las necesidades del<br />
perfil de cada alumno específico.<br />
Figura 5.1.2.a. Especificaciones y documentos producidos por el grupo de trabajo<br />
IMS AccessForAll.<br />
IMS AccessForAll<br />
MetaData specification<br />
Guidelines for the Development<br />
of Accessible Applications<br />
AccessForAll<br />
5.2. IMS ACCESSIBILITY FOR LIP<br />
163<br />
IMS Accessibility for LIP<br />
specification<br />
La especificación IMS Accessibility for LIP (de ahora en adelante, IMS ACCLIP)<br />
supone una extensión de la especificación original IMS LIP (descrita en el capítulo 3)<br />
orientada a permitir la inclusión en los perfiles de los alumnos información acerca de<br />
sus necesidades derivadas de características ambientales o fisiológicas.<br />
La especificación se centra en dos modificaciones concretas que se realizan sobre la<br />
especificación IMS LIP. La primera, tal y como se describe en la sección 5.2.1 es la<br />
inclusión de estructuras para indicar las preferencias y necesidades de cada alumno<br />
de cara a interactuar con el contenido del sistema. La otra modificación, descrita en la<br />
sección 5.2.2, es la inclusión de mecanismos para definir peticiones especiales de los<br />
alumnos de cara a interactuar con determinados elementos de contenido, como podría<br />
ser la necesidad de usar un intérprete durante un examen.
5.2.1. Definición de Preferencias<br />
Las preferencias que se pueden definir mediante la especificación IMS ACCLIP se<br />
dividen en tres categorías fundamentales:<br />
Formato: Los perfiles de los alumnos pueden incluir peticiones sobre los<br />
dispositivos de salida especiales que pudiesen necesitar así como el formato<br />
de los contenidos a mostrar, incluyendo elementos como los tamaños de los<br />
textos, las combinaciones de colores o el comportamiento de la interfaz de<br />
usuario.<br />
Control: En esta categoría incluimos las necesidades especiales referidas a los<br />
mecanismos de entrada mediante los cuales el alumno interactúa con el<br />
sistema como pueden ser un teclado, un ratón, un sistema de comandos de<br />
voz, un dispositivo de braille, etc.<br />
Contenido: Ciertos contenidos incluyen características que los hacen poco<br />
accesibles como pueden ser diagramas explicativos o recursos sonoros. La<br />
especificación IMS ACCLIP permite definir las necesidades que un alumno<br />
pueda tener de cara a disponer de contenidos alternativos en estos casos.<br />
Por otro lado, como ya se mencionaba en el ejemplo de la sección 5.1.1, los requisitos<br />
de AccessForAll incluyen la posibilidad de que un mismo alumno tenga necesidades<br />
distintas en distintos contextos (distinguiendo por ejemplo entre acceder desde un<br />
ambiente tranquilo o un entorno ruidoso).<br />
Partiendo de estos requisitos, la especificación IMS ACCLIP extiende la funcionalidad<br />
del elemento accessibility de la especificación IMS LIP (ver sección 3.4.8)<br />
añadiendo un nuevo elemento denominado accessForAll 2 , cuya estructura<br />
podemos observar en la Figura 5.2.1.a.<br />
Figura 5.2.1.a. Estructura gramatical del elemento accessForAll empleado para<br />
indicar las preferencias y necesidad de accesibilidad de los alumnos.<br />
accessForAll 1 .. ∞<br />
context<br />
164<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
display<br />
control<br />
content<br />
El elemento accessForAll del perfil de cada alumno puede contener uno o más<br />
elementos de tipo context. Esto permite definir, para un mismo alumno, distintos<br />
2 La especificación IMS LIP incluye el elemento disability originalmente pensado para<br />
cubrir algunos de los aspectos ahora cubiertos por IMS ACCLIP. Con la introducción del<br />
elemento AccessForAll, el elemento disability queda obsoleto y no debe usarse.
perfiles de accesibilidad en función del entorno o la situación en que se encuentre, de<br />
acuerdo con las necesidades identificadas en el ejemplo de la sección 5.1.1, tal y<br />
como se observa en la Figura 5.2.1.b. Cada posible perfil definido puede contener,<br />
opcionalmente, los siguientes elementos:<br />
El elemento display se emplea para definir requerimientos y preferencias<br />
relativas a los formatos y tecnologías de salida empleados por el sistema. Este<br />
elemento, de gran complejidad, permite indicar cuestiones como la necesidad<br />
de emplear software que lea la información textual de la pantalla (así como<br />
todos sus parámetros de configuración), la necesidad de emplear técnicas que<br />
aumenten la legibilidad de los contenidos (por ejemplo, ampliando el tamaño de<br />
las letras o aumentando el contraste), el uso de dispositivos que traduzcan los<br />
textos a braille, etc.<br />
El elemento control se emplea para definir requerimientos y preferencias<br />
relativas a los mecanismos de entrada. Mediante este elemento se pueden<br />
indicar necesidades como el empleo de teclados especiales (con teclas más<br />
accesibles o mostrados por pantalla), emulación del uso del ratón mediante<br />
mecanismos alternativos (uso del teclado o de dispositivos que detectan el<br />
lugar hacia donde apuntan los ojos) o incluso interacción mediante<br />
reconocimiento de voz.<br />
El elemento content, por su parte, se emplea para indicar los tipos de<br />
contenido alternativo que el alumno puede usar en caso de que los contenidos<br />
por defecto no se ajusten a sus necesidades de accesibilidad. Mediante este<br />
elemento se definen, por ejemplo, posibles alternativas al uso de elementos<br />
visuales, alternativas a los elementos sonoros, necesidad de evitar textos o<br />
incluso la necesidad de emplear materiales adicionales como diccionarios o<br />
calculadoras de cara a interactuar con el contenido. Este elemento se refleja<br />
directamente en la especificación IMS AccessForAll Metadata, empleada para<br />
indicar las modalidades de cada unidad de contenido y para describir las<br />
características de los posibles recursos alternativos tal y como se describe en<br />
la sección 5.3.<br />
165
Figura 5.2.1.b. Ejemplos de definición de contextos para su inclusión en el perfil de<br />
un usuario concreto formalizados mediante la especificación IMS ACCLIP. Se<br />
muestran definiciones de contextos para casos de discapacidad visual o para acceso<br />
mediante un dispositivo móvil.<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
5.2.2. Solicitud de servicios adicionales<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Los alumnos con necesidades especiales de accesibilidad pueden necesitar de<br />
apoyos o servicios adicionales cuando interactúan con determinadas unidades de<br />
contenido. Esto es especialmente aplicable cuando tratamos con exámenes y tests<br />
para los cuales un alumno puede solicitar estos apoyos adicionales de cara a realizar<br />
la prueba en las mejores condiciones posibles. Estos apoyos podrían incluir el uso de<br />
un intérprete, ubicarse en una sala distinta al resto de participantes, usar dispositivos<br />
de entrada/salida alternativos o disponer de tiempo adicional para realizar la prueba.<br />
La especificación IMS ACCLIP presenta los elementos necesarios para formalizar y<br />
almacenar el proceso de solicitar estos servicios y la gestión de su autorización si<br />
procede. Según la visión de esta especificación, una autorización para el uso de<br />
servicios adicionales se descompone en las siguientes partes:<br />
Descripción del objeto de aprendizaje: Consiste en identificar a qué examen o<br />
prueba se refiere la solicitud.<br />
166
Petición de servicios: Un texto que contiene la solicitud realizada por el alumno<br />
para disponer de servicios adicionales durante la realización de la prueba.<br />
Descripción de los servicios autorizados: Un texto que contiene la respuesta de<br />
la institución ante la petición del alumno. Este texto puede coincidir o no con la<br />
petición original, en función de si todos los servicios solicitados son<br />
autorizados.<br />
Autorización: Persona responsable de la autorización/denegación de los<br />
servicios solicitados.<br />
Fechas: La fecha en la que se firmó la autorización y el tiempo de expiración de<br />
la misma (si procediese).<br />
Para incluir este tipo de transacciones en el perfil del alumno, la especificación IMS<br />
ACCLIP modifica el elemento eligibility de la especificación IMS LIP (ver sección<br />
3.4.8) añadiendo un nuevo elemento denominado accommodation cuya estructura se<br />
puede observar en la Figura 5.2.2.a.<br />
Figura 5.2.2.a. Estructura gramatical del elemento accommodation empleado<br />
para almacenar las peticiones de servicios de apoyo realizadas por el alumno.<br />
accommodation<br />
1 .. ∞<br />
authorizedDate<br />
expirationDate<br />
accommodatationPackage<br />
1 .. 1<br />
0 .. 1<br />
1 .. 1<br />
1 .. 1<br />
167<br />
atributos<br />
learningObjectDescription<br />
requestForAccommodation<br />
accommodationDescription<br />
authorizedBy<br />
El elemento accommodation consta básicamente de una serie de ocurrencias del<br />
elemento accommodationPackage. Cada una de estas instancias, describe un<br />
proceso de solicitud de servicios de apoyo realizado por el alumno. Este elemento<br />
incluye los atributos authorizedDate y expirationDate empleados para indicar,<br />
respectivamente, la fecha en la que fue autorizada la petición de servicios de apoyo y<br />
la fecha de expiración de dicha autorización. El campo incluye además los siguientes<br />
elementos:
El elemento learningObjectDescription incluye una cadena de texto en<br />
la que se incluye la descripción del examen o prueba al que se refiere la<br />
petición.<br />
El elemento requestForAccommodation contiene una cadena de texto con<br />
la petición original realizada por el alumno.<br />
A su vez, el elemento accommodationDescription contiene la descripción<br />
de los servicios autorizados (o no) por parte del instructor responsable.<br />
El elemento authorizedBy se emplea para identificar al instructor<br />
responsable de la decisión de autorizar o no la solicitud.<br />
El uso de estos elementos se ejemplifica en la Figura 5.2.2.b, donde se representa una<br />
petición de servicios de apoyo solicitada por un alumno con discapacidad visual de<br />
cara a realizar un examen de inglés.<br />
Figura 5.2.2.b. Ejemplo de una petición de servicios de apoyo formalizado mediante<br />
la especificación IMS ACCLIP.<br />
<br />
<br />
Examen de Inglés - Nivel 5 - Junio de 2008<br />
<br />
<br />
Se solicitan los siguientes elementos de apoyo: Realización del examen en una<br />
habitación aparte; disponer de un sistema de lectura automática para escuchar<br />
el contenido; disponer de una máquina Braille para leer el contenido; tiempo<br />
adicional para la realización del examen (un 25% adicional).<br />
<br />
<br />
El alumno podrá realizar el examen en una habitación aparte, podrá emplear la<br />
máquina Braille y dispondrá del tiempo adicional solicitado. No se aprueba el uso<br />
de tecnología de lectura automática pues podría comprometer la neutralidad de<br />
la parte oral del examen.<br />
<br />
<br />
Pedro Fernández - Director de la Escuela de Idiomas UCM<br />
<br />
<br />
5.3. IMS ACCESSFORALL METADATA<br />
Existen distintas especificaciones y estándares para añadir metadatos a los contenidos<br />
<strong>educativo</strong>s con el propósito de facilitar su catalogación, interoperabilidad o su<br />
descubrimiento en repositorios (Fernández-Manjón, Sierra et al. 2007). Pero estas<br />
especificaciones no cubren las necesidades relativas a la accesibilidad de los<br />
contenidos.<br />
La especificación IMS AccessForAll Metadata (IMS ACCMD) intenta cubrir este hueco<br />
definiendo las estructuras de metadatos a emplear para indicar las características<br />
relativas a la accesibilidad de los contenidos <strong>educativo</strong>s.<br />
168
La especificación fue diseñada para actuar como complemento de la especificación<br />
IMS ACCLIP (ver sección 5.2), pudiendo emplear los metadatos definidos mediante<br />
IMS ACCMD para identificar si un determinado contenido se ajusta a las necesidades<br />
indicadas por un alumno concreto en su perfil IMS ACCLIP.<br />
5.3.1. Descripción general<br />
En lugar de emplearse meramente como instrumento para comprobar si un recurso es<br />
apropiado para un determinado alumno en un determinado contexto, la especificación<br />
IMS ACCMD define también los mecanismos para complementar o sustituir los<br />
contenidos que no cumplan determinados requisitos de accesibilidad.<br />
Por poner un ejemplo, una pieza “contenido” puede consistir en un vídeo con narración<br />
y gráficos explicativos. Sus metadatos indicarán por tanto que no es accesible para<br />
personas con discapacidad auditiva (o en ambientes ruidosos) ni para personas con<br />
discapacidad visual (o que escuchan una narración del contenido mientras realizan<br />
alguna otra actividad). Pero estos mismos metadatos pueden incluir referencias a otros<br />
contenidos que extienden o sustituyen al vídeo principal.<br />
Si el perfil del alumno indicase necesidades relacionadas con el uso de imágenes<br />
(discapacidad visual o uso de navegadores que sólo interpreten texto), será necesario<br />
incluir una referencia a un fichero que en lugar del vídeo contenga una descripción<br />
textual del mismo. Este tipo de fichero secundario se denomina “equivalente” dado que<br />
proporciona la misma información que el fichero principal y puede ser empleado en<br />
lugar del mismo.<br />
Por otro lado, si el perfil del alumno indica necesidades especiales relacionadas con el<br />
sonido (discapacidad auditiva, ambiente ruidoso, carencia de equipo sonoro en<br />
dispositivo de acceso…), los metadatos pueden incluir una referencia a un fichero<br />
adicional que contenga los subtítulos para la narración del vídeo. Este fichero<br />
secundario se denomina “equivalente suplementario” ya que modifica el fichero<br />
principal ampliando su usabilidad, siendo posible emplear ambos a la vez.<br />
Como se observa en la Figura 5.3.1.a, un recurso primario puede relacionarse con<br />
distintos recursos equivalentes, pero los recursos equivalentes sólo pueden<br />
relacionarse con un único recurso primario. Esto simplifica las dependencias e impide<br />
que se puedan llegar a crear cadenas de referencias circulares.<br />
169
Figura 5.3.1.a. Relación entre un recurso primario y distintos recursos equivalentes.<br />
Recurso Equivalente<br />
(texto explicativo)<br />
Recurso Equivalente<br />
(subtítulos francés)<br />
Recurso Primario<br />
(video explicativo)<br />
170<br />
Recurso Equivalente<br />
(subtítulos español)<br />
suplementario<br />
Recurso Equivalente<br />
(subtítulos ingles)<br />
La especificación IMS ACCMD distingue por tanto distintos tipos de metadatos para<br />
los recursos primarios y equivalentes. Los recursos primarios consisten en los<br />
documentos originales y es posible que sus creadores no sigan ningún tipo de<br />
recomendación o estándar para garantizar o evaluar la accesibilidad de los contenidos.<br />
Los metadatos de este tipo de recursos se reducen por tanto al mínimo, limitándose a<br />
indicar aspectos como las capacidades sensoriales requeridas (visual, auditiva, etc.),<br />
si el contenido se puede transformar directamente (permitiendo por ejemplo cambios<br />
de tamaño de fuente o distintas combinaciones de colores) y si existe un fichero<br />
alternativo equivalente.<br />
Por otro lado, los recursos equivalentes se crean específicamente para tratar con<br />
problemas de accesibilidad, por lo que los metadatos de este tipo de recursos son<br />
mucho más ricos y detallados.<br />
Como es el caso con todas las especificaciones de IMS, los metadatos de la<br />
especificación IMS ACCMD se definen mediante documentos XML. El elemento base<br />
para los metadatos de un determinado recurso se denomina accessibility y<br />
podemos observar su estructura general en la Figura 5.3.1.b. Los dos elementos<br />
fundamentales para describir la accesibilidad de un determinado recursos son<br />
precisamente los dedicados a definir el recurso primario y los posibles recursos<br />
equivalentes asociados. Los siguientes apartados describen con mayor detalle estos<br />
dos conjuntos de metadatos.
Figura 5.3.1.b. Estructura gramatical de una sección de metadatos sobre<br />
accesibilidad.<br />
accesibility<br />
Elemento<br />
opcional<br />
1 .. 1<br />
0 o más<br />
ocurrencias<br />
resourceDescription<br />
0 .. 1<br />
0 .. ∞<br />
5.3.2. Metadatos para recursos primarios<br />
171<br />
primary<br />
equivalent<br />
Como se mencionaba en la sección anterior, los metadatos empleados para describir<br />
recursos primarios se centran fundamentalmente en tres aspectos:<br />
Modalidades de acceso: Las modalidades de acceso indican los sentidos y<br />
capacidades necesarios para interactuar con el contenido (visión, oído, tacto o<br />
lectura de texto).<br />
Adaptabilidad: Los contenidos primarios de por sí pueden tener la capacidad de<br />
adaptarse a determinadas condiciones.<br />
Recursos equivalentes: El recurso primario puede incluir referencias a aquellos<br />
ficheros equivalentes (suplementarios o no) inicialmente conocidos. Dado que<br />
los ficheros equivalentes incluyen obligatoriamente una referencia al recurso<br />
primario, el uso de referencias en los recursos primarios es opcional (aunque<br />
recomendable).<br />
En la Figura 5.3.2.a podemos observar la estructura de un bloque de metadatos de un<br />
recurso primario, tomando como raíz el elemento primary. Dicho elemento raíz<br />
incluye los siguientes atributos que tratan los aspectos relacionados con las<br />
modalidades de acceso:<br />
El atributo hasAuditory indica si el recurso incluye una componente auditiva,<br />
como puede ser un fichero de sonido o un vídeo con pista de sonido.<br />
El atributo hasTactile indica si es necesario emplear el tacto para interactuar<br />
con este contenido.<br />
Para indicar la presencia de texto que deba ser leído (o interpretado por un<br />
sistema de lectura automática) se emplea el atributo hasText.
Por último, el atributo hasVisual indica la presencia de contenidos visuales<br />
como imágenes, vídeos o animaciones.<br />
Figura 5.3.2.a. Estructura gramatical de una sección de metadatos de un recurso<br />
primario.<br />
atributo<br />
opcional<br />
atributos<br />
? hasAuditory<br />
? hasTactile<br />
? hasText<br />
? hasVisual<br />
primary<br />
172<br />
0 .. ∞ adaptability<br />
0 .. ∞<br />
type<br />
equivalentResource<br />
Dentro del elemento primary podemos incluir varios elementos adaptability, que<br />
describen la adaptabilidad del contenido. Cada uno de estos elementos incluye un<br />
atributo type cuyos posibles valores son “displayTransformability” y “controlFlexibility”,<br />
para indicar respectivamente las alternativas contempladas para modificar la<br />
apariencia del contenido (tamaños de letra, combinaciones de colores, etc.) y los<br />
mecanismos de control (teclado, ratón, lector de braille, etc.). El contenido de estos<br />
elementos es una referencia a un fichero externo con la descripción de estos<br />
mecanismos de adaptabilidad. La especificación IMS ACCMD sugiere emplear<br />
informes EARL (http://www.w3.org/TR/EARL10/) para crear estos ficheros.<br />
Por último, en caso de conocer a priori uno o más recursos equivalentes, podemos<br />
emplear elementos equivalentResource para indicar la ubicación de los mismos,<br />
tal y como se observa en la Figura 5.3.2.b<br />
Figura 5.3.2.b. Ejemplo de metadatos de un recurso primario.<br />
<br />
<br />
documentos/descripcionDelVideo.html<br />
video/subtitulosEspañol.srt<br />
video/subtitulosIngles.srt<br />
video/subtitulosEspañol.srt<br />
<br />
5.3.3. Metadatos para recursos equivalentes<br />
En los casos en los que un recurso primario tenga asociado uno o varios recursos<br />
equivalentes, los metadatos correspondientes a dicho recurso incluirán un bloque<br />
describiendo cada uno de los mencionados recursos equivalentes.<br />
La definición de los metadatos para recursos equivalentes cubre los siguientes<br />
aspectos:<br />
Suplementario o alternativo: Como ya se ha mencionado en la sección 5.3.1,<br />
los recursos equivalentes pueden ser alternativas completas (se emplean en<br />
lugar del recurso primario) o suplementarios (se emplean junto con el recurso<br />
primario).<br />
Recurso principal: Todo recurso equivalente va siempre asociado a un único<br />
recurso principal mediante una referencia al mismo.<br />
Contenido: Como se describe en la sección 5.3.2, los recursos primarios<br />
indican sus modalidades de contenido (texto, imágenes, sonido, etc.). Los<br />
recursos equivalentes ofrecen alternativas a dichas modalidades. Así, un<br />
recurso con los subtítulos de un vídeo puede actuar como alternativa a la<br />
modalidad sonora, pero no a la modalidad visual. Por este motivo es necesario<br />
especificar para qué modalidades un determinado recurso equivalente supone<br />
una alternativa al recurso primario.<br />
La estructura gramatical de los metadatos para un recurso equivalente se puede<br />
observar en la Figura 5.3.3.a. Como indica la figura, el elemento raíz se denomina<br />
equivalent. Este elemento incluye un atributo supplementary empleado para<br />
indicar si es un recurso equivalente suplementario o alternativo. Dentro del elemento<br />
equivalent encontramos también los siguientes elementos:<br />
El elemento primaryResource es obligatorio y consiste en una referencia al<br />
recurso primario relacionado con este elemento equivalente.<br />
Los elementos opcionales primaryFile se emplean para incluir también<br />
referencias a los ficheros concretos que forman el recurso primario.<br />
El elemento content refleja qué tipo de alternativas ofrece este recurso<br />
equivalente ante las modalidades del recurso primario. Sus elementos<br />
constituyentes se relacionan directamente con el modelo de datos del elemento<br />
content de la especificación IMS ACCLIP:<br />
- El elemento alternativesToVisual indica en qué manera el<br />
recurso equivalente supone una alternativa a la modalidad visual del<br />
recurso primario.<br />
- El elemento alternativesToText por su parte indica las alternativas<br />
ofrecidas a la modalidad textual del recurso primario.<br />
173
- El elemento alternativesToAuditory indica en qué manera el<br />
recurso equivalente supone una alternativa a la modalidad sonora del<br />
recurso primario.<br />
- El elemento learnerScaffold se emplea para indicar recursos<br />
adicionales requeridos por el alumno para interactuar con el contenido<br />
como pueden ser un diccionario o una calculadora. En este caso, el<br />
recurso secundario no supone una alternativa en sí, sino que<br />
representa una herramienta externa que el alumno necesita usar para<br />
poder interactuar con el recurso primario.<br />
Figura 5.3.3.a. Estructura gramatical de una sección de metadatos de un recurso<br />
equivalente.<br />
? supplementary<br />
equivalent<br />
1 .. 1 primaryResource<br />
0 .. ∞<br />
0 .. 1<br />
primaryFile<br />
content<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
0 .. 1<br />
174<br />
alternativesToVisual<br />
alternativesToText<br />
alternativesToAuditory<br />
learnerScaffold<br />
En la Figura 5.3.3.b podemos encontrar un ejemplo del uso del elemento equivalent<br />
para marcar dos de los recursos equivalentes del ejemplo de la Figura 5.3.1.a.
Figura 5.3.3.b. Ejemplo de metadatos de un recurso primario.<br />
<br />
<br />
videos/video1<br />
videos/video1.avi<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
videos/video1<br />
videos/video1.avi<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
6. HERRAMIENTAS DE SOPORTE PARA LOS DISEÑOS<br />
EDUCATIVOS<br />
Otra forma alternativa de ver los lenguajes de modelado <strong>educativo</strong> (EMLs de su<br />
término en inglés Educational Modeling Languages) es como lenguajes que<br />
proporcionan un mecanismo a los profesores para que puedan controlar y adaptar un<br />
sistema de gestión de aprendizaje (LMS de su término en inglés Learning<br />
Management System).<br />
Como se ha descrito en el capítulo 1 existen diversos EMLs que varían principalmente<br />
en su generalidad y potencia expresiva. Desde el punto de vista tecnológico, podemos<br />
dividir las herramientas de soporte a EMLs en diversos tipos:<br />
Herramientas de autoría. Dentro de este conjunto se encuentran las<br />
herramientas que son utilizadas principalmente por los profesores para<br />
crear las unidades de aprendizaje (UAs o UoL, por sus siglas del inglés<br />
Units of Learning). Estas UAs pueden verse como plantillas, de modo que la<br />
misma plantilla puede ponerse en práctica, es decir ejecutarse, múltiples<br />
veces con distintos participantes en cada reproducción. El proceso<br />
requerido para poner en práctica una UA una vez creada recibe el nombre<br />
de proceso de publicación.<br />
Herramientas de reproducción. Estas herramientas son utilizadas por los<br />
profesores y estudiantes (los participantes) para interactuar con ejecución<br />
concreta de una UA. En el caso de los alumnos, estas herramientas<br />
permiten acceder a todas las actividades que se incluyen en una UA,<br />
además de realizar la función de portal para el resto de herramientas de<br />
apoyo que se utilizan en las actividades. En el caso de los profesores, estas<br />
175
herramientas sirven para monitorizar el estado de la UA para cada uno de<br />
los alumnos participantes, así como para llevar a cabo las actividades que<br />
tengan asignadas los profesores.<br />
Intérpretes. Los intérpretes son aplicaciones informáticas encargadas de<br />
interpretar el diseño <strong>educativo</strong> descrito en una UA. Su misión es gestionar<br />
las actividades que deben llevar a cabo los participantes de la UA y la<br />
sincronización necesaria que haya entre participantes y actividades. Las<br />
herramientas de interpretación interactúan con las herramientas de<br />
reproducción para coordinar la secuenciación y la sincronización entre los<br />
distintos participantes de la UA.<br />
Herramientas de soporte. Estas herramientas son utilizadas dentro de las<br />
actividades educativas definidas en las UAs. Habitualmente se tratan de<br />
herramientas informáticas que ya existen y que se utilizan directamente o<br />
con ligeras modificaciones para poder ser aplicadas con propósitos<br />
pedagógicos. En IMS LD los requisitos de herramientas de soporte son<br />
especificados en los entornos asociados a las actividades. Algunos<br />
ejemplos de herramientas son los reproductores de contenidos <strong>educativo</strong>s<br />
(e.g vídeos, objetos <strong>educativo</strong>s SCORM, etc.), herramientas de<br />
comunicación para promover el trabajo colaborativo (e.g. chat, foros, etc.),<br />
intercambio de contenidos (e.g. espacio personal, Wiki, etc.), etc. El uso de<br />
estas herramientas enriquecen los diseños de aprendizaje a costa,<br />
habitualmente, de un mayor trabajo por parte del profesor o el personal<br />
técnico. Para simplificar su aplicación, los EMLs normalmente permiten<br />
definir de una forma bastante abstracta las herramientas o servicios<br />
educacionales que estarán disponibles a la hora de crear una UA. De este<br />
modo, las herramientas de interpretación y reproducción de un EML<br />
concreto ya pueden tener en cuenta la necesidad de proporcionar un<br />
conjunto de herramientas de soporte de forma que las tareas de<br />
administración y gestión se ven simplificadas.<br />
En la actualidad podemos encontrar diversas herramientas informáticas aplicadas en<br />
la educación y más en particular en la creación y publicación de unidades de<br />
aprendizaje. Como se introdujo en el capítulo 1 existen diversas aproximaciones a la<br />
hora de crear unidades de aprendizaje. En las siguientes sub-secciones se<br />
introducirán las WebQuest (sección 6.1) como mecanismo de creación de unidades de<br />
aprendizaje informal y JClic (sección 6.2) como herramienta para la creación de<br />
unidades de aprendizaje estructurado. La sección 6.3 introducirá la herramienta LAMS<br />
que, si bien en la actualidad no sigue ningún estándar <strong>educativo</strong> particular, ha tenido<br />
una gran acogida por la comunidad educativa. La sección 6.4 pone en práctica el caso<br />
de estudio del seminario de enología descrito a lo largo del capítulo 2 utilizando LAMS.<br />
Finalmente la sección 6.5 describe cómo poner en práctica el caso de del seminario de<br />
enología utilizando herramientas concretas para la especificación IMS LD.<br />
6.1. WEBQUEST<br />
El concepto de WebQuest fue desarrollado en 1995 por Bernie Dodge y Tom March en<br />
la Universidad Estatal de San Diego (Dodge, 1995; Adell, 2004 y Fernández Carballo-<br />
Calero, 2008). Uno de los objetivos principales de las WebQuest es la integración de<br />
las TIC, en particular internet, en las escuelas. Las WebQuest pueden ser<br />
176
consideradas como un mecanismo informal (o en el mejor de los casos estructurado)<br />
para definir unidades de aprendizaje en las que el proceso de aprendizaje está guiado<br />
y descrito en lenguaje natural.<br />
Una WebQuest es una actividad orientada a la investigación en la que la información<br />
con la que interactúan los alumnos proviene total o parcialmente de recursos de<br />
internet (Dodge, 1995). Las WebQuest pretenden rentabilizar el tiempo del alumno,<br />
centrando su actividad en el uso de la información más que en su búsqueda,<br />
apoyando la reflexión del alumno en los niveles de análisis, síntesis y evaluación.<br />
La estructura que debería tener una WebQuest es la siguiente:<br />
Introducción. Establece el escenario y proporciona la información previa<br />
necesaria para llevar a cabo la tarea.<br />
Descripción de la tarea a realizar. Descripción de la tarea investigadora a<br />
realizar. Se recomienda que sea una tarea factible en tiempo y que, en<br />
particular, sea una tarea de investigación interesante desde el punto de<br />
vista del alumno.<br />
Descripción del proceso a seguir. Descripción del proceso recomendado<br />
a los alumnos para llevar a cabo su tarea. Es recomendable que este<br />
proceso se divida en pasos y tareas más simples.<br />
Descripción de los recursos necesarios. Descripción de los recursos<br />
necesarios para llevar a cabo la tarea propuesta en la WebQuest, en<br />
particular, enlaces a los recursos web necesarios.<br />
Guía para la recolección de información. Descripción acerca de cómo<br />
organizar la información obtenida por los alumnos (e.g. mapas de<br />
conceptos, preguntas y respuestas, etc.) que formará parte de los<br />
resultados de la actividad y que serán entregados por los alumnos.<br />
Conclusiones. Proporciona unas conclusiones para finalizar la tarea<br />
propuesta en la WebQuest. En particular las conclusiones deben hacer<br />
referencia a los conceptos con los que el alumno ha trabajado y los<br />
conceptos que ha aprendido.<br />
La promoción de actividades de investigación siguiendo el paradigma de las<br />
WebQuest ha tenido y tiene una gran aplicación en todo el mundo. Algunos sitios web<br />
interesantes acerca de la creación, aplicación, uso y herramientas aplicables a las<br />
WebQuest son:<br />
http://www.webquest.org<br />
http://questgarden.com/<br />
http://www.xtec.es/~cbarba1/<br />
http://www.aula21.net/index.htm<br />
http://www.isabelperez.com/webquest/<br />
La creación de unidades de aprendizaje en base a las WebQuest se lleva a cabo<br />
mediante la creación de una página web que guíe a los alumnos tanto en el proceso<br />
177
como a los recursos que estos utilizarán durante el uso de la WebQuest. La estructura<br />
de la página web utilizada para guiar el proceso de la WebQuest habitualmente es la<br />
misma, por lo que se han creado un conjunto de plantillas básicas (ver Figura 6.1.a)<br />
para facilitar la creación de un WebQuest por parte de profesores con conocimientos<br />
limitados en informática. Algunas de estas plantillas y herramientas gratuitas para la<br />
creación de WebQuest pueden encontrarse en los enlaces mencionados<br />
anteriormente.<br />
6.2. JCLIC<br />
Figura 6.1.a Ejemplo de plantilla web para la creación de una WebQuest.<br />
La iniciativa JClic (http://clic.xtec.net/es/jclic/) proporciona un conjunto de aplicaciones<br />
informáticas que permiten la autoría y la publicación de unidades de aprendizaje. En el<br />
contexto de JClic una unidad de aprendizaje, denominada proyecto, incluye una o más<br />
actividades educativas junto a una o varias secuencias de dichas actividades. Las<br />
distintas herramientas que se encuentran dentro del contexto de la iniciativa JClic han<br />
sido desarrolladas tras la experiencia del proyecto Clic iniciado en 1992. Además la<br />
iniciativa JClic aloja un repositorio de actividades que pueden ser descargadas y<br />
modificadas (habitualmente bajo licencias que permiten la libre distribución con ciertas<br />
condiciones).<br />
178
La iniciativa JClic distribuye las siguientes herramientas:<br />
JClic Author. La herramienta de autor que permite crear, editar y modificar<br />
actividades a través de una interfaz sencilla y amigable.<br />
JClic Player. Es una aplicación de escritorio que permite ejecutar<br />
secuencias JClic que se encuentran en el ordenador donde está instalado<br />
JClic Player. También existe una versión web, denominada JClic Applet,<br />
que permite incrustar el reproductor JClic dentro de una página web.<br />
JClic Reports. Permite recolectar la información generada por los JClic<br />
Player en una red de ordenadores, por ejemplo un aula, permitiendo la<br />
generación de informes estadísticos sobre los resultados obtenidos por<br />
todos los alumnos.<br />
Como se ha descrito anteriormente una unidad de aprendizaje en JClic se compone de<br />
un conjunto de actividades educativas y la definición de secuencias de actividades<br />
simples. JClic permite la creación actividades educativas de los siguientes tipos:<br />
Asociaciones. Los alumnos tendrán que asociar los conceptos que se<br />
presentan en dos conjuntos de elementos.<br />
Juegos de memoria. Los alumnos tendrán que ir descubriendo parejas de<br />
elementos relacionados que se encuentran escondidos.<br />
Exploración, identificación e información. Permite definir un conjunto de<br />
elementos interactivos. En el caso de las actividades de exploración los<br />
elementos mostrados son reactivos de modo que al hacer clic con el ratón<br />
se muestra información adicional acerca del elemento. En el caso de<br />
actividades de identificación permite definir un conjunto de elementos de<br />
modo que el alumno tiene que elegir cuáles de ellos cumplen una<br />
condición. Finalmente la actividad de información permite definir un<br />
conjunto de elementos interactivos que permiten lanzar contenidos<br />
textuales y multimedia al hacer clic en alguna de las opciones mostradas.<br />
Puzzles. Plantean actividades en las que el alumno debe reconstruir la<br />
información que se presenta inicialmente desordenada. Los tipos de<br />
información que pueden ser incluidos son: gráficos, texto y sonidos.<br />
También es posible combinar distintas fuentes de información.<br />
Respuesta escrita. Permiten la creación de actividades en las que la<br />
respuesta se basa en la escritura de una palabra o frases completas.<br />
Texto. Plantean ejercicios basados siempre en las letras, palabras, frases y<br />
párrafos de un texto que hay que completar, entender, corregir u ordenar.<br />
Además de contenido textual la actividad puede contener contenidos<br />
multimedia y contenidos interactivos.<br />
Sopas de letras y crucigramas. Estas actividades son variantes<br />
interactivas de los conocidos pasatiempos del mismo nombre.<br />
Las secuencias de los proyectos JClic permiten especificar el orden en el que se<br />
muestran las actividades del proyecto a los alumnos. El orden de las actividades de<br />
una secuencia puede definirse de las siguientes formas:<br />
179
Automáticamente. Transcurrido un cierto tiempo desde la finalización de<br />
una actividad se pasa a la siguiente actividad.<br />
Interacción con la actividad. Haciendo clic en alguna casilla que tenga<br />
como contenido activo la acción de saltar a un determinado punto de la<br />
secuencia.<br />
Elegido por el alumno. Haciendo clic en los botones de avance y<br />
retroceso de la interfaz de JClic.<br />
Durante la autoría, el profesor puede definir el comportamiento de los botones de<br />
avance y retroceso que aparecen en la interfaz de JClic Player y que, por defecto,<br />
avanzan a la siguiente actividad o retroceden a la actividad anterior. De forma<br />
adicional, se pueden especificar saltos a actividades concretas de la secuencia e<br />
incluso se pueden definir saltos condicionales en base a los resultados obtenidos o el<br />
tiempo empleado por el alumno en una actividad.<br />
Como ejemplo de proyectos que se pueden encontrar en el repositorio de actividades<br />
de la iniciativa JClic la Figura 6.2.a muestra un conjunto de actividades relacionadas<br />
con la conversión entre sistemas de numeración (Redondo Templado, 2006). La<br />
Figura 6.2.b muestra el informe generado por JClic Player donde se incluyen distintas<br />
medidas que resumen el progreso del alumno con la unidad de aprendizaje: tiempo<br />
invertido, número de actividades y secuencias completadas, porcentaje de completitud<br />
global. Además también se incluye un resumen detallado por actividad en forma<br />
tabular con las mismas medidas. Finalmente, la Figura 6.2.c muestra la unidad de<br />
aprendizaje cargada en el editor de secuencias JClic Author.<br />
180
Figura 6.2.a Ejecución de una secuencia de actividades en JClic sobre el sistema<br />
binario (Redondo Templado, 2006).<br />
181
Figura 6.2.b Informe generado durante la ejecución de las secuencias de<br />
actividades.<br />
182
Figura 6.2.c. Captura de JClic abriendo el proyecto acerca del Sistema Binario<br />
(Redondo Templado, 2006).<br />
6.3. LAMS<br />
6.3.1. Introducción<br />
La herramienta Learning Activity Management System (LAMS) es uno de los proyectos<br />
que se llevan a cabo dentro del Centro de Excelencia en e-learning de la Universidad<br />
de Macquarie en Australia (Macquarie University’s E-Learning Centre Of Excellence,<br />
MELCOE) dirigido por James Dalziel, creador del propio sistema LAMS.<br />
El objetivo de LAMS es proporcionar una herramienta informática para diseñar y<br />
automatizar secuencias de actividades educativas. Dentro del conjunto de actividades<br />
disponibles en la herramienta se pueden encontrar desde actividades que los alumnos<br />
deben llevar a cabo de manera individual (e.g. análisis de contenidos <strong>educativo</strong>s,<br />
183
entregas de trabajos, etc.) a actividades colaborativas que pueden desarrollarse en<br />
grupos reducidos de alumnos dentro de una misma clase o incluso la clase completa<br />
(e.g. sesiones de chat, foros de debate, etc.). La herramienta LAMS puede utilizarse<br />
de manera aislada o en colaboración con otros sistemas de gestión de aprendizaje<br />
ampliamente utilizados como, por ejemplo, Moodle, Sakai y Blackboard. Esta<br />
integración permite la utilización de LAMS desde el LMS que actualmente se esté<br />
usando de manera oficial en la organización o institución educativa pasando a formar<br />
parte del repertorio de recursos disponibles a través de dichas plataformas.<br />
LAMS surge alrededor de 2002 como herramienta informática que cubre algunas de<br />
las deficiencias detectadas en los sistemas de gestión de aprendizaje y en las<br />
propuestas de estandarización educativas de la época y que, al menos en parte,<br />
permanecen en la actualidad. LAMS aborda los mismos problemas que los lenguajes<br />
de modelado <strong>educativo</strong> (ver capítulo 1), en particular, la tendencia de los sistemas y<br />
estándares a centrarse en los contenidos <strong>educativo</strong>s y en los problemas técnicos que<br />
surgen con motivo de facilitar el intercambio de dichos contenidos <strong>educativo</strong>s, dejando<br />
un poco de lado a profesores y alumnos y sus necesidades pedagógicas. LAMS<br />
aborda este problema utilizando las actividades educativas como pieza fundamental y<br />
facilitando la aplicación de diseños de aprendizaje en la creación de secuencias de<br />
actividades.<br />
Cabe destacar que LAMS se inspira en las ideas propuestas en los lenguajes de<br />
modelado <strong>educativo</strong>, en particular, en los lenguajes: Educational Modeling Language<br />
(EML-OUNL) e IMS Learning Design (IMS LD) (ver capítulo 1), sin embargo, LAMS no<br />
es una implementación de referencia de ninguno de estos lenguajes, sino que pone en<br />
práctica el concepto de diseño de aprendizaje promovido por los EMLs. En la<br />
actualidad LAMS (en su versión 2.2) es capaz de exportar las secuencias de<br />
aprendizaje utilizando IMS LD nivel A, sin embargo no permite la importación de<br />
unidades de aprendizaje IMS LD en ninguno de sus niveles.<br />
La herramienta LAMS se ofrece con una licencia doble similar a la licencia del servidor<br />
de base de datos MySQL. El resultado es que LAMS es una herramienta de software<br />
libre bajo las condiciones de la licencia GNU GPL de la Fundación de Software Libre.<br />
En particular, la herramienta LAMS puede obtenerse de manera gratuita desde la<br />
página de la Fundación LAMS (http://www.lamsfoundation.org/) en sus distintas<br />
versiones. Como complemento también se ofrece una licencia comercial dirigida<br />
principalmente a empresas.<br />
Esta sección no pretende ser un manual completo de la herramienta LAMS, sino una<br />
breve introducción a la herramienta y a las posibilidades que ofrece a los profesores<br />
para crear secuencias de aprendizaje. Para un mayor detalle acerca del uso de la<br />
herramienta LAMS, puede consultar las siguientes fuentes de información:<br />
Wiki oficial de LAMS (en inglés). Esta Wiki se actualiza continuamente<br />
con los cambios y características que se incluyen en las nuevas versiones<br />
de LAMS. Pueden encontrase varias secciones dirigidas a desarrolladores<br />
de herramientas, a administradores de LAMS y, principalmente, a<br />
profesores. Gran parte del contenido de esta sección está basado en el<br />
material que está disponible en esta Wiki.<br />
http://wiki.lamsfoundation.org/display/lamsdocs/Home<br />
184
Wiki LAMS en castellano. Esta Wiki es una traducción de la Wiki en<br />
inglés, y aunque se actualiza regularmente, su información puede estar<br />
desfasada respecto a la Wiki en inglés. En particular en esta Wiki (al igual<br />
que en su versión en inglés) se proporcionan unas instrucciones muy<br />
detalladas para la instalación de LAMS.<br />
http://wiki.lamsfoundation.org/display/lamsdocses/Home<br />
Comunidad LAMS. La comunidad de LAMS permite la comunicación y el<br />
intercambio de experiencias entre los profesores que actualmente están<br />
utilizando LAMS. Dentro de esta comunidad se pueden encontrar muchos<br />
ejemplos de secuencias de actividades LAMS, que se pueden importar<br />
directamente en la herramienta de autor para su modificación y posterior<br />
publicación. Además la comunidad LAMS informa acerca de los distintos<br />
eventos de la comunidad en todo el mundo (e.g. conferencias, seminarios,<br />
etc.). Finalmente, esta comunidad sirve como mecanismo para contactar e<br />
intercambiar experiencias con los desarrolladores de LAMS.<br />
http://www.lamscommunity.org<br />
Monográfico sobre LAMS en el Observatorio Tecnológico del ITE<br />
(antiguo CNICE). Proporciona un conjunto de tutoriales que cubren diversos<br />
aspectos de LAMS (de la versión 2.0.4 en la fecha de escritura de este<br />
trabajo), desde su instalación hasta la puesta en práctica de varios casos<br />
de estudio.<br />
http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag<br />
e&pageid=72.<br />
6.3.2. La herramienta LAMS<br />
La herramienta LAMS proporciona una solución completa que puede ser utilizada no<br />
sólo de apoyo y refuerzo a las clases presenciales si no también como una<br />
herramienta de soporte para un curso totalmente online. LAMS ofrece cuatro<br />
perspectivas complementarias basadas en la distinción del papel que juegan los<br />
actores involucrados en el proceso pedagógico:<br />
Reproducción. Esta perspectiva se centra en el papel de los alumnos<br />
proporcionando un reproductor web utilizado para interactuar con las<br />
distintas actividades que se proponen en las secuencias. A través del<br />
reproductor los alumnos pueden acceder a los contenidos y a las<br />
herramientas suministradas en las actividades. Además pueden hacer<br />
anotaciones de su progreso en cada una de las actividades, a modo de<br />
apuntes, y realizar la entrega de ejercicios y trabajos que se propongan en<br />
dichas actividades.<br />
Autoría. Esta perspectiva se centra en el papel de los profesores<br />
encargados de crear las secuencias educativas. La herramienta de autor<br />
proporciona una notación gráfica que permite la creación, almacenamiento<br />
y reutilización de secuencias de actividades. También ofrece la posibilidad<br />
de previsualizar la secuencia que actualmente se está editando.<br />
185
Monitorización y seguimiento. Esta perspectiva se centra en el papel de<br />
los profesores y de los ayudantes del profesor. La herramienta de<br />
monitorización y seguimiento permite al profesor que creó la secuencia (o a<br />
un ayudante del mismo) monitorizar el progreso de los alumnos dentro de la<br />
secuencia. En particular, una parte de las tareas de monitorización es<br />
permitir el avance de los alumnos cuando se han establecido puntos de<br />
sincronización (hitos) dentro de la secuencia de actividades. La herramienta<br />
de seguimiento también se utiliza para evaluar los trabajos enviados por los<br />
alumnos a través de LAMS. Finalmente, cabe destacar que es posible<br />
realizar una edición en vivo (con ciertas restricciones) de las secuencias de<br />
actividades que se están ejecutando. Esto es útil, por ejemplo, para añadir<br />
alguna actividad extra o para modificar alguna de las actividades cuando se<br />
ha cometido un error ortográfico al crear los contenidos o en las<br />
descripciones de las actividades.<br />
Administración. Esta perspectiva se centra en el papel de los<br />
administradores de la instalación de LAMS. LAMS proporciona una interfaz<br />
web simple y a la vez versátil para realizar las tareas básicas de<br />
administración del servidor LAMS. Permite, por ejemplo, la creación de<br />
clases, grupos, usuarios y la asignación de usuarios a grupos y clases.<br />
LAMS incluye una administración jerárquica, de modo que un profesor<br />
pueda administrar sus propias clases lo que simplifica la administración<br />
general del servidor.<br />
El administrador de LAMS es el encargado de la creación de los distintos usuarios que<br />
tendrán acceso a la herramienta y, en particular, la asignación de los privilegios del<br />
usuario permitiendo el acceso a una o varias de las perspectivas descritas.<br />
LAMS es una aplicación web permitiendo que una única instalación de LAMS pueda<br />
ser utilizada por múltiples usuarios. Desde el punto de vista técnico la estructura<br />
interna de LAMS ha sufrido una gran modificación en el paso de la versión 1.0 a la<br />
versión 2.0 con el objetivo de facilitar la integración de LAMS con otras herramientas y<br />
plataformas educativas ya existentes. Esto permite que LAMS pueda ser utilizada<br />
como un recurso adicional dentro de dichas herramientas. No obstante, con la versión<br />
2.2 los desarrolladores de LAMS han dado un paso más allá permitiendo que los<br />
recursos y herramientas de los sistemas en los que LAMS está integrado también<br />
puedan ser utilizados y configurados desde la propia herramienta de autor de LAMS.<br />
Esta nueva característica (que en la redacción de este trabajo estaba todavía en fase<br />
de pruebas) permite que los profesores puedan crear secuencias LAMS utilizando<br />
herramientas que ya conocen, e incluso que colaboren con otras actividades LAMS.<br />
Uno de los casos prueba es el de la configuración de los foros de Moodle desde LAMS<br />
cuando LAMS está integrado dentro de la plataforma Moodle.<br />
Finalmente, como detalle técnico cabe destacar que la herramienta LAMS está<br />
desarrollada utilizando la plataforma Java Enterprise Edition. Para facilitar la creación<br />
de una interfaz atractiva visualmente y que soporte una gran interactividad, la interfaz<br />
web ha sido desarrollada con tecnología Adobe Flash. De este modo los usuarios<br />
finales de la herramienta, profesores y alumnos, pueden utilizar LAMS a través de un<br />
navegador web con la única condición de que tenga soporte para Flash (activado el<br />
complemento o plug-in de Flash). Además, como la herramienta LAMS se ha<br />
186
desarrollado sobre la plataforma Java, un servidor LAMS es compatible con todos los<br />
sistemas operativos comúnmente utilizados como Windows, Linux y Mac.<br />
6.3.3. Actividades, secuencias de actividades y mecanismos de<br />
adaptación<br />
Los dos conceptos fundamentales en LAMS son las actividades educativas y las<br />
secuencias de actividades. A lo largo de esta sección se introducen estos dos<br />
conceptos describiendo sus posibles equivalencias o relaciones con elementos de IMS<br />
LD.<br />
Las actividades educativas LAMS proporcionan un mecanismo simple para configurar<br />
y adaptar herramientas que habitualmente se encuentran en los LMS y en las<br />
plataformas de trabajo colaborativo. De este modo, lo importante son las posibilidades<br />
pedagógicas ofrecidas por la herramienta, pretendiendo simplificar al máximo los<br />
conocimientos técnicos necesarios para su configuración. En comparación con IMS LD<br />
las actividades de LAMS pueden verse como plantillas de las Actividades de<br />
Aprendizaje y sus Entornos asociados (ver sección 2.5.2). En particular, las<br />
actividades LAMS pueden verse como plantillas para los recursos y herramientas que<br />
se proporcionarían en un Entorno IMS LD equivalente.<br />
LAMS ofrece una gran variedad de actividades. A continuación se describen los<br />
distintos tipos de actividades junto a las que están incluidas dentro de dichos tipos:<br />
Actividades de comunicación y colaboración: Foro, Chat, Wiki, DimDim<br />
(herramienta de conferencia web).<br />
Actividades de distribución de contenidos: Cartelera, Compartir<br />
Recursos.<br />
Actividades para evaluar al alumno y entrega de trabajos: Enviar<br />
Archivos, Opción múltiple, Anotador, Preguntas y Respuestas, Lista de<br />
tareas, Votación, Encuestas y Colección de datos.<br />
Otras Herramientas. Mapas (Google Maps), Hojas de cálculo.<br />
Actividades combinadas. Permiten configurar dos herramientas a la vez<br />
de modo que el alumno tenga la pantalla dividida en dos mitades<br />
permitiendo el uso de ambas herramientas al mismo tiempo. Estas<br />
herramientas son particularmente útiles, por ejemplo, para escenarios en<br />
los que uno de los alumnos actúa de escriba o secretario en una sesión de<br />
chat resumiendo los aspectos más importantes debatidos durante la sesión.<br />
Las secuencias de actividades no son más que un conjunto de actividades LAMS<br />
sobre las que se ha definido un orden concreto. La Figura 6.3.3.a muestra un ejemplo<br />
de secuencia de actividades LAMS compuesta por las actividades: Actividad 1 (de tipo<br />
Cartelera), Actividad 2 (de tipo Encuesta) y Actividad 3 (de tipo Envío de Archivos). Sin<br />
embargo, en este ejemplo aún no se ha establecido el orden entre actividades. El<br />
orden entre las actividades de una secuencia LAMS se define mediante el uso de una<br />
notación de flecha. Estas flechas se denominan “transiciones” en LAMS. La figura<br />
Figura 6.3.3.b muestra las mismas actividades de ejemplo y su ordenación utilizando<br />
187
la notación flecha, donde el orden concreto de las actividades es: primero la Actividad<br />
2, después la Actividad 1 y finalmente la Actividad 3.<br />
Figura 6.3.3.a. Ejemplo de notación gráfica para actividades LAMS sin definir el<br />
orden de las actividades.<br />
Figura 6.3.3.b. Ejemplo de notación gráfica para actividades y la definición del<br />
orden entre las actividades.<br />
Además de secuencias de actividades puramente lineales, LAMS ofrece la posibilidad<br />
de incluir los siguientes elementos dentro de una secuencia:<br />
Grupos. Los grupos permiten definir agrupaciones de alumnos dentro de<br />
una clase, de modo que una actividad pueda ser asignada a un grupo de<br />
estudiantes en vez de a la clase completa [ver Figura 6.3.3.c 1)]. Este<br />
mecanismo permite la creación de pequeños grupos de trabajo facilitando el<br />
uso de las herramientas de comunicación como el chat y el foro. Los grupos<br />
pueden ser elegidos y creados por el profesor cuando se llega a la actividad<br />
de grupo (a través de la interfaz de seguimiento) o LAMS puede generarlos<br />
aleatoriamente en base a la configuración de número de grupos y/o<br />
participantes por grupo. Es posible crear varios grupos en una misma<br />
secuencia, dejando que en cada actividad se pueda seleccionar si se usa o<br />
no algún tipo de agrupación. Los grupos de LAMS se asemejan a los roles<br />
de IMS LD pero su aplicación es diferente. Los roles en IMS LD se utilizan<br />
para asignar actividades a un grupo de alumnos concreto, sin embargo, en<br />
LAMS los alumnos deben llevar a cabo todas las actividades de la<br />
secuencia y los grupos se usan como mecanismo para establecer grupos<br />
de trabajo reducido en tareas colaborativas.<br />
Actividades Opcionales. Este mecanismo define un conjunto de<br />
actividades de las cuales el alumno puede elegir cuales desea llevar a cabo<br />
[ver Figura 6.3.3.c 2)]. El profesor puede configurar cuál es el número<br />
mínimo y máximo de actividades que el alumno debe llevar a cabo para<br />
considerar que la actividad opcional ha sido completada. Nótese que es<br />
posible incluir una actividad opcional dentro de otra actividad opcional<br />
188
permitiéndose la creación de actividades complejas. Este mecanismo es<br />
similar a las Actividades Estructuradas de tipo selección que existen en IMS<br />
LD.<br />
Puertas. Las puertas permiten que los profesores puedan definir puntos de<br />
espera dentro de una secuencia de actividades [ver Figura 6.3.3.c 3)]. De<br />
este modo, los alumnos no pueden avanzar a la siguiente actividad hasta<br />
que la puerta se "abra". Las puertas pueden configurarse para que se abran<br />
cuando lo decida el profesor (a través de la interfaz de seguimiento) o<br />
cuando todos los alumnos han finalizado la actividad previa a la puerta. Las<br />
puertas son similares a los mecanismos de finalización de las Actividades,<br />
Actos y Guiones de IMS LD.<br />
Figura 6.3.3.c. Notación visual para distintos elementos de control utilizados en las<br />
secuencias de actividades. 1) Notación visual para la definición de grupos. 2) Notación<br />
visual para la definición de actividades opcionales y 3) notación visual para las<br />
puertas.<br />
Con las versiones 2.1 y 2.2 de LAMS se han introducido nuevos tipos de actividades y<br />
características que enriquecen los mecanismos para adaptar las secuencias a los<br />
conocimientos y destrezas de los alumnos. Estos nuevos mecanismos se basan en la<br />
ramificación de la secuencia principal, de modo que cada alumno o grupos de alumnos<br />
puedan pasar por distintas ramas de la secuencia principal. Las nuevas características<br />
que influyen en la personalización y adaptación de las secuencias de actividades son:<br />
Puertas mejoradas. Se introducen la espera basada en tiempo y la espera<br />
condicional. Las puertas con espera basada en tiempo se abren<br />
automáticamente transcurrido un cierto lapso de tiempo desde el comienzo<br />
de la ejecución de la secuencia. Las puertas de espera condicional<br />
bloquean el paso de un alumno hasta que la condición no se haga cierta<br />
para dicho alumno. Las posibles condiciones de espera son iguales a las<br />
condiciones que se pueden utilizar en las ramificaciones (por simplicidad se<br />
189
describen más adelante). En ambos casos el profesor (o ayudante del<br />
profesor) puede abrir la puerta saltándose las restricciones temporales o las<br />
condiciones.<br />
Grupos mejorados. Se permite que los estudiantes se agrupen ellos<br />
mismos. Desde LAMS se puede establecer el número máximo de grupos (y<br />
sus nombres) y los estudiantes elegirán en qué grupo desean participar.<br />
También se ofrece la posibilidad de especificar el número máximo de<br />
estudiantes por grupo, de modo que LAMS generará automáticamente los<br />
grupos según se vayan llenando los que ha creado.<br />
Secuencias opcionales. Este nuevo mecanismo permite la definición de<br />
un conjunto de secuencias (hasta diez) de las cuales el alumno puede<br />
elegir algunas secuencias a realizar [ver notación gráfica en Figura 6.3.3.d<br />
2)]. De manera similar a las actividades opcionales, el profesor define el<br />
número mínimo y máximo de secuencias que el alumno debe realizar para<br />
considerar finalizada la actividad de secuencias opcionales. La Figura<br />
6.3.3.d 2) muestra un ejemplo de secuencias opcionales. Las actividades<br />
de cada una de las secuencias aparecen en la misma fila y con un color de<br />
fondo distinto. Las actividades están identificadas por su icono<br />
correspondiente. El orden de las actividades de una secuencia se define<br />
ordenando las actividades (de izquierda a derecha) dentro de cada una de<br />
las filas que representan a las secuencias, es decir, la actividad más a la<br />
izquierda se ejecuta en primer lugar y la que está en el extremo derecho en<br />
último lugar. En el caso del ejemplo, la primera secuencia contiene (en este<br />
orden): una actividad de tipo Colección de datos, una actividad de tipo<br />
Compartir Recursos y una actividad de tipo Encuesta. La segunda<br />
secuencia contiene (en este orden): una actividad de tipo Cartelera y una<br />
actividad de tipo Foro de discusión. Nótese que las secuencias que se<br />
incluyen dentro de la actividad opcional no tienen por qué tener la misma<br />
longitud. Al igual que con las actividades opcionales, es posible incluir<br />
dentro de una secuencia cualquier tipo de actividad (incluidas las<br />
actividades opcionales, secuencias opcionales y ramificaciones)<br />
permitiendo crear secuencias complejas.<br />
Actividades de Ramificación. Las ramificaciones son similares a las<br />
actividades y secuencias opcionales ya que permiten crear secuencias de<br />
actividades paralelas. Sin embargo, en las ramificaciones el alumno no<br />
decide la actividad o secuencia que va seguir sino que automáticamente se<br />
le asigna una secuencia concreta. Al igual que con las secuencias<br />
opcionales dentro de una actividad de ramificación se pueden incluir otras<br />
ramificaciones y otras actividades opcionales. Este mecanismo de<br />
ramificación es similar al uso de las condiciones de IMS LD para ocultar y<br />
mostrar Actividades dentro de un mismo Acto. Los mecanismos para decidir<br />
automáticamente qué rama sigue un alumno concreto son:<br />
- Seleccionado por el profesor. El profesor (o el ayudante) a través de la<br />
herramienta de seguimiento asigna a los alumnos una rama concreta al<br />
llegar a la actividad de ramificación.<br />
- Basado en grupos. Los alumnos son asignados automáticamente a las<br />
distintas ramas dependiendo de alguna agrupación que se haya<br />
realizado en la secuencia. Durante la creación de la actividad de<br />
190
amificación el profesor decide cómo se asignan los grupos a cada una<br />
de las ramas.<br />
- Condicional basado en el resultado de otras actividades. Los alumnos<br />
son asignados automáticamente a las distintas ramas dependiendo de<br />
los resultados que hayan obtenido en alguna de las actividades<br />
anteriores a la actividad de ramificación. Al igual que en las puertas, la<br />
descripción de las condiciones se realiza más adelante.<br />
Notificaciones. Las notificaciones son un mecanismo de comunicación de<br />
LAMS con los alumnos y profesores que están involucrados en la ejecución<br />
de una secuencia de actividades. LAMS notifica, enviando un correo<br />
electrónico, eventos importantes que han sucedido durante la ejecución de<br />
alguna de las actividades de la secuencia. Por ejemplo, en las actividades<br />
de tipo Enviar Archivo el autor de la secuencia puede configurar que se<br />
envíe un correo electrónico cuando los alumnos hayan enviado sus trabajos<br />
y, de manera similar, los alumnos pueden recibir una notificación indicando<br />
que las notas de los trabajos enviados ya están disponibles. Aunque las<br />
notificaciones no modifican el número o tipo de actividades que realiza un<br />
alumno, sí modifican el modo de trabajo tanto de los alumnos como de los<br />
profesores. Con el uso de las notificaciones, profesores y alumnos no<br />
tienen que acceder al sistema para comprobar si se han enviado trabajos o<br />
si ya están corregidos. Las notificaciones recuerdan al mecanismo de<br />
notificación de IMS LD. Sin embargo, a diferencia de las notificaciones de<br />
LAMS, las de IMS LD pueden modificar el número de actividades que un<br />
alumno debe realizar.<br />
191
Figura 6.3.3.d. Notación visual para distintos elementos de control avanzados<br />
utilizados en las secuencias de actividades. 1) Notación visual las actividades de<br />
ramificación. 2) Notación visual para la definición de secuencias opcionales.<br />
Las condiciones juegan un papel importante en las ramificaciones y en las puertas, ya<br />
que permiten personalizar la secuencia de las actividades teniendo en cuenta la<br />
participación y contribución del alumno en las actividades. Las condiciones LAMS son<br />
expresiones que, como resultado de su evaluación, generan los valores cierto<br />
indicando que la condición se cumple y falso en caso contrario. A modo de ejemplo,<br />
durante la creación de una actividad de ramificación el profesor crea condiciones y las<br />
asigna a cada una de las ramas. Cuando el alumno llega a la actividad de ramificación<br />
LAMS evalúa las condiciones y automáticamente asigna al alumno la ramificación<br />
cuya condición es cierta.<br />
Las condiciones tienen en cuenta los resultados generados en las actividades, por<br />
ejemplo, la nota que ha obtenido un alumno en una actividad de tipo Opción Múltiple.<br />
LAMS proporciona una interfaz amigable para definir condiciones basadas en los<br />
resultados que generan las actividades. LAMS distingue dos tipos de resultados de<br />
actividades:<br />
Resultados específicos. Los creadores de LAMS han identificado algunas<br />
medidas que pueden ser útiles para medir el rendimiento o desempeño del<br />
alumno en la actividad. Un ejemplo es la actividad de tipo Foro que permite<br />
crear condiciones en base al número de contribuciones del alumno en dicho<br />
foro. Otro ejemplo es la actividad de tipo Opción Múltiple que permite definir<br />
condiciones en base a la puntuación que ha obtenido el alumno en el test o<br />
simplemente si ha acertado todas las preguntas o no. En la versión 2.2 de<br />
LAMS sólo las actividades de tipo Foro y Opción Múltiple ofrecen resultados<br />
específicos que se pueden utilizar en la creación de condiciones. No<br />
obstante, los propios desarrolladores fomentan la participación de la<br />
comunidad para identificar nuevas medidas que sean útiles a la hora de<br />
crear estas condiciones.<br />
Resultados textuales. Existen varias actividades dentro del repertorio que<br />
ofrece LAMS donde el resultado que genera el alumno es texto. Estos<br />
resultados textuales permiten la creación de condiciones basadas en la<br />
192
úsqueda de palabras clave, fragmentos de frases, etc. Los tipos de<br />
actividades que generan resultados textuales y que, por tanto, permiten<br />
crear condiciones basadas en texto son: Encuesta, Foro, Preguntas y<br />
Respuestas, Anotador, Chat y Foro.<br />
6.3.4. Configuración y uso básico de LAMS<br />
A lo largo de esta sección se introducen los conceptos básicos y se describen los<br />
primeros pasos necesarios para trabajar con LAMS versión 2.2 y abordar así el caso<br />
de estudio de la sección 6.4.<br />
A modo de repaso de algunos conceptos ya introducidos a lo largo del capítulo y como<br />
base para introducir nuevos, se definen, a continuación, los conceptos básicos<br />
necesarios para trabajar con LAMS:<br />
Clases. Una clase en LAMS puede verse como una asignatura o curso.<br />
Desde el punto de vista LAMS una clase es un mecanismo para asociar un<br />
grupo de estudiantes con uno o más profesores. Dentro de una clase se<br />
pueden crear grupos de estudiantes. Nótese que estos grupos de alumnos<br />
no están relacionados con los grupos que se pueden incluir dentro de una<br />
secuencia.<br />
Roles. Los roles permiten definir las funcionalidades de LAMS a las que<br />
tiene acceso un usuario. Los roles se asignan dentro de una clase (o grupo)<br />
de modo que es posible que un usuario pueda tener distintos roles en<br />
distintas clases (o grupos). Los roles disponibles dentro de LAMS son:<br />
- Autor. Este rol permite crear secuencias de actividades con la<br />
herramienta de autoría y permite publicarlas en alguna de las clases o<br />
grupos en los que el profesor tiene rol de autor. El rol de autor es uno<br />
de los roles que típicamente tiene asignado un profesor.<br />
- Monitor. Este rol da acceso a la herramienta de seguimiento. La<br />
herramienta de seguimiento es utilizada por los profesores para<br />
monitorizar el progreso de los alumnos, corregir trabajos enviados por<br />
los alumnos, creación de agrupaciones de estudiantes, abrir puertas,<br />
etc. El rol de monitor está asociado a los profesores y ayudantes del<br />
profesor.<br />
- Alumno. Este rol da acceso al reproductor de secuencias. El<br />
reproductor de secuencias permite interactuar con las actividades que<br />
el profesor ha definido en una secuencia.<br />
- Roles administrativos. LAMS ofrece un conjunto adicional de roles que<br />
habitualmente son asignados a los profesores. Estos roles permiten<br />
realizar tareas típicamente administrativas, como la creación de grupos,<br />
usuarios y asignación de usuarios a grupos. No obstante, las tareas<br />
administrativas están restringidas a una clase concreta y no al servidor<br />
completo.<br />
Actividades. Desde el punto de vista del profesor, las actividades son las<br />
distintas herramientas que puede utilizar en la herramienta de autoría para<br />
193
crear secuencias de actividades. Desde el punto de vista del alumno, las<br />
actividades son las tareas educativas que debe realizar como parte del<br />
proceso de aprendizaje.<br />
Secuencias de actividades. Las secuencias de actividades son un<br />
conjunto de actividades para las que se ha definido un orden concreto. Un<br />
profesor puede crear progresivamente varias secuencias que residen en un<br />
espacio de trabajo privado al que únicamente tiene acceso dicho profesor.<br />
Publicación de secuencias de actividades. Las secuencias de<br />
actividades pueden ser consideradas como plantillas en las que los<br />
participantes concretos no están definidos. El proceso de publicación<br />
permite al profesor crear una instancia concreta de la plantilla para un<br />
conjunto concreto de alumnos. Es posible publicar una plantilla en una<br />
clase o en un grupo particular que se haya definido dentro de la clase.<br />
Nótese que es posible tener publicadas múltiples secuencias dentro de una<br />
clase o grupo de modo que el alumno puede ir progresando en cada una de<br />
ellas.<br />
Como paso previo a la puesta en práctica del caso de estudio de la sección 6.4, es<br />
necesario tener acceso a un servidor LAMS donde se puedan realizar las pruebas,<br />
para ello se puede:<br />
Instalar el servidor LAMS. La documentación de la Wiki del proyecto<br />
LAMS (ver sección 6.3.1) describe cómo obtener e instalar el servidor<br />
LAMS, así como integrar LAMS con otros LMS.<br />
Utilizar el servidor LAMS de demostración. La Fundación LAMS<br />
proporciona un servidor de demostración (disponible en<br />
http://demo.lamscommunity.org/) que se puede utilizar para realizar pruebas<br />
básicas. Se puede solicitar una cuenta de usuario que tiene asignada los<br />
roles de autor, monitor y estudiante en un grupo que existe por defecto en<br />
ese servidor de demostración.<br />
Para un primer contacto con LAMS es recomendable el uso del servidor de<br />
demostración para poder realizar las primeras pruebas, no obstante, si finalmente se<br />
desea poner en práctica una secuencia con alumnos reales es recomendable la<br />
instalación de un servidor LAMS propio.<br />
Si se opta por la instalación del servidor LAMS, en la sección 6.3.4.1 se proporciona<br />
una guía básica de configuración de dicho servidor. Tanto si se ha optado por la<br />
instalación del servidor LAMS como si se utiliza el servidor de demostración, la sección<br />
6.3.4.2 describe brevemente las características principales de la interfaz gráfica de la<br />
herramienta de autoría y la publicación de secuencias previamente creadas.<br />
Finalmente, la sección 6.3.4.3 proporciona una breve introducción a la herramienta de<br />
seguimiento utilizada para la monitorización y para realizar el seguimiento en las<br />
secuencias publicadas.<br />
194
6.3.4.1. Administración básica de LAMS<br />
Una vez instalado el servidor LAMS 2.2 se puede acceder utilizando un navegador<br />
(con las opciones de instalación por defecto) a través de la dirección web<br />
http://localhost:8080/lams.<br />
La instalación por defecto de LAMS permite el uso de la mayoría de características<br />
que ofrece LAMS. No obstante, se recomienda llevar a cabo los siguientes pasos:<br />
1. Configurar las opciones de correo. Con el objetivo de enviar notificaciones<br />
desde el servidor de LAMS, es necesario configurar el servidor de correo saliente<br />
(servidor SMTP) que utilizará LAMS para enviar notificaciones.<br />
2. Verificar las herramientas habilitadas. El administrador del servidor puede<br />
habilitar o deshabilitar las herramientas que ofrece LAMS. Por ejemplo, el<br />
administrador puede deshabilitar la herramienta de chat si no se tiene acceso a<br />
ningún servidor de chat. El conjunto de herramientas habilitadas serán las<br />
herramientas que están disponibles a través de la herramienta de autoría.<br />
3. Crear clases y grupos de ejemplo. Como paso previo a la puesta en práctica del<br />
caso de estudio del seminario de Iniciación a la Cata descrito a lo largo del capítulo<br />
2, es recomendable crear una nueva clase de ejemplo con dos grupos.<br />
4. Crear cuentas de usuario para la clase de ejemplo. Para poder probar las<br />
distintas perspectivas que ofrece LAMS es recomendable crear al menos un par de<br />
cuentas de usuario: una como profesor y otra como alumno. No obstante, por<br />
completitud, más adelante se crearán cuentas de usuario para todos los<br />
personajes que se describen en el caso de estudio.<br />
5. Asignación de usuarios a una clase (o grupo) y su rol. Una vez creadas las<br />
clases, grupos y las cuentas de usuario hay que asignar (matricular) las cuentas de<br />
usuario a la clase (o grupo) correspondiente. Además, como parte de la asignación<br />
de usuarios a clases (o grupos) es necesario asignar el rol (o roles) con el que<br />
participará el usuario en la clase (o grupo).<br />
Para configurar las opciones del servidor es necesario conectarse al sistema como<br />
administrador (nombre de usuario sysadmin, contraseña sysadmin en la instalación<br />
por defecto). Una vez que el administrador se ha conectado al sistema es necesario:<br />
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).<br />
2. Seleccionar la opción Editar Configuración de Sistema (ver Figura 6.3.4.1.b).<br />
3. Introducir el nombre del servidor SMTP que utilizará LAMS para enviar<br />
notificaciones. El nombre del servidor SMTP (o servidor de correo saliente)<br />
puede consultarse en las opciones de cuenta de correo en las aplicaciones de<br />
gestión de correo electrónico como Microsoft Outlook o Mozilla Thunderbird<br />
(ver Figura 6.3.4.1.c).<br />
195
Figura 6.3.4.1.a. Captura de pantalla con la página inicial del administrador del<br />
sistema.<br />
Figura 6.3.4.1.b. Captura de pantalla de parte de las opciones disponibles en la<br />
Administración de Sistema.<br />
196
Figura 6.3.4.1.c. Captura de pantalla parcial del editor de configuración del sistema.<br />
Los valores que aparecen son meramente informativos.<br />
Para verificar las herramientas que están habilitadas en el servidor LAMS es<br />
necesario:<br />
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).<br />
2. Seleccionar la opción Administración de Actividades de Enseñanza (una de las<br />
últimas opciones disponibles).<br />
3. Comprobar el valor de la columna Función (columna más a la derecha de la Figura<br />
6.3.4.1.d). Las actividades que tienen valor Desactivado, se encuentran<br />
actualmente activadas. Las actividades que tienen valor Activado, se encuentran<br />
actualmente desactivadas. Todas las actividades que aparecen en la Figura<br />
6.3.4.1.d menos la herramienta de Escriba se encuentran actualmente activadas.<br />
Con la configuración por defecto, sólo están desactivadas las actividades de<br />
Escriba y DimDim. Para activar o desactivar una herramienta, simplemente hay<br />
que hacer clic sobre el valor correspondiente de la columna Función, de modo que<br />
si el valor que aparece es Activado la herramienta se activará. Del mismo modo, si<br />
el valor que aparece es Desactivado, al hacer clic sobre el valor la herramienta se<br />
desactivará.<br />
197
Figura 6.3.4.1.d. Captura de pantalla parcial de la opción de Administración de<br />
Actividades de Enseñanza.<br />
Tras realizar la configuración básica del servidor, es conveniente crear una clase para<br />
realizar las pruebas con las secuencias de actividades. Como complemento también<br />
pueden crearse grupos de alumnos dentro de la clase.<br />
LAMS ofrece dos posibilidades para crear nuevas clases y grupos: mediante un<br />
formulario web o utilizando un documento de hoja de cálculo. Para simplificar el<br />
proceso de creación de la clase de prueba, se describirán los pasos necesarios para<br />
crear la clase de prueba Iniciación a la Cata (utilizada en el caso de estudio de la<br />
sección 6.4) usando un documento de hoja de cálculo. Al igual que el resto de tareas<br />
administrativas es necesario conectarse al servidor como administrador y seguir los<br />
siguientes pasos:<br />
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).<br />
2. Seleccionar la opción Importar Clases y descargar el documento de hoja de cálculo<br />
lams_groups_template.xls. Dentro de esta opción se describe brevemente la<br />
sintaxis que deben seguir los datos del documento de hoja de cálculo para que se<br />
puedan procesar correctamente. Una vez descargado este documento se puede<br />
editar con cualquier herramienta que soporte el formato de archivos .xls como, por<br />
ejemplo, Microsoft Excel, Open Office Calc o incluso Google Docs.<br />
3. Una vez editado el documento de hoja de cálculo el contenido del mismo debería<br />
ser similar al que aparece en la figura Figura 6.3.4.1.e. La primera línea del<br />
documento proporciona una cabecera para las columnas útiles del documento. El<br />
resto de filas del documento están agrupadas en bloques separados por una fila en<br />
198
lanco. Cada bloque representa la definición de una clase y de grupos dentro de la<br />
clase. La primera fila del bloque representa la definición de la clase (en la Figura<br />
6.3.4.1.e se está definiendo la clase Iniciación a la Cata) y las filas restantes<br />
representan definiciones de grupos dentro de dicha clase (en la Figura 6.3.4.1.e se<br />
definen los grupos Nuevos alumnos y Antiguos alumnos). El significado de las<br />
columnas es el siguiente:<br />
Name(250). Nombre de la clase (o grupo) a crear con una longitud máxima de<br />
250 caracteres.<br />
Code(20). Código de la clase (o grupo) a crear con una longitud máxima de 20<br />
caracteres.<br />
Description(250). Descripción de la clase (o grupo) a crear con una longitud<br />
máxima de 250 caracteres.<br />
Locale_id. Entero que identifica el idioma que tiene asociada la clase (o grupo).<br />
El valor 1 equivale al idioma inglés y el valor 2 equivale al idioma español.<br />
admin_add_new_users, admin_browse_all_users, admin_change_status. Son<br />
columnas relativas a permisos de administración dentro de la clase. Se<br />
recomienda asignar el valor "0" a estas columnas.<br />
Figura 6.3.4.1.e. Captura de pantalla del documento de hoja de cálculo utilizado<br />
para crear la clase de prueba Iniciación a la Cata.<br />
Tras crear la clase de prueba, también es necesario crear cuentas de usuarios para<br />
los participantes ficticios del seminario Iniciación a la Cata que fue descrito a lo largo<br />
del capítulo 2. Al igual que el resto de tareas administrativas es necesario conectarse<br />
al servidor como administrador y seguir los siguientes pasos:<br />
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).<br />
2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de<br />
cálculo lams_users_template.xls. Dentro de esta opción se describe brevemente la<br />
sintaxis que deben seguir los datos del documento de hoja de cálculo para que<br />
puedan ser procesados correctamente.<br />
3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería<br />
ser similar al que aparece en la Figura 6.3.4.1.f. La primera línea del documento<br />
proporciona una cabecera para las columnas útiles del documento. El resto de filas<br />
199
del documento representan nuevas cuentas de usuarios que serán creadas en el<br />
servidor LAMS. En la Figura 6.3.4.1.f se están definiendo cuentas de usuario para<br />
cada uno de los usuarios ficticios que aparecen en la Figura 2.5.2.c del capítulo 2.<br />
Las columnas marcadas con un asterisco representan las columnas para las que<br />
obligatoriamente se debe proporcionar un valor. El significado de las columnas<br />
obligatorias es el siguiente:<br />
login. Nombre de la cuenta de usuario con la que se accederá a LAMS. Todas<br />
las cuentas de usuario deben tener nombres distintos.<br />
password. Contraseña de acceso a LAMS.<br />
First_name. Nombre real del usuario.<br />
Last_name. Apellidos del usuario.<br />
Email. Dirección de correo electrónico utilizada para el envío de<br />
comunicaciones.<br />
Figura 6.3.4.1.f. Captura de pantalla del documento de hoja de cálculo utilizado<br />
para crear las cuentas de usuario para los usuarios ficticios del caso de estudio del<br />
capítulo 2.<br />
Finalmente, una vez creadas la clase y las cuentas de usuario, es necesario asignar<br />
las cuentas de usuario a la clase (o grupo) y además asignarle el rol (o roles) que<br />
tendrá el usuario dentro de la clase (o grupo). Al igual que en el resto de tareas<br />
administrativas es necesario conectarse al servidor como administrador y seguir los<br />
siguientes pasos:<br />
1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a).<br />
2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de<br />
cálculo lams_roles_template.xls. Dentro de esta opción se describe brevemente la<br />
sintaxis que deben seguir datos del documento de hoja de cálculo para que se<br />
puedan procesar correctamente.<br />
200
3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería<br />
ser similar al que aparece en la Figura 6.3.4.1.g. La primera línea del documento<br />
proporciona una cabecera para las columnas útiles del documento. El resto de filas<br />
del documento representan la asignación de roles por usuario y clase (o grupo). En<br />
la Figura 6.3.4.1.g se están asignando los permisos a cada una de las cuentas de<br />
usuario y grupos definidos anteriormente. En particular, todas las cuentas de<br />
usuario tienen asignado el rol learner (estudiante) salvo la cuenta del profesor<br />
Corbinus Bodeguero que tiene además asignados los roles: author (autor) y<br />
monitor (monitor). Las columnas marcadas con un asterisco representan las<br />
columnas para las que obligatoriamente se debe proporcionar un valor. El<br />
significado de las columnas obligatorias es el siguiente:<br />
login. Nombre de la cuenta de usuario a la que se le va a asignar un rol.<br />
organisation. Identificador de la clase o grupo donde se va asignar el rol. El<br />
identificador de clase o grupo puede consultarse en el listado de clases a<br />
través de la opción Administración de Cursos y Clases que se encuentra<br />
accesible desde la página inicial de las opciones de administración (ver Figura<br />
6.3.4.1.a).<br />
roles. Lista de roles (separados por el carácter "|") que serán asignados a la<br />
cuenta de usuario en la clase (o grupo) especificado. Los posibles valores para<br />
los roles son: learner, author y monitor.<br />
Figura 6.3.4.1.g. Captura de pantalla del documento de hoja de cálculo utilizado<br />
para asignar los roles a los usuarios ficticios del caso de estudio del capítulo 2.<br />
201
6.3.4.2. Autoría y publicación de secuencias LAMS<br />
En esta sección se proporcionará una introducción a las herramientas que<br />
habitualmente maneja un profesor dentro de LAMS para crear nuevas secuencias de<br />
actividades y para publicarlas en alguna de sus clases.<br />
La Figura 6.3.4.2.a muestra la página inicial del Profesor Corbinus cuando se conecta<br />
a LAMS. Ya que el profesor Corbinus tiene asignado el rol de autor, esta página<br />
contiene la opción Diseño de ... [ver Figura 6.3.4.2.a 1)] que permite acceder a la<br />
herramienta de autoría.<br />
Figura 6.3.4.2.a. Captura de pantalla de la página inicial del Profesor Corbinus al<br />
conectarse a LAMS. 1) Botón para abrir la herramienta de autor. 2) Botón para publicar<br />
una secuencia creada.<br />
Una vez que se hace clic sobre el botón Diseño de ... se abre una nueva ventana que<br />
incluye la herramienta de autoría (ver Figura 6.3.4.2.c). Utilizando esta herramienta,<br />
Corbinus puede crear secuencias para representar cada uno de los escenarios<br />
<strong>educativo</strong>s que tiene en mente (ver sección 3.2).<br />
En la parte superior de la herramienta se puede encontrar el menú de opciones y justo<br />
debajo una barra de botones de acceso rápido. Algunas de las funcionalidades que se<br />
ofrecen a través del menú Archivo son:<br />
Las opciones Abrir, Guardar y Guardar como ofrecen las funciones básicas<br />
para poder abrir, guardar y crear una nueva secuencia de actividades<br />
dentro del espacio privado de trabajo que cada usuario tiene asignado.<br />
Estas opciones también están disponibles a través de la barra de botones.<br />
202
La opción Exportar permite exportar la secuencia que actualmente se está<br />
editando. La exportación de secuencias facilita que la secuencia pueda ser<br />
reutilizada por otro profesor. LAMS ofrece la posibilidad de exportar una<br />
secuencia utilizando el formato interno de LAMS o utilizando IMS LD (sólo<br />
nivel A).<br />
La opción Importar permite importar secuencias que han sido creadas por<br />
otro profesor, sin embargo, sólo se admiten secuencias en formato LAMS.<br />
La opción de Insertar permite insertar una secuencia previamente guardada<br />
en la secuencia que se está editando actualmente.<br />
La opción Salir permite salir de la herramienta de autoría, también es<br />
posible cerrar el editor cerrando directamente la ventana del navegador. En<br />
cualquiera de los casos, la herramienta verifica si la secuencia se ha<br />
guardado, ofreciendo la posibilidad de realizarlo si todavía no se había<br />
hecho.<br />
El menú Editar contiene las opciones habituales para Copiar y Pegar actividades,<br />
además de ofrecer la posibilidad de Deshacer y Rehacer las operaciones que se han<br />
realizado en el editor. Aunque no aparezca en el menú editar de manera explícita, los<br />
comandos copiar, pegar y deshacer pueden invocarse con las teclas de acceso rápido<br />
habituales.<br />
Al seleccionar alguna de las opciones Abrir o Guardar se abre una ventana (ver Figura<br />
6.3.4.2.b) similar al explorador de archivos del sistema operativo, que permite<br />
gestionar el espacio personal del profesor. Este espacio personal tiene una parte<br />
privada (identificada por el nombre del usuario) donde el profesor almacena las<br />
secuencias que ha creado e importado. Además, el profesor también tiene acceso a<br />
las secuencias que han sido publicadas en cada una de las clases (y grupos) en las<br />
que es profesor, las haya creado o no él mismo. A través del explorador se permiten<br />
gestionar carpetas y archivos (secuencias de actividades) del espacio privado del<br />
profesor.<br />
En el ejemplo de la Figura 6.3.4.2.b aparece el espacio de trabajo de Corbinus con<br />
tres secuencias (UACata1, UACata1_1 y UACata2) dentro de su espacio privado, sin<br />
embargo no aparece ninguna secuencia en el espacio de trabajo para la clase de<br />
Iniciación a la Cata ya que todavía no se ha publicado ninguna.<br />
203
Figura 6.3.4.2.b. Interfaz gráfica del gestor de espacio de trabajo del usuario.<br />
En la parte central de la herramienta de autoría [ver Figura 6.3.4.2.c 1)] se encuentra<br />
el espacio de trabajo donde se crean las secuencias de actividades. En la parte<br />
izquierda de la herramienta de autoría [ver Figura 6.3.4.2.c 2)] se encuentra la librería<br />
de actividades donde se listan todas las actividades que pueden ser incluidas en las<br />
secuencias de actividades, en particular, las básicas y las combinadas descritas en la<br />
sección 6.3.3. Para añadir una actividad simplemente hay que arrastrarla desde la<br />
librería al espacio de trabajo. Dentro del espacio de trabajo también hay una papelera<br />
que se usa para borrar elementos de la secuencia (tanto actividades como<br />
transiciones). Para borrar un elemento de la secuencia hay que arrastrarlo a la<br />
papelera.<br />
En la barra de botones [ver Figura 6.3.4.2.c 3)] también se ofrece acceso a (de<br />
izquierda a derecha):<br />
La herramienta de transición. Esta herramienta se usa para definir el<br />
orden entre las actividades. Una vez pulsado el botón Transición el puntero<br />
del ratón cambia a un lápiz para advertir que se va a crear una transición. Si<br />
se desea crear una transición entre las actividades A y B (de modo que la<br />
actividad A se lleva a cabo antes que la B) hay que hacer clic sobre A y<br />
arrastrar el puntero del ratón hasta que esté sobre B. Una vez creada la<br />
transición aparece una flecha entre las actividades A y B.<br />
204
Actividades y secuencias opcionales. Al pulsar el botón Opcional se<br />
despliega una lista que incluye las opciones de creación de una actividad o<br />
secuencia opcional. Al seleccionar cualquiera de las dos opciones el<br />
puntero del ratón cambia indicando que la herramienta está activa, para<br />
crear el elemento simplemente hay que hacer clic sobre el espacio de<br />
trabajo.<br />
Elementos de control de flujo. Al pulsar el botón Flujo se despliega una<br />
lista que incluye las opciones de creación de una puerta o una actividad de<br />
ramificación. Al seleccionar cualquiera de las dos opciones el puntero del<br />
ratón cambia indicando que la herramienta está activa, para crear el<br />
elemento simplemente hay que hacer clic sobre el espacio de trabajo.<br />
Previsualización. Utilizando esta opción es posible previsualizar y probar<br />
la secuencia que se está creando desde la propia herramienta de autoría.<br />
Figura 6.3.4.2.c. Interfaz gráfica de la Herramienta de Autoría. 1) Espacio de<br />
trabajo. 2) Librería de actividades. 3) Herramienta de transición, actividades de<br />
adaptación y previsualización. 4) Botón de expansión de la sección de propiedades.<br />
205
Una vez creada una actividad es necesario precisar los detalles de la misma (e.g.<br />
nombre, descripción, si se aplica a grupos, etc.). La personalización de una actividad<br />
se lleva a cabo a través de las Propiedades de la actividad. Las propiedades de una<br />
actividad pueden modificarse en dos lugares:<br />
Inspector de propiedades. El inspector de propiedades incluye las<br />
propiedades más comunes. El inspector de propiedades de una actividad<br />
puede abrirse seleccionando la actividad en el espacio de trabajo (hacer clic<br />
sobre la actividad) y pulsando el icono con forma de ventanas [ver Figura<br />
6.3.4.2.c 4)] que se encuentra en la parte inferior derecha de la herramienta<br />
de autoría. El resultado será similar al mostrado en la Figura 6.3.4.2.d. Las<br />
propiedades que comúnmente se pueden modificar a través del inspector<br />
de propiedades son:<br />
- Título. Permite editar el nombre de la actividad que aparece dentro<br />
del icono de cada actividad que hay en el espacio de trabajo.<br />
- Grupos. Permite seleccionar si hay una única actividad para toda la<br />
clase (valor ninguno) o si hay una actividad por cada grupo. Nótese<br />
que en la lista desplegable aparecerán los nombres de las<br />
agrupaciones disponibles. La Figura 6.3.4.2.e muestra un ejemplo<br />
de secuencia con una actividad (Introducción) y tres actividades de<br />
agrupación (Agrupación 1, Agrupación 2 y Agrupación 3). En el<br />
ejemplo, sólo las actividades de agrupación: Agrupación 1 y<br />
Agrupación 2, participan en la secuencia, por lo que sólo estas dos<br />
aparecerán entre las posibilidades ofertadas en la propiedad Grupos<br />
para la actividad Introducción.<br />
- Actividad Offline. Permite marcar una actividad como actividad a<br />
realizar fuera de LAMS, por ejemplo, una clase presencial.<br />
- Definir en seguimiento. Una actividad que tiene marcada esta<br />
propiedad puede ser modificada mientras la secuencia se está<br />
ejecutando. El profesor puede cambiar el contenido de la actividad a<br />
través de la herramienta de seguimiento.<br />
- Conectar objetivos. A partir de LAMS 2.2 es posible definir una lista<br />
de objetivos <strong>educativo</strong>s que el autor de la secuencia desea cubrir<br />
con las actividades de la secuencia. El profesor puede crear y editar<br />
esta lista a través del editor de objetivos <strong>educativo</strong>s que puede<br />
abrirse seleccionando el menú Herramientas, Editor de Objetivos<br />
(Figura 6.3.4.2.f). Una vez que la lista de objetivos ha sido creada,<br />
las actividades de la secuencia pueden conectarse a los objetivos<br />
<strong>educativo</strong>s a través de la opción Conectar objetivos del inspector de<br />
propiedades (ver Figura 6.3.4.2.g), que permite al profesor marcar<br />
aquellos objetivos <strong>educativo</strong>s que son cubiertos total o parcialmente<br />
por la actividad.<br />
Página de propiedades. La página de propiedades permite modificar el<br />
contenido y el comportamiento de las actividades. Para acceder a la página<br />
de propiedades de una actividad es necesario hacer doble clic sobre la<br />
actividad. Las opciones de la página de propiedades se describirán más<br />
adelante.<br />
206
Figura 6.3.4.2.d. Detalle de las propiedades de una actividad y de la edición de<br />
objetivos <strong>educativo</strong>s.<br />
Figura 6.3.4.2.e. Detalle de la edición de la propiedad Grupos para una actividad.<br />
207
Figura 6.3.4.2.f. Editor de Objetivos Educativos.<br />
Figura 6.3.4.2.g. Diálogo de conexión de objetivos <strong>educativo</strong>s con actividades.<br />
La página de propiedades de una actividad permite configurar su contenido y su<br />
comportamiento. Al hacer doble clic sobre una de las actividades que se encuentra<br />
dentro del espacio de trabajo de la herramienta de autor, aparece una ventana similar<br />
a Figura 6.3.4.2.h. Esta página contiene un conjunto de propiedades que son comunes<br />
a todas las actividades LAMS e incluso permite editar propiedades que son<br />
particulares de cada una de las actividades. La página de propiedades se encuentra<br />
divida en tres secciones:<br />
Básico. Dentro de este apartado se permite editar el contenido de la<br />
actividad. Todas las actividades permiten dar un título y redactar una<br />
descripción (que puede incluir contenidos multimedia) de la actividad. Este<br />
título y el contenido se muestran a los alumnos, de modo que pueden ser<br />
utilizados para describir la actividad. Además, cada tipo de actividad puede<br />
208
incluir dentro de esta sección contenidos adicionales, por ejemplo, en la<br />
actividad de tipo Compartir Recursos se permite añadir los recursos (e.g<br />
archivos, enlaces) que van a ser compartidos en la actividad.<br />
Avanzado. Dentro de esta sección se pueden editar algunas propiedades<br />
relacionadas que modifican el comportamiento de la actividad. Una<br />
propiedad que siempre está disponible es la de Añadir Anotaciones. Al<br />
activar Añadir Anotaciones el alumno tiene la posibilidad de, tras finalizar la<br />
actividad, anotar el proceso que ha seguido para completar la actividad. De<br />
forma adicional, cada actividad tiene otras propiedades, por ejemplo, la<br />
actividad de tipo Compartir Recursos incluye propiedades que pueden ser<br />
activadas para permitir a los alumnos compartir sus propios recursos (e.g.<br />
archivos y enlaces) con sus compañeros.<br />
Instrucciones. Dentro de esta sección se permite al autor de la secuencia<br />
incluir las pautas que se deben seguir para llevar a cabo esta actividad,<br />
tanto si la actividad se realiza dentro de LAMS como si la actividad es<br />
externa (actividad offline). Estas instrucciones sólo están disponibles para<br />
los profesores (y ayudantes del profesor). De este modo, las instrucciones<br />
pueden servir para que el profesor que ha creado la secuencia pueda<br />
documentar su diseño pedagógico y describir las instrucciones o pautas<br />
que considere oportunas para llevar a cabo la actividad.<br />
Figura 6.3.4.2.h. Página de propiedades de la actividad Introducción.<br />
209
Una vez que Corbinus ha creado las secuencias que ha considerado oportunas, debe<br />
publicarlas para ponerlas en práctica con los alumnos del seminario de Iniciación a la<br />
Cata. Corbinus puede publicar la secuencia utilizando la opción Agregar Lecciones<br />
que aparece en su pantalla inicial [ver Figura 6.3.4.2.a 2)]. Al seleccionar Agregar<br />
Lecciones aparece una ventana similar al explorador de archivos (ver Figura 6.3.4.2.i),<br />
en la que se puede seleccionar alguna de las secuencias a las que Corbinus tiene<br />
acceso. Estas secuencias pueden ser privadas, es decir, secuencias que todavía no<br />
ha publicado o puede ser alguna secuencia publicada de alguno de los cursos en los<br />
que está registrado como profesor (con rol autor). En el ejemplo mostrado en la Figura<br />
6.3.4.2.i aparecen tres secuencias privadas: UACata1, UACata1_1 y UACata2, junto a<br />
las secuencias que están publicadas en las clases en las que Corbinus está registrado<br />
como profesor (cursos MATH111 e Iniciación a la Cata).<br />
Figura 6.3.4.2.i. Diálogo de selección de secuencias utilizado al añadir secuencias a<br />
clases y grupos.<br />
210
Una vez que Corbinus selecciona la secuencia UACata1 para ser publicada, al pulsar<br />
el botón Continuar aparece un nuevo diálogo en el que Corbinus puede seleccionar a<br />
los estudiantes y ayudantes del profesor que participarán en la secuencia. La Figura<br />
6.3.4.2.j muestra todos los usuarios que están registrados en la clase Iniciación a la<br />
Cata divididos en los grupos Antiguos alumnos y Nuevos alumnos. Corbinus<br />
selecciona a todos los alumnos y a él mismo para participar dentro de la secuencia<br />
que está publicando.<br />
Figura 6.3.4.2.j. Diálogo de selección de participantes.<br />
Una vez que Corbinus ha seleccionado a los participantes y pulsa el botón Continuar,<br />
aparece el último cuadro de diálogo del proceso de publicación (ver Figura 6.3.4.2.k).<br />
Este último diálogo, permite dar un nombre y una descripción a la secuencia que se<br />
está publicando. De manera complementaria, se puede seleccionar si se permitirá<br />
editar la secuencia durante su ejecución (edición en vivo) utilizando la herramienta de<br />
seguimiento y si los alumnos podrán guardar el trabajo que han realizado a lo largo de<br />
la secuencia (exportar porfolio). Finalmente se puede decir si la secuencia estará<br />
211
disponible inmediatamente para los alumnos (opción por defecto) o si estará disponible<br />
a partir de una fecha y horas concretas.<br />
Figura 6.3.4.2.k. Diálogo utilizado para ultimar los detalles de publicación de la<br />
secuencia de actividades.<br />
Una vez publicada la secuencia, ésta aparece (identificada por el título que le hemos<br />
dado en Figura 6.3.4.2.k) dentro de la clase o grupo donde ha sido creada. En la<br />
Figura 6.3.4.2.l aparece la secuencia UACata1 que Corbinus acaba de publicar dentro<br />
de la clase de Iniciación a la Cata. Se incluyen, además, los enlaces para participar<br />
dentro de la secuencia [ver Figura 6.3.4.2.l 1)] y para monitorizar la secuencia [(ver<br />
Figura 6.3.4.2.l 2)].<br />
212
Figura 6.3.4.2.l. Página inicial de Corbinus una vez publicada la secuencia<br />
UACata1. 1) Enlace que permite a Corbinus interactuar con la secuencia como un<br />
alumno. 2) Enlace que permite abrir la herramienta de seguimiento.<br />
6.3.4.3. Monitorización y Seguimiento.<br />
El objetivo de la herramienta de seguimiento es triple: permitir al profesor monitorizar<br />
el progreso de los estudiantes, realizar tareas administrativas dentro de la secuencia<br />
publicada y evaluar los trabajos de los alumnos. La herramienta de seguimiento está<br />
divida en tres secciones:<br />
Lección. Dentro de esta pestaña pueden realizarse tareas administrativas<br />
respecto a la secuencia publicada (ver Figura 6.3.4.3.a), por ejemplo, se<br />
puede acceder a la lista de estudiantes que actualmente participan en la<br />
secuencia y editarla. Dentro de esta sección también se encuentra una lista<br />
de las actividades que obligatoriamente requieren la intervención del<br />
profesor (o de un ayudante). En la Figura 6.3.4.3.a aparecen tres<br />
actividades que requieren la intervención del profesor. Estas actividades<br />
corresponden a tres puertas que están incluidas dentro de la secuencia. Al<br />
seleccionar la opción Ir de la actividad Permiso Corbinus se abre una nueva<br />
ventana (ver Figura 6.3.4.3.b) que permite administrar la puerta,<br />
permitiendo la apertura de la misma para toda la clase o para alumnos<br />
concretos.<br />
213
Secuencia. Dentro de la pestaña secuencia, se tiene acceso a una vista<br />
similar al espacio de trabajo de la herramienta de autor (ver Figura<br />
6.3.4.3.c). Esta vista permite realizar un seguimiento de la secuencia desde<br />
el punto de vista de las actividades. Al hacer doble clic sobre alguna de las<br />
actividades se abre una ventana que permite:<br />
- Acceder a información acerca del número de alumnos que ya han<br />
finalizado la actividad.<br />
- Acceder a las instrucciones que el autor de la secuencia ha podido<br />
incluir durante la creación de la secuencia.<br />
- Acceder a los trabajos enviados por los alumnos para que puedan<br />
ser evaluados por el profesor.<br />
- Permitir la creación de grupos en las actividades de grupo y la<br />
asignación de estudiantes a ramas dentro de actividades de<br />
ramificación.<br />
- Edición en vivo del contenido de la actividad. La edición del<br />
contenido debería de estar restringida a eliminar erratas dentro de la<br />
descripción o enunciado de la actividad, ya que la actividad puede<br />
haber sido comenzada por algún alumno.<br />
De manera adicional, también es posible realizar una edición en vivo de la<br />
propia secuencia, es decir, se pueden modificar las actividades existentes<br />
dentro de la secuencia o añadir nuevas actividades. Nótese que esta<br />
edición de una secuencia está restringida, de modo que no se pueden<br />
modificar actividades que ya han sido comenzadas por alumnos.<br />
Finalmente, dentro de la secuencia aparecen unos iconos que representan<br />
a los participantes de la secuencia (ver región resaltada en Figura<br />
6.3.4.3.c). Estos iconos pueden ser desplazados a otras actividades de<br />
modo que el profesor puede forzar el avance del estudiante hasta una<br />
actividad concreta.<br />
Estudiantes. En esta sección (ver Figura 6.3.4.3.d) se muestra una<br />
representación lineal gráfica de la secuencia de cada uno de los<br />
estudiantes que están participando. Esta sección permite observar el<br />
progreso de los estudiantes dentro de la secuencia, mostrando si el alumno<br />
ha completado la actividad (círculos azules), cuál es la actividad que<br />
actualmente está realizando (cuadrado rojo) y cuáles son las actividades<br />
que le quedan (triángulo verde). También se permite, dentro de esta<br />
sección, que el profesor pueda exportar las contribuciones de un alumno en<br />
una o varias actividades.<br />
214
Figura 6.3.4.3.a. Pestaña Lección de la herramienta de seguimiento.<br />
215
Figura 6.3.4.3.b. Opciones de administración de la puerta Permiso Corbinus.<br />
216
Figura 6.3.4.3.c. Pestaña secuencia de la herramienta de seguimiento.<br />
217
Figura 6.3.4.3.d. Pestaña de estudiantes de la herramienta de seguimiento.<br />
En las siguientes secciones 6.4 y 6.5 se pone en práctica la unidad de aprendizaje<br />
utilizada como caso de estudio a lo largo de todo el capítulo 2 empleando la<br />
herramienta LAMS (sección 6.4) y haciendo uso de herramientas de soporte para IMS<br />
LD (sección.6.5). A modo de resumen, en el caso de estudio del capítulo 2 se<br />
proponen tres escenarios <strong>educativo</strong>s entorno a un seminario/taller de Iniciación a la<br />
Cata (ver Figura 2.3.b) donde cada escenario es una evolución del anterior:<br />
UACata1. Describe un proceso de enseñanza tradicional presencial que<br />
incluye algunas actividades soportadas por las TICs. El resumen de los<br />
componentes principales y el método pedagógico se pueden encontrar en<br />
las figuras: Figura 2.5.5.a, Figura 2.5.5.b, Figura 2.5.5.c y Figura 2.5.5.d.<br />
UACata2. En base al escenario 1, se personaliza el método pedagógico en<br />
base a las necesidades particulares de los alumnos. El resumen de los<br />
componentes principales y el método pedagógico se pueden encontrar en<br />
las figuras: Figura 2.6.9.a, Figura 2.6.9.b, Figura 2.6.9.c, Figura 2.6.9.d,<br />
Figura 2.6.9.e, Figura 2.6.9.f y Figura 2.6.9.g.<br />
218
UACata3. En base al escenario 2, se incluye un mecanismo de notificación<br />
de la entrega de trabajos. El resumen de los componentes principales y el<br />
método pedagógico se pueden encontrar en las figuras: Figura 2.7.3.a y<br />
Figura 2.7.3.b.<br />
6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON<br />
LAMS<br />
En esta sección se codificarán los escenarios <strong>educativo</strong>s UACata1, UACata2 y el<br />
escenario UACata3. Nótese que para el escenario UACata2 es necesario tener acceso<br />
a un servidor de LAMS 2.1 o superior y que para crear el escenario UACata3 es<br />
necesario tener acceso a un servidor de LAMS 2.2 o superior.<br />
Una vez que ya se ha instalado LAMS o se tiene acceso a un servidor LAMS propio,<br />
los pasos a seguir son:<br />
1. Diseñar la secuencia. Es necesario conectarse a LAMS como profesor (con<br />
rol de autor). Una vez creada la secuencia, ésta se almacena en el espacio<br />
privado del profesor.<br />
2. Publicar las secuencia. Mediante este proceso el profesor configura una<br />
secuencia para una clase y alumnos concretos. Es posible configurar varias<br />
secuencias para los mismos alumnos, de modo que puedan llevar a cabo<br />
varias tareas a la vez. También es posible configurar la disponibilidad de una<br />
secuencia publicada a partir de una fecha y hora concretas.<br />
3. Realizar las actividades de la secuencia. Una vez que una secuencia de<br />
actividades se ha publicado y se encuentra activa, tanto el alumno como los<br />
profesores pueden acceder a ella. De este modo:<br />
- Los alumnos podrán llevar a cabo las actividades propuestas en la<br />
secuencia.<br />
- Los profesores pueden monitorizar y gestionar ciertas actividades de la<br />
secuencia. En particular, las tareas habituales de gestión son la creación de<br />
grupos, el control de puertas y la asignación de estudiantes a ramas dentro<br />
de una actividad de ramificación.<br />
6.4.1. Diseño de las unidades de aprendizaje / secuencias de actividades<br />
LAMS para el caso de estudio<br />
Utilizando secuencias de actividades LAMS se pueden poner en práctica los<br />
escenarios <strong>educativo</strong>s UACata1, UACata2 y UACata3. No obstante, el<br />
comportamiento no será exactamente el mismo a las UA creadas con IMS LD (que<br />
fueron descritas a lo largo del capítulo 2). A continuación se describen algunas pautas<br />
para traducir (si es posible) los elementos de IMS LD a LAMS:<br />
Actividades Educativas y Entornos. Las actividades LAMS representan<br />
las actividades educativas de IMS LD junto a un entorno preconfigurado.<br />
219
Las actividades IMS LD contenían una información básica (e.g. título,<br />
descripción, etc.) que se complementa con el entorno donde se realiza la<br />
actividad. Estos entornos necesitan ser configurados uno a uno. En el caso<br />
de LAMS, las actividades ya contienen un entorno preconfigurado, de modo<br />
que la configuración a realizar es mínima.<br />
Actividades de Soporte. El concepto de actividad de soporte no existe<br />
como actividad separada en LAMS. No obstante, existen diversas<br />
actividades que requieren de la participación de un profesor como, por<br />
ejemplo, la actividad de tipo Enviar Archivos, en la que el profesor evalúa<br />
los trabajos que han enviado los alumnos.<br />
Roles. Los roles no existen directamente en LAMS. Un concepto similar<br />
son las clases y grupos. Dentro de las clases (o grupos) pueden crearse<br />
pequeños grupos de alumnos y publicar secuencias de actividades para<br />
cada uno de los grupos de manera independiente. Sin embargo, no se<br />
pueden asignar actividades específicas a grupos de una clase. Una manera<br />
de simular el comportamiento de los roles y actuaciones es adelantar a los<br />
alumnos de un grupo concreto (utilizando la herramienta de seguimiento)<br />
hasta la actividad o actividades que es preciso que lleven a cabo.<br />
Actividades Estructuradas. Las actividades estructuradas de IMS LD se<br />
pueden simular con las actividades opcionales:<br />
- Actividades estructuradas de tipo selección. Se pueden simular con las<br />
actividades opcionales de LAMS. Todas las actividades educativas que<br />
eran referenciadas en la actividad estructurada se incluyen dentro de la<br />
actividad opcional.<br />
- Actividades estructuradas de tipo secuencia. Se pueden simular con las<br />
secuencias opcionales de LAMS con una única secuencia. No obstante,<br />
este uso es demasiado complejo ya que se pueden obtener resultados<br />
similares utilizando actividades simples y la herramienta de transición<br />
para definir el orden entre las mismas.<br />
Método, Guiones y Actos. Estos elementos de IMS LD permitían a los<br />
creadores de unidades de aprendizaje definir el orden de las actividades<br />
simples. Los actos servían como mecanismos de sincronización entre los<br />
participantes de la unidad de aprendizaje. En LAMS no existen elementos<br />
equivalentes, sin embargo, se pueden diseñar secuencias de actividades<br />
con el mismo comportamiento utilizando actividades y definiendo las<br />
transiciones entre ellas. En particular, el uso de las puertas permite simular<br />
el comportamiento de sincronización entre participantes. Un problema que<br />
surge cuando se crean secuencias complejas es que se ofrecen muy pocos<br />
mecanismos para estructurar una secuencia, de hecho, el único mecanismo<br />
que permite la estructuración de las secuencias es la posibilidad de insertar<br />
secuencias previamente creadas en la secuencia que se está editando<br />
actualmente.<br />
Actuaciones. Las actuaciones de IMS LD asocian tipos de participantes<br />
(roles) con las actividades que deben realizar estos participantes. En LAMS<br />
no existe el concepto de rol como tal y, por tanto, no tienen sentido las<br />
actuaciones. Todas las actividades de una secuencia LAMS pueden ser<br />
consideradas como si estuvieran asignadas a un rol de alumno de IMS LD.<br />
220
Propiedades. El concepto de propiedad no existe como tal en LAMS. En<br />
IMS LD los diseñadores de las unidades de aprendizaje deben definir las<br />
propiedades que habitualmente representan medidas de rendimiento del<br />
alumno y se utilizan dentro de las condiciones para adaptar el flujo de<br />
aprendizaje en base a estas medidas. No obstante, ciertas actividades<br />
LAMS ofrecen acceso a medidas del rendimiento del alumno en la<br />
actividad, por lo que podrían ser consideradas como propiedades<br />
predefinidas.<br />
Condiciones. Las condiciones no tienen un equivalente directo en LAMS.<br />
Sin embargo, las actividades de ramificación pueden utilizarse para simular<br />
el comportamiento para el que habitualmente se usan las condiciones:<br />
adaptar el flujo de aprendizaje en base a resultados previos.<br />
Notificaciones. A partir de LAMS 2.2 se incluye el concepto de notificación<br />
que es similar al de las notificaciones de IMS LD. LAMS puede enviar<br />
mensajes de notificación cuando suceden ciertos eventos durante la<br />
ejecución de una secuencia. Durante el diseño de la secuencia, el profesor<br />
puede seleccionar si desea que se envíen notificaciones o no. La diferencia<br />
principal entre las notificaciones de LAMS y de IMS LD es que en IMS LD<br />
una notificación puede hacer visible una actividad que inicialmente estaba<br />
oculta, sin embargo, LAMS no ofrece esta posibilidad.<br />
Finalmente, un concepto que afecta a las actividades de una UA en IMS LD es el<br />
concepto de finalización. En IMS LD las actividades (simples o estructuradas),<br />
actuaciones, actos y guiones pueden finalizar de las siguientes maneras:<br />
A elección del participante. Las actividades simples, actos y guiones<br />
pueden finalizar por elección del participante. Este comportamiento es<br />
similar al que tienen las actividades LAMS ya que el alumno elige cuándo<br />
finaliza la actividad.<br />
Transcurrido un lapso de tiempo. Las actividades, actos y guiones IMS<br />
LD pueden finalizar automáticamente transcurrido un lapso de tiempo. Este<br />
comportamiento puede simularse en LAMS utilizando una puerta. Sin<br />
embargo, esta solución requiere que se establezca una puerta por cada<br />
actividad LAMS y, adicionalmente, la definición del lapso de tiempo se<br />
define respecto al instante en el que comenzó la secuencia completa, por lo<br />
que puede ser engorrosa la definición de varias puertas en diferentes partes<br />
de la secuencia de actividades.<br />
En base a la finalización de los elementos anidados. Los elementos de<br />
IMS LD se pueden anidar durante la definición de la unidad de aprendizaje.<br />
Este anidamiento concreta una relación entre los distintos elementos de la<br />
unidad de aprendizaje que en IMS LD puede utilizarse para definir la<br />
finalización del elemento externo en base a los elementos que contiene. Por<br />
ejemplo, la finalización de un acto puede definirse en base a la terminación<br />
de las actuaciones que contiene. En LAMS sólo existe esta relación de<br />
anidamiento para las actividades opcionales y las actividades de<br />
ramificación. Para el resto de situaciones en las que es necesario<br />
sincronizar actividades se recurre habitualmente al uso de puertas<br />
controladas por el profesor.<br />
221
En los escenarios IMS LD planteados para el caso de estudio del capítulo 2 existen<br />
numerosas actividades cuya finalización se define utilizando lapsos de tiempo. Ya que<br />
en LAMS el uso de esta sincronización requiere un elevado esfuerzo durante la<br />
creación de la secuencia, y que desde el punto de vista del alumno puede ser poco<br />
intuitivo, se ha optado por utilizar el mecanismo por defecto de LAMS para acabar las<br />
actividades, es decir, a elección del usuario. En casos puntuales, se han definido<br />
puntos de control (equivalentes a los actos de IMS LD) para sincronizar a los<br />
participantes de la secuencia.<br />
La Figura 6.4.1.a muestra la secuencia de actividades LAMS creada por Corbinus para<br />
implementar el escenario UACata1. Las actividades (incluyendo el orden en el que son<br />
llevadas a cabo) son:<br />
1. Presentación. Es una actividad de tipo Cartelera que Corbinus ha utilizado<br />
para saludar a los nuevos alumnos del seminario y para indicarles que la<br />
primera actividad será una clase presencial. En particular, ha sido necesario<br />
introducir esta actividad que no se incluía en el escenario IMS LD ya que una<br />
actividad LAMS marcada como offline no muestra ni su título ni su contenido a<br />
los alumnos, sino que muestra un mensaje indicando a los alumnos que<br />
contacten con su profesor para más instrucciones.<br />
2. Clase Presencial. Actividad de tipo Cartelera que representa la primera clase<br />
presencial del curso. Ya que esta actividad no será realizada en LAMS se ha<br />
marcado como actividad offline. LAMS presenta las actividades offline con<br />
colores invertidos para diferenciarlas del resto de actividades.<br />
3. Puerta de permiso. Esta puerta es controlada por Corbinus para permitir<br />
avanzar a los alumnos una vez que haya finalizado la clase presencial.<br />
4. Autoaprendizaje. Actividad opcional que incluye tres actividades:<br />
- Artículo Bebo. Actividad de tipo Compartir Recursos en la que se comparte<br />
el artículo de la profesora Bebo.<br />
- Artículo Birra. Actividad de tipo Compartir Recursos en la que se comparte<br />
el artículo del profesor Birra.<br />
- Visionado de vídeo. Actividad de tipo Compartir Recursos en la que se<br />
comparte el vídeo del profesor Bacus.<br />
La actividad ha sido marcada para que termine cuando las tres actividades<br />
incluidas hayan finalizado. Nótese que esta actividad se ha traducido como una<br />
actividad opcional utilizando las pautas de traducción descritas anteriormente.<br />
Sin embargo existen otras formas de implementar esta actividad, por ejemplo,<br />
empleando una única actividad de tipo Compartir Recursos y compartir todos<br />
los recursos a la vez (especificando en las propiedades avanzadas de la<br />
actividad, que hay que visitar todos los recursos compartidos). Finalmente, si<br />
se aplicaran estrictamente las pautas de traducción se llegaría a una secuencia<br />
similar a la mostrada en la Figura 6.4.1.b donde la actividad opcional<br />
Autoaprendizaje y la actividad Examen del sitio web han sido fusionadas en<br />
una sola de tipo Secuencia Opcional con una única secuencia, donde la<br />
primera actividad es la actividad opcional Autoaprendizaje y la segunda (y<br />
última) actividad es el Examen del sitio web.<br />
222
5. Examen del sitio web. Actividad de tipo Compartir Recursos donde se<br />
comparte el enlace al sitio web www.lacatadelvinotinto.org.<br />
6. Puerta sincronizada. Esta puerta simula la finalización de un acto de IMS LD,<br />
de modo que la puerta no se abrirá hasta que todos los estudiantes hayan<br />
terminado la actividad anterior.<br />
7. Debate. Actividad de tipo Chat, donde los alumnos debaten acerca de los<br />
contenidos <strong>educativo</strong>s visionados y la lectura de los artículos.<br />
8. Puerta de permiso. Puerta que controla Corbinus para marcar el avance a la<br />
siguiente actividad del seminario.<br />
9. Entrega de trabajos. Actividad de tipo Enviar Archivos, que será utilizada por<br />
los alumnos de Corbinus para enviarle los trabajos escritos.<br />
10. Puerta de permiso. Puerta que controla Corbinus que sirve para marcar el<br />
final del seminario.<br />
Figura 6.4.1.a. Estructura final de la secuencia LAMS completa que formaliza la<br />
descripción de unidad de aprendizaje UACata1.<br />
223
Figura 6.4.1.b. Estructura final de la secuencia LAMS completa que formaliza la<br />
descripción de la unidad de aprendizaje UACata1. La actividad estructurada<br />
Autoaprendizaje se ha definido como una secuencia opcional.<br />
Al igual que en las unidades de aprendizaje IMS LD, Corbinus crea las secuencias de<br />
actividades de manera incremental. Tras guardar la secuencia de actividades<br />
correspondiente al escenario UACata1, puede modificar esta secuencia para las<br />
nuevas características del escenario UACata2, que podrá guardar de manera<br />
independiente. La Figura 6.4.1.c muestra la secuencia de actividades que implementa<br />
el escenario UACata2, el tipo y orden de las actividades es el siguiente:<br />
1. Presentación. Esta actividad es la misma que se ha descrito para implementar<br />
el escenario UACata1.<br />
2. Clase Presencial. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
3. Puerta de permiso. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
4. Test. Actividad de tipo Opción Múltiple utilizada como examen tipo test para<br />
evaluar los conocimientos previos del alumno.<br />
5. Evaluación de conocimientos. Actividad de tipo ramificación que utiliza la<br />
nota que se ha generado en la actividad Test para redirigir al alumno a una<br />
rama concreta dentro de la actividad. Las ramas de la actividad pueden<br />
editarse haciendo doble clic sobre la actividad, de modo que aparecerá un<br />
nuevo espacio de trabajo particular para la actividad de ramificación (Figura.<br />
6.4.1.d). En el espacio de trabajo de una ramificación aparecen dos iconos<br />
especiales con forma de puerta. Estos dos iconos representan: el punto de<br />
entrada a la actividad de ramificación (puerta verde), donde se crearán las<br />
distintas ramas de la secuencia, y el punto de salida (puerta roja), que es el<br />
punto donde se vuelven a unir las ramificaciones para proseguir a la siguiente<br />
actividad. En el ejemplo mostrado en la Figura. 6.4.1.d aparecen definidas dos<br />
ramas:<br />
224
- Conocimientos suficientes. Esta rama representa la secuencia de<br />
actividades que debe seguir el alumno si demuestra que tiene<br />
conocimientos suficientes de enología. Contiene la actividad opcional<br />
Autoaprendizaje descrita en la implementación del escenario UACata1.<br />
- Conocimientos insuficientes. Esta rama representa la secuencia de<br />
actividades que debe seguir el alumno que no tenga los conocimientos<br />
mínimos de enología para desarrollar las actividades posteriores. Esta<br />
rama incluye la lectura del libro Enología Básica escrito por Corbinus y,<br />
posteriormente, la realización de la actividad Autoaprendizaje. Nótese<br />
que esta actividad ha sido copiada en ambas ramas ya que no puede<br />
haber transiciones entre actividades de distintas ramas.<br />
Una vez creadas las ramas Corbinus crea un par de condiciones, utilizando el<br />
editor de condiciones accesible desde el inspector de propiedades. La Figura<br />
6.4.1.e muestra dos condiciones: la primera con nombre Suficientes cuya<br />
condición es que los puntos totales del estudiante sean mayor o igual que 5 y la<br />
segunda, con nombre Insuficientes, cuya condición es que los puntos totales<br />
del estudiante estén en el rango 0 a 4. Finalmente, Corbinus asocia las<br />
condiciones con las ramas de secuencias. La Figura. 6.4.1.f muestra como la<br />
rama Conocimientos suficientes está asignada a la condición Suficientes y la<br />
rama Conocimientos insuficientes está asignada a la condición Insuficientes.<br />
6. Examen del sitio web. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
7. Puerta sincronizada. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
8. Debate. Esta actividad es la misma que se ha descrito para implementar el<br />
escenario UACata1.<br />
9. Puerta de permiso. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
10. Entrega de trabajos. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
11. Evaluación de trabajos. Actividad de tipo ramificación en la que Corbinus<br />
redirige a los alumnos a la rama correspondiente tras corregir los trabajos que<br />
los alumnos han entregado en la actividad anterior. Nótese que esta asignación<br />
de alumnos a ramas debe hacerse manualmente ya que la actividad de tipo<br />
Enviar Archivos no genera ningún valor que pueda ser utilizado en una<br />
condición. La Figura 6.4.1.g muestra las dos ramas que incluye esta actividad:<br />
- Trabajo suficiente. Por esta rama serán encauzados los alumnos cuyo<br />
trabajo cumpla los requisitos mínimos exigidos por Corbinus. Como<br />
puede observarse, en esta rama no hay ninguna actividad, de modo que<br />
el alumno simplemente finalizará automáticamente la actividad.<br />
- Trabajo insuficiente. Por esta rama pasarán todos los alumnos cuyo<br />
trabajo no cumpla los requisitos mínimos exigidos por Corbinus. Dentro<br />
de esta rama aparece una secuencia de tres actividades: Necesitas<br />
Repasar, Repaso y Revisión del trabajo. La actividad Necesitas<br />
Repasar es de tipo Cartelera donde se informa al estudiante de que<br />
debe revisar el material y rehacer el trabajo de nuevo (adicionalmente<br />
puede revisar los comentarios acerca del trabajo volviendo a la<br />
225
actividad Evaluación de Trabajos). La actividad Repaso es opcional y<br />
contiene tres actividades de tipo Compartir Recursos donde cada una<br />
de estas actividades propone el repaso de los contenidos más<br />
relevantes: libro del profesor Corbinus, artículo del profesor Birra y visita<br />
al sitio web www.lacatadelvinotinto.org. Finalmente, en la actividad<br />
Revisión del trabajo el alumno debe enviar de nuevo el trabajo<br />
incluyendo las correcciones que considere oportunas.<br />
12. Puerta de permiso. Esta actividad es la misma que se ha descrito para<br />
implementar el escenario UACata1.<br />
Figura 6.4.1.c. Estructura final de la secuencia LAMS completa que formaliza la<br />
descripción de la unidad de aprendizaje UACata2.<br />
226
Figura. 6.4.1.d. Detalle de la actividad de ramificación Evaluación de conocimiento.<br />
227
Figura. 6.4.1.e. Detalle del editor de condiciones asociado a la actividad Evaluación<br />
de conocimiento.<br />
Figura. 6.4.1.f. Detalle del diálogo utilizado para asignar condiciones a ramas de la<br />
actividad Evaluación de conocimiento.<br />
228
Figura 6.4.1.g. Detalle de la actividad de ramificación Evaluación de trabajos.<br />
En último lugar, la secuencia que implementa el escenario UACata3 es una ligera<br />
modificación de la secuencia de actividades que implementa el escenario UACata2. En<br />
particular sólo se han modificado las propiedades de las actividades Entrega de<br />
Trabajos y Revisión del Trabajo, de modo que se notifique a Corbinus mediante un<br />
mensaje de correo electrónico que un alumno ha enviado su trabajo (ver Figura<br />
6.4.1.h). Como complemento, también se ha configurado que los alumnos sean<br />
notificados cuando Corbinus haya evaluado los trabajos y que los alumnos puedan<br />
revisar tanto su nota como los comentarios que Corbinus haya añadido a la corrección.<br />
229
Figura 6.4.1.h. Página de propiedades de la actividad Entrega de Trabajos. Las<br />
propiedades de notificación a profesores y alumnos se encuentran activadas.<br />
Como se mencionó en la sección 6.3.4.2, es posible exportar una secuencia de<br />
actividades LAMS desde la herramienta de autoría. La secuencia exportada se<br />
empaqueta en un archivo comprimido en formato zip que contiene una descripción de<br />
la secuencia de actividades y todos los archivos de contenidos que se utilizan en las<br />
actividades de la secuencia. La Figura 6.4.1.i muestra el contenido (en formato XML)<br />
del archivo que representa la secuencia de actividades. A diferencia del formato XML<br />
de IMS LD, que tiene como objetivo ser un formato simple de intercambio para<br />
unidades de aprendizaje que incluso puede ser editado directamente por un profesor,<br />
el formato XML de LAMS no está pensado para ser modificado directamente, ya que<br />
incluye numerosos detalles técnicos como, por ejemplo, las coordenadas dentro del<br />
espacio de trabajo donde se encuentra cada una de las actividades, el instante en el<br />
que se creó la actividad, etc.<br />
Figura 6.4.1.i. Extracto del contenido del documento XML donde se define la<br />
secuencia de actividades del escenario UACata2.<br />
230
36<br />
UACata2<br />
525<br />
34<br />
118<br />
true<br />
false<br />
false<br />
10<br />
1<br />
<br />
2008-12-03 13:27:53.0<br />
2.1.0.200806131057<br />
1<br />
50<br />
2008-12-03<br />
16:35:17.0<br />
ff8080811ded4e44011def28de5a006c<br />
<br />
<br />
<br />
514<br />
1<br />
Tool for displaying HTML content including external<br />
sources such as images and other media.<br />
Clase Presencial<br />
Displays formatted text and links to external sources<br />
on a read only page.<br />
<br />
http://wiki.lamsfoundation.org/display/lamsdocs/lanb11<br />
166<br />
43<br />
1<br />
false<br />
36<br />
<br />
2008-12-03 13:27:53.0<br />
true<br />
lanb11<br />
2<br />
452<br />
NoticeboardX<br />
20070524<br />
tool/lanb11/authoring.do<br />
tool/lanb11/monitoring.do<br />
4<br />
false<br />
2<br />
<br />
tool/lanb11/images/icon_htmlnb.swf<br />
false<br />
false<br />
false<br />
<br />
<br />
false<br />
<br />
...<br />
231
Para finalizar esta sección, la Figura 6.4.1.j muestra el curso de Moodle que Corbinus<br />
utiliza como apoyo al curso de Enología Presencial que imparte en la de Escuela<br />
Estudios y Prospecciones Vinícolas (EEPV). Moodle es el LMS utilizado dentro de los<br />
diferentes cursos de la EEPV, sin embargo, ya que Corbinus ha dedicado un gran<br />
esfuerzo al desarrollo de secuencias de actividades, la instalación de Moodle de la<br />
escuela se encuentra integrada con el servidor de LAMS. De este modo, Corbinus<br />
puede utilizar la herramienta de autoría y publicar secuencias LAMS desde la propia<br />
interfaz de Moodle.<br />
Figura 6.4.1.j. Publicación de la secuencia de actividades UACata1 dentro de<br />
Moodle.<br />
6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON IMS<br />
LD<br />
Existen numerosas iniciativas, en particular en el ámbito de la investigación, para crear<br />
herramientas de autoría y herramientas de reproducción entre otras, que faciliten el<br />
uso de los lenguajes de modelado <strong>educativo</strong> con énfasis en IMS LD. Entre estas<br />
iniciativas se encuentra el proyecto RELOAD (http://www.reload.ac.uk) que ofrece<br />
varias herramientas para dar soporte a las especificaciones ADL SCORM e IMS LD.<br />
232
Las herramientas que el proyecto RELOAD ofrece para IMS LD son dos:<br />
RELOAD LD Editor. Esta herramienta permite crear una UA compatible<br />
con IMS LD. RELOAD LD Editor fue una de las primeras herramientas de<br />
autoría compatible con los tres niveles de la especificación IMS LD.<br />
RELOAD LD Player. Esta herramienta es un reproductor de unidades de<br />
aprendizaje IMS LD pensado para complementar a RELOAD LD Editor.<br />
Este reproductor permite reproducir unidades de aprendizaje desde el<br />
ordenador del propio creador de las unidades de aprendizaje. Proporciona<br />
una interfaz simple para publicar una UA y crear usuarios de prueba.<br />
Internamente, RELOAD LD Player utiliza el intérprete CopperCore para<br />
reproducir las unidades de aprendizaje.<br />
En la actualidad los desarrolladores de RELOAD participan en el proyecto<br />
internacional TENCompetence (http://www.tencompetence.org) desarrollando una<br />
nueva versión de RELOAD LD Editor, llamada ReCourse, que tiene como objetivo<br />
proporcionar una herramienta más amigable y simple de usar para un usuario que no<br />
sea experto en IMS LD. No obstante, en la actualidad, ReCourse soporta la<br />
expresividad de IMS LD nivel A, aunque según los autores (Griffiths et al., 2008) en<br />
poco tiempo estará disponible una versión de ReCourse que soporte la expresividad<br />
de los niveles B y C de IMS LD.<br />
La especificación de IMS LD propone la aplicación de la metodología Análisis, Diseño,<br />
Desarrollo, Implementación y Evaluación (ADDIE) (Dick y Carey, 1996) ampliamente<br />
utilizada en la creación y desarrollo de materiales <strong>educativo</strong>s y cursos. Esta<br />
metodología se compone de 5 fases, cuyos objetivos son:<br />
Análisis. En esta fase se analiza un escenario <strong>educativo</strong> concreto teniendo<br />
en cuenta los distintos tipos de participantes que están involucrados en el<br />
escenario <strong>educativo</strong>. El objetivo de esta fase es crear un documento en<br />
lenguaje natural en el que se narre brevemente cómo se pondría en<br />
práctica el caso de estudio. En particular, este documento narrativo podría<br />
incluir una lista con todas las tareas a llevar a cabo en el escenario<br />
<strong>educativo</strong>.<br />
Diseño. En la fase de diseño se propone que, utilizando el documento<br />
narrativo como entrada, se cree un diagrama de actividad UML (OMG,<br />
2007). Los diagramas de actividad UML son un tipo de diagrama utilizados<br />
habitualmente en el desarrollo de aplicaciones informáticas y en la<br />
descripción de procesos de negocio, por ejemplo, para describir<br />
gráficamente el orden de las tareas que intervienen en un proceso de<br />
negocio. Este diagrama se utiliza como base para generar el documento<br />
XML que represente la UA compatible con IMS LD. Durante esta fase del<br />
desarrollo, se puede utilizar la herramienta RELOAD LD Editor para facilitar<br />
la creación de este documento XML sin tener que trabajar directamente con<br />
el archivo XML.<br />
Desarrollo. Durante esta fase se crean los recursos necesarios para la UA.<br />
Estos recursos se tienen que haber declarado en los Entornos utilizados en<br />
las actividades. Una vez creados estos recursos, se puede utilizar RELOAD<br />
LD Editor para incluirlos dentro de la UA.<br />
233
Implementación. Durante esta fase, se publica la UA con alumnos<br />
concretos para su puesta en práctica. Para esto es necesario crear un<br />
paquete IMS que incluya tanto la UA como todos los recursos necesarios.<br />
Reload LD Editor permite crear y validar un paquete IMS para que pueda<br />
ser utilizado en un reproductor compatible con IMS LD.<br />
Evaluación. Esta fase tiene como objetivo evaluar la UA para que se pueda<br />
mejorar para una ejecución posterior.<br />
Como se ha descrito, RELOAD LD Editor se puede usar durante la fase de diseño<br />
para crear la UA compatible con IMS LD. El proceso de creación de una UA utilizando<br />
RELOAD LD Editor es el siguiente:<br />
1. Crear un nuevo diseño de aprendizaje (del inglés learning design). Un diseño de<br />
aprendizaje puede ser considerado como un proyecto de UA.<br />
2. Crear las actividades. A partir de la descripción narrativa del escenario <strong>educativo</strong>,<br />
pueden identificarse las actividades de la UA. Las actividades educativas y de<br />
soporte pueden agregarse en actividades estructuradas más complejas.<br />
3. Crear los entornos donde se llevarán a cabo las actividades y asociarlos a sus<br />
correspondientes actividades. La definición de las actividades sólo incluye una<br />
descripción de la tarea a realizar. Esta definición de actividades se complementa<br />
con la definición de entornos y su asociación a las actividades.<br />
4. Crear los roles de los participantes del diseño de aprendizaje. El escenario<br />
<strong>educativo</strong> puede incluir distintos tipos de participantes, por lo que será necesario<br />
definir un rol por cada uno de los tipos de personaje identificados.<br />
5. Crear el método de la unidad del diseño de aprendizaje. En el método se define el<br />
orden, la sincronización y la asignación de las actividades individuales (definidas<br />
en el paso 2) a roles identificados en el escenario <strong>educativo</strong>. Además, si la UA<br />
incluye aspectos de personalización, es necesario definir las distintas propiedades<br />
que se utilizarán en dicha personalización.<br />
6. Importación y vinculación de los recursos a los entornos. Como parte de la fase de<br />
desarrollo, el profesor creará los distintos materiales <strong>educativo</strong>s que serán<br />
enlazados desde los distintos entornos. Una vez creados los recursos <strong>educativo</strong>s,<br />
el profesor importará los recursos en RELOAD LD Editor, en particular los objetos<br />
<strong>educativo</strong>s u objetos de aprendizaje (learning objects en inglés) y reeditará los<br />
entornos para enlazar los materiales <strong>educativo</strong>s importados.<br />
7. Verificación del diseño de aprendizaje. Una UA compatible con IMS LD debe<br />
cumplir ciertas restricciones para que pueda ser ejecutada en un reproductor<br />
compatible. RELOAD LD Editor permite que el creador de una UA pueda validarla<br />
respecto a estas restricciones. En caso de que alguno de los elementos no cumpla<br />
los requisitos mínimos, se proporciona un mensaje de error con una pequeña<br />
ayuda que indica cómo arreglar el fallo.<br />
8. Exportación del diseño de aprendizaje. Una vez creada y validada la UA, ésta está<br />
lista para ser exportada. La UA junto a todos los recursos necesarios serán<br />
empaquetados en un archivo comprimido (con formato zip) listo para ser ejecutado<br />
en un reproductor compatible con IMS LD.<br />
234
Una vez creada la UA es recomendable que el profesor la pruebe antes de ponerla en<br />
práctica con usuarios reales y más si la UA es adaptativa. RELOAD Player puede<br />
utilizarse para probar una UA compatible con IMS LD. Sin embargo, RELOAD LD<br />
Player es un reproductor completo y real de IMS LD, de modo que al probar la UA será<br />
necesario cumplir con todas las restricciones que se especifiquen en ella. En<br />
particular, las actividades educativas de los escenarios de ejemplo pasarán a estar<br />
completadas transcurrido un lapso de tiempo, de modo que el profesor tendría que<br />
esperar dicho lapso de tiempo durante las pruebas, lo que no es efectivo. Para facilitar<br />
el proceso de prueba de la UA que se está creando, es recomendable crear una UA<br />
"trucada", donde:<br />
Las actividades deberían configurarse para ser completadas a elección del<br />
usuario. De este modo, el profesor podrá ir completando las actividades y<br />
probando las adaptaciones incluidas en la UA.<br />
El profesor debería poder modificar el valor de las propiedades que<br />
modifican el proceso de adaptación. Por tanto, es necesario crear recursos<br />
de tipo imsldcontent que incluyan los elementos globales de IMS LD<br />
necesarios para ver y modificar el valor de las propiedades que afecten al<br />
proceso de adaptación.<br />
Una vez que se ha probado la UA, las actividades pueden configurarse con los<br />
mecanismos de finalización que inicialmente se habían ideado, y los recursos<br />
accesorios que se habían creado para la prueba y que ya no son necesarios se<br />
pueden eliminar.<br />
La interfaz gráfica de RELOAD LD Editor ofrece una pestaña por cada uno de los<br />
diferentes aspectos relativos a la edición de una UA. Cada pestaña proporciona el<br />
soporte necesario para cada uno de los ocho pasos anteriormente descritos.<br />
Las unidades de aprendizaje que ponen en práctica los escenarios <strong>educativo</strong>s<br />
descritos en el capítulo 2 han sido creadas y probadas con las últimas versiones<br />
(hasta la fecha de escritura del presente trabajo) de las siguientes herramientas:<br />
RELOAD LD Editor versión 2.1.3 (herramienta de autoría).<br />
RELOAD LD Player versión 2.1.3 (herramienta de pruebas).<br />
CopperCore Runtime Environment (CCRT) versión 3.1.1 + SLeD versión<br />
3.0 (herramienta de pruebas).<br />
A continuación, se describe brevemente el proceso de creación de la UA para el<br />
escenario de aprendizaje UACata3 descrito en el capítulo 2. El caso de estudio<br />
UACata3 se ha modificado mínimamente para poder probarlo completamente. Las<br />
modificaciones realizadas son:<br />
La finalización de actividades se ha configurado para que el usuario elija<br />
cuando finalizan.<br />
Se ha añadido la propiedad global personal email. Esta propiedad es<br />
necesaria para crear las notificaciones para profesores.<br />
235
La Figura 6.5.a muestra la interfaz de RELOAD LD Editor que permite editar el<br />
resumen de la UA que se está creando. Esta interfaz permite definir:<br />
Un título (title). Este título es utilizado habitualmente por las herramientas<br />
de reproducción para mostrar el listado de unidades de aprendizaje<br />
publicadas. En el ejemplo el título es Seminario de introducción a la cata.<br />
Una URI y versión. La URI proporciona un identificador único para la UA.<br />
Este identificador puede utilizarse para hacer referencia a la UA que se está<br />
creando desde otra UA, por ejemplo, para ejecutar una UA como parte de<br />
otra UA. En el ejemplo, la URI de la UA es http://www.e-ucm.es/uacata3/1<br />
que tiene la estructura habitual de la dirección de una página web, sin<br />
embargo, en el caso de las URI esta dirección es meramente descriptiva y<br />
no tiene por qué existir una página web con dicha dirección.<br />
Nivel. Este atributo especifica cuál es la compatibilidad mínima que debe<br />
soportar un reproductor para reproducir la unidad de aprendizaje que se<br />
está editando.<br />
Objetivos de aprendizaje. Editor que permite asociar una lista de recursos<br />
para definir el conjunto de objetivos de aprendizaje que se cubren en la<br />
unidad de aprendizaje. Estos recursos pueden ser tanto archivos como<br />
enlaces web.<br />
Prerequisitos. Editor que permite asociar una lista de recursos para definir<br />
el conjunto de prerrequisitos que se cubren en la unidad de aprendizaje.<br />
Estos recursos pueden ser tanto archivos como enlaces web.<br />
236
Figura 6.5.a. Pestaña de edición del resumen de una unidad de aprendizaje.<br />
237
La Figura 6.5.b muestra la interfaz que permite definir la jerarquía de roles de la unidad<br />
de aprendizaje. En la parte izquierda se encuentra el editor, en forma de árbol, para<br />
los dos tipos de roles principales de la unidad de aprendizaje: rol alumno (Learners) y<br />
rol plantilla (Staff). A través de este editor se pueden añadir nuevos sub-roles tanto de<br />
los roles principales como de alguno particular que se haya definido. En la parte<br />
derecha se permite editar los detalles particulares del rol que actualmente se<br />
encuentre seleccionado. En concreto, se puede asociar una lista de recursos para<br />
describir la finalidad del rol dentro de la unidad de aprendizaje. En el ejemplo mostrado<br />
en la Figura 6.5.b se aprecian los dos roles de estudiante Alumno de nueva promoción<br />
y Alumno de promociones antiguas, además del rol del tipo plantilla Profesor del<br />
seminario.<br />
Figura 6.5.b. Pestaña de creación de los roles de la unidad de aprendizaje.<br />
238
La Figura 6.5.c muestra la interfaz que permite crear y editar las actividades<br />
individuales de la unidad de aprendizaje. En la parte izquierda se encuentra un editor<br />
donde se pueden crear nuevas actividades y, para el caso particular de las actividades<br />
estructuradas, es posible crear las referencias a las actividades que se incluirán.<br />
Además también es posible crear las referencias al entorno donde se llevará a cabo la<br />
unidad de aprendizaje. En la parte derecha se permiten editar los detalles particulares<br />
de la actividad que se encuentre seleccionada, en concreto, establecer la visibilidad de<br />
la actividad, el mecanismo de finalización de la actividad y configurar la notificación de<br />
finalización de la actividad.<br />
Figura 6.5.c. Pestaña de creación de las actividades de la unidad de aprendizaje.<br />
239
La Figura 6.5.d muestra la interfaz para crear los entornos de la unidad de aprendizaje.<br />
Como parte de los entornos pueden definirse los objetos <strong>educativo</strong>s y, en particular,<br />
configurar los servicios de comunicación. En el ejemplo mostrado en la Figura 6.5.d se<br />
está configurando el servicio de comunicación que se utilizará en la actividad de<br />
debate. Este servicio de comunicación está configurado como servicio de<br />
comunicación síncrono (i.e. un chat) y tiene asignados a los roles de alumnos como<br />
participantes activos del chat y el rol de profesor como observador, moderador y<br />
administrador de la sesión de chat.<br />
Figura 6.5.d. Pestaña de creación de los entornos de la unidad de aprendizaje.<br />
240
La Figura 6.5.e muestra la interfaz para crear el método de la unidad de aprendizaje.<br />
En la parte izquierda se encuentra el editor donde se pueden añadir nuevos guiones,<br />
actos y actuaciones. Al seleccionar alguno de los elementos del editor, en la parte<br />
derecha pueden editarse los detalles del elemento. En el caso particular del método,<br />
parte de los detalles que se pueden definir son las condiciones del método.<br />
Figura 6.5.e. Pestaña de creación del método de la unidad de aprendizaje.<br />
241
La Figura 6.5.f muestra el diálogo que permite crear las condiciones de la unidad de<br />
aprendizaje. En el ejemplo mostrado, aparecen las dos condiciones que permiten la<br />
adaptación de la unidad de aprendizaje dependiendo del test previo y de los resultados<br />
en el trabajo (ver Figura 2.6.9.f).<br />
Figura 6.5.f. Diálogo de creación de las condiciones de la unidad de aprendizaje.<br />
242
La Figura 6.5.g muestra la interfaz del editor para crear las propiedades de la unidad<br />
de aprendizaje. En la parte izquierda aparece la lista de propiedades definidas y en la<br />
parte de la derecha se pueden editar los detalles particulares de la propiedad que<br />
actualmente se encuentre seleccionada. En el ejemplo de la Figura 6.5.g se muestra la<br />
edición de detalles de la propiedad email. Ya que ésta es una propiedad global<br />
personal, su definición global (opción Global Definition) puede crearse a través del<br />
editor, o se puede hacer referencia a una propiedad global ya existente (opción<br />
Existing).<br />
Figura 6.5.g. Pestaña de creación de propiedades de la unidad de aprendizaje.<br />
243
La Figura 6.5.h muestra la interfaz del editor para gestionar los recursos de la unidad<br />
de aprendizaje. A través de esta pestaña se muestran los archivos que actualmente<br />
están dentro del directorio content del directorio del proyecto que se ha creado para la<br />
unidad de aprendizaje. A través de esta interfaz el profesor puede importar otros<br />
recursos dentro del proyecto de la unidad de aprendizaje. No obstante, el profesor<br />
puede utilizar el explorador de archivos de su sistema operativo para copiar archivos y<br />
recursos en el directorio content.<br />
Figura 6.5.h. Pestaña de gestión de archivos de la unidad de aprendizaje.<br />
244
En último lugar, la Figura 6.5.i muestra la interfaz de exportación del editor de<br />
unidades de aprendizaje. El objetivo de esta sección del editor es triple:<br />
Asignar un tipo a los recursos de la unidad de aprendizaje. A través del<br />
apartado de Validación de Recursos (Check Resources) el profesor verifica<br />
los recursos que actualmente tiene disponibles en la unidad de aprendizaje<br />
y adicionalmente puede asignar un tipo (opción Type...) al recurso que esté<br />
seleccionado. En particular, imsldcontent es el tipo de recurso que se utiliza<br />
en los recursos web que incluyan elementos globales de IMS LD.<br />
Validación de la unidad de aprendizaje. A través del apartado de Lista de<br />
tareas (Checklist) el profesor verifica la unidad de aprendizaje respecto a<br />
todas las reglas y restricciones que impone la especificación IMS LD. En<br />
caso de error se mostrará un mensaje indicando el error y proporcionando<br />
alguna pista acerca de cómo se puede solucionar el problema. Es<br />
recomendable que la unidad de aprendizaje se valide cada cierto tiempo<br />
para comprobar que los nuevos elementos introducidos se han configurado<br />
adecuadamente.<br />
Exportación. Una vez que la unidad de aprendizaje ha sido validada, ya<br />
está lista para ser empaquetada. El apartado de exportación (Export)<br />
permite exportar la unidad de aprendizaje y todos los recursos asociados en<br />
un paquete IMS.<br />
245
Figura 6.5.i. Pestaña de validación, asignación de tipos a recursos y exportación de<br />
la unidad de aprendizaje.<br />
Para finalizar este capítulo se muestran algunas capturas de la ejecución de las<br />
unidades de aprendizaje utilizando el motor de ejecución CopperCore junto a la<br />
herramienta de reproducción SLeD (ambas herramientas están descritas en el capítulo<br />
1). SLeD es una herramienta web de reproducción de unidades de aprendizaje<br />
compatibles con IMS LD que utiliza el motor de ejecución CopperCore para interpretar<br />
las unidades de aprendizaje.<br />
246
Nótese que para emplear SLeD es necesario tener instalado y funcionando el motor<br />
CopperCore (disponible gratuitamente en: http://www.coppercore.org/). Una vez<br />
instalado, es necesario instalar SLeD (que también se puede obtener de manera<br />
gratuita en: http://sled.open.ac.uk/). En ambos sitios web se encuentra la<br />
documentación necesaria para instalar ambas herramientas informáticas (en inglés).<br />
La Figura 6.5.j muestra la reproducción de la unidad de aprendizaje UACata1 para un<br />
usuario con rol Nuevo Alumno.<br />
Figura 6.5.j. Captura de pantalla de la reproducción de la unidad de aprendizaje<br />
UACata1 dentro de SLeD.<br />
Además de CopperCore existen otros reproductores de unidades de aprendizaje<br />
compatibles con IMS LD, entre ellos, destaca la iniciativa GRAIL (Escobedo del Cid et<br />
al., 2007) desarrollado por el Grupo de Aplicaciones y Servicios Telemáticos (GAST)<br />
de la Universidad Carlos III de Madrid. GRAIL es un reproductor de unidades de<br />
aprendizaje que se encuentra integrado dentro de la plataforma educativa .LRN<br />
(http://dotlrn.org) y que, por tanto, permite reproducir unidades de aprendizaje como<br />
una herramienta más de la plataforma educativa, además de estar integrada con los<br />
servicios que ofrece .LRN.<br />
247
Para utilizar el reproductor, se puede:<br />
Utilizar el servidor de pruebas que ofrece el grupo GAST. Este servidor<br />
permite publicar unidades aprendizaje propias y reproducirlas. Este servidor<br />
está disponible en:<br />
https://gradient.it.uc3m.es/xowiki/main_page<br />
<strong>Descargar</strong> una máquina virtual, compatible con VMWare, en la que se<br />
encuentra instalado el LMS .LRN y el reproductor de IMS LD. Esta máquina<br />
virtual contiene un sistema operativo configurado con todos los requisitos<br />
para poder utilizar .LRN utilizando un reproductor de máquina virtual como<br />
VMWare, QEMU, VirtualBox o Virtual PC entre otros. El Observatorio<br />
Tecnológico del ITE (antiguo CNICE) ofrece un monográfico de Máquinas<br />
Virtuales que se encuentra disponible en:<br />
http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag<br />
e&pageid=63<br />
248
7. BIBLIOGRAFÍA<br />
Esta bibliografía es parte de la que se ha utilizado en la redacción del presente informe<br />
pero dista mucho de ser completa. Debido a la propia naturaleza del campo del elearning<br />
en general que es relativamente joven a la vez que muy activo, y por tanto en<br />
continuo cambio, hace que muchas de las referencias puedan quedar obsoletas muy<br />
rápidamente. Esto es todavía más cierto si cabe en los aspectos de modelado<br />
<strong>educativo</strong> donde, como hemos comentado previamente, todavía no existen consensos<br />
ni prácticas comúnmente aceptadas. Por tanto algunas de estas referencias son<br />
realmente meta-referencias ya que son menciones a sitios web que contienen la<br />
información actualizada.<br />
Por otro lado a lo largo del trabajo se han proporcionado muchas referencias a<br />
información disponible directamente en Internet, por ejemplo, sobre herramientas o<br />
sistemas concretos. Aunque en muchos casos no se podrían considerar referencias<br />
propiamente dichas son parte muy importante de la información disponible.<br />
• Adell, J. (2004). Internet en el aula: las WebQuest. Edutec: Revista Electrónica<br />
de Tecnología Educativa [en línea] 17, pp. 3-4. Disponible en:<br />
http://www.uib.es/depart/gte/edutec-e/revelec17/adell_16a.htm [2008, 5 de<br />
diciembre].<br />
• ADL SCORM (2009). Sharable Course Object Reference Model 2004 4th<br />
Edition Documentation Suite Public Draft, [en línea]. Disponible en:<br />
http://adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM 2004 4th<br />
Ed V1.1/Documentation Suite/SCORM_2004_4ED_v1_1_Doc_Suite.zip [2009,<br />
12 de noviembre].<br />
• AICC (2004). CMI guidelines for interoperability AICC revision 4.0. Technical<br />
Report CMI001, Aviation Industry CBT Committee -AICC Subcommittee.<br />
• AICC Aviation Industry CBT Committee. Disponible en: http://www.aicc.org<br />
[2008, 27 de noviembre].<br />
• ALFANET. Alfanet project (2007). Disponible en: http://alfanet.ia.uned.es [2007,<br />
16 de mayo].<br />
• ARIADNE Alliance of Remote Instructional Authoring and Distribuion Networks<br />
for Europe. Disponible en: http://www.ariadne-eu.org/ [2008, 27 de noviembre]<br />
• Balatsoukas, P., Morris, A. et al. (2008). Learning Objects Update: Review and<br />
Critical Approach to Content Aggregation. Educational Technology & Society 11<br />
(2), 119-130.<br />
• Berggreen, A., Burgos, D., Fontana, J. M., Hinkelman, D., Hung, V., Hursh, A. y<br />
Tielemans, G. (2005). Practical and pedagogical issues for teacher adoption of<br />
ims learning design standards in moodle LMS. Journal of Interactive Media in<br />
Education, 2005 (2), 1-24.<br />
• Berlanga, A. J. y García, F. J. (2005). IMS ld reusable elements for adaptive<br />
learning designs. Journal of Interactive Media in Education, 11, 1-16.<br />
• Botturi, L. (2006). E2ML: A visual language for the design of instruction.<br />
Educational Technology Research and Development, 54 (3), 265-293.<br />
• Brickley, D. (1998). Tutorial Markup Language (TML), [en línea]. Bristol:<br />
Institute for Learning and Research Technology, University of Bristol.<br />
Disponible en: http://www.ilrt.bris.ac.uk/netquest/about/lang/ [2008, 27 de<br />
noviembre].<br />
249
• Britain, S. (2004). A review of learning design: Concept, specification and tools.<br />
JICS E-learning Pedagogy Programme report, [en línea]. Disponible en:<br />
www.jisc.ac.uk/uploaded_documents/ACF83C.doc [2008, 27 de noviembre].<br />
• Buendia, F., Agustí, M. Benlloch, J.V., Bisbal, E. y Lluesma, M (2003). Xedu, a<br />
proposal of learning management system implementation. In International<br />
Conference on Network Universities and e-Learning, Valencia (España), Mayo<br />
8-9 2003.<br />
• Buendía, F., Agustí, F., Benlloch, J. V., Bisbal, E. y Lluesma, M. (2004). Xedu,<br />
a proposal of learning management system implementation. Journal of<br />
Information Technology Impact, 4 (1), 12.<br />
• Burgos, D. y Grif?ths, D. (2005). The unfold project. Understanding and using<br />
learning design. Herleen: Open University of The Netherlands.<br />
• Caeiro Rodríguez, M., Marcelino, M. J., Llamas-Nistal, M., Anido Rifón, L. E.,<br />
Mendes, A. J. (2007). Supporting the Modeling of Flexible Educational Units<br />
PoEML: A Separation of Concerns Approach, [en línea]. Disponible en: J. UCS<br />
13 (7), 980-990.<br />
• CopperAuthor (2007). Disponible en:<br />
http://sourceforge.net/projects/copperauthor [2008, 17 de mayo].<br />
• CopperCore (2008). Disponible en: http://www.coppercore.org [2008, 27 de<br />
noviembre]<br />
• Dalziel, J. (2003). Implementing learning design: The learning activity<br />
management system (lams). En G. Crisp, D. Thiele, I. Scholten, S. Barker & J.<br />
Baron (Eds.), 20th Annual Conference of the Australasian Society for<br />
Computers in Learning in Tertiary Education (ASCILITE 2003). Adelaide,<br />
Australia.<br />
• Dalziel, J. (2005). From re-usable e-learning content to re-usable learning<br />
designs: Lessons from lams. LAMS Foundation.<br />
• Dick, W. y Carey, L. (1996). The Systematic Design of Instruction (4a. ed.).<br />
Nueva York: Haper Collins College Publishers.<br />
• Dick, W., Carey, L. y Carey, J. O. (2000). The Systematic Design of Instruction<br />
(5a ed.). Allyn & Bacon.<br />
• Dodero, J. M., Tattersall, C., Burgos, D. y Koper, R. (2006). Nonrepresentational<br />
authoring of learning designs: from idioms to model-driven<br />
development, [en línea]. Disponible en: http://hdl.handle.net/1820/783. [2008,<br />
27 de mayo].<br />
• Dodge, B. (1995). Some thoughts about WebQuests, [en línea]. Disponible en:<br />
http://webquest.sdsu.edu/about_webquests.html [2008, 5 de diciembre].<br />
• Escobedo del Cid, J. P., de la Fuente Valentín, L., Gutiérrez, S., Pardo, A. y<br />
Delgado Kloos, C. (2007). Implementation of a Learning Design Run-Time<br />
Environment for the LRN Learning Management System. Journal of Interactive<br />
Media in Education.<br />
• Fernández Carballo-Calero, M. V. (2008). WebQuests: Un modelo <strong>educativo</strong><br />
basado en el uso de internet. Revista de Formación e Innovación Educativa<br />
Universitaria, 1 (2), 58-60.<br />
• Fernández-Manjón, B., Moreno-Ger, P., Sierra, J.L. y Martínez-Ortiz, I. (2007).<br />
Uso de estándares aplicados a TIC en Educación. Informe Nº 16. CNICE.<br />
• Griffiths, D., Beauvoir, P. y Sharples, P. (2008). Advances in Editors for IMS LD<br />
in the TENCompetence Project. En Proc. of 8th IEEE International Conference<br />
on Advanced Learning Technologies (ICALT 08), pp. 1045-1047.<br />
250
• Hernández-Leo, D., Villasclaras-Fernández, E. D., Asensio-Pérez, J. I.,<br />
Dimitriadis, Y., Jorrín-Abellán, I. M., Ruiz-Requies, I. y Rubia-Avi, B. (2006).<br />
Collage: A collaborative learning design editor based on patterns. Educational<br />
Technology & Society, 9 (1), 58–71.<br />
• HR-XML Consortium (2004). Competencies Schema, [en línea]. Disponible en:<br />
http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/Competencies.html [2008, 27 de<br />
noviembre].<br />
• IEEE (2007). 1484.20.1/Draft Standard for Learning Technology— Data Model<br />
for Reusable Competency Definitions (último borrador publicado de acceso<br />
público y gratuito). Disponible en: http://www.ieeeltsc.org:8080/Plone/workinggroup/competency-data-standards-working-group-<br />
20/IEEE_1484.20.1.D5.WD11.zip [2008, 12 de noviembre].<br />
• IEEE LOM (2002). IEEE Standard for Learning Object Metadata. IEEE<br />
Standard 1484.12.1-2002. Autor.<br />
• IEEE RCD (2008). IEEE Standard for Learning Technology - Data Model for<br />
Reusable Competency Definitions, IEEE Std 1484.20.1-2007. Autor.<br />
• IMS CP (2004). IMS Content Packaging Specification v 1.1.4. [en línea].<br />
Disponible en www.imsglobal.org/content/packaging/ [2008, 15 de noviembre].<br />
• IMS Global Consortium (2002). IMS Reusable Definition of Competency or<br />
Educational Objective Specification, Version 1.0 Final Specification, [en línea].<br />
Disponible en: http://www.imsglobal.org/competencies/index.html [2008, 27 de<br />
noviembre].<br />
• IMS Global Consortium (2003). IMS Learner Information Package Accessibility<br />
for LIP, Version 1.0 Final Specification, [en línea]. Disponible en:<br />
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].<br />
• IMS Global Consortium (2004). IMS AccessForAll Meta-data, Version 1.0 Final<br />
Specification, [en línea]. Disponible en:<br />
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].<br />
• IMS Global Consortium (2005). IMS Guidelines for Developing Accessible<br />
Learning Applications, Version 1.0 White Paper, [en línea]. Disponible en:<br />
http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre].<br />
• IMS Global Consortium (2005). IMS Learner Information Package, Version<br />
1.0.1 Final Specification, [en línea]. Disponible en:<br />
http://www.imsglobal.org/profiles/index.html [2008, 27 de noviembre].<br />
• IMS Global Learning Consortium (2008). Disponible en:<br />
http://www.imsproject.org [2008, 27 de noviembre].<br />
• IMS LD (2003). IMS Learning Design, [en línea]. Disponible en:<br />
http://www.imsglobal.org/learningdesign/ [2008, 27 de noviembre].<br />
• IMS META (2006). IMS Meta-Data Version 1.3., [en línea]. Disponible en:<br />
www.imsglobal.org/metadata/#version1.3. [2008, 15 de noviembre].<br />
• IMS QTI (2005). IMS Question & Test Interoperablity Specification, Version 2.0<br />
Final Specification, [en línea]. Disponible en:<br />
http://www.imsglobal.org/question/index.html [2008, 27 de noviembre].<br />
• IMS QTI (2006). IMS Question & Test Interoperability Specification v2.1. , [en<br />
línea]. Disponible en: www.imsglobal.org/question [2008, 15 de noviembre].<br />
• IMS RDCEO (2002). IMS Reusable Definition of Competency or Educational<br />
Objective Specification v 1., [en línea]. Disponible en:<br />
www.imsglobal.org/competencies [2008, 15 de noviembre].<br />
• IMS SS (2003). IMS Simple Sequencing Specification v1.0., [en línea].<br />
Disponible en: www.imsglobal.org/simplesequencing [2008, 15 de noviembre].<br />
251
• Institute of Electrical and Electronics Engineers (IEEE) Learning Technology<br />
Standards Committee (LTSC) (2008). Disponible en: http://ltsc.ieee.org [2008,<br />
27 de noviembre].<br />
• Karampiperis, P. y Sampson, D. (2004). A ?exible authoring tool supporting<br />
adaptive learning activities. En Proceedings of IADIS International Conference<br />
on Cognition and Exploratory Learning in Digital Age. Lisboa, Portugal.<br />
• Koch, M. (2002). Interoperable community platforms and identity management<br />
in the university domain. International Journal on Media Management, 4 (1),<br />
21–30.<br />
• Koper, R. (2000). From change to renewal: Educational technology foundations<br />
of electronic learning environments. Holanda: Open University of the<br />
Netherlands.<br />
• Koper, R. (2001). Modelling units of study from a pedagogical perspective: the<br />
pedagogical meta-model behind EML. Holanda: Educational Technology<br />
Expertise Centre (OTEC), Open University of the Netherlands.<br />
• Li, X. (1991). What's So Bad About Rule-Based Programming?. IEEE Software<br />
8, 103-105.<br />
• Martínez-Ortiz, I., Moreno-Ger, P., Sancho-Thomas, P., y Fernández-Manjon,<br />
B. (2005). Using docbook to aid in the creation of learning content. En A.<br />
Rettberg & C. Bobda (Eds.), New Trends and Technologies in Computer-Aided<br />
Learning for Computer-Aided Design, (pp. 11–23). Springer.<br />
• Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2006).<br />
Using docbook and xml technologies to create adaptive learning content.<br />
International Journal of Computer Science and Applications, 3 (2), 91–108.<br />
• Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2008).<br />
A Flow-Oriented Visual Language for Learning Designs. En Proceedings of the<br />
7th International Conference on Web-based Learning (ICWL 2008). Jinhua,<br />
China. Lecture Notes in Computer Science 5145, pp 486-496.<br />
• Mayes, T., de Freitas, S. (2004). Stage 2: Review of e-learning theories,<br />
frameworks and models. JICS E-learning Model Desk Study, [en línea].<br />
Disponible en:<br />
http://www.jisc.ac.uk/uploaded_documents/Stage%202%20Learning%20Model<br />
s%20(Version%201).pdf [2008, 27 de noviembre].<br />
• McAndrew, P., Woods, W. I. S., Little, A., Weller, M. J., Koper, R. y Vogten, H.<br />
(2004). Implementing learning design to support web-based learning. En<br />
Proceedings of the Australasian World Wide Web Conference (AusWeb04).<br />
• MedBiquitous Competencies Working Group (2008). Disponible en:<br />
http://www.medbiq.org/working_groups/competencies/index.html [2008, 27 de<br />
noviembre].<br />
• Merrill, M. D. (1994) Instructional Design Theory. Educational Technology<br />
Publications. Englewood Cliffs.<br />
• Miao, Y. (2005). Cosmos: Facilitating learning designers to author units of<br />
learning using ims ld. En D. Jonassen & I. Mitsuru (Eds.), International<br />
Conference on Computers in Education (pp. 275–282). Singapore: IOS Press.<br />
• Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I. y Fernández-Manjón, B. (2007).<br />
A Documental Approach to Adventure Game Development. Science of<br />
Computer Programming 67 (1), 3-31.<br />
• Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I., Fernández-Manjón, B. (2008).<br />
A Content-Centric Development Process Model. IEEE Computer 41 (3), 24-30.<br />
252
• OMG (2007). Unified Modeling Language: Superstructure version 2.1.1, [en<br />
línea]. Disponible en: http://www.omg.org/cgi-bin/doc?formal/07-02-05 [2008,<br />
27 de noviembre].<br />
• Paquette, G. (2004). Educational modeling languages, from an instructional<br />
engineering perspective. En McGreal, R. (ed.), Online education using learning<br />
objects (pp 331–246). Londres: Routledge/Falmer.<br />
• Paquette, G., Teja, I., Leonard, M., Lundgren-Cayrol, K. y Marino, O. (2005).<br />
An Instructional engineering method and tool for design of Units of Learning. En<br />
Learning Design, a Handbook on Modelling and Delivering Networked<br />
Education and Training (pp 161–184). Heidelberg: Springer.<br />
• Polsani, P. (2003). Use and Abuse of Reusable Learning Objects. En Journal of<br />
Digital Information 3 (4).<br />
• Rawlings, A., van Rosmalen, P., Koper, R., Artacho-Rodriguez, M. y Lefrere, P.<br />
(2002). Survey of educational modelling languages (EML). En CEN/ISSS<br />
WS/LT Learning Technologies Works-hop, September 19.<br />
• Redondo Templado, F. M. (2006). Sistema Binario [en línea]. Disponible en:<br />
http://clic.xtec.net/db/act_es.jsp?id=3259 [2008, 5 de diciembre].<br />
• Reigeluth, C. M. (1983). Instructional Design Theories and Models: An<br />
Overview of Their Current Status. Lawrence Erlbaum Associates.<br />
• RELOAD (2008). Disponible en: http://www.reload.ac.uk [2008, 27 de<br />
noviembre].<br />
• Rodríguez-Artacho, M., Verdejo, M. F., Mayorga, J. I. y Calero, M. Y. (1999).<br />
Using high-level language to describe and create web-based learning<br />
scenarios. En IEEE Frontiers In Education FIE ’99 (pp 10-13). San Juan, Puerto<br />
Rico.<br />
• SCORM (2004). Scorm 2004 overview 2nd edition. Advanced Distributed<br />
Learning.<br />
• Sierra, J. L., Moreno-Ger, P., Martínez-Ortiz, I. y Fernández-Manjón, B. (2006).<br />
A highly modular and extensible architecture for an integrated ims based<br />
authoring system: The experience. Software-Practice & Experience,<br />
37 (4), 441–461.<br />
• Van Durm, R., Duval, E., Verhoeven, B., Cardinaels, K. y Olivié, H. (2001).<br />
Extending the ariadne web-based learning environment. En World Conference<br />
on Educational Multimedia, Hypermedia & Telecommunications (ED-MEDIA<br />
2001) (pp 1932–1937). Tampere, Finlandia.<br />
• Vantroys, T. (2003). Du langage métier au langage technique, une plateforme<br />
?exible déxécution de scénarios pédagogiques. Lille: Computer sciences,<br />
Université des Sciences et Technologies de Lille.<br />
• Verbert, K. y Duval, E. (2004). Towards a global component architecture for<br />
learning objects: A comparative analysis of learning object content models. En<br />
P. Kommers & G. Richards (Eds.), World Conference on Educational<br />
Multimedia, Hypermedia and Telecommunications 2004 (pp. 202–208),<br />
Chesapeake, VA: AACE.<br />
• Walsh, N. y Muellner, L. (1999). DocBook: The De?nitive Guide (1a ed.).<br />
Sebastopol, CA, EE.UU.: O’Reilly.<br />
• Weitl, F., Süß, Ch., Kammerl, R. y Freitag, B. (2002). Presenting Complex e-<br />
Learning Content on the Web: A Didactical Reference Model. En Proc. e-learn<br />
2002 world conference on E-Learning in Corporate, Government, Healthcare,<br />
and Higher Education.<br />
253
• Weller, M., Little, A., McAndrew, P. y Woods, W. (2006). Learning design,<br />
generic service descriptions and universal acid. Educational Technology &<br />
Society, 9 (1), 138–145.<br />
• XML Schema (2004). W3C Recommendation: XML Schema (2a ed.) [en línea].<br />
Disponible en: www.w3.org/TR [2008, 15 de noviembre].<br />
254