ESTANDARIZACIÓN Y DISEÑO EDUCATIVO DIRECCIÓN DE LA SERIE Instituto de Tecnologías Educativas (ITE) Dirección: Antonio Pérez Sanz y Alfonso Berlanga Coordinación: María Luisa Gutiérrez de la Concepción, Nieves Gutiérrez de la Concepción y Antonio Galisteo del Valle Corrección y revisión: Antonio Galisteo del Valle, Pamela Fernández Sánchez y Antonio Estévez Funes AUTORES Dirección del Informe: Baltasar Fernández Manjón, José Luis Sierra Rodríguez, Iván Martínez Ortiz y Pablo Moreno Ger PUBLICACIÓN Dirección: Antonio Pérez Sanz Producción ejecutiva: Antonio Galisteo del Valle, Mª Luisa Gutiérrez de la Concepción y Nieves Gutiérrez de la Concepción Diseño gráfico: Aurelio Lorenzo Pérez y Mercedes Moral Maroto Edición web: Antonio Estévez Funes y Pamela Fernández Sánchez 2 Resumen Ejecutivo Este informe aborda los aspectos de especificación, sistematización y estandarización de los modelos educativos utilizados en la enseñanza que emplea como ayuda y soporte las Tecnologías de la Información y la Comunicación (TIC). Todo este conjunto de diseños o estrategias instruccionales, basados a su vez en diversos modelos pedagógicos, es lo que se engloba bajo el término de “diseño educativo” (en inglés Learning Design). La idea subyacente es que las primeras iniciativas de estandarización (e.g. IMS Content Packaging, IEEE LOM) se han basado principalmente en la organización y descripción de los contenidos (para una descripción mas completa se puede consultar el informe 16 de esta misma colección Uso de estándares aplicados a TIC en Educación que aunque resuelven el problema de la interoperabilidad y portabilidad, no son suficientes para abordar y describir completamente procesos educativos complejos como los que se utilizan de forma habitual en las clases para lograr un aprendizaje efectivo. Por tanto se ha evolucionado tratando de proporcionar formas de descripción de los procesos educativos que vayan más allá de los contenidos y contemplen también los aspectos dinámicos (e.g. actividades, secuenciación, interacciones) que son una parte fundamental de los procesos de aprendizaje y que hacen posible la creación de aplicaciones mas avanzadas como, por ejemplo, las basadas en competencias o las colaborativas. La formalización de estas descripciones de modo que sean automatizables y reproducibles por una computadora es lo que se ha denominado Lenguajes de Modelado Educativo (en inglés, Educational Modelling Languages). Es necesario destacar que este modelado educativo y en general la utilización de las TIC para la educación y aprendizaje que englobamos bajo el término e-learning no implica necesariamente una modalidad de formación a distancia ya que su uso es más amplio, siendo frecuente su empleo como apoyo a clases presenciales o incluso un modelo mixto de clases semipresenciales (lo que se ha denominado blended learning o b-learning). De hecho, por ejemplo, en las actividades modeladas pueden implicar algún tipo de interacción entre los usuarios que, a su vez, puede ser realizado con apoyo de las TIC o de forma presencial. Este documento se basa, además de en la revisión bibliográfica y de los propios estándares, en la experiencia en investigación, implementación y desarrollo que han adquirido los autores en su trabajo como miembros del grupo de investigación en elearning (<e-UCM>, http://www.e-ucm.es) de la Facultad de Informática de la Universidad Complutense de Madrid. El propósito principal de este estudio es presentar una visión general sobre las iniciativas y estándares de facto para modelado educativo que han surgido en el mundo del e-learning y que son aplicables a distintos enfoques y contextos educativos. No obstante hay que destacar que es una visión desde el punto de vista más técnico y de aplicación, no siendo objetivo del trabajo un análisis en profundidad de las teorías educativas subyacentes. Se presentan sus fundamentos y sus aplicaciones de la forma más simple posible, pero tratando de no perder el rigor, de modo que pueda ser comprensible y útil para los educadores. La amplitud, diversidad y continua evolución de este campo hace que un estudio de este tipo no pueda ser exhaustivo, es decir que cubra todas las iniciativas existentes, de modo que se ha tenido que limitar su 3 contenido para que únicamente considere aquellas iniciativas que son más utilizadas actualmente o que consideramos que son más prometedoras. Después de realizar una revisión general del modelado educativo, así como de las iniciativas y herramientas más representativas, se realiza una revisión en profundidad del estándar de facto que actualmente es más completo y versátil para el modelado educativo: IMS Learning Design. Mediante un ejemplo sencillo pero a la vez suficientemente significativo se introducen los distintos elementos necesarios para entender un estándar tan expresivo (y por tanto, en algunos casos, complejo de entender). También se presentan otros estándares relacionados con la información sobre los usuarios como es IMS Learner Information Profile (IMS LIP). IMS-LIP es una especificación para expresar la información personal de los alumnos, su historial dentro del sistema (incluyendo su porfolio de trabajos realizados) y las preferencias que tengan estos usuarios. El tema de la información de los usuarios y su estandarización aunque es muy importante plantea problemas de muy diversa índole, desde legales (debido a que la Ley de Protección de Datos Personales en Europa y España es más estricta que en otros países –aunque este tema no se aborda en este estudio- ) a culturales o de madurez de la propia especificación. A pesar del avance que supone disponer de IMS-LIP, éste es un tema complejo en el que sigue habiendo competencia comercial y falta de suficiente consenso. No obstante, se están realizando avances en temas relacionados pues ya se ha llegado al suficiente acuerdo para estandarizar una forma básica de definición de competencias y capacidades de los estudiantes. Este aspecto se trata en la especificación IMS RDCEO (y en su estándar oficial IEEE RCD asociado). En este informe también se analizan las especificaciones que tratan de lograr que el elearning sea accesible a personas con diversidad funcional. AccessForAll es la denominación genérica empleada por el consorcio IMS para designar sus iniciativas y esfuerzos relacionados con potenciar la accesibilidad de los contenidos educativos a personas con necesidades especiales derivadas de su entorno, circunstancias o discapacidades. En el capítulo final se ponen ejemplos de uso práctico de herramientas de edición de diseños educativos con IMS-LD por ser el estándar y con LAMS por ser actualmente el modelado, que aunque no sigue el estándar parece contar con mayor aceptación. La organización de este trabajo está pensada para diferentes públicos. Si el lector está interesado en tener solamente una visión general del modelado educativo en elearning podrá adquirirla mediante la lectura de los dos primeros capítulos. Un lector que ya tenga un cierto conocimiento de este modelado educativo en e-learning y de cómo se ve afectado por la estandarización, pero que quiera profundizar en aspectos más técnicos de IMS-LD o de alguno de los estándares abordados (IMS LIP, IMS RDCEO, IMS A4A) podrá obtenerlo mediante la lectura de los capítulos posteriores al segundo. Aunque estos capítulos son más técnicos, hasta donde ha sido posible, se ha tratado de hacerlos comprensibles y de poner ejemplos simplificados siempre tratando de no perder el rigor técnico. Este campo tiene además la particularidad de su juventud y cambio continuo. Como incesantemente surgen o bien nuevas especificaciones o bien correcciones o añadiduras a las existentes, la bibliografía existente queda rápidamente superada por 4 la realidad. Esto hace que gran parte de las referencias que aparecen en este trabajo lo sean a páginas web de las instituciones implicadas en la estandarización, publicaciones electrónicas o documentos que están disponibles en Internet. 5 Mensaje de comunicación corporativa Este informe ha sido encargado por el Instituto de Tecnologías Educativas del Ministerio de Educación a los profesores Baltasar Fernández Manjón, José Luis Sierra Rodríguez, Ivan Martinez Ortiz y Pablo Moreno Ger del grupo de Investigación de Ingeniería del Software aplicado al e-learning (<e-UCM>, www.e-ucm.es) perteneciente al Departamento de Ingeniería del Software e Inteligencia Artificial de la Universidad Complutense de Madrid. El encargo se realizó en el año 2008, a raíz de sus investigaciones relacionadas con el modelado educativo y en cómo estos aspectos estaban viéndose reflejados en los estándares emergentes en e-learning y en los sistemas e-learning. El tema central del informe es la situación actual del modelado educativo y cómo dicho modelado puede utilizarse en la mejora de los procesos educativos. El objetivo es descubrir a los lectores de este informe las principales características, incluyendo cualidades y limitaciones, del modelado educativo y cómo se refleja dicho modelado en los sistemas actuales de e-learning. Por completitud se presentan también especificaciones relacionadas con el modelado educativo (e.g. cómo se representa al estudiante o cómo se tienen en cuenta sus características especiales o sus competencias) y cómo este modelado educativo se refleja en sistemas concretos de e-learning que consideramos especialmente prometedores como, por ejemplo, LAMS. Baltasar Fernández Manjón es Doctor en Ciencias Físicas por la Universidad Complutense de Madrid donde actualmente es profesor en la Facultad de Informática. Es el codirector del grupo de Investigación de Ingeniería del Software aplicado al elearning (<e-UCM>, www.e-ucm.es). Ha dirigido distintos proyectos de investigación relacionados con los usos educativos de las nuevas tecnologías y es miembro del Working Group 3.3 "Research on the Educational uses of Communication and Information Tecnlogies" de la International Federation for Information Processing (IFIP), del Subcomité 36 de Tecnologías de la Información y la Comunicación para el aprendizaje (SC36), de la Asociación Española de Normalización y Certificación (AENOR CTN71/SC36) y del Capítulo Español para la Sociedad de la Educación de IEEE (Red CESEI). Ha publicado más de 90 artículos de investigación en revistas y congresos y ha participado en la organización de diversas conferencias del área (e.g. SCORM, ICALT, SIIE). Sus áreas principales de investigación son las tecnologías y los estándares de e-learning, las aplicaciones educativas de la web, la aplicación de los videojuegos a la educación y los sistemas adaptativos (incluyendo modelado de usuario y aspectos de accesibilidad). José-Luis Sierra-Rodríguez es Doctor en Informática por la Universidad Complutense de Madrid, donde actualmente ocupa una plaza de Profesor Titular de Universidad. El Dr. Sierra es coautor de más de 70 artículos de investigación publicados en revistas y actas de conferencias internacionales. Sus intereses investigadores incluyen la Ingeniería del Software orientada a lenguajes, los lenguajes de marcado y el desarrollo dirigido por lenguajes de Sistemas e-learning. Ivan Martínez es licenciado en Informática por la Universidad Complutense de Madrid. Desde 2007 trabaja como profesor Colaborador en la Facultad de Informática de la dicha universidad donde está completando su doctorado en modelado educativo y estándares de e-learning. Ha participado en diversos proyectos relacionados en el área de la educación asistida por computador tanto en el ámbito nacional como 6 internacional. Además ha publicado más de 25 artículos en conferencias y revistas internacionales. Sus áreas principales de investigación son el modelado educativo, los estándares de e-learning, las aplicaciones educativas de la web y la aplicación de los videojuegos a la educación. Pablo Moreno Ger es Doctor en Informática por la Universidad Complutense de Madrid y en la actualidad trabaja como Profesor Ayudante Doctor en el Departamento de Ingeniería del Software e Inteligencia Artificial de la UCM. Ha participado en diversos proyectos relacionados con el área de la educación asistida por computador tanto en el ámbito nacional como internacional. Además ha publicado más de 30 artículos en conferencias y revistas internacionales. Sus intereses de investigación abarcan todo tipo de tecnologías educativas, centrándose en el desarrollo e integración de contenidos altamente interactivos en los entornos de aprendizaje y sistemas elearning, especialmente en juegos educativos, así como la adaptación y la evaluación de los procesos de aprendizaje. 7 Deseamos mostrar nuestro agradecimiento al resto de miembros del Grupo de elearning de la Facultad de Informática de la Universidad Complutense de Madrid así como a los responsables del Campus Virtual de nuestra Universidad coordinados por el profesor Alfredo Fernández-Valmayor. Algunas de las pruebas se han realizado en dicho Campus Virtual. Parte de los resultados reflejados en este trabajo se han obtenido en la investigación realizada en los proyectos AdaptaLearn y OdA Virtual que han sido parcialmente financiados por la Comisión Ministerial de Ciencia y Tecnología (TIN2007-68125-C0201, TIN2005 08788 C04-01) y con ayudas de la Comunidad de Madrid y de la Universidad Complutense de Madrid para el grupo de Investigación Ingeniería del Software y e-learning (<e-UCM>, 921340 UCM-CAM). También se han reutilizado algunos de los resultados logrados en el proyecto Avanza Flexo (TSI-020301-2008-19) realizado en colaboración con otras universidades y fundaciones (U. Carlos III, U. de Cádiz, U de Santiago de Compostela, U de Harvard, LAMS-Australia y Sidar) y empresas (Atos Origin, Indra, CEPAL) y en el proyecto Cenit INREDIS liderado por Technosite y en el que participan mas de 25 univesidades y empresas españolas. Finalmente este trabajo se ha beneficiado del contraste internacional proporcionado por la participación del grupo <e-UCM> en el proyecto CID – Comunidad Intercultural para el Desarrollo y Uso de Objetos de Aprendizaje (liderado por la U. de Chile y en el que participan 8 universidades europeas e iberoamericanas). El proyecto CID pertenece al programa europeo Alfa (II-0511-A). 8 1. LENGUAJES DE MODELADO EDUCATIVO........................... 13 1.1. INTRODUCCIÓN................................................................. 13 1.2. EL CONCEPTO DE MODELADO EDUCATIVO................ 13 1.3. LENGUAJES DE MODELADO EDUCATIVO.................... 15 1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS ............. 17 1.4.1. Lenguajes Especí?cos .................................................. 18 1.4.2. Lenguajes de Estructuración de Contenidos ................ 19 1.4.3. Lenguajes de Actividades ............................................. 22 1.5. IMS LEARNING DESIGN ................................................... 24 1.6. HERRAMIENTAS DE SOPORTE A IMS-LD ..................... 27 1.6.1. Herramientas de Autoría de IMS-LD............................. 28 1.6.2. Motores de ejecución compatibles con IMS-LD ........... 33 1.6.3. Reproductores de IMS-LD ............................................ 34 1.6.4. Otras iniciativas y proyectos de investigación relacionados con IMS-LD........................................................... 36 1.7. A MODO DE CONCLUSIÓN .............................................. 38 2. LA ESPECIFICACIÓN IMS LEARNING DESIGN .................... 39 2.1. INTRODUCCIÓN................................................................. 39 2.2. UN CASO DE ESTUDIO..................................................... 39 2.3. VISIÓN CONCEPTUAL DE IMS LD ................................... 41 2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES ........ 46 2.4.1. IMS Content Packaging e IMS LD ................................ 46 2.4.2. Niveles en la Especificación ......................................... 49 2.5. EL NIVEL A......................................................................... 50 2.5.1. Estructura de alto nivel de un Diseño Educativo .......... 50 2.5.2. Descripción de los Componentes: Roles, Actividades y Entornos ..................................................................................... 52 2.5.3. Descripción del método educativo ................................ 60 2.5.4. Modelo de Ejecución ..................................................... 62 2.5.5. Ejemplo de Diseño de Nivel A ...................................... 63 2.6. EL NIVEL B ......................................................................... 68 2.6.1. Propiedades .................................................................. 69 2.6.2. Expresiones................................................................... 71 2.6.3. Acciones........................................................................ 73 2.6.4. Condiciones................................................................... 74 2.6.5. Extensión de las condiciones de finalización de actividades, actos, guiones y métodos ...................................... 76 9 2.6.6. Extensión de las acciones tras la finalización para actividades, actos, guiones y métodos ...................................... 76 2.6.7. Elementos globales y monitores ................................... 76 2.6.8. Modelo de Ejecución ..................................................... 77 2.6.9. Ejemplo de diseño de nivel B........................................ 77 2.7. EL NIVEL C ......................................................................... 84 2.7.1. Notificaciones ................................................................ 84 2.7.2. Extensiones en IMS LD nivel C .................................... 85 2.7.3. Ejemplo de diseño de nivel C ....................................... 85 2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS ... 87 2.8.1. Codificación de la Estructura de Alto nivel del Diseño . 87 2.8.2. Codificación de los roles ............................................... 89 2.8.3. Codificación de las actividades..................................... 91 2.8.4. Codificación de los entornos ......................................... 94 2.8.5. Codificación de los métodos ......................................... 95 2.8.6. Codificación de las propiedades ................................... 99 2.8.7. Codificación de las expresiones, acciones y condiciones 101 2.8.8. Codificación de elementos globales y servicio de monitorización .......................................................................... 103 2.8.9. Codificación de notificaciones..................................... 103 3. IMS LEARNER INFORMATION PACKAGE........................... 104 3.1. INTRODUCCIÓN............................................................... 104 3.2. VISIÓN CONCEPTUAL .................................................... 104 3.2.1. Categorías de datos .................................................... 105 3.2.2. Metadatos.................................................................... 107 3.3. UN CASO DE ESTUDIO................................................... 108 3.4. ESTRUCTURA XML ......................................................... 109 3.4.1. Metadatos y otros elementos comunes ...................... 109 3.4.2. El elemento learnerInformation................................... 113 3.4.3. El elemento identification ............................................ 115 3.4.4. El elemento qcl............................................................ 117 3.4.5. El elemento activity ..................................................... 120 3.4.5.1. Descripción de Actividades: definition............... 123 3.4.5.2. Productos Generados en Actividades: product. 125 3.4.5.3. Informes sobre Actividades: testimonial............ 127 3.4.5.4. Evaluación de Actividades: evaluation .............. 128 3.4.6. El elemento affiliation .................................................. 131 3.4.7. El elemento transcript ................................................. 133 10 3.4.8. El elemento accessibility ............................................. 134 3.4.8.1. Accesibilidad idiomática: language ................... 136 3.4.8.2. Preferencias de acceso: preference ................. 138 3.4.9. El elemento goal.......................................................... 139 3.4.10. El elemento competency............................................. 141 3.4.11. El elemento interest .................................................... 143 3.4.12. El elemento securitykey .............................................. 145 3.4.13. El elemento relationship.............................................. 146 4. IMS REUSABLE DEFINITION OF COMPETENCY OR EDUCATIONAL OBJECTIVE ....................................................... 148 4.1. INTRODUCCIÓN............................................................... 148 4.2. VISIÓN CONCEPTUAL DE LA DEFINICIÓN DE COMPETENCIAS ....................................................................... 151 4.3. EJEMPLOS DE POSIBLES APLICACIONES ................. 152 4.3.1. Casos de uso .............................................................. 152 4.3.2. Ejemplo de uso............................................................ 153 4.4. ESTRUCTURA XML ......................................................... 154 4.4.1. El elemento rdceo ....................................................... 154 4.4.2. El elemento identifier................................................... 157 4.4.3. El elemento title........................................................... 157 4.4.4. El elemento description............................................... 157 4.4.5. El elemento definition.................................................. 157 4.4.6. El elemento metadata ................................................. 159 4.5. EXTENSIBILIDAD............................................................. 159 5. IMS ACCESS FOR ALL .......................................................... 160 5.1. INTRODUCCIÓN............................................................... 160 5.1.1. Una problemática compleja ........................................ 161 5.1.2. Tres aspectos de un mismo problema........................ 162 5.2. IMS ACCESSIBILITY FOR LIP ........................................ 163 5.2.1. Definición de Preferencias .......................................... 164 5.2.2. Solicitud de servicios adicionales ............................... 166 5.3. IMS ACCESSFORALL METADATA ................................ 168 5.3.1. Descripción general .................................................... 169 5.3.2. Metadatos para recursos primarios ............................ 171 5.3.3. Metadatos para recursos equivalentes ....................... 173 6. HERRAMIENTAS DE SOPORTE PARA LOS DISEÑOS EDUCATIVOS................................................................................ 175 11 6.1. WEBQUEST...................................................................... 176 6.2. JCLIC ................................................................................ 178 6.3. LAMS................................................................................. 183 6.3.1. Introducción................................................................. 183 6.3.2. La herramienta LAMS ................................................. 185 6.3.3. Actividades, secuencias de actividades y mecanismos de adaptación........................................................................... 187 6.3.4. Configuración y uso básico de LAMS ......................... 193 6.3.4.1. Administración básica de LAMS........................ 195 6.3.4.2. Autoría y publicación de secuencias LAMS ...... 202 6.3.4.3. Monitorización y Seguimiento. .......................... 213 6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON LAMS .......................................................................................... 219 6.4.1. Diseño de las unidades de aprendizaje / secuencias de actividades LAMS para el caso de estudio.............................. 219 6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON IMS LD ........................................................................................ 232 7. BIBLIOGRAFÍA ....................................................................... 249 12 1. LENGUAJES DE MODELADO EDUCATIVO 1.1. INTRODUCCIÓN En la enseñanza apoyada por la tecnología, y que globalmente se denomina por el término en inglés e-learning, se ha producido una gran revolución con la nueva forma de crear contenidos que suponen los objetos de aprendizaje (OA, en inglés learning objects). Aunque los objetos de aprendizaje tienen múltiples definiciones una de las más aceptadas es la utilizada en el estándar LOM donde se definen como “cualquier entidad que puede ser usada, reutilizada o referenciada durante un proceso de aprendizaje apoyado por la tecnología”. La principal ventaja es que permite crear cursos mediante combinación de contenidos previamente existentes es decir potencia la reusabilidad y la interoperabilidad (para una descripción más completa se puede consultar el informe 16 de esta misma colección Uso de estándares aplicados a TIC en Educación). No obstante, y a pesar de las ventajas que aportan los OA en e-learning, existe también un amplio consenso entre los educadores de que la creación y presentación de materiales educativos de gran calidad no es su?ciente para obtener una experiencia educativa plena y satisfactoria. Es igualmente importante la plani?cación de las otras actividades (tutorías, exámenes, lectura de libros, etc.) que el estudiante debe llevar a cabo para conseguir los objetivos educativos propuestos por el profesor. De este análisis surge el concepto de Lenguaje de Modelado Educativo (EML) (del inglés Educational Modeling Language) como nueva piedra angular del e-learning, ya que con este tipo de lenguajes se pretende que puedan ser utilizados por los profesores para formalizar los procesos de enseñanza, de manera que las descripciones resultantes puedan ser interpretadas por las computadoras. No obstante, antes de seguir adelante es necesario destacar que estos lenguajes de modelado educativo a pesar de su potencial se encuentran todavía más en los aspectos de investigación y prueba académica que en los aspectos de aplicación directa e inmediata a gran escala. Hay varias razones de diversa índole que justifican esta situación, desde educadores que siguen teniendo dudas sobre su aplicabilidad práctica hasta la falta de herramientas suficientemente maduras y sencillas de usar por profesores que no tengan un previo conocimiento técnico. No obstante, parece ampliamente aceptado que cualquier avance que se produzca en este campo sería muy relevante y que, por tanto, a pesar de sus limitaciones actuales es necesario continuar en esta línea. Aún así, como ya se ha mencionado en la introducción, hay que destacar que este informe pretende dar una visión desde el punto de vista más técnico y de aplicación, no siendo su objetivo un análisis en profundidad de las teorías educativas subyacentes (un estudio más en esta línea es el de Mayes y de Freitas, 2004). 1.2. EL CONCEPTO DE MODELADO EDUCATIVO El concepto de modelado educativo es muy amplio y es previo a su uso en el campo del e-learning. Ya sea en enseñanza presencial como en enseñanza a distancia ha 13 habido muchos esfuerzos para planificar y documentar el proceso utilizado para enseñar a los alumnos. No obstante, en la mayoría de los casos, se han realizado descripciones informales (a veces descritas como “recetas”) o mediante fichas (patrones o plantillas) pero no ha habido iniciativas exitosas ampliamente aceptadas de formalización y documentación rigurosa y estándar del proceso educativo. En ese sentido se pueden distinguir, por lo menos, tres categorías de diseños: § Los diseños informales donde sólo se proporcionan unas indicaciones sobre el proceso educativo y que normalmente contemplan los contenidos, el contexto y las estrategias a utilizar, pero en esas descripciones no siguen un patrón común ni tienen por qué abordar todas los mismos aspectos. § Los diseños estructurados en base a plantillas que tienen un conjunto fijo de aspectos a describir y que se cumplimentan en todos los casos. De esta forma se tienen descripciones más regulares pero donde normalmente no se ponen limitaciones o normas muy estrictas sobre cómo rellenar dichos apartados. En el mejor de los casos se acompañan de una guía metodológica sobre cómo rellenarlos que incluso en algunos campos proporciona un conjunto de valores fijos entre los que seleccionar. § Los diseños formales en los que, normalmente mediante un lenguaje específico, se proporciona una sintaxis que clarifica qué se puede describir y una gramática que determina el significado de dichas descripciones. Estas descripciones formales, aunque mucho más trabajosas de crear, son susceptibles de automatización. Esto significa, por ejemplo, que se puede comprobar que las descripciones son correctas y que es factible crear un sistema informático que las ejecute automáticamente. Desde el punto de vista del alcance del modelado se pueden distinguir los modelados especializados, que pretenden cubrir sólo un ámbito o tipo determinado de actividades educativas (e.g. WebQuest) y los modelados genéricos que pretenden cubrir cualquier tipo de situación educativa tanto por el dominio como por el tipo de actividades o medios utilizados. En e-learning se comienza a hablar de modelado educativo cuando se deja de considerar que los contenidos (y por tanto los objetos de aprendizaje) son el centro y elemento principal del aprendizaje en el que sólo se tiene en cuenta el escenario de un alumno individual accediendo al contenido. De ahí se ha pasado a una visión más global en la que se tratan de especificar los procesos educativos de una forma más completa en base a las condiciones en las que se realiza y a las actividades que tienen que llevar a cabo, tanto los alumnos como los profesores, para lograr unos determinados objetivos de aprendizaje. La idea es pasar de sistemas basados o centrados en contenidos a sistemas orientados a actividades y aprendizajes activos (aunque la calidad de los contenidos sigue siendo imprescindible) que permitan incrementar las posibilidades que ofrecen los entornos de gestión de e-learning. Las ideas subyacentes a este enfoque son (Britain, 2004): § Las personas aprenden mejor cuando están implicadas activamente en la realización de una actividad (actividad de aprendizaje). El aprendizaje es un proceso activo, que requiere esfuerzo, y en el cual no todos los alumnos tienen la misma capacidad de aprender por sí mismos. Este aprendizaje puede verse facilitado si se proporciona algún tipo de guiado o soporte (estrategia didáctica 14 o método de aprendizaje) que implique o motive a los alumnos (trabajo colaborativo, aprendizaje basado en problemas, etc). § Las actividades de aprendizaje se pueden secuenciar y organizar para lograr un aprendizaje más efectivo. Este secuenciamento es lo que se ha denominado flujo de aprendizaje. El aprendizaje se mejora no sólo si se tienen actividades que impliquen a los estudiantes si no también si se diseña de forma cuidadosa su secuenciación en el tiempo o el tiempo que tienen asignado. De esta forma se pueden considerar, por ejemplo, distintas “rutas” de aprendizaje, tareas que puedan ser realizadas en paralelo o trabajos que deben completarse en subgrupos antes de continuar con el desarrollo del curso. § Los diseños educativos se pueden describir de una forma consistente (formal) y transferible para facilitar que se puedan compartir y reutilizar. Aquí surge el problema de cómo describir una estrategia de enseñanza de modo lo suficientemente abstracto como para que sea útil en un contexto que no sea igual que en el que se ha creado, pero que a la vez sea suficientemente detallada como para que se pueda reproducir sin perder su valor pedagógico. Además, dicha descripción debe ser procesable automáticamente por una computadora. Parece ampliamente aceptado que el modelado educativo, a pesar de sus dificultades, tiene una serie de ventajas. Por un lado permite que los profesores formalicen sus diseños educativos de modo que quede reflejado qué actividades se realizan y cómo se organizan dichas actividades. La otra ventaja es que cuando un diseño ha probado su eficacia puede ser compartido con otros docentes o archivado para un uso o consulta posterior. 1.3. LENGUAJES DE MODELADO EDUCATIVO La generalización del término EML en e-learning proviene del trabajo desarrollado en la Universidad Abierta de los Países Bajos (OUNL) durante ?nales de los años 90. El grupo de investigación liderado por el Profesor Rob Koper analizó los sistemas de gestión de la enseñanza (LMSs de su término en inglés Learning Management Systems) que existían y que eran los más utilizados en aquella época, intentando identi?car los problemas y defectos de dichos sistemas de e-learning. En particular se identi?có como principal problema la falta de aplicación de la teoría instruccional y del aprendizaje dentro de los mismos. Como resultado desarrolló y puso en práctica una propuesta basada en la de?nición de un Lenguaje especí?co de dominio llamado Educational Modelling Language (OUNL-EML) (para evitar ambigüedades se denominará a este lenguaje OUNL-EML a lo largo de este capítulo, en lugar de simplemente EML). En un estudio realizado por el CEN/ISSS WS/LT Learning Technology Workshop acerca de los Lenguajes de Modelado Educativo se de?nió el concepto de EML como: Modelo de información semántico y su vinculación, que describen el contenido y el proceso dentro de una “Unidad de Aprendizaje” desde una perspectiva pedagógica y con el objetivo de dar soporte a la reutilización y la interoperabilidad (Rawlings et al., 2002). 15 De esta de?nición pueden extraerse los siguientes conceptos principales: § Modelo de Información Semántico. Un modelo de información semántico es un meta-modelo (conceptualización) de un dominio de discurso. En este caso se trata de un meta-modelo que describe el proceso de enseñanza/aprendizaje. § Modelo de información y vinculación. La “vinculación” de un EML es una formalización lingüística del modelo semántico. Habitualmente, esta formalización se realiza mediante la de?nición de un Lenguaje Especí?co de Dominio basado en las tecnologías XML a ?n de conseguir una vinculación o representación directamente procesable en el ordenador. § Unidad de Aprendizaje. El concepto de Unidad de Aprendizaje (UOL) es el punto clave de los EMLs. En palabras del profesor Koper (2001): “Una UOL (también conocida como unidad de estudio) es la menor unidad que proporciona eventos educativos a los estudiantes, satisfaciendo uno o más objetivos educativos interrelacionados”. En los EMLs se pasa del concepto de OA como elemento constructivo básico y atómico a otro de mayor granularidad que es la UOL y que no sólo agrupa contenidos. Por tanto, una UOL no puede dividirse sin perder su propia semántica orientada al logro de los objetivos educativos. Una UOL puede ser un curso, un taller, una práctica, una titulación completa, etc. Cada UOL de?ne el modelo instructivo, y el entorno donde se realiza. Este entorno está caracterizado por los recursos materiales (que pueden ser OAs) y los servicios (v.g. foro, chat, videoconferencia, e-mail) que serán utilizados durante la puesta en ejecución de la UOL. § Perspectiva Pedagógica. Un EML debe ser relativamente independiente de las teorías instruccionales, de manera que el profesor o el diseñador instruccional pueda decidir cuál de estas teorías desea aplicar. Una vez más los estándares educativos no tratan de limitar la expresividad del docente o de imponer una visión determinada de cómo debe realizarse la enseñanza. § Reutilización e Interoperatibilidad. La idea detrás de los EMLs no es sólo permitir a las aplicaciones informáticas interpretar los guiones creados mediante dichos lenguajes. Además tienen como objetivo promover la reutilización de aquellas UOLs que hayan tenido una aplicación exitosa, así como permitir el intercambio de estas unidades de aprendizaje entre distintos sistemas de e-learning sin tener en cuenta cómo el sistema de información implementará ?nalmente la semántica del modelo de?nido. Además de estos conceptos básicos de los EMLs, el profesor Koper (2000) identi?ca las siguientes características deseables que debería cumplir un EML: § Un Lenguaje de Modelado Educativo debe estar de?nido formalmente y tiene que poder ser procesable en el ordenador, de manera que los guiones creados con dicho lenguaje puedan ser interpretados por aplicaciones informáticas. § Un Lenguaje de Modelado Educativo tiene que ser pedagógicamente neutral. Como ya se ha indicado anteriormente, el lenguaje no debe imponer restricciones a la forma de enseñar y, por tanto, debe permitir la aplicación de distintas estrategias pedagógicas que el educador considere oportunas en la concepción de las UOLs. 16 § Un Lenguaje de Modelado Educativo debe permitir a los diseñadores crear UOLs completas que incluyan actividades a realizar por el estudiante (¿qué hacer?), las personas involucradas en dichas actividades (¿con quién?) y el entorno donde se llevarán a cabo las actividades (¿qué materiales son necesarios?, ¿qué herramientas?, etc.). § Una UOL creada utilizando un EML debería ser perdurable, es decir, resistente a los cambios y evoluciones tecnológicas, así como a cambios de plataformas, puesto que su propósito es facilitar la reusabilidad e interoperabilidad entre sistemas y herramientas distintas. A modo de resumen, los EMLs son lenguajes que permiten describir UOLs, las cuáles a su vez describen el proceso de aprendizaje como un todo (y no sólo centrado en los contenidos como se hace en los objetos de aprendizaje). Además, otra característica añadida de estos lenguajes es que proporcionan un mecanismo para la comunicación entre el personal técnico de soporte y el personal no técnico (normalmente los educadores) dentro de una organización durante la operacionalización del EML. Ahora las UOLs son completas de modo que el personal técnico puede saber qué es lo que está planificado y ayudar a resolver las incidencias que pudieran producirse (e.g. no disponibilidad de un recurso). 1.4. CLASIFICACIÓN DE LOS PRINCIPALES EMLS A partir de las diferentes iniciativas desarrolladas en base a los principios de los Lenguajes de Modelado Educativo previamente mencionados y a los EMLs descritos en (Rawlings et al., 2002), es posible crear una clasi?cación para los mismos similar a la propuesta en (Vantroys, 2003): § Lenguajes Especí?cos. En esta categoría se encuentran los lenguajes que, aún sin cumplir estrictamente todas las características de un EML, permiten a los diseñadores describir las etapas del proceso de aprendizaje utilizando una metodología especí?ca. En particular, dentro de esta categoría podemos destacar aquellos lenguajes aplicados a la metodología de enseñanza basada en la resolución de problemas mediante el planteamiento de preguntas y a la recolección de soluciones y respuestas. § Lenguajes de estructuración de contenidos. Esta categoría está formada por aquellos lenguajes que permiten a los diseñadores organizar los recursos educativos en una secuencia, siempre teniendo en cuenta las necesidades del estudiante y la interacción con el propio contenido, a ?n de mejorar la experiencia educativa. § Lenguajes de Actividad. En esta categoría se encuentran los lenguajes que están enfocados principalmente a la organización de actividades en general (utilizando computadoras o no) durante el proceso de aprendizaje. En la tabla Tabla 1.4.a. se clasi?can diversos EMLs de acuerdo a estas tres categorías. En los siguientes puntos se darán más detalles acerca de cada uno de estos lenguajes. 17 Tabla 1.4.a. Clasi?cación de Alto nivel de algunos Lenguajes de Modelado Educativo. Tipo Lenguajes Especí?cos Lenguajes de Estructuración de Contenidos Lenguajes de Actividad Lenguage Tutorial Markup Language (TML) IMS Question and Test Interoperability (IMS-QTI) <e-Adventure> TArgeted Reuse and GEne ration of TEAching Mate-rials (Targeteam) Learning Material Mark-up Language (LMML) ARIADNE Course (Curriculum) Description Format (A-CDF) AICC Course Data Model (AICC/CMI) IMS Simple Sequencing (IMS SS) ADL Sharable Content Object Reference Model 2004 (SCORM) <e-DocBook> PALO Educational Environment Modeling Language (EEML) XEDU Méthode d’ingénierie d’un système d’apprentissage (MISA) Educational Modeling Language -Open University of the Netherlands (EML-OUNL <e-LD> PoEML IMS Learning Design (IMS LD) Sitio web http://www.ilrt.bris.ac.uk/netquest http://imsglobal.org/question http://edventure.e-ucm.es http://www.targeteam.net No Disponible http://www.ariadne-eu.org/ http://www.aicc.org http://www.imsglobal.org/simplesequencing/ http://www.adlnet.gov/scorm/ http://e-docbook.e-ucm.es/ http://sensei.ieec.uned.es/palo/ http://www.istituti.usilu.net/botturil/ publications.htm http://www.licef.teluq. uquebec.ca/gp/ http://eml.ou.nl http://e-ld.e-ucm.es/ http://wwwgist.det.uvigo.es/~mcaeiro/thesis/ http://www.imsglobal.org/learningdesign/ 1.4.1. Lenguajes Especí?cos Tutorial Markup Language (TML) (Brickley, 1998) es una extensión de HTML para crear preguntas. TML esta diseñado para separar por un lado la semántica del contenido asociado a la distribución de la pregunta y por otro la semántica del contenido de la pregunta en sí. El formato de los archivos TML es texto plano, pudiendo ser generados a partir de otros formatos y otras preguntas que se encuentren almacenadas en una base de datos. IMS Question and Test Interoperability (IMS-QTI) es una propuesta llevada a cabo por el consorcio internacional IMS (Instructional Management Systems – Global Learning Consortium) para crear bancos de preguntas y de evaluaciones (IMS QTI, 2006). El 18 principal objetivo de IMS-QTI es permitir el intercambio de evaluaciones y de la información asociada a las evaluaciones entre distintos LMSs. En las evaluaciones creadas con IMS-QTI existe una división clara entre las preguntas en sí mismas (¿qué es lo que se pregunta?) y la forma en la que se presentan dichas preguntas al alumno y en la que se evalúan las respuestas dadas por el mismo. IMS-QTI permite crear test interactivos, los cuáles pueden incluir pistas (información para ayudar a los alumnos). También es posible crear plantillas de exámenes que pueden ser utilizadas cuando los estudiantes llevan a cabo el examen, creando diferentes exámenes a partir de la misma plantilla. En el Informe número 16 de esta misma colección se puede encontrar una presentación completa y detallada de este estándar (Fernández-Manjón et al., 2007). <e-Adventure> (Moreno-Ger, 2007) es un proyecto que propone un modelo de desarrollo de videojuegos educativos que son directamente desplegables en un LMS (siempre que el LMS cumpla con los estándares de IMS Content Packaging). Con <eAdventure> es posible crear aventuras grá?cas y simulaciones con estructura de juego que tengan un objetivo educativo. Esta iniciativa está compuesta por dos conceptos principales: el motor <e-Adventure> y el lenguaje <e-Adventure>. Características distintivas de este enfoque es que tanto el motor como el lenguaje <e-Adventure> permiten crear juegos adaptativos e incluyen mecanismos que monitorizan e informan acerca de la actividad de los estudiantes dentro del juego. El motor de <e-Adventure> ejecuta los juegos que están representados (o codificados) mediante el lenguaje <e-Adventure>. Este motor es capaz de comunicarse con un sistema de e-learning o LMS permitiendo que el juego pueda informar al LMS acerca del progreso del alumno al interactuar con el mismo. El lenguaje <e-Adventure> es un lenguaje especí?co de dominio ya que permite a un profesor con pocos conocimientos tecnológicos definir juegos educativos (Moreno-Ger, 2008). Este lenguaje permite la codi?cación del storyboard del juego, así como la de?nición de los personajes y objetos con los que podrá interactuar el alumno. De la misma manera, también es posible de?nir de manera simple las condiciones de las que dependen las distintas acciones que pueden llevarse a cabo en el juego. Finalmente, el lenguaje también incluye construcciones que permiten la monitorización de características importantes desde el punto de vista pedagógico (e.g. si el alumno se queda bloqueado en alguna parte del juego o si toma decisiones erróneas que implican algún error de concepto) e incluso la creación de juegos que se adaptan a las características específicas del usuario. 1.4.2. Lenguajes de Estructuración de Contenidos Targeted Reuse and Generation of Teaching Materials (Targeteam) permite la creación y el mantenimento (uso y reutilización) de contenidos educativos (Koch, 2002). Este EML permite el uso de los materiales en diferentes situaciones y dominios pedagógicos (primaria, secundaria y nivel universitario). Haciendo uso de Targeteam, es posible crear las notas de clase, además de otros contenidos, como aclaraciones, explicaciones y ejemplos. Este lenguaje está enfocado al uso de tecnologías XML, como TeachML, e introduce el concepto de tema (issue) como UOL. 19 Learning Material Markup Language (LMML) está basado en un meta-modelo que puede encajar en distintos dominios de aplicación. LMML ha sido diseñado como aplicación del meta-lenguaje XML para la descripción de los contenidos educativos (Weitl et al., 2002). Estos contenidos educativos están estructurados en módulos, que a su vez pueden estar estructurados en submódulos. LMML se basa en una estructuración del contenido educativo de manera jerárquica y modular, donde los contenidos creados con LMML pueden ser adaptados a diferentes situaciones de aprendizaje y a distintos tipos de estudiantes. Utiliza el concepto de curso (course) como UOL. ARIADNE Course Description Format (A-CDF) es un EML que permite la creación de cursos en línea (Verbert y Duval, 2004). Un curso en A-CDF consiste en documentos XML que serán utilizados conjuntamente con una herramienta LMS que será la que finalmente generará los cursos (Van Durm et al., 2001). A-CDF pone especial interés en el contenido y en su agregación, siendo además lo su?cientemente expresivo como para describir el proceso de aprendizaje de acuerdo con un modelo pedagógico. El desarrollo con A-CDF se realiza a través de un conjunto de herramientas construidas en el seno del consorcio ARIADNE (editores curriculares, LMS, KPS). Este lenguaje establece el concepto de curso (course) como UOL. AICC Course Data Model (AICC/CMI) contiene toda la información necesaria para describir un curso (AICC, 2004). Este formato puede intercambiarse entre distintos LMSs mediante herramientas de importación / exportación, utilizando el concepto de Unidades de Asignación (Assignable Units) como unidad de intercambio. La información generada durante la interacción del alumno con las unidades de asignación también es almacenada por el LMS. Desde la descripción AICC/CMI es posible hacer referencia a esta información para decidir qué datos se envían a las unidades de asignación en tiempo de ejecución. La secuenciación dentro del curso se controla mediante el uso de los prerequisitos que deben satisfacer los estudiantes antes de acceder a una nueva unidad de asignación. AICC/CMI utiliza el concepto de curso (course) como UOL. IMS Simple Sequencing (IMS-SS) de?ne métodos para poder representar el comportamiento dentro de una experiencia educativa, de manera que un LMS pueda secuenciar actividades discretas de forma consistente (IMS SS, 2003). Los diseñadores instruccionales o los desarrolladores de contenido declaran el orden relativo en el cuál se presentan al alumno los elementos de contenido, y las condiciones bajo las cuáles una pieza de contenido se selecciona, se muestra o se omite durante la presentación. Utiliza el concepto de actividad de aprendizaje (learning activity) como UOL. ADL Sharable Content Object Reference Model (SCORM) representa un modelo de coordinación que tiene el objetivo de proporcionar una colección de prácticas estandarizadas susceptibles de ser ampliamente aceptadas y ampliamente implementadas en entornos de e-learning (SCORM, 2004). De hecho, el modelo SCORM puede ser considerado como un “per?l de aplicación” (en inglés application profile) de estas prácticas ya que se apoya en otras especificaciones más generales como, por ejemplo, las proporcionadas por IMS, pero además concreta algunos aspectos que no están fijados en dichas especificaciones. La iniciativa SCORM pone en práctica diferentes desarrollos tecnológicos de las iniciativas propuestas por grupos como IMS, AICC, ARIADNE y IEEE-LTSC, todos ellos agrupados en un único modelo 20 de referencia para especi?car una implementación consistente que pueda ser utilizada por toda la comunidad de e-learning. SCORM de?ne los fundamentos técnicos de un LMS basado en tecnologías web, estableciendo: § Un Modelo de agregación de Contenidos que describe los componentes utilizados dentro de una experiencia educativa, cómo empaquetar estos componentes para su intercambio y cómo describir estos componentes mediante el uso de los metadatos para permitir su búsqueda y descubrimiento. Además también de?ne los requisitos para la construcción de agregaciones de contenidos (e.g. cursos, lecciones, módulos, etc.). Este modelo da lugar a un concepto de OA denominado Shareable Content Object (SCO). § Un Entorno de ejecución dinámico para la reproducción de los SCOs, proporcionando de esta forma, un modelo instruccional adaptativo basado en OAs. Normalmente dicho entorno de ejecución se servirá a los distintos clientes que acceden al sistema. § Un Mecanismo de interoperabilidad entre los SCOs que se ejecutan en el citado entorno y el resto de componentes que se ejecutan en el LMS, que habitualmente reside en el lado del servidor. De forma adicional, en SCORM 2004 (anteriormente conocido como SCORM 1.3) se ha introducido un Modelo de Secuenciación y Navegación para permitir la presentación dinámica de los contenidos educativos en función de las necesidades de aprendizaje. Está basado en la propuesta IMS Simple Sequencing (IMS-SS) y describe cómo se puede secuenciar el contenido compatible con el modelo SCORM utilizando una secuencia de eventos de navegación, donde estos eventos pueden ser iniciados por el estudiante o por el sistema. El control de las bifurcaciones y el ?ujo puede ser descrito utilizando un conjunto prede?nido de actividades que normalmente se deben fijar en el momento del diseño del curso. Además, también describe cómo los LMSs compatibles con SCORM tienen que interpretar estas reglas de secuenciación expresadas por el desarrollador de contenidos, acompañadas por el conjunto de eventos de navegación iniciados por el estudiante o por el sistema, y cuáles son sus efectos sobre el entorno en tiempo de ejecución. SCORM utiliza el concepto de “organización de contenido” (en inglés content organization) como UOL. <e-DocBook> es una metodología y un conjunto de herramientas ideadas para simpli?car el proceso de creación de materiales educativos adaptativos basados en el concepto de OAs (Martinez-Ortiz, 2005, 2006). Esta iniciativa utiliza una extensión de DocBook (Walsh, 1999), un lenguaje XML usado en entornos técnicos para la creación de manuales. La metodología propuesta por <e-DocBook> se basa en la metáfora de escritura de un manual, proceso al que habitualmente están acostumbrados los docentes (aunque para e-learning los contenidos deberían ser concebidos de forma diferente, en base a los conceptos que se quieren enseñar y su relación con los OAs, y no sólo como un libro que se publica en la red). A partir del manual generado y aplicando las herramientas proporcionadas por <e-DocBook> se pueden obtener distintos productos: un curso, módulos de curso basados en OAs, trasparencias para ser utilizadas como notas de clase, etc. 21 En ambos casos el resultado ?nal será agregado en un paquete IMS Content Packaging (IMS-CP) para poder simpli?car el intercambio de los contenidos entre sistemas de e-learning. Además, las herramientas proporcionadas permiten la generación de los contenidos en formatos HTML, PS, PDF, RTF, archivos de ayuda de Eclipse y ?nalmente archivos de ayuda de Windows. 1.4.3. Lenguajes de Actividades PALO es un lenguaje de modelado desarrollado en la Universidad Nacional de Enseñanza a Distancia (UNED) (Rodriguez-Artacho et al., 1999). PALO permite describir cursos organizados mediante módulos que contienen actividades educativas, contenido y un plan de enseñanza. Utilizando PALO el diseñador puede crear plantillas para de?nir tipos de escenarios de aprendizaje. Utilizando las características del lenguaje, es posible secuenciar tareas de aprendizaje y módulos. Como complemento, se pueden añadir restricciones sobre los cursos, permitiendo de?nir tiempos y fechas límite, así como dependencias entre módulos y tareas. Utiliza el concepto de módulo como UOL. Educational Environment Modeling Language (E2ML) es una propuesta de EML que proporciona un lenguaje visual con el objetivo de permitir diseñar entornos educativos en el ámbito universitario (Botturi, 2006). Dicho lenguaje permite crear una de?nición explícita del proceso de aprendizaje y de las actividades educativas. En particular aborda los siguientes aspectos: § Facilita la comunicación entre los diferentes interesados dentro del proceso (diseñadores de unidades de aprendizaje, personal técnico, profesores, etc). Para ello propone una representación visual del diseño, que se puede utilizar de manera similar a como se utilizan los planos de un edi?cio que va a construir. § El diseño de una UOL puede utilizarse como base de otra UOL, no sólo por parte del mismo diseñador, sino por toda la comunidad educativa. E2ML utiliza el concepto de curso (course) como UOL. XEDU está ideado para ofrecer a los diseñadores instruccionales un marco de trabajo para la especi?cación de cualquier aplicación educativa, tanto desde el punto de vista de las teorías instruccionales como desde el punto de vista de la ingeniería del software (Buendía et al., 2003, 2004). Los principales conceptos de?nidos en XEDU son: § Per?l de alumno. Almacena toda la información relevante acerca del estudiante, incluyendo el resultado del proceso de aprendizaje. § Escenario educativo. Consta de actividades y condiciones en un contexto educativo especí?co. § Estructura didáctica. Organiza el contenido educativo con un objetivo didáctico especí?co. 22 El concepto de estructura didáctica representa una UOL en XEDU. MISA introduce una nueva aproximación denominada “ingeniería instruccional” (en inglés Instructional Engineering) (Paquette, 2004). La ingeniería instruccional está basada en las teorías del Diseño Instruccional (en inglés Instructional Design) (Reigeluth, 1983; Merrill, 1994; Dick, 2000) junto a la ingeniería cognitiva y la ingeniería del software. Para ello proporciona una metodología que da soporte a la plani?cación, análisis, diseño y entrega de un sistema de aprendizaje y comparte los principios de los EMLs. MISA permite el diseño de sistemas de aprendizaje a través de 35 tareas, produciendo 35 entregables denominados elementos de documentación. La creación de estos documentos está dividida en fases bien de?nidas. El concepto de Escenario de aprendizaje representa una UOL en MISA. OUNL-EML ha sido desarrollado por la OUNL para su aplicación en e-learning. La versión 1.0 de dicho lenguaje y su modelo XML fue distribuida en el año 2000 (Koper, 2000, 2001). OUNL-EML fue seleccionado como base de la especi?cación IMS-LD, integrando OUNL-EML con la especi?cación IMS-CP e IMS-SS. OUNL-EML ha sido utilizado y puesto en práctica en diversas aplicaciones de e-learning, y, en particular, en la Universidad Complutense de Madrid en las primeras versiones del proyecto <eAula> (Sierra et al., 2006). OUNL-EML permite la de?nición de “diseños de aprendizaje” (diseños instructivos) con el objetivo de permitir la creación de herramientas avanzadas de e-learning, (e.g. herramientas que permitan la de?nición de un modelo educacional basado en competencias, en portafolio o en el aprendizaje colaborativo). En OUNL-EML el concepto de “diseño de aprendizaje” (learning design) representa el concepto de UOL. Un diseño de aprendizaje es una instancia concreta de un modelo pedagógico, el cual a su vez es una instancia de un meta-modelo pedagógico. Este meta-modelo no fuerza a los usuarios de OUNL-EML a utilizar un modelo pedagógico concreto, sino que les permite crear y describir sus propios modelos de manera expresiva. El meta-modelo ofrecido por OUNL-EML ha sido desarrollado a partir del análisis de los modelos existentes basados en las aproximaciones constructivistas (sociales), de comportamiento y cognitivas. <e-LD> es una iniciativa que trata de simplificar la autoría y reutilización de diseños educativos mediante la aplicación de conceptos de flujos de trabajo (en inglés workflows) (Martínez-Ortiz et al., 2008). La idea es proponer un lenguaje específico de dominio orientado a flujo (a secuenciamiento de actividades) que es más comprensible para los docentes. La compatibilidad con otros estándares como IMS-LD se obtiene mediante procesos de exportación automática. Además proporciona herramientas para ayudar a la compresión de diseños previamente creados con IMS-LD de los que únicamente se dispone de su representación en XML (permitiendo, por ejemplo, la visualización de dependencias entre tareas o entre tareas y condiciones). PoEML (Perspective-oriented EML) es un lenguaje basado en IMS-LD que se define a partir de la propuesta de separación de asuntos o aspectos (Caeiro et al., 2007). El lenguaje tiene una estructura modular con la que se pretende mejorar los problemas de capacidad expresiva, complejidad y usabilidad identificados en los EMLs actuales. Finalmente entre las diferentes propuestas de especi?caciones, IMS Learning Design ha emergido como el estándar de-facto para la representación de cualquier UOL ya que en principio permite utilizar cualquier teoría de aprendizaje. Debido a su 23 importancia tanto en el ámbito del e-learning como para este trabajo, se realiza una presentación breve de esta especificación en la siguiente sección (el siguiente capítulo está dedicado a realizar una presentación completa y con ejemplos de IMS-LD). 1.5. IMS LEARNING DESIGN IMS Learning Design está basado en el lenguaje OUNL-EML. Esta especi?cación ha sido elaborada por el grupo de trabajo IMS/LDWG enmarcado dentro de las iniciativas desarrolladas por el IMS Global Learning Consortium (IMS LD, 2003). El punto de partida de este grupo de trabajo fue la especi?cación OUNL-EML. El resultado ?nal ha sido el desarrollo de una nueva especi?cación adaptada en aquellas partes en las que existía un solapamiento con el resto de especi?caciones propuestas por IMS, junto a una adaptación de la propia especi?cación para poder dividirla en varios niveles, al estilo del modelo de capas en una arquitectura de software, para hacerla más comprensible. Una de las adaptaciones más relevantes llevada a cabo ha sido la adopción de la especi?cación IMS Content Packaging como formato y medio de transmisión e intercambio entre distintos LMSs y herramientas. Asimismo, otras partes de?nidas en OUNL-EML no han sido reutilizadas (por ejemplo, el formato XML para la descripción de los contenidos educativos, que era un dialecto del formato DocBook (Walsh y Muellner, 1999). Además de la adaptación al entorno de especi?caciones de IMS, otro objetivo ha sido la inclusión de otros trabajos y especi?caciones que no se solapaban con el trabajo realizado. Por ejemplo, IMS-SS ha sido incluido dentro del ámbito de trabajo de IMS Learning Design para llevar a cabo el secuenciamiento de los OAs dentro de las actividades que se llevan a cabo en el contexto de la UOL. Otro ejemplo ha sido IMS Question and Test Interoperability, de manera que los exámenes y preguntas presentadas con IMS QTI pueden utilizarse dentro de las actividades. De esta manera, la puntuación obtenida en estas pruebas puede provocar que aparezcan nuevas actividades o que desaparezcan otras. En la Figura 2.3.a puede observarse la estructura de alto nivel de una UOL expresada en IMS-LD. Además, para facilitar el aprendizaje y la implementación de la especi?cación, el modelo conceptual de IMS-LD (Figura 1.5.b) está dividido en tres niveles (A, B y C) donde cada nivel está construido encima del modelo y de la semántica de?nida en los niveles previos: § Nivel A. Contiene el núcleo de los componentes de la especi?cación. Cuando se crea una UOL con IMS-LD, se debe especi?car un modelo estático y un modelo dinámico. § Nivel B. Añade los conceptos de propiedades y condiciones al nivel anterior. Las propiedades de?nen un modelo de datos para el alumno y las condiciones se utilizan para personalizar las UOLs en base a los conocimientos previos de los alumnos y a su interacción con dichas UOLs. 24 § Nivel C. Añade el concepto de noti?cación al nivel anterior. Las noti?caciones proporcionan un nuevo mecanismo de noti?cación de sucesos que ocurren durante la ejecución de una UOL. Figura 1.5.a. Estructura de alto nivel de una unidad de aprendizaje en IMS-LD. El modelo estático de IMS-LD permite de?nir qué es lo que se va llevar a cabo en la UOL, qué tipos de usuarios (e.g. profesores, alumnos, etc.) participan en la UOL y con qué recursos se llevarán a cabo las actividades (e.g. páginas HTML, PDF, etc.). El modelo estático está compuesto por los siguientes conceptos: § Título. Permite dar un título para la UOL. § Objetivos educativos. De?nición de los objetivos educativos de la UOL. Esta descripción habitualmente se realiza en lenguaje natural. § Prerrequisitos. De?nición de los conocimientos previos que debe tener un alumno para que pueda llevar a cabo las actividades de la UOL. La descripción de los prerrequisitos también se realiza en lenguaje natural. § Metadatos. Esta meta-información permite la indexación de las UOLs, de manera que se simpli?que su posterior clasi?cación, catalogación y recuperación. § Roles. De?nición de los diferentes tipos de usuario que aparecerán en la UOL. § Actividades. De?nición de las actividades que se llevarán a cabo dentro de las UOLs. En la de?nición de las actividades se incluyen los objetivos y los prerrequisitos de las actividades. Además, también se incluye una descripción textual de cuáles son los objetivos de la actividad. Finalmente, se incluye una referencia al entorno donde se llevará a cabo la actividad. 25 § Entornos. De?nen los contenidos educativos (OAs) y las herramientas (servicios de aprendizaje) que se utilizarán en las distintas actividades de la UOL. Figura 1.5.b. Estructura conceptual de IMS-LD. El modelo dinámico de IMS Learning Design permitir de?nir el quién y el cúando. El modelo dinámico hace uso de los conceptos de?nidos en el modelo estático anteriormente descrito. El modelo dinámico permite de?nir qué tipo de usuario (rol) llevará a cabo una actividad concreta y también permite de?nir la sincronización y las dependencias que existirán entre las distintas actividades que componen la UOL. El modelo dinámico puede verse como la esceni?cación de una obra teatral. El método (method) consiste en una o varias representaciones (play) que son interpretadas en paralelo. Cada una de las obras está formada por uno o más actos (acts) que serán interpretados uno tras otro (ver Figura 1.5.c). Dentro de cada acto se realiza la distribución de papeles (role-parts), es decir, se de?ne qué actividades serán llevadas a cabo por cada uno de los tipos de usuario involucrados en el proceso de aprendizaje (ver Figura 1.5.c). Utilizando los niveles B y C podemos crear secuenciaciones dinámicas más complejas. En particular podemos incluir dependencias entre actividades (por ejemplo, para indicar que un profesor debe desempeñar una actividad en la que corrija un examen después de que el alumno lo termina). 26 Figura 1.5.c. Representación de un método con tres actos secuenciales (a) y representación de un método en el que se incluyen los roles de los usuarios en las actividades y se muestra que puede haber actividades en paralelo (b). 1.6. HERRAMIENTAS DE SOPORTE A IMS-LD Aunque la aplicación práctica de IMS-LD sigue siendo muy limitada sí existen diversas iniciativas que proporcionan herramientas para trabajar con IMS-LD. En esta sección se realiza una breve presentación de algunas de las iniciativas que debido a su relevancia o madurez se han considerado como más prometedoras actualmente. Podemos encontrar tres tipos de herramientas: § Herramientas de Autoría. Son herramientas que permiten la creación de las UOLs. § Motores de Ejecución. Son herramientas que, dada una UOL codi?cada con IMS-LD, interpretan el proceso de aprendizaje, monitorizando la realización de las actividades y actualizando el per?l del alumno según los resultados que se vayan obteniendo en las actividades que tienen asignadas. Este tipo de herramientas residen habitualmente en un servidor de aplicaciones y son utilizadas tanto por los profesores como por los alumnos a través de una interfaz web adecuada. § Reproductores. Estas herramientas son utilizadas por los actores que interactúan con la UOL, tanto en el proceso de ejecución de la misma, como 27 durante el proceso de publicación de la UOL (es decir, el proceso de preparación de la misma para su puesta en ejecución). De esta forma, estas herramientas proporcionan la citada interfaz web con los motores de ejecución. 1.6.1. Herramientas de Autoría de IMS-LD En esta sección se hace un breve análisis de distintas iniciativas de desarrollo de herramientas de autoría compatibles con la especi?cación IMS-LD. Esta sección no pretende realizar un análisis exhaustivo de todas las iniciativas existentes (para mayor detalle se puede consultar Berggreen et al., 2005; Burgos y Griffiths, 2005; Dodero et al., 2006; Berlanga y García, 2005) sino de las que en el momento de escritura del documento hemos considerado más relevantes, como son ALFANET, CopperAuthor, RELOAD, CoS-MoS, Collage, MOT+, ASK-LDT y LAMS. ALFANET (Active Learning for Adaptive Internet) es una iniciativa europea que tiene como objetivo el desarrollo de nuevos métodos y servicios para llevar a cabo un proceso de aprendizaje activo y adaptado al alumno (http://alfanet.ia.uned.es). El editor de IMS-LD de ALFANET representa los conceptos de IMS-LD mediante elementos gráficos que conforman la interfaz. Esta herramienta sólo permite la creación y el desarrollo de diseños educativos IMS-LD de nivel A (este proyecto ya está concluido y no parece claro que se haya seguido con este desarrollo). CopperAuthor (Figura 1.6.1.a) es una herramienta desarrollada en paralelo al motor de ejecución CopperCore. Esta herramienta permite a los diseñadores construir y navegar sobre la estructura del diseño educativo mediante una interfaz basada en tablas (CopperAuthor, 2007). En su versión actual la interfaz es un tanto primitiva y sólo permite el desarrollo de diseños educativos IMS-LD de nivel A. 28 Figura 1.6.1.a. Interfaz de CopperAuthor. 29 RELOAD (Reusable E-Learning Object Authoring & Delivery) (Figura 1.6.1.b) es un editor desarrollado en el seno de un proyecto patrocinado por la iniciativa JISC del Reino Unido (http://www.reload.ac.uk). Este editor permite la edición de una UOL mediante la interacción con múltiples formularios y estructuras en forma de árbol que representan la estructura de agregación de los conceptos de IMS-LD implícita en el formato XML utilizado para representar las UOL de IMS-LD. Con esta herramienta se pueden crear diseños educativos IMS-LD de los tres niveles (del nivel A al nivel C). Figura 1.6.1.b. Interfaz del editor de IMS-LD de RELOAD. 30 CoSMoS (Collaboration Script Modelling System) (Figura 1.6.1.c) es una herramienta de autoría ideada inicialmente para dar soporte a la formalización de procesos de aprendizaje colaborativos (Miao, 2005). Posteriormente la herramienta fue modi?cada para dar soporte a los conceptos de IMS-LD. La edición de la UOL se basa en la navegación sobre la estructura en árbol de la misma y la edición de los conceptos mediante formularios. Con esta herramienta se pueden crear diseños educativos IMSLD de nivel B. Figura 1.6.1.c. Interfaz del editor de IMS-LD de CoSMoS. Collage es una herramienta de autoría de alto nivel y de autoría colaborativa basada en el concepto de los patrones de ?ujo colaborativos (Collaborative Learning Flow Patterns), que son plantillas que de?nen el ?ujo de tareas para dirigir de manera adecuada el proceso de aprendizaje (Hernandez-Leo et al., 2006). Esta herramienta ha sido desarrollada sobre RELOAD y con ella sólo se pueden crear diseños educativos IMS-LD de nivel A. MOT+ es una herramienta desarrollada en el centro de investigación LICEF de Canadá, con el objetivo inicial de estructurar mapas conceptuales para la representación de conocimiento en diversos dominios (Paquette et al., 2005). MOT+ utiliza una notación grá?ca para representar las entidades de conocimiento con las que trabaja la herramienta. MOT+ fue extendida para soportar la edición de IMS-LD, de manera que la herramienta permite representar y editar los conceptos que están 31 de?nidos en IMS-LD. Con esta herramienta se pueden crear diseños educativos IMSLD de nivel A y se están realizando trabajos para soportar los niveles B y C. ASK-LDT (Advanced e-Services for the Knowledge Society Research Unit) (Figura 1.6.1.d) es una herramienta que proporciona una notación grá?ca para los conceptos de IMS-LD (Karampiperis y Sampson, 2004). ASK-LDT de?ne una notación grá?ca para un conjunto de tipos de actividades prede?nidas como, por ejemplo, lecciones, discusiones, exámenes, etc. Además, también proporciona una notación grá?ca para poder de?nir el ?ujo entre dichas actividades. Con esta herramienta podemos crear diseños educativos IMS-LD de nivel A y parcialmente de nivel B. Figura 1.6.1.d. Interfaz del editor de ASK-LDT. Finalmente, Learning Activity Management system (LAMS) es una herramienta que permite el diseño, gestión y distribución de actividades colaborativas para e-learning (Dalziel, 2003, 2005). LAMS proporciona una herramienta de autoría visual muy intuitiva (Figura 1.6.1.e) que permite crear las secuencias de actividades de aprendizaje. En los cursos de LAMS se pueden encontrar diferentes actividades: individuales, para pequeños grupos de usuarios o para clases completas. Estas actividades pueden incluir el trabajo con contenidos educativos o tareas de trabajo colaborativo. 32 Figura 1.6.1.e. Interfaz del editor de LAMS. 1.6.2. Motores de ejecución compatibles con IMS-LD Quizá el motor IMS-LD más popular sea CooperCore. CopperCore es un motor de ejecución de UOLs formalizadas con IMS-LD desarrollado por la OUNL. Como características principales de CopperCore podemos destacar: § Es un proyecto de software libre. § Soporta la ejecución de UOLs hasta el nivel C de IMS-LD. § CopperCore está desarrollado sobre la plataforma Java EE, y su puesta en funcionamiento es relativamente simple. § CopperCore proporciona una Interfaz de Programación de Aplicaciones (API) que permite extender sus funcionalidades, así como controlar el motor de ejecución desde otra herramienta. § Proporciona una capa de abstracción, CopperCore Service Integration (CCSI), que permite integrar de forma sencilla diversos servicios de aprendizaje, como, por ejemplo, herramientas compatibles con IMS-QTI. 33 1.6.3. Reproductores de IMS-LD CopperCore Player (Figura 1.6.3.a) es una aplicación web simple que permite interactuar con el motor de ejecución CopperCore. Esta herramienta fue creada como herramienta simple para realizar las pruebas necesarios durante el desarrollo del motor CopperCore. Figura 1.6.3.a. Reproductor CopperCore. SLeD Player (Figura 1.6.3.b) es un nuevo cliente web para el motor de ejecución CopperCore (McAndrew et al., 2004; Weller et al., 2006). Las principales características de SLeD Player son: 1. Proporciona una interfaz web para la gestión de usuarios y de las ejecuciones de las UOLs. 2. Permite la personalización del diseño y de la distribución de la interfaz de reproducción de la UOL mediante el uso de tecnologías XML. 3. Proporciona implementaciones para los servicios de búsqueda y foro que pueden ser referenciados dentro de los entornos de una UOL codi?cada con IMS-LD. 4. Proporciona soporte a la capa de abstracción CCSI. Como ejemplo de uso de CCSI, SLeD integra los servicios de foro y de búsqueda. 34 Figura 1.6.3.b. Reproductor SLeD. RELOAD Player (Figura 1.6.3.c) ha sido desarrollado por Paul Sharples y Phillip Beauvoir en la Universidad de Bolton. RELOAD Player ha sido construidO sobre la plataforma Eclipse y hace uso de CopperCore como motor de ejecución de IMSLD. Esta herramienta proporciona una interfaz simple para la publicación de UOLs compatibles con IMS-LD y la creación de usuarios de prueba que pueden ser utilizados para probar las UOLs. RELOAD Player está pensada principalmente para probar de manera simple las UOLs que se están diseñando con el correspondiente editor. 35 Figura 1.6.3.c. Reproductor de IMS-LD de RELOAD. Otro entorno de ejecución es GRAIL (Gradient-lab RTE for Adaptive IMS-LD in .LRN) desarrollado en la Universidad Carlos III de Madrid que permite la ejecución de UOL en el LMS de código libre .LRN (Escobedo del Cid et al., 2007). GRAIL ejecuta OULs de los tres niveles que permite la especificación y es una de las pocas herramientas disponibles que se integra completamente en un LMS ampliamente difundido y utilizado. 1.6.4. Otras iniciativas y proyectos de investigación relacionados con IMS-LD Como este campo del modelado educativo no está suficientemente maduro para su aplicación industrial y generalizada, una forma de mantenerse al corriente de los avances es considerar los proyectos de investigación relacionados. Aunque los proyectos que tratan, al menos en parte, estos aspectos son muy numerosos nos quedaremos con algunos que por su volumen y número de socios implicados son susceptibles de tener un cierto impacto, bien en la evolución de las especificaciones o bien en el desarrollo de herramientas. Hay dos proyectos europeos del sexto programa marco que están relacionados con IMS-LD y que tienen como objetivos avanzar en el uso de dicha especificación y, hasta cierto punto, producir herramientas que simplifiquen su aplicación. Uno de ellos es Prolix (http://www.prolixproject.org/) donde se ha creado una herramienta de autoría denominada Prolix LD authoring tool que traduce un diseño de alto nivel a dicha especificación (aunque en el momento de escribir este documento no está 36 públicamente disponible y no existen muchos detalles al respecto). Otro proyecto europeo muy relacionado con el modelado educativo y las competencias es TENCompetence (http://www.tencompetence.org), donde el mismo equipo que ha participado en el desarrollo de RELOAD, está desarrollando un editor más amigable para IMS-LD denominado ReCourse (Figura 1.6.4.a). No obstante a fecha de redacción de este informe todavía no tenían ningún software públicamente disponible mas allá de capturas de pantalla como la presentada. Figura 1.6.4.a. Editor de ReCourse. Otro punto de referencia en la red relativo a estándares educativos es el observatorio de estándares de tecnologías educativas (CEN/ISSS Learning Technology Standards Observatory) mantenido en la Universidad de Vigo (http://www.cen-ltso.net) que a partir del verano de 2008 ha sido incluido en la red europea de buenas prácticas ASPECT que busca mejorar la adopción de especificaciones y estándares de elearning. El sitio web del JISC en el Reino Unido (http://www.jisc.ac.uk/) mantiene mucha información actualizada de los usos educativos de las tecnologías y financia, por ejemplo, el proyecto LD4P (Learning Design for Practicioners) sobre la aplicación práctica de IMS-LD (http://bsd1.phosphorix.co.uk/ld4p/index.php) dentro de su iniciativa más general sobre diseño educativo (http://www.jisc.ac.uk/elp_desinglearn.html). El proyecto canadiense IDLD (www.idld.org) está dedicado a la diseminación del diseño educativo y al uso de IMS-LD proporcionando acceso a información metodológica sobre cómo aplicar dicho modelado y a un almacén (repositorio) de diseños educativos. 37 Otro sitio web donde se puede encontrar mucha información relacionada con elearning y el modelado educativo, tanto en sus aspectos más técnicos como en sus aspectos más educativos, es la Edutech wiki mantenida en la Universidad de Ginebra (http://edutechwiki.unige.ch/en/Main_Page). 1.7. A MODO DE CONCLUSIÓN Los EMLs permiten a profesores y educadores el diseño, la formalización y el intercambio de cursos basados en el concepto general de unidad de aprendizaje. Estas unidades de aprendizaje, debidamente formalizadas y descritas mediante metadatos (e.g. IEEE LOM) pueden realmacenarse en una base de datos (también llamada repositorio) para su reutilización posterior, tanto para repetir el proceso de aprendizaje, como para la creación de unidades de aprendizaje nuevas tomando ésas como punto de partida. Además, los EMLs tienen también otro uso y es que sirven como medio de comunicación entre el personal técnico y el personal docente. El personal docente es responsable de la descripción de las experiencias educativas mientras que el personal técnico es responsable de la creación de intérpretes que permitan ejecutar automáticamente las UOLs creadas y su integración dentro del LMS que se utilice. Al integrar el intérprete del EML dentro del LMS estamos proporcionando al personal docente la posibilidad de adaptar y personalizar el propio LMS, teniendo en cuenta sus necesidades educativas especí?cas, y sin demandar de ellos conocimientos de programación profundos (aunque, a día de hoy, sí exige tener mucho conocimiento del propio estándar IMS-LD debido a la ausencia de herramientas de autoría sencillas y maduras para usuarios finales). La especi?cación IMS-LD se ha convertido en el estándar de facto como medio de incorporación en las herramientas de gestión de e-learning de aspectos más avanzados de metodologías educativas, lo que permite que los LMS transciendan la concepción simplista de ser meros artefactos de distribución de contenidos educativos. Sin embargo, IMS-LD está en un punto medio entre un modelo puramente educacional y un modelo puramente tecnológico. En nuestra opinión, para poder aplicar esta especi?cación de manera efectiva necesitamos movernos simultáneamente hacia ambos extremos. Efectivamente: Desde el punto de vista educativo, se necesita diseñar y documentar el proceso de enseñanza de manera cuidadosa, con el objetivo de que el diseño pueda ser analizado y/o reutilizado por otros docentes y que, ?nalmente, este diseño pueda ponerse en práctica (ejecutarse) automáticamente en un LMS. Por tanto es necesario elevar el nivel de abstracción proporcionado por las herramientas de autoría de UOL para que los docentes no tengan que conocer todos los detalles y complejidades del modelo subyacente impuesto por IMS-LD. Desde el punto de vista tecnológico, es necesario formalizar todos los detalles relativos a la ejecución de la UOL diseñada, por ejemplo, cuando se interpreta en un LMS. La especi?cación IMS-LD deja claramente fuera de su alcance los detalles especí?cos de ejecución de una UOL de modo que sería necesario un perfil de 38 aplicación ampliamente aceptado que fijara dichos detalles y simplificara el desarrollo de entornos de ejecución (del mismo modo que SCORM ha fijado detalles no incluidos en las especificaciones IMS en las que se basa para simplificar su implementación en sistemas comerciales). 2. LA ESPECIFICACIÓN IMS LEARNING DESIGN 2.1. INTRODUCCIÓN Disponer de contenidos digitales de calidad y de servicios informáticos de alta tecnología (por ejemplo, sofisticados programas de comunicación) no es suficiente, por sí mismo, para dar lugar a aplicaciones e-learning totalmente funcionales. Además se necesita indicar la forma en la que los distintos participantes en el proceso de aprendizaje deben utilizar dichos recursos a fin de lograr los objetivos educativos perseguidos. Dicho de otra forma, es necesario diseñar las distintas pedagogías en las que se basan las citadas aplicaciones. La especificación IMS Learning Design (IMS LD) surge, precisamente, como un mecanismo básico que permite describir dichas pedagogías. IMS LD proporciona un lenguaje de dominio específico que permite diseñar las experiencias educativas a las que se expondrán a los usuarios de las aplicaciones de e-learning. Aún siendo un lenguaje informático artificial, el lenguaje de IMS Learning Design contiene primitivas y conceptos que pueden ser fácilmente entendidos por los educadores. De esta forma, su uso no demanda conocimientos muy avanzados de informática, programación o desarrollo de aplicaciones web. Por el contrario, con un poco de entrenamiento y con un mínimo de herramientas de soporte (por ejemplo, editores específicos para IMS LD), un educador motivado podrá utilizar el lenguaje para plasmar sus diseños educativos. Estos diseños servirán como base para la generación automática de las aplicaciones finales utilizando herramientas informáticas adecuadas (por ejemplo, reproductores de IMS LD). De esta forma, el principal potencial de IMS LD es permitir que sean los propios educadores, que son los que realmente entienden las necesidades y objetivos finales de las aplicaciones educativas, los que realmente lideren el desarrollo y mantenimiento de dichas aplicaciones. En este capítulo se analiza con detalle la especificación IMS LD. Para ello, se comienza planteando un caso de estudio sencillo que será utilizado a lo largo del mismo para ilustrar los distintos aspectos introducidos. Seguidamente se presentan los principales conceptos y estructuras subyacentes a la especificación. Para finalizar, se muestra cómo dichos conceptos y estructuras se describen en XML. 2.2. UN CASO DE ESTUDIO El Profesor Corbinus, primo segundo del conocido Profesor Eméritus (FernandezManjón et al., 2007) dicta clases de Enología Aplicada en la prestigiosa Escuela de Estudios y Prospecciones Vinícolas (EEPV), en Villanueva del Tintorro. Corbinus imparte un seminario de Iniciación a la Cata que, con los años, ha adquirido bastante 39 prestigio entre la comunidad de la EEPV. Parte de este éxito se debe a las grandes dotes que Corbinus, siempre preocupado por las mejoras de sus procesos pedagógicos, posee como docente. Este año, Corbinus, que ha seguido un curso intensivo de verano en e-learning, se ha planteado introducir en su seminario diversas mejoras con ayuda de las tecnologías de la Información y las Comunicaciones (TICs). Consciente como es de que el éxito último de la aplicación satisfactoria de estas tecnologías radica en basar las aplicaciones en diseños pedagógicos bien fundados, Corbinus baraja los siguientes escenarios educativos para la articulación de su seminario: § Escenario 1. Un proceso de enseñanza tradicional, que incluye algunas actividades soportadas por las TICs. Inicialmente Corbinus impartirá una serie de clases presenciales. A continuación pondrá a disposición de los alumnos distinto material complementario sobre el Arte de la Cata. Este material incluye: (i) un vídeo de 10 minutos de duración en el que el insigne Profesor Bacus (de la Universidad de Uva Dulce) analiza la importancia del retrogusto en la evaluación de los matices del vino de Rueda, variedad Verdejo; (ii) un artículo escrito por el conocido experto italiano Giorgio Birra, en el que se realiza un estudio comparativo entre las tonalidades de los caldos de la Baja Toscana y (iii) un estudio llevado a cabo por la Profesora Yoyo Bebo sobre el efecto de los sulfitos en el regusto y en el postgusto del vino de mesa común. De la misma manera, Corbinus también quiere recomendar a sus alumnos la visita del sitio www.lacatadelvinotinto.org. Por último, Corbinus quiere fomentar también el aprendizaje colaborativo mediante la organización de un debate on-line en el que, aparte de los alumnos matriculados en el seminario, participarán también alumnos de anteriores promociones. Una vez finalizadas todas estas actividades, los alumnos deben preparar un trabajo escrito, que Corbinus evaluará a fin de decidir las notas finales de los mismos. § Escenario 2. Introducción de mecanismos de adaptación del proceso a las necesidades particulares de los alumnos. Este escenario se basa en el anterior. No obstante, antes de iniciar las actividades complementarias, Corbinus somete a sus alumnos a un examen tipo test. En función de los resultados obtenidos en este examen y como paso previo al inicio de las actividades complementarias, Corbinus puede decidir recomendar a los alumnos repasar el material básico contenido en su libro Introducción a la Esencia de la Cata (Corbinus tiene una versión electrónica en formato PDF de este libro que, a pesar de su carácter autoeditado, ha llegado a ganar un merecido renombre entre los miembros especializados de la comunidad vinícola). Asimismo, Corbinus también desea introducir una fase de recuperación para aquellos alumnos cuyo trabajo no haya superado ciertos umbrales mínimos de calidad. Esta fase consiste en el repaso del libro Introducción a la Esencia de la Cata, del artículo de Birra y del material contenido en el sitio www.lacatadelvinotinto.org. Seguidamente el alumno deberá revisar y mejorar su trabajo, trabajo que de nuevo será evaluado por Corbinus. § Escenario 3. En este escenario Corbinus desea mejorar el proceso de entrega de trabajos, permitiendo que se le notifique cada entrega, a fin de facilitar el solapamiento del período de corrección con el período de 40 redacción de trabajos para aquellos trabajos que se hayan entregado antes de la expiración de la fecha de entrega. 2.3. VISIÓN CONCEPTUAL DE IMS LD La especificación IMS LD permite diseñar las pedagogías de componentes educativos denominados “unidades de aprendizaje”. Una unidad de aprendizaje es un concepto abstracto con el que se denota cualquier pieza utilizada con un propósito educativo o de entrenamiento como, por ejemplo, un curso, un módulo, una lección, etc. Es importante notar que, desde el punto de vista de IMS LD, una unidad de aprendizaje no es una mera organización de recursos de soporte al aprendizaje (v.g. contenidos educativos tales como textos, diagramas, ejercicios, enunciados de prácticas o servicios informáticos y telemáticos tales como e-mail, foros, chats, etc.), sino que también integra las actividades necesarias que los distintos participantes en el proceso deben llevar a cabo con ayuda de dichos recursos a fin de lograr una experiencia educativa satisfactoria (v.g. realización de prácticas, resolución de ejercicios, realización y corrección de exámenes, exposiciones y debates, etc.). Los recursos, las actividades y los participantes concretos dependen de cada unidad de aprendizaje particular. De hecho, la identificación y la adecuada orquestación de estos componentes constituyen el núcleo fundamental de todo diseño educativo. En el caso de estudio cada uno de los escenarios planteados dará lugar a una unidad de aprendizaje, integrando distintos recursos, participantes y actividades. 41 Figura 2.3.a. Recursos, participantes y actividades en las unidades de aprendizaje derivadas del caso de estudio. (c) UACata3 (b) UACata2 (a) UACata1 Repaso Sitio Web Evaluación Test ACTIVIDADES Lectura Articulo Birra Impartición Clase Presencial Visionado Video Lectura Articulo Bebo Examen Sitio Web Evaluación Trabajo Realización Trabajo Repaso Libro Corbinus Realización Test Lectura Libro Corbinus Debate Repaso Artículo Birra Revisión y Mejora del Trabajo Consulta Resultados Consulta Resultados Repesca Re-evaluación Trabajo PARTICIPANTES Profesor Alumnos Antiguos Alumnos test.zip birra.pdf bebo.pdf www. lacatadelvinotinto. Servidor org Archivos Tablón RECURSOS bacus.avi Chat libroCorbinus.pdf Efectivamente: § En el escenario 1 surge una unidad de aprendizaje (UACata1) caracterizada por los siguientes componentes − Figura 2.3.a (a): - Recursos: Los recursos incluyen todos los contenidos digitales utilizados por Corbinus en la articulación de las actividades complementarias: el vídeo con la charla del Prof. Bacus, el artículo de Giorgio Birra (v.g. contenido en un archivo PDF), el estudio de la Profª. Bebo (otro PDF) e incluso la propia web www.lacatadelvinotinto.org. Del mismo modo, también es necesario incluir recursos adicionales en forma de herramientas telemáticas de soporte al proceso: un chat que permita articular el debate entre los alumnos de nueva promoción y los alumnos de promociones anteriores, un servidor de archivos en el que los alumnos puedan depositar sus trabajos para que estos puedan ser 42 corregidos por Corbinus y un tablón de notas en el que Corbinus publicará los resultados. § § - Participantes: El propio Corbinus, los alumnos de nueva promoción y los alumnos de promociones anteriores. - Actividades: Impartición de la clase presencial, Visionado del vídeo de Bacus, Lectura del artículo de Birra, Lectura del artículo de Bebo, Examen del sitio web, Debate, Realización del Trabajo, Evaluación del Trabajo y Consulta Resultados. En el escenario 2 la unidad de aprendizaje anterior se extiende con nuevos recursos y actividades, para dar lugar a la Unidad de Aprendizaje UACata2 − Figura 2.3.a (b): - Recursos: Todos los de UACata1. Se incluye además el test previo a las actividades complementarias (codificado en la especificación de representación de exámenes IMS QTI: ver IMS QTI, 2006), así como el libro de Corbinus (un PDF). - Participantes: Los mismos que en UACata1. - Actividades: Todas las de UACata1. Además se añaden las siguientes: Realización de Test, Evaluación de Test, Lectura del libro de Corbinus, Repaso del libro de Corbinus, Repaso del Artículo de Birra, Repaso del material del sitio web, Revisión y Mejora del Trabajo, Revaluación del Trabajo y Consulta Resultados Repesca. Los componentes de la unidad de aprendizaje que surge en el escenario 3 (UACata3) son los mismos que los de la unidad de aprendizaje UACata2 − Figura 2.3.a (c). Es importante notar que la especificación de los componentes no es suficiente para caracterizar completamente una Unidad de Aprendizaje. Efectivamente, también es preciso especificar la forma en la que dichos componentes interactúan entre sí durante el proceso educativo. O, lo que es lo mismo, diseñar el método pedagógico seguido en cada unidad de aprendizaje. En el caso de estudio, el método seguido en cada unidad de aprendizaje queda capturado a grosso modo en las narraciones de cada uno de los escenarios y supone, en gran medida, decidir qué participantes llevan a cabo qué actividades, así como el orden de realización de dichas actividades: § Método seguido en la unidad UACata1 − Figura 2.3.b (a): Corbinus lleva a cabo la Impartición de la Clase Presencial. Una vez finalizada dicha clase, los alumnos deben llevar a cabo el Visionado del vídeo de Bacus, la Lectura del artículo de Birra y la Lectura del artículo de Bebo (el orden es indiferente). Seguidamente los alumnos deben realizar el Examen del sitio web. A continuación, los alumnos participan junto con los de las promociones anteriores en el Debate (aquí Corbinus puede jugar el papel de moderador). Una vez finalizado el debate, los alumnos proceden a la Realización del Trabajo. Pasada la fecha de entrega, Corbinus lleva a cabo la Evaluación del Trabajo. Finalizada esta evaluación, los alumnos pueden consultar los resultados. 43 § Método seguido en la unidad UACata2 − Figura 2.3.b (b): Lo mismo que en la unidad UACata1, Corbinus lleva a cabo la Impartición de la Clase Presencial. Una vez finalizada dicha clase, los alumnos llevan a cabo la Realización del Test y Corbinus la Evaluación del Test. Si la nota obtenida en el test es menor que 5, el alumno debe llevar a cabo la Lectura del libro de Corbinus antes de pasar a realizar el resto de actividades (visionado del vídeo, lectura de artículo e informe, etc). Si no, puede pasar a realizar directamente dichas actividades. Asimismo, una vez corregido el trabajo, si la nota obtenida en el mismo es menor que 5, el alumno debe llevar a cabo el Repaso del libro de Corbinus, el Repaso del Artículo de Birra, el Repaso del material del sitio web así como la Revisión y Mejora del Trabajo. Por su parte, Corbinus deberá llevar a cabo la Revaluación del Trabajo. Finalizada la revaluación, los alumnos pueden consultar los resultados. § Método seguido en la unidad UACata3 − Figura 2.3.b (c): Idéntico al seguido en la unidad UACata2, salvo que ahora, cuando el alumno finaliza el trabajo notifica este hecho a Corbinus, lo que evita que éste tenga que estar mirando de vez en cuando el espacio de archivos compartidos. 44 Figura 2.3.b. Métodos pedagógicos asociados con las unidades derivadas del caso de estudio. (a) Lectura Articulo Birra Impartición Clase Presencial Visionado Video Profesor Alumno Todos los alumnos Todos los alumnos antiguos Lectura Articulo Bebo Examen Sitio Web Debate Realización Trabajo Consulta resultados Evaluación Trabajo Nota < 5 (b) Realización Test Impartición Clase Presencial Evaluación Test Lectura Libro Corbinus Consulta resultados Nota ≥5 Lectura Articulo Birra Visionado Video Examen Sitio Web Debate Realización Trabajo Evaluación Trabajo Lectura Articulo Bebo Nota < 5 Re-evaluación Trabajo Revisión y Mejora del Trabajo Consulta Resultados Repesca (c) Realización Trabajo Revisión y Mejora del Trabajo 45 Repaso Libro Corbinus Repaso Sitio Web Repaso Artículo Birra IMS LD permite formalizar de manera rigurosa la estructura y el método pedagógico de las unidades de aprendizaje, de manera que el diseño educativo resultante pueda ser interpretado por un programa informático apropiado (un reproductor de IMS LD), haciendo posible, por tanto, la automatización del proceso educativo. Las siguientes secciones proporcionan más detalle sobre dicho proceso de formalización. 2.4. EMPAQUETADO Y ORGANIZACIÓN EN NIVELES Desde un punto de vista técnico, las unidades de aprendizaje pueden representarse como paquetes IMS, siguiendo la especificación IMS Content Packaging (IMS CP). Esta especificación se organiza en niveles de complejidad creciente, cada uno de los cuáles permite expresar diseños educativos más sofisticados. A continuación se analizan estos aspectos de empaquetado y de organización en niveles. 2.4.1. IMS Content Packaging e IMS LD Tal y como se detalla en (Fernández-Manjón et al., 2007), la especificación IMS CP dicta la forma de encapsular contenidos educativos interrelacionados en piezas de información denominadas “paquetes”. En la Figura 2.4.1.a (a) se muestra la estructura de alto nivel de un paquete IMS. 46 Figura 2.4.1.a. En la parte (a) se muestra el esquema de la estructura de un paquete IMS;En la parte (b) se muestra una unidad de aprendizaje representada como un paquete IMS: es un paquete en el que la organización está descrita de acuerdo con la especificación IMS LD. (a) (b) Organizaciones Subpaquetes Recursos Archivos internos Archivos externos 47 Diseño educativo expresado en IMS LD Figura 2.4.1.b. Esbozo del paquete IMS asociado con la unidad UACata1. Diseño educativo descrito en IMS LD rbacus bacus.avi rbirra rweb rbebo birra.pdf bebo.pdf www.lacatadelvinotintotinto.org Otros archivos Otros archivos externos Tal y como se esquematiza en la Figura: § El paquete puede involucrar archivos internos y archivos externos. Los archivos internos son archivos digitales que forman parte del paquete y pueden estar físicamente organizados en carpetas. En el caso de estudio, el vídeo, los artículos, el libro, el examen tipo test son todos ellos archivos internos. Los archivos externos, por su parte, son elementos que no forman parte del paquete pero que se refieren desde el mismo utilizando una URL (una dirección estándar de Internet). En el caso de estudio, el sitio web puede considerarse un archivo externo. § Los archivos internos pueden agruparse en recursos internos. En dichas agrupaciones siempre se distingue un “archivo primario”. El resto de los archivos son “archivos secundarios”. En el caso de estudio los recursos se corresponden directamente con archivos. No obstante, existen otros casos en los que es conveniente agrupar varios archivos interrelacionados en un único recurso. Un ejemplo típico es el de una página HTML. Dicha página constará, por una parte, de un archivo HTML pero también de todos aquellos elementos referidos desde la página (v.g. imágenes). En este caso, el recurso en sí es toda una colección de archivos: el archivo HTML (que será el archivo primario) y los archivos asociados con todos los elementos referidos desde el mismo (que serán los archivos secundarios). A modo de ejemplo, si Corbinus hubiera ofertado su libro en formato HTML, probablemente tendría que haber considerado una colección de archivos en 48 el recurso asociado con dicho libro (el texto HTML en sí y todos los elementos multimedia referidos desde el mismo). § Los archivos externos están asociados con recursos externos. En el caso de estudio, el sitio web dará lugar a un recurso externo. § Los recursos pueden, a su vez, organizarse siguiendo un determinado convenio a efectos de su presentación, dando lugar a distintas organizaciones. § Por último, el paquete puede incluir, además, otros subpaquetes con la misma estructura descrita. La conexión entre IMS CP e IMS LD se lleva a cabo a través de las organizaciones. Efectivamente, IMS LD permite sustituir el formalismo descriptivo de organizaciones básico introducido por IMS CP (que, a grandes rasgos, se reduce a organizar jerárquicamente los contenidos) con un formalismo de diseño pedagógico mucho más rico y sofisticado. De hecho, desde el punto de vista de IMS LD, un paquete IMS puede considerarse como una unidad de aprendizaje si y sólo si incluye una descripción en IMS LD en la parte de organizaciones del paquete − Figura 2.4.1.a (b). A modo de ejemplo, en la Figura 2.4.1.b se esboza el encapsulado de la unidad UACata1 como un paquete IMS. Para mayor detalle sobre la especificación IMS CP puede consultarse (IMS CP, 2004). 2.4.2. Niveles en la Especificación La especificación IMS LD se estructura en tres niveles de complejidad creciente. Cada nivel se construye sobre el anterior, añadiendo al mismo nuevas características que pueden utilizarse para expresar diseños educativos más sofisticados. En concreto: § El nivel A de la especificación introduce los principales elementos estructurales (recursos y servicios, participantes -roles-, actividades, etc.) y dinámicos (aquellos correspondientes al método pedagógico) de IMS LD. No obstante, este nivel no permite describir métodos pedagógicos cuyo comportamiento varía dependiendo de la propia ejecución de dichos métodos. Efectivamente, los métodos pedagógicos que pueden ser descritos a nivel A se ejecutarán siempre de la misma manera. Esto permite, por ejemplo, modelar el diseño educativo que surge en el escenario A del caso de estudio (unidad UACata1), pero no así los que surgen en los escenarios B y C (en los cuáles la ejecución depende de resultados dinámicos tales como la puntuación obtenida por los participantes en el examen y en el trabajo). § El nivel B de la especificación introduce un mecanismo sencillo que permite representar el estado de la ejecución del método pedagógico: las propiedades. Los valores de las propiedades pueden modificarse durante la reproducción de la unidad de aprendizaje. Del mismo modo, el nivel B permite expresar condiciones sobre los valores de las propiedades, condiciones cuya verdad o falsedad puede provocar la visibilidad o invisibilidad de nuevas actividades y, por tanto, la adaptación del flujo de aprendizaje a las necesidades de cada participante. El nivel B permite, por 49 ejemplo, representar el diseño pedagógico que surge en el escenario B del caso de estudio (unidad UACata2), manteniendo propiedades que almacenen los resultados de las evaluaciones y utilizando dichos valores en condiciones que permitan determinar qué actividades deben proponerse a continuación. § El nivel C, por último, introduce un mecanismo de notificación que ofrece paradigmas alternativos para controlar el flujo de aprendizaje. Utilizando este mecanismo de nivel C es posible, por ejemplo, modelar fácilmente el diseño educativo asociado con la unidad de aprendizaje del escenario C (unidad UACata3). Las siguientes secciones analizan con más detalle cada uno de estos niveles. 2.5. EL NIVEL A El nivel A de la especificación permite describir diseños educativos no adaptativos, en el sentido de que el método pedagógico siempre exhibirá el mismo comportamiento, independientemente del resultado de las distintas actividades. No obstante, en este nivel se introducen los principales constructores del lenguaje. A continuación se analizan las principales características de este nivel. La sección termina ejemplificando el uso de estas características mediante el modelado de la unidad de aprendizaje UACata1. 2.5.1. Estructura de alto nivel de un Diseño Educativo La Figura 2.5.1.a esquematiza la estructura de alto nivel de la especificación de un diseño educativo de nivel A. Figura 2.5.1.a. Estructura de un diseño educativo de nivel A . 0..1 0..1 Diseño educativo 0..1 1 Título Objetivos de Aprendizaje Prerequisitos Componentes 1 Método 0..1 50 Metadatos De acuerdo con esta figura, la especificación del diseño consta de: § Un título opcional que describe brevemente el diseño educativo y que puede utilizarse, a efectos informativos, durante la inspección de alto nivel de la unidad de aprendizaje. § Opcionalmente, los objetivos de aprendizaje de la unidad asociada con el diseño. Estos objetivos hacen referencia a los logros de aprendizaje que se espera que consigan los distintos alumnos que cursen la unidad. Es importante indicar que IMS LD no proporciona mecanismos específicos para formalizar dichos objetivos. Este elemento de información permite únicamente referir a un recurso que contendrá una descripción (informal o formal) de tales objetivos. De hecho, en el caso más simple los objetivos harán referencia a recursos que expliquen textualmente dichos objetivos. Por ejemplo, en nuestro caso de estudio Corbinus podría preparar un recurso adicional (v.g. un archivo PDF) en el que planteara los objetivos generales del seminario. IMS también ha propuesto otras especificaciones alternativas para la descripción de tales objetivos como, por ejemplo, IMS RDCEO (Reusable Definition of Compentency or Educational Objectives – veáse IMS RCDEO, 2002 y también el capítulo sobre RDCEO en este informe). § Opcionalmente, los prerrequisitos necesarios para cursar la unidad. De nuevo debe indicarse que IMS LD no proporciona mecanismos específicos para formalizar tales requisitos. El elemento de información permitirá únicamente referir a un recurso (v.g. un archivo con un documento apropiado) que describa dichos requisitos. Si se desea un grado mayor de formalización, puede utilizarse también IMS RDCEO para este propósito. § Los componentes del diseño educativo. Dichos componentes enumeran los participantes, las actividades y los materiales involucrados en el proceso de aprendizaje. § El método pedagógico que se sigue en la unidad de aprendizaje. Esta característica (la posibilidad de formalizar explícitamente el método más apropiado para cada unidad / escenario de aprendizaje) es uno de los elementos distintivos de IMS LD y suele calificarse normalmente de neutralidad pedagógica. Efectivamente, IMS LD no se compromete con ninguna pedagogía concreta, sino que se sitúa al metanivel, permitiendo a los diseñadores describir la pedagogía más apropiada para cada dominio / aplicación. § Los metadatos son un componente esencial de cualquier material educativo informatizado con mínimas aspiraciones de permitir su descubrimiento y reutilización por terceros. Dichos metadatos son información adicional que se añade a los contenidos y que describen distintas características semánticas de los mismos. En este caso se podría describir quién ha codificado el diseño educativo, quién ha sido el último revisor del mismo, cómo puede clasificarse el diseño educativo en una taxonomía de diseños, etc. Para ello, la especificación permite utilizar cualquier convenio de descripción de metadatos (por ejemplo la Norma española UNE 71361:2010 Perfil de Aplicación LOM-ES v1.0), aunque 51 recomienda el uso de la especificación Learning Object Metadata (LOM) para tal fin. Para una descripción detallada de LOM puede consultarse (IEEE LOM, 2002; IMS META, 2006; Fernández-Manjón et al., 2007). Además, como se verá a lo largo de este capítulo, existen otros muchos lugares de la especificación donde pueden utilizarse metadatos. La diferencia entre componentes y método es esencial para entender la estructura formal de un diseño educativo. En palabras de la propia especificación, esta diferencia es la misma que existe en una receta de cocina entre la lista de ingredientes (los componentes) y la descripción de los pasos que hay que seguir para preparar el plato (el método). Para aquellos lectores con conocimientos de programación, una analogía útil puede ser considerar la sección de componentes como la sección de declaraciones y la sección de método como la sección de instrucciones. 2.5.2. Descripción de los Componentes: Roles, Actividades y Entornos La Figura 2.5.2.a muestra la estructura de la especificación de los componentes del diseño educativo. Dicha Figura introduce también la terminología utilizada en IMS LD en relación con los participantes (en IMS LD: roles) y con los contenidos y servicios utilizados en las actividades (en IMS LD: entornos). Figura 2.5.2.a. Estructura de la especificación de los componentes. 1 Componentes 0..1 0..1 Roles Actividades Entornos En la Figura 2.5.2.b se esquematiza la estructura de la especificación de los roles. Tal y como muestra dicha figura, IMS LD introduce dos tipos predefinidos de roles: aprendiz y plantilla (en inglés, staff). Cada rol puede, a su vez, especializarse en nuevos subroles, tal y como indican los ciclos introducidos en la Figura 2.5.2.b. Por ejemplo, en nuestro caso de estudio el rol aprendiz se especializará en el subrol alumno de nueva promoción y alumno de promociones antiguas, mientras que el rol plantilla se especializará en el subrol profesor del seminario − Figura 2.5.2.c (a). 52 Figura 2.5.2.b. Estructura de la especificación de los roles. 0..1 0..∞ Aprendiz 0..1 Título Información 0..∞ 0..1 Metadatos Roles 0..1 0..∞ Plantilla 0..1 Título Información 0..∞ 0..1 Metadatos Figura 2.5.2.c. (a) Roles en el caso de estudio; (b) hipotética asignación de usuario a roles durante la ejecución de la unidad de aprendizaje. (a) (b) Aprendiz Alumno de nueva promoción <agregar> José Botella Ana Brandy Pedro Rioja Alumno de promociones antiguas <agregar> Anselmo Cacique María Valdepeñas Profesor del Seminario <agregar> Corbinus Bodeguero Alumno de promociones antiguas Alumno de nueva promoción Plantilla Profesor del Seminario Es importante señalar que los roles no introducen participantes concretos, sino tipos de participantes. Por ejemplo, supongamos que José Botella es un alumno de nueva promoción matriculado en el curso de Corbinus. El rol, identificado en tiempo de diseño, será alumno de nueva promoción. Por su parte, José Botella será un usuario concreto de la unidad de aprendizaje, asignado al rol alumno de nueva promoción. En general cada rol podrá tener asignados múltiples usuarios en tiempo de ejecución, aunque, por supuesto, también pueden concebirse roles que tengan asignados un 53 único usuario (v.g. Corbinus es el único usuario asignado al rol profesor del seminario). Qué usuarios están asignados a qué roles es un aspecto que no se describe en el diseño educativo (es decir, no se describe usando IMS LD), sino que se decide posteriormente, en tiempo de explotación, administración y ejecución de la unidad de aprendizaje −por ejemplo, mediante una herramienta de administración que permite asignar usuarios a roles, como se sugiere en la Figura 2.5.2.c (b). En lo que se refiere al resto de los elementos de información en sí introducidos en la Figura 2.5.2.b, su significado es directo: § Cada rol puede tener asociado un título descriptivo breve. § Asimismo, cada rol puede tener asociado un elemento de información, que permite hacer referencia a recursos que describen de manera detallada dicho rol. Por ejemplo, Corbinus podría usar esta característica para enlazar documentos descriptivos de cada uno de los roles asociados con los alumnos. § Por último, cada rol puede tener asociados metadatos. Entre las múltiples posibilidades que ofrece esta característica puede pensarse en la disposición de una biblioteca externa de roles y en la selección de dichos roles en la biblioteca utilizando esta sección de metadatos (aunque, por supuesto, estos usos no están ni deben estar normativizados en IMS LD). Figura 2.5.2.d. Estructura de la especificación de las actividades. Las llaves quieren decir que puede elegirse entre cualesquiera de los elementos de información que agrupan. Actividad de Aprendizaje Actividades Actividad de Soporte 1..∞ Actividad Estructurada La estructura de las actividades se esquematiza en la Figura 2.5.2.d. Como puede observarse en dicha Figura, se distinguen los siguientes tres tipos de actividades: § Actividades de aprendizaje: estas actividades deben ser realizadas individualmente por cada participante, que logrará alcanzar ciertos objetivos educativos mediante la realización de las mismas. Por ejemplo, en nuestro caso de estudio, las actividades Lectura Artículo Birra y Realización Trabajo son ejemplos de actividades de aprendizaje § Actividades de soporte: actividades que permiten a un rol proporcionar algún tipo de soporte a otro rol. Un ejemplo típico son las actividades de evaluación. Aquí, el profesor proporciona un soporte de evaluación a cada uno de los miembros de un rol alumno. Por ejemplo, en nuestro caso de estudio, la actividad Evaluación Trabajo es una actividad de soporte. § Actividades estructuradas: estas actividades permiten agrupar otras actividades más simples. El resultado puede considerarse como una 54 actividad individual a efectos de su uso en el método pedagógico. En nuestro caso de estudio, las actividades Lectura Artículo Birra, Visionado Vídeo y Lectura Artículo Bebo pueden agruparse en una actividad estructurada, ya que el grupo resultante se trata como un todo en la especificación del método pedagógico. Estas actividades estructuradas pueden, además, configurarse de dos formas diferentes: - En modo secuencia. Este modo indica que la realización de la actividad estructurada supondrá realizar consecutivamente, una detrás de la otra, las actividades constituyentes. - En modo selección. Este modo indica que el orden de realización de las actividades componentes puede ser elegido por el usuario. En el caso de la actividad estructurada puesta como ejemplo, tendrá sentido configurar la misma en modo selección. Figura 2.5.2.e. Estructura de la especificación de una actividad de aprendizaje. 0..1 0..1 0..1 0..∞ Titulo Objetivos de Aprendizaje Prerequisitos Entorno (referencia) Actividad de Aprendizaje 1 0..1 0..1 0..1 Descripción Condición de Finalización Acción tras la finalización Metadatos La Figura 2.5.2.e esquematiza la estructura de la descripción de una actividad de aprendizaje. Los elementos de información explicitados en esta figura son: § Un breve título descriptivo opcional. § Opcionalmente, descripción de los objetivos de aprendizaje y de los prerrequisitos de la actividad. La naturaleza de estos elementos es análoga a la de los asociados con el diseño educativo global, aunque esta vez referida a la actividad concreta. § Referencias a los distintos entornos que caracterizan los materiales educativos y servicios requeridos por la actividad (más adelante se ampliarán los detalles sobre estos componentes). Es importante notar que los entornos en sí no se describen aquí, sino que en este campo se sitúan 55 únicamente referencias a los mismos. Esto permite reutilizar un mismo entorno en múltiples actividades. § Descripción de la actividad. Referencias a recursos que describen la actividad. Por ejemplo, en la actividad Visionado de Vídeo, aparte del entorno conteniendo el material concreto a utilizar (v.g. el vídeo), Corbinus podrá incluir una referencia a un recurso asociado con un PDF explicando la actividad. § Descripción opcional sobre la forma de finalizar la actividad. En IMS LD una actividad de aprendizaje se puede finalizar, bien porque así lo decida el aprendiz (v.g. pulsando un botón de finalización asociado con la actividad en el reproductor), bien porque se haya superado el tiempo límite asignado por el diseñador educativo para su finalización. Es importante indicar que, si no se especifica esta descripción, por defecto la actividad se asume finalizada (es decir, la actividad estará finalizada desde el comienzo mismo de la reproducción). § Descripción opcional de la acción a llevar a cabo una vez que se ha completado la actividad. A nivel A dicha acción puede ser, únicamente, mostrar un recurso proporcionando información de realimentación al aprendiz. Por ejemplo, Corbinus podría utilizar esta opción en Visionado de Vídeo para visualizar un texto resumen con los principales puntos expuestos en el vídeo, una vez que dicho vídeo hubiera finalizado. § Un elemento con metadatos acerca de la actividad. La estructura de la especificación de una actividad de soporte es, por su parte, similar a la de una actividad de aprendizaje, tal y como se muestra en la Figura 2.5.2.f. La principal diferencia es que en este tipo de actividades pueden identificarse explícitamente los roles a los que se da soporte (rol soportado). Figura 2.5.2.f. Estructura de la especificación de una actividad de soporte. 0..1 0..∞ 0..1 0..1 Actividad de Soporte 0..∞ 1 0..1 0..1 0..1 56 Titulo Rol soportado (referencia) Objetivos de Aprendizaje Prerequisitos Entorno (referencia) Descripción Condición de finalización Acción tras la finalización Metadatos La Figura 2.5.2.g esboza cómo se especifica una actividad estructurada en IMS LD. Los elementos de información involucrados son: § Título descriptivo opcional. § Referencia a recursos que describen la actividad. Al contrario que con el elemento de descripción de una actividad simple, este elemento es opcional (ya que, en última instancia, las actividades estructuradas podrán entenderse descritas por sus actividades constituyentes). No obstante, puede haber muchos casos donde desee puntualizarse mejor el propósito de la actividad estructurada. Por ejemplo, Corbinus podría explicar que el propósito de la actividad estructurada formada por Lectura Artículo Birra, Visionado Vídeo y Lectura Artículo Bebo es clarificar una serie de conceptos (v.g. la función de la papila gustativa en el proceso de la cata, y la importancia del retrogusto frutal en la apreciación de la variedad de uva Malvasía), a fin de guiar al alumno en la realización de las distintas actividades constituyentes. § Referencia a los entornos necesarios para llevar a cabo esta actividad estructurada. Por ejemplo, es posible referir un entorno con un vídeo o un texto introductorios o preparatorios de / para la actividad, que puede ser presentado al usuario antes de que éste aborde la consecución de las actividades constituyentes. § Referencias a las actividades constituyentes. Nótese que dichas actividades constituyentes pueden ser actividades de aprendizaje, actividades de soporte, otras actividades estructuradas, e, incluso, otras unidades de aprendizaje. De nuevo el uso de referencias permite reutilizar una misma actividad en múltiples actividades estructuradas. § Metadatos asociados con la actividad. Figura 2.5.2.g. Estructura de la especificación de una actividad estructurada. 0..1 Titulo 0..1 0..∞ Información Entorno (referencia) Actividad Estructurada Actividad de aprendizaje (referencia) 1..∞ Actividad de soporte (referencia) Unidad de aprendizaje (referencia) Actividad estructurada (referencia) 0..1 Metadatos 57 La estructura de los entornos se esboza en la Figura 2.5.2.h. Como evidencia dicha estructura, un entorno agrupa los recursos educativos necesarios para llevar a cabo una actividad. IMS LD discrimina entre dos tipos básicos de recursos educativos: § Los objetos de aprendizaje. Recursos reproducibles y referenciables, normalmente, aunque no necesariamente, digitales, que se utilizan en la realización de una actividad. En nuestro caso de estudio, los artículos, el libro o el vídeo son buenos ejemplos de este tipo de objetos. El elemento de información en sí permitirá referir a tales recursos, que estarán disponibles en el contexto de uso del diseño educativo (v.g. en el paquete IMS utilizado para representar la unidad de aprendizaje). IMS LD contempla también la extensión del lenguaje básico con otros sublenguajes que permitan describir in situ tipos concretos de objetos de aprendizaje (v.g. descripción de la estructura de un examen utilizando IMS QTI). § Los servicios. Herramientas y programas de soporte a las actividades de aprendizaje. En nuestro caso, el Chat es un buen ejemplo de servicio. Figura 2.5.2.h. Estructura de la especificación de los entornos. 0..1 Titulo Objeto de Aprendizaje Entornos 1..∞ 0..∞ Entorno Servicio Entorno (referencia) 0..1 Metadatos El cometido de los elementos de información en la Figura 2.5.2.h es directo: § Un título descriptivo opcional. § Los objetos de aprendizaje y los servicios. § La posibilidad de referir y reutilizar entornos previamente definidos. § Una sección de metadatos. Merece la pena profundizar un poco más en la diferencia entre objeto de aprendizaje y servicio. De nuevo podemos apelar aquí a criterios estrictamente formales. Efectivamente, IMS LD concibe los objetos de aprendizaje como recursos que pueden reproducirse de forma incontextual, independientemente del contexto particular de cada ejecución. Por ejemplo, para visualizar una serie de archivos, únicamente es necesario conocer el formato de dichos archivos y esto puede decidirse en tiempo de 58 diseño. Por su parte, los servicios requieren información del contexto de ejecución de la unidad de aprendizaje para su correcta reproducción. Así, el envío de un correo electrónico a todos los usuarios asignados a un determinado rol depende de los usuarios concretos asociados con dicho rol y esto no se decide, como ya se ha dicho, en tiempo de diseño, sino que es una característica que dependerá de la puesta en marcha y la reproducción de la unidad de aprendizaje. IMS LD contempla la existencia de distintos tipos de servicios. La Figura 2.5.2.i muestra la estructura de la especificación de estos servicios en IMS LD. Figura 2.5.2.i. Estructura de la especificación de los servicios. Correo Electrónico Conferencia Servicio Búsqueda Otro servicio Dicha figura incluye la posibilidad de configurar servicios de los siguientes tipos: § Servicio de correo electrónico. Su configuración permite identificar los destinatarios del e-mail (un grupo de usuarios identificados por uno o varios roles). Esta descripción se interpretará como una orden para invocar a un servicio de correo electrónico que, previsiblemente, permitirá editar el mensaje y dirigirlo a los destinatarios. § Servicio de conferencia. Este servicio permite articular conferencias virtuales. Su configuración permite fijar los siguientes aspectos de uso del servicio: § - La lista de participantes. Cada participante se refiere a un rol. - La lista de observadores (usuarios que observan, pero que no pueden participar). Cada observador se asocia con un rol. - El moderador de la conferencia. Una conferencia puede tener más de un moderador. De hecho, los moderadores se identifican mediante referencias a roles. - El administrador de la conferencia. Un administrador de conferencia puede crear nuevas sub-conferencias (por ejemplo, asignando dinámicamente subgrupos de usuarios a las mismas), así como destruir dichas sub-conferencias. No puede, no obstante, destruir la conferencia base (ésta será liberada automáticamente por el entorno de ejecución). Servicio de búsqueda. Este servicio permite configurar un buscador que actúa sobre la información contenida en la unidad de aprendizaje. Para ello es posible acotar los fragmentos de la unidad de aprendizaje sobre los que 59 se realizará la búsqueda (es decir, definir los índices de la misma), así como seleccionar el tipo de búsqueda que se llevará a cabo: por texto libre o distintos estilos de búsqueda guiada. Aparte de estos servicios, IMS LD ofrece un mecanismo de extensión que permite la inclusión de nuevos servicios para cada escenario particular de aplicación. Por ejemplo, los administradores de la infraestructura e-learning de Corbinus podrían utilizar este mecanismo para incorporar los servicios de archivística y de publicación de anuncios utilizados por Corbinus en sus diseños. No obstante, por motivos de simplicidad no contemplaremos esta posibilidad, tratando como objetos de aprendizaje todas aquellas herramientas telemáticas no incluidas por defecto como servicios. 2.5.3. Descripción del método educativo IMS LD introduce una metáfora basada en una obra de teatro para la descripción de los métodos educativos. De esta forma, la descripción de uno de estos métodos se equipara a la descripción de la estructura de una obra que consta de un guión (o incluso de varios guiones alternativos). El guión se estructura, a su vez, en una secuencia de actos. Cada acto se caracteriza, por último, por un conjunto de actuaciones. Cada actuación consiste en la realización de una actividad por parte de un rol. La dinámica resultante de esta metáfora supone la ejecución simultánea de todos los guiones, la ejecución en secuencia de cada acto dentro de cada guión y la ejecución simultánea de todas las actuaciones dentro de cada acto. Figura 2.5.3.a. Estructura de la especificación de un método. 1..∞ Metodo 0..1 0..1 Guión Condición de finalización Acción tras finalización La Figura 2.5.3.a esquematiza la estructura de la descripción de un método. Dicha descripción se ajusta a la metáfora teatral e incluye: § Uno o más guiones. § Una condición que dicta la finalización de la ejecución del método. Dicha condición puede ser: (i) la finalización de uno de los guiones o (ii) la superación de un tiempo límite. Es importante notar que, si esta condición no se especifica, se asume que el método está finalizado. § Una acción a realizar una vez que dicho método ha finalizado. En el nivel A dicha acción puede consistir únicamente en proporcionar material de realimentación al usuario. La Figura 2.5.3.b muestra la estructura de la descripción de un guión. Dicha estructura contempla la existencia de: 60 § Un título opcional. § Uno o más actos. § Opcionalmente, una condición de finalización del guión. Dicha condición puede ser: (i) la finalización del último acto del guión o (ii) la superación de un tiempo límite. Es importante señalar que si esta condición no se especifica, se asume que el guión está finalizado. § Opcionalmente, una acción a realizar tras la finalización del guión. En el nivel A, dicha acción consiste, al igual que en otras situaciones, en proporcionar realimentación al usuario. § Un cuerpo opcional de metadatos. Figura 2.5.3.b. Estructura de la especificación de un guión. 0..1 1..∞ Guión 0..1 0..1 0..1 Título Acto Condición de finalización Acción tras finalización Metadatos Figura 2.5.3.c. Estructura de la especificación de un acto. 0..1 1..∞ Acto 0..1 0..1 0..1 Título Actuación Condición de finalización Acción tras finalización Metadatos La Figura 2.5.3.c muestra la estructura de la descripción de un acto. Dicha descripción incluye: § Un título opcional. § Una o más actuaciones. 61 § Opcionalmente, una condición de finalización. Dicha condición puede ser: (i) la finalización de una actuación o (ii) la superación de un tiempo límite. Si esta condición no se especifica, se asume que el acto habrá finalizado. § Opcionalmente, una acción de finalización (a nivel A, mostrar información de realimentación al usuario). Figura 2.5.3.d. Estructura de la especificación de una actuación. 0..1 Título rol (referencia) Actuación actividad (referencia) 0..1 Metadatos Por último, la Figura 2.5.3.d muestra cómo se describe una actuación. Básicamente dicha descripción consiste en referir el rol involucrado, así como la actividad involucrada. Una restricción importante impuesta por IMS LD es que en un mismo acto cada rol puede participar, a lo sumo, en una actuación. Las actividades estructuradas constituyen, de esta forma, un mecanismo fundamental para agrupar actividades más simples en una única, a fin de que todas ellas puedan ser llevadas a cabo por un rol en un acto. 2.5.4. Modelo de Ejecución Una vez introducidos los componentes de modelado, es interesante reflexionar sobre el modelo de ejecución de los métodos. Un aspecto relevante para entender este modelo es el aceptar que cada usuario tendrá una vista diferente de la ejecución, que dependerá del rol al que dicho usuario esté asignado, o, dicho de otra forma, su propia vista de la obra. Efectivamente: § El usuario verá únicamente aquellas actividades asociadas a las actuaciones en las que interviene su rol. § Asimismo, las actuaciones serán llevadas a cabo por cada uno de los miembros de un rol. § La forma de sincronizar las actuaciones de los distintos usuarios es mediante los actos, ya que es posible hacer depender la finalización de un acto de la finalización de una actuación. De esta forma, el acto no finalizará hasta que no finalicen sus actuaciones todos los usuarios que juegan el papel especificado en la actuación. Otro aspecto importante a tener en cuenta es el relativo al secuenciamiento de las actividades en el interior de los actos. Efectivamente, dicho secuenciamiento no se 62 decide a nivel de acto, sino que debe especificarse a nivel de actividad, mediante la creación de actividades estructuradas adecuadas. 2.5.5. Ejemplo de Diseño de Nivel A En este apartado se esboza el diseño educativo de la unidad de aprendizaje UACata1, utilizando para ello características de nivel A de IMS LD. A fin de simplificar el desarrollo, se omiten muchas de las características opcionales, características que se podrían incluir en sucesivas revisiones y mejoras del diseño. Figura 2.5.5.a. Fragmento de diseño con roles. Roles ..Aprendiz ....Título: Alumno de nueva promoción ..Aprendiz ....Título: Alumno de promociones antiguas ..Plantilla ....Título: Profesor del seminario El fragmento de diseño esbozado en la Figura 2.5.5.a muestra el diseño de los tres roles (los dos roles de tipo aprendiz: Alumno de nueva generación y Alumno de promociones antiguas, y el rol de tipo plantilla: Profesor de Seminario). El diseño de los entornos para las actividades se muestra en la Figura 2.5.5.b Este fragmento de diseño esboza los siguientes entornos: § El entorno Artículo Birra, que refiere al artículo del Profesor Birra. § El entorno Artículo Bebo, que hace referencia al artículo de la Profesora Bebo. § El entorno Vídeo Bacus, que hace referencia al vídeo con la charla del Profesor Bacus. § El entorno Sitio Web, www.lacatadelvinotinto.org. § El entorno Servicio Debate, que configura un servicio de conferencia a fin de articular el debate. § El entorno Espacio de Archivos, que hace referencia a una URL que da paso a un servidor de archivos (se asume que dicha URL está asociada con el recurso archivos). Se supone que en la página accesible vía esta URL se pedirá el nombre y la contraseña del usuario concreto. Esto permite concebir el recurso como un objeto de aprendizaje, en lugar de cómo un servicio. § El entorno Tablón, que hace referencia a una URL que permite consultar / editar un tablón de notas (recurso rtablon). Al igual que en el caso anterior, se supone que en la página correspondiente se pedirán los datos del usuario, lo que permite usar el recurso como un objeto de aprendizaje en lugar de como un servicio. que 63 hace referencia al sitio web Figura 2.5.5.b. Fragmento de diseño con la descripción de los entornos. Entornos ..Entorno ....Título: Artículo Birra ....Objeto de Aprendizaje: <referencia a recurso rbirra> ..Entorno ....Título: Artículo Bebo ....Objeto de Aprendizaje: <referencia a recurso rbebo> ..Entorno ....Título: Video Bacus ....Objeto de Aprendizaje: <referencia a recurso rbacus> ..Entorno ....Título: Sitio web ....Objeto de Aprendizaje: <referencia a recurso rweb> ..Entorno ....Título: Servicio Debate ....Servicio ......Conferencia: Participantes: <referencia a rol alumno de nueva promoción> <referencia a rol alumno de promociones antiguas> Moderador: <referencia a rol profesor del seminario> ..Entorno: ....Título: Espacio de Archivos ....Objeto de Aprendizaje: <referencia a recurso rarchivos> ..Entorno: ....Título: Tablón ....Objeto de Aprendizaje: <referencia a recurso rtablón> La Figura 2.5.5.c esquematiza el diseño de las actividades. Nótese que cada actividad hace referencia a un entorno apropiado, así como a un recurso que la describe (por simplicidad estos recursos no se listaron en la Figura 2.4.1.b). Más concretamente, se incluyen las siguientes actividades de aprendizaje: § La actividad Lectura Artículo Birra hace referencia al entorno Artículo Birra. También hace referencia al recurso rdalectartbirra, que estará asociado con una descripción de esta actividad. § Las actividades Lectura Artículo Bebo y Visionado Vídeo son análogas. Los entornos referidos son, respectivamente, Artículo Bebo y Vídeo Bacus, mientras que los recursos descriptivos referidos son, respectivamente, rdalectartbebo y rdavisvideo. § Las actividades Examen sitio web, Realización trabajo y Consulta Resultados, por su parte, refieren a los entornos asociados con los recursos web externos correspondientes al sitio web (Sitio Web), al punto de entrada al servidor de archivos (Espacio de Archivos) y al punto de entrada al tablón de resultados (Tablón). Los recursos descriptivos son, respectivamente, rdaexweb, rdarealtrabajo y rdaconresultados. § La actividad Debate, que representa el debate mantenido entre alumnos de nueva promoción y alumnos de promociones antiguas. En la descripción de 64 dicha actividad se refiere al entorno que configura el servicio de conferencia para llevar a cabo el debate. § La actividad Impartición Clase Presencial. El propósito de esta actividad es únicamente que, una vez impartida dicha clase, Corbinus pueda indicar la misma como finalizada, dando lugar a la parte on-line del diseño educativo. Nótese que esta actividad no involucra entorno alguno ya que, desde un punto de vista meramente operacional, su función es ofrecer únicamente el botón de arranque del proceso. 65 Figura 2.5.5.c. Fragmento de diseño con la descripción de las actividades. Actividades ..Actividad de Aprendizaje ....Título: Lectura Artículo Birra ....Entorno: <referencia a entorno Artículo Birra> ....Descripción: <referencia a recurso rdalectartbirra> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Lectura Artículo Bebo ....Entorno: <referencia a entorno Artículo Bebo> ....Descripción: <referencia a recurso rdalectartbebo> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Visionado Video ....Entorno: <referencia a entorno Video Bacus> ....Descripción: <referencia a recurso rdavisvideo> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Examen sitio web ....Entorno: <referencia a entorno Sitio Web> ....Descripción: <referencia a recurso rdexweb> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Realización Trabajo ....Entorno: <referencia a entorno Espacio de Archivos> ....Descripción: <referencia a recurso rdrealtrabajo> ....Condición de finalización: una vez transcurrida una semana ..Actividad de Aprendizaje ....Título: Consulta Resultados ....Entorno: <referencia a entorno Tablón> ....Descripción: <referencia a recurso rdaconresultados> ....Condición de finalización: finalizada por el usuario ..Actividad de Aprendizaje ....Título: Debate ......Entorno: <referencia a entorno Debate> ......Descripción: <referencia a recurso rdadebate> ......Condición de finalización: una vez transcurridas dos horas ..Actividad de Aprendizaje ....Título: Impartición Clase Presencial ....Descripción: <referencia a recurso rdaimpclase> ....Condición de finalización: finalizada por el usuario ..Actividad de Soporte ....Título: Corrección de Trabajo ....Rol soportado: <referencia a Alumno de nueva promoción> ....Entorno: <referencia a entorno Espacio de Archivos> ....Entorno: <referencia a entorno Tablón> ....Condición de finalización: finalizada por el usuario ..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3) ....Título: Examen materiales ....Actividad de aprendizaje (referencia): Lectura Artículo Bebo ....Actividad de aprendizaje (referencia): Lectura Artículo Birra ....Actividad de aprendizaje (referencia): Visionado Video ..Actividad Estructurada (tipo secuencia) ....Título: Autoaprendizaje ....Actividad estructurada (referencia): Examen materiales ....Actividad de aprendizaje (referencia): Examen sitio web 66 Figura 2.5.5.d. Fragmento de diseño con la descripción del método pedagógico. Método ..Guión ....Acto ......Título: clase presencial .......Actuación .........Título: Actuación impartición .........Rol(referencia): <referencia a Profesor del Seminario> .........Actividad(referencia): <referencia a Impartición clase presencial> .......Actuación .........Título: Actuación asistencia .........Rol(referencia): <referencia a Alumnos de nueva promoción> .........Actividad(referencia): <referencia a Impartición clase presencial> ......Condición de finalización: <finalizada Actuación impartición> ....Acto ......Título: período autoaprendizaje ......Actuación ........Título: Actuación autoaprendizaje ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Autoaprendizaje> ......Condición de finalización: <finalizada Actuación autoaprendizaje> ....Acto ......Título: discusión ......Actuación ........Título: Actuación debate alumno nuevo ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Debate> ......Actuación ........Título: Actuación debate alumno antiguo ........Actividad(referencia): <referencia a Debate> ........Rol(referencia): <referencia a Alumno de promociones antiguas> ......Actuación ........Título: Actuación debate profesor ........Rol(referencia): <referencia a Profesor del seminario> ........Actividad(referencia): <referencia a Debate> ......Condición de finalización: <finalizada Actuación debate profesor> ....Acto ......Título: trabajo ......Actuación ........Título: Actuación trabajo ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Realización Trabajo> ......Condición de finalización: <finalizada Actuación trabajo> ....Acto ......Título: evaluación ......Actuación ........Título: Actuación evaluación ........Rol(referencia): <referencia a Profesor del seminario> ........Actividad(referencia): <referencia a Corrección de Trabajo> ......Condición de finalización: <finalizada Actuación evaluación> ....Acto ......Título: resultados ......Actuación ........Título: Actuación resultados ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Consulta resultados> ......Condición de finalización: <finalizada Actuación resultados> ....Condición de finalización: finalizado último acto 67 El diseño incluye, además, la actividad de soporte Evaluación de Trabajo. El papel soportado es el de los alumnos de nueva promoción. De esta forma, quien realice esta actividad deberá notificar, de alguna manera que dependerá del entorno de ejecución, que cada uno de los alumnos de nueva promoción han sido atendidos antes de que el entorno de ejecución decida que la actividad ha sido completada. La actividad en sí requiere tanto el espacio de archivos (donde Corbinus podrá encontrar los trabajos) como el tablón de anuncios (donde podrá publicar los resultados). Nótese, asimismo, cómo distintas actividades pueden compartir los mismos entornos. Para finalizar, se incluyen también las siguientes actividades estructuradas: § Las actividades Lectura Artículo Birra, Visionado Vídeo y Lectura Artículo Bebo se agrupan en Examen Materiales. § Por su parte, esta actividad se agrega con la actividad Examen sitio web para dar lugar a la actividad estructurada Autoaprendizaje. Esta estructuración permite situar todas estas actividades en un único acto en el método que se esboza en la Figura 2.5.5.d. Los actos incluidos en el método son: § El acto clase presencial, que representa la impartición de la clase presencial (en realidad, y tal y como se ha indicado, el efecto de este acto será permitir decidir al profesor cuándo comenzar el proceso de aprendizaje on-line representado en este diseño). § El acto periodo autoaprendizaje, que representa para el alumno el examen de todo el material educativo proporcionado por el profesor. § El acto discusión, en el que se lleva a cabo el debate entre los alumnos de nueva promoción y los antiguos alumnos. Nótese que en este acto se incluye una actuación para cada uno de los roles involucrados, aunque dichas actuaciones incluyan todas ellas la misma actividad Debate. § El acto trabajo, en el que el alumno realiza el trabajo. § El acto evaluación, en el que el profesor evalúa el trabajo. § El acto resultados, en el que el alumno consulta los resultados 2.6. EL NIVEL B La ejecución de los diseños de nivel A está predeterminada por la estructura de los propios diseños y no puede ser alterada como consecuencia de la realización de las actividades. En muchas situaciones esta dinámica es bastante limitada, ya que no permite explotar una de las principales ventajas de un escenario e-learning: la personalización de los contenidos y de los intinerarios educativos a las necesidades de cada participante en el proceso. Por ejemplo, en base al conocimiento previo del alumno (que puede venir descrito externamente, en su información curricular o bien puede determinarse durante el proceso, mediante algún tipo de evaluación previa) es posible ofrecer material más básico o más avanzado, así como incluir u omitir actividades. De hecho, en IMS LD nivel A es imposible modelar un escenario 68 educativo tradicional típico donde, si un alumno aprueba en Junio, aprueba la asignatura, y si el alumno suspende, debe ir a Septiembre. En IMS LD este comportamiento adaptativo de los métodos pedagógicos requiere el uso de facilidades de nivel B. En esta sección se analizan dichas características. La sección termina ejemplificando el uso de las mismas mediante el modelado de la unidad de aprendizaje UACata2, donde los itinerarios de aprendizaje de cada alumno dependen de su rendimiento en las evaluaciones realizadas y, por tanto, no pueden predeterminarse completamente en tiempo de diseño. 2.6.1. Propiedades IMS LD nivel B añade un nuevo tipo de componente educativo a los diseños: las propiedades. Dichas propiedades almacenan información relevante que se produce durante la ejecución del método educativo (v.g. puntuación del alumno en un test), o bien que se extrae del contexto educativo donde dicho método se ejecuta (v.g. lista de asignaturas que tiene aprobadas el alumno). Las propiedades constituyen una representación explícita del contexto y estado de los métodos pedagógicos. Su valor puede modificarse conforme avanza la ejecución para reflejar dicho estado y puede utilizarse para decidir la forma de llevar a cabo dicha ejecución. Desde un punto de vista informático, las propiedades son análogas a las variables en un lenguaje informático de programación convencional. Figura 2.6.1.a. El nivel B introduce las propiedades como nuevos componentes en el diseño. 1 0..1 Componentes Roles Propiedades 0..1 Actividades 0..1 69 Entornos Figura 2.6.1.b. Estructura de la especificación de las propiedades. Propiedad local personal Propiedad local de rol Propiedades 1..∞ Propiedad local general Propiedad global personal Propiedad global general La Figura 2.6.1.a ilustra la extensión de la descripción de los componentes de nivel A para incorporar la descripción de las propiedades de un diseño. Nótese que dichas propiedades pasan a ser componentes educativos de pleno derecho, situándose al mismo nivel que roles, actividades y entornos. La Figura 2.6.1.b muestra, por su parte, la estructura de la descripción de las propiedades. Este esbozo hace patente la distinción de propiedades en distintas categorías. Una primera distinción hace referencia a la localidad o la globalidad de las propiedades: § Las propiedades locales son aquéllas que se crean y se mantienen únicamente dentro de cada ejecución de la unidad de aprendizaje. § Las propiedades globales son aquellas que se crean y se mantienen en el entorno en el que se ejecutan las unidades de aprendizaje. El valor de dichas propiedades sobrevivirá, por tanto, a las distintas ejecuciones y prevalecerá entre ejecuciones de la misma unidad y/o de unidades distintas. Esta categorización puede refinarse como sigue: § § Las propiedades locales pueden ser de tres tipos diferentes: - Propiedades locales personales: Propiedades cuyo valor puede ser distinto para cada participante (por ejemplo, la nota obtenida en un test). - Propiedades locales de rol: Propiedades cuyo valor es el mismo para todos los miembros de un mismo rol, pero que puede variar entre distintos roles (por ejemplo, el número de usuarios asignados al rol). - Propiedad local general: Propiedades cuyo valor es el mismo para todos los participantes (por ejemplo, el tiempo transcurrido desde que comenzó a ejecutarse la unidad). Las propiedades globales pueden ser de los dos tipos siguientes: - Propiedad global personal: Propiedad global cuyo valor varía para cada posible usuario (por ejemplo, el nombre de usuario en el sistema 70 informático en el que está instalada la infraestructura de ejecución de IMS LD). - Propiedad global general: Propiedad global cuyo valor es el mismo para todos los usuarios (por ejemplo, el nombre y la versión del sistema operativo de la máquina en la que está instalada la infraestructura de ejecución de IMS LD). 2.6.2. Expresiones IMS LD nivel B incluye mecanismos para describir expresiones cuya evaluación da lugar a valores. Ejemplos de este tipo de expresiones son el sumar una serie de valores, comprobar si todos los valores de una serie son ciertos, comparar dos valores, etc. Estas expresiones podrán utilizarse en contextos y constructores de más alto nivel. IMS LD introduce los formatos de expresiones que se esquematizan en la Figura 2.6.2.a y en la Figura 2.6.2.b. Más concretamente: § Expresión de tipo “es miembro de rol”, que será cierta cuando el usuario pertenece al rol referido y falsa en otro caso. § Expresión “es”, que permite comprobar si dos valores son iguales. Aparte de los entes tipificados como expresiones en IMS LD, también es posible utilizar propiedades y valores literales como argumentos en esta expresión (lo mismo ocurre con todas aquellas en las que se indica “operando” como argumentos en la Figura 2.6.2.a; ver también Figura 2.6.2.b). § Expresión “no es”, que permite comprobar si dos valores son distintos. § Expresión “y”, que es cierta cuando lo son todos sus argumentos. § Expresión “o”, que es cierta cuando lo es alguno de sus argumentos. § Expresión “suma”, que suma todos sus argumentos1. § Expresión “resta”, que resta a su primer argumento el segundo. § Expresión “mul”, que multiplica el primer argumento por el segundo. § Expresión “div”, que divide el primer argumento entre el segundo. § Expresión “mayor que”, que permite comprobar si el valor del primer argumento es mayor que el valor del segundo. § Expresión “menor que”, que permite comprobar si el valor del primer argumento es menor que el valor del segundo. § Expresión “usuarios en rol”, que restringe la aplicabilidad de la expresión a todos aquellos usuarios que pertenecen al rol indicado. 1 La especificación únicamente permite un número par de argumentos para “suma” (2, 4, 8, etc. argumentos). Si bien los autores de este informe entienden que ésta es una errata en la especificación, han preferido constatarla en el informe a fin de ajustarse a la realidad de dicha especificación. 71 § Expresión “no valor”, que es cierta sobre propiedades que no tienen valor asignado. § Expresión “inicio unidad”, cuyo valor es el momento en el que comenzó a ejecutarse la unidad. § Expresión “inicio actividad”, cuyo valor es el momento en el que comenzó a ejecutarse la actividad actualmente activa. § Expresión “día y hora”, cuyo valor es el día y la hora actual. § Expresión “finalizado”, que permite comprobar si un determinado componente (actividad, actuación, acto o guión) ha finalizado. § Expresión “no”, que permite comprobar el incumplimiento de un determinado aserto. Figura 2.6.2.a. Expresiones. inicio unidad es miembro de rol (referencia) operando es inicio actividad operando operando no es y o día y hora unidad de aprendizaje (referencia) expresión finalizado actuación (referencia) expresión no operando 2..∞ 2..∞ suma expresión expresión acto (referencia) operando guión (referencia) 1.∞ operando operando resta operando mul operando operando operando div actividad (referencia) operando operando mayor que operando rol (referencia) usuarios en rol no valor expresión propiedad (referencia) 72 Figura 2.6.2.b. Operandos. expresión operando propiedad (referencia) valor 2.6.3. Acciones IMS LD nivel B también incluye mecanismos para expresar acciones que, al igual que la expresiones, podrán utilizarse en contextos de más alto nivel. La Figura 2.6.3.a esquematiza las posibles acciones expresables en IMS. Dichas acciones son: § Mostrar algún componente educativo o recurso. Efectivamente, componentes como las actividades, los entornos de las actividades, etc. pueden ser o no ser visibles, estado que puede alterarse en IMS LD nivel B. Más concretamente y tal y como se sugiere en la Figura 2.6.3.a, es posible mostrar (hacer visibles): - Todos los recursos o entornos de una determinada clase. Efectivamente, los recursos de una actividad de aprendizaje, así como los entornos, pueden clasificarse semánticamente en clases. La acción mostrar puede actuar globalmente sobre todos los elementos así clasificados. - Un recurso concreto. - Un entorno concreto. - Una actividad concreta. - Un guión. - Toda una unidad de aprendizaje. § Ocultar algún componente educativo o recurso. Los tipos de elementos que pueden ocultarse son los mismos que los que pueden mostrarse. § Cambiar el valor de una propiedad. Nótese que el nuevo valor puede ser, bien un literal, bien el valor de otra propiedad, bien venir dado por una expresión. 73 Figura 2.6.3.a. Acciones. clase recurso (referencia) entorno (referencia) Mostrar actividad (referencia) acción guión (referencia) unidad (referencia) Ocultar Propiedad (referencia) Cambiar valor de propiedad operando 2.6.4. Condiciones La introducción de propiedades tiene una repercusión importante a nivel de método. Efectivamente, IMS LD nivel B incluye un nuevo elemento descriptivo en los métodos educativos: las condiciones. Dichas condiciones son reglas que, en función del cumplimiento de una determinada guarda (un aserto o condición sobre el estado de ejecución), permiten actualizar los valores de las propiedades. Las condiciones en sí se plasman en reglas tipo si <guarda> entonces <acción-cierto> en otro caso <acción-falso>, con el significado: si <guarda> es cierta, realiza las acciones indicadas en <acción-cierto> y, si no, realiza las acciones indicadas en <acción-falso>. Evaluar una condición supone, por tanto, evaluar su guarda y, dependiendo de si dicha guarda es cierta o falsa, ejecutar la acción correspondiente. Dado que la parte else es opcional, la evaluación de condiciones sin parte else no tendrá efecto cuando la guarda sea falsa. Es importante notar que el modelo de ejecución de estas reglas es reactivo u oportunista (al contrario del modelo de ejecución secuencial típico en lenguajes informáticos de programación más usuales). Efectivamente, las condiciones se evalúan: § Al comienzo de la ejecución de la unidad. § Siempre y cuando el valor de una propiedad haya cambiado. 74 Asimismo, dado que las acciones de las reglas pueden modificar valores de propiedades que, a su vez, afectan a las guardas de otras reglas, en general la ejecución de las reglas se encadenará, como sucede con los sistemas basados en reglas clásicos (Li, 1991) utilizados en campos específicos de la informática como, por ejemplo, la Inteligencia Artificial. La Figura 2.6.4.a esquematiza la extensión de la descripción de los métodos con la incorporación de las condiciones a nivel B. Nótese que puede haber varios conjuntos de condiciones, cada uno de los cuáles podrá incluir varias condiciones. La estructura de estos conjuntos de condiciones se especifica en la Figura 2.6.4.b. Figura 2.6.4.a. Extensión de la estructura para los métodos con condiciones. 1..∞ Metodo 0..1 0..1 Guión Condición de finalización Acción tras finalización 0..∞ Condiciones Figura 2.6.4.b. Estructura de la especificación de las condiciones. 0..1 Condiciones expresión si Título 1..∞ 0..1 entonces Metadatos 0..1 en otro caso acción acción La descripción de tales conjuntos incluye: § Un título opcional. § La secuencia de las condiciones en sí. Nótese que la parte en otro caso en cada condición es opcional. Obsérvese también que la estructura de la parte si se corresponderá con una expresión, mientras que las de las partes entonces y en otro caso se corresponderán con una acción. § Un cuerpo de metadatos opcional. 75 2.6.5. Extensión de las condiciones de finalización de actividades, actos, guiones y métodos IMS LD nivel B extiende también las condiciones de finalización de actividades, actos, guiones y métodos, permitiendo que dicha finalización dependa de la asignación de cierto valor a cierta propiedad. Más concretamente, las condiciones de finalización pueden también tomar en el nivel B, el formato descrito en la Figura 2.6.5.a. La condición se hará cierta cuando la propiedad se actualice y, en caso de que se especifique valor adicional, cuando el valor de actualización coincida con el especificado. Figura 2.6.5.a. Extensión de las condiciones de finalización en IMS LD nivel B. Propiedad (referencia) Condición de finalización Propiedad actualizada 0..1 operando 2.6.6. Extensión de las acciones tras la finalización para actividades, actos, guiones y métodos En IMS LD nivel B la finalización de una actividad, acto, guión o método puede desencadenar la asignación de un valor a una propiedad, tal y como se sugiere en el esquema mostrado en la Figura 2.6.6.a. En conjunción con el condicionamiento de la terminación de elementos en términos de valores de propiedades, esta extensión permite llevar a cabo un secuenciamiento de actividades mucho más complejo, que depende de la forma en la que se ejecuta la unidad de aprendizaje, así como del contexto inicial de ejecución de la misma. Figura 2.6.6.a. Extensión de las acciones tras la finalización en IMS LD nivel B. Cambiar valor de propiedad Acción tras la finalización 2.6.7. Elementos globales y monitores IMS LD nivel B contempla también la posibilidad de que durante la realización de una actividad se modifiquen los valores de las propiedades de la unidad. Dado que IMS LD no norma la forma concreta en la que se ejecutan las actividades elementales, sino únicamente cómo se integran éstas en el diseño educativo, dichas modificaciones 76 exceden el alcance de la especificación. No obstante, la especificación introduce artefactos descriptivos estándar que pueden utilizarse para declarar en la descripción de un determinado tipo de contenidos que dichos contenidos van a consultar y/o modificar propiedades de la unidad de aprendizaje. Dichos artefactos se denominan elementos globales. De igual manera, a nivel B se introduce un nuevo tipo de servicio (servicio de monitorización), que permite consultar y/o modificar los valores de las propiedades de la unidad de aprendizaje. 2.6.8. Modelo de Ejecución El nivel B permite modular el modelo de ejecución por defecto introducido a nivel A. Efectivamente: § Las actividades pueden ser visibles o no visibles (este criterio de visibilidad también se aplica a nivel A, aunque es a nivel B donde realmente adquiere sentido). § Esta condición de visibilidad / invisibilidad puede alterarse mediante la ejecución de las condiciones, las cuales, como ya se ha indicado anteriormente, se consideran al comienzo de la ejecución, así como cada vez que cambia el valor de una propiedad. Dichas propiedades engloban tanto las definidas en la unidad de aprendizaje como aquellas cuyo valor se establece de manera automática (v.g. el estado de visibilidad o invisibilidad de las actividades). Es importante, no obstante, considerar también la interacción de este modelo de ejecución con algunas características de nivel A. En particular, la especificación establece que todas las actividades que forman parte de una actividad estructurada de tipo secuencia visible son visibles, independientemente de que éstas se hayan marcado como no visibles en su descripción, e independientemente de las condiciones. Dicho de otro modo, la visibilidad de las actividades que, en un acto, se ejecutan en secuencia viene predeterminada y no puede alterarse. 2.6.9. Ejemplo de diseño de nivel B En este apartado se esboza el diseño educativo de la unidad de aprendizaje UACata2, utilizando para ello características de nivel B de IMS LD. Como en el esbozo del diseño para UACata1 y con el fin de simplificar el desarrollo se omiten muchas de las características opcionales. De este modo y dado que esta unidad es, en realidad, una extensión de UACata1, únicamente se describirán los nuevos elementos que deben añadirse así como aquellos que han de modificarse. La descripción del diseño introduce las siguientes propiedades: § Propiedad nota en el test. Esta propiedad contendrá la puntuación obtenida por los alumnos en el test previo realizado. 77 § Propiedad nota en el trabajo. Esta propiedad contendrá la puntuación obtenida por cada alumno en el trabajo. § Propiedad recuperación finalizada. Esta propiedad se actualizará a cierto cuando se haya finalizado la recuperación. § Propiedad asignatura superada. Esta propiedad se actualizará a cierto cuando se haya superado la asignatura. Estas propiedades son ambas de tipo locales personales, ya que cada alumno tendrá las suyas propias, almacenando sus calificaciones y controlando la finalización de la recuperación. La Figura 2.6.9.a esboza su descripción: Figura 2.6.9.a. Fragmento de diseño con la descripción de las propiedades. Propiedades ..Propiedad ..Propiedad ..Propiedad ..Propiedad local local local local personal: personal: personal: personal: nota en el test nota en el trabajo recuperación finalizada asignatura superada Tal y como se muestra en la Figura 2.6.9.b, será necesario añadir los siguentes entornos a los ya existentes: § Entorno test, que hará referencia a un sitio web que aloja una herramienta de realización de tests. En este sitio web, los alumnos podrán identificarse y realizar los tests asignados. § Entorno libro Corbinus, que hará referencia al libro de Corbinus en formato electrónico. Figura 2.6.9.b. Nuevos entornos que aparecen en el diseño de UACata2. ..Entorno ....Título: Test ....Objeto de Aprendizaje: <referencia a recurso rherramientatests> ..Entorno ....Título: Libro Corbinus ....Objeto de Aprendizaje: <referencia a recurso rcorbinus> La Figura 2.6.9.c muestra las nuevas actividades que aparecen en este diseño. Se incluyen las siguientes actividades de aprendizaje y de soporte: § Actividad de aprendizaje Realización Test, orientada a la resolución del test previo. § Actividad de soporte Evaluación Test, orientada a la corrección del test previo. 78 § Actividad de aprendizaje Lectura libro Corbinus, en la que los alumnos que han obtenido peores notas en el test refuerzan sus conocimientos mediante la lectura del libro de Corbinus. § Actividades de aprendizaje Repaso libro Corbinus, Repaso Artículo Birra, Repaso Sitio Web, orientadas al repaso de los distintos materiales propuestos en el curso. § Actividad de aprendizaje Revisión y Mejora del Trabajo, en la que los alumnos podrán mejorar y corregir los defectos detectados en sus trabajos. § Actividad de soporte Re-evaluación del Trabajo, en la que el profesor corregirá los trabajos revisados. § Actividad de aprendizaje Consulta Resultados Repesca, en la que los alumnos podrán consultar los resultados definitivos de sus trabajos. Nótese que dicha actividad actualiza la propiedad recuperación finalizada tras su finalización. 79 Figura 2.6.9.c. Nuevas actividades de soporte y de aprendizaje que aparecen en UACata2. ..Actividad de Aprendizaje ....Título: Realización test ....Entorno: <referencia a entorno test> ....Descripción: <referencia a recurso rdareltest> ....Condición de finalización: una vez transcurrida 1 hora ..Actividad de Soporte ....Título: Evaluación test ....Rol soportado: <referencia a Alumno de nueva promoción> ....Entorno: <referencia a entorno test> ....Condición de finalización: finalizada por el usuario ..Actividad de Aprendizaje ....Título: Lectura libro Corbinus ....Entorno: <referencia a entorno Libro Corbinus> ....Descripción: <referencia a recurso rdalectlibcorbinus> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Repaso libro Corbinus ....Entorno: <referencia a entorno Libro Corbinus> ....Descripción: <referencia a recurso rdalectlibcorbinus> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Repaso Artículo Birra ....Entorno: <referencia a entorno Artículo Birra> ....Descripción: <referencia a recurso rdalectartbirra> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Repaso sitio web ....Entorno: <referencia a entorno Sitio Web> ....Descripción: <referencia a recurso rdexweb> ....Condición de finalización: una vez transcurrido un día ..Actividad de Aprendizaje ....Título: Revisión y mejora del trabajo ....Entorno: <referencia a entorno Espacio de Archivos> ....Descripción: <referencia a recurso rdrealtrabajo> ....Condición de finalización: una vez transcurrida una semana ..Actividad de Soporte ....Título: Re-evaluación del Trabajo ....Rol soportado: <referencia a Alumno de nueva promoción> ....Entorno: <referencia a entorno Espacio de Archivos> ....Entorno: <referencia a entorno Tablón> ....Condición de finalización: finalizada por el usuario ..Actividad de Aprendizaje ....Título: Consulta Resultados Repesca ....Entorno: <referencia a entorno Tablon> ....Descripción: <referencia a recurso rdaconresultados> ....Condición de finalización: finalizada por el usuario ....Acción tras finalización ......Cambiar valor de propiedad ........Propiedad(referencia): <referencia a propiedad recuperación finalizada> ........valor: Cierto 80 Además, tal y como muestra la Figura 2.6.9.d, se incluyen las siguientes actividades estructuradas: § Autoaprendizaje con repaso que incluye la lectura del libro de Corbinus como paso previo al autoaprendizaje. § Autoaprendizajes, actividad tipo selección que engloba los dos métodos de autoaprendizaje contemplados. Obsérvese que, para completar esta actividad, bastará con elegir una de las que engloba. En realidad, en el método de aprendizaje se incluirán condiciones que asegurarán que únicamente una de éstas sea visible, dependiendo de la nota obtenida en el test. § Realización Repaso, que engloba las tres actividades básicas de repaso contempladas. Figura 2.6.9.d. Nuevas actividades estructuradas que aparecen en UACata2. ..Actividad Estructurada (tipo secuencia) ....Título: Autoaprendizaje con repaso ....Actividad de aprendizaje (referencia): Lectura Libro Corbinus ....Actividad estructurada (referencia): Autoaprendizaje ..Actividad Estructurada (tipo selección, número de actividades a seleccionar=1) ....Título: Autoaprendizajes ....Actividad estructurada (referencia): Autoaprendizaje con repaso ....Actividad estructurada (referencia): Autoaprendizaje ..Actividad Estructurada (tipo selección, número de actividades a seleccionar=3) ....Título: Realización Repaso ....Actividad de aprendizaje (referencia): Repaso Libro Corbinus ....Actividad de aprendizaje (referencia): Repaso Artículo Birra ....Actividad de aprendizaje (referencia): Repaso Sitio Web La Figura 2.6.9.e esquematiza cómo se modifican los actos del método de UACata1 en el contexto del nuevo diseño: § Se añaden nuevos actos orientados a la realización y corrección del test (test previo y corrección test previo). 81 Figura 2.6.9.e. Modificación y extensión de los actos. ........................ ....Acto ......Título: test previo ......Actuación ........Título: Actuación test previo ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): Realización de test ......Condición de finalización: <finalizada Actuación test previo> ....Acto ......Título: corrección test previo ......Actuación ........Título: Actuación corrección test previo ........Rol(referencia): <referencia a Profesor del seminario> ........Actividad(referencia): Corrección de test ......Condición de finalización: <finalizada Actuación corrección test previo> ....Acto ......Título: período autoaprendizaje ......Actuación ........Título: Actuación autoaprendizaje ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Autoaprendizajes> ......Condición de finalización: <finalizada Actuación autoaprendizaje> ........................ ....Acto ......Título: repaso ......Actuación ........Título: Actuación repaso ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Realización Repaso> ......Condición de finalización: <finalizada Actuación repaso> ....Acto ......Título: revisión ......Actuación ........Título: Actuación revisión ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Revisión y mejora del trabajo> ......Condición de finalización: <finalizada Actuación revisión> ....Acto ......Título: re-evaluación ......Actuación ........Título: Actuación re-evaluación ........Rol(referencia): <referencia a Profesor del seminario> ........Actividad(referencia): <referencia a Re-Evaluación del Trabajo> ......Condición de finalización: <finalizada Actuación re-evaluación> ....Acto ......Título: resultados2 ......Actuación ........Título: Actuación resultados2 ........Rol(referencia): <referencia a Alumno de nueva promoción> ........Actividad(referencia): <referencia a Consulta resultados de repesca> ......Condición de finalización: <finalizada Actuación resultados2> En este diseño es necesario, además, adaptar la ejecución dependiendo de los valores de las notas del test y del trabajo. Dicha adaptación se logra como sigue: 82 § Se incluyen condiciones que permiten adaptar el proceso de aprendizaje dependiendo de los resultados obtenidos en el test y en el trabajo (Figura 2.6.9.f). La primera de dichas condiciones comprueba el resultado del test. Si éste es menor que 5 oculta la actividad Autoaprendizaje. En otro caso (es igual o supera el 5), oculta la actividad Autoaprendizaje con repaso. Como aspecto sutil cabe destacar que, aunque cuando la nota es menor que 5 se oculta la actividad Autoaprendizaje, dicha actividad estructurada se hará visible una vez alcanzada la actividad Autoaprendizaje con repaso, ya que dicha actividad es una actividad de tipo secuencia y, por tanto, hace visibles a todas las actividades secuenciadas independientemente del efecto de las condiciones. La segunda de las condiciones determina la finalización de la asignatura. Para ello debe haberse superado el trabajo o bien debe haberse terminado la recuperación. § Se modifica la finalización del guión para que ésta dependa de que la asignatura haya finalizado (Figura 2.6.9.g). Figura 2.6.9.f. Condiciones para la adaptación del estilo de aprendizaje. ..Condiciones .....si .......menor ............propiedad(referencia): <referencia a propiedad nota en el test> ............valor: 5 ........entonces ............ocultar: <referencia a actividad Autoaprendizaje> ........en otro caso ............ocultar: <referencia a actividad Autoaprendizaje con repaso> .....si ........o ..........o ............mayor ..............propiedad(referencia): <referencia a nota en el trabajo> ..............valor: 5 ............es ..............propiedad(referencia): <referencia a nota en el trabajo> ..............valor: 5 ........ es ...............propiedad(referencia): <referencia a finalizada recuperación> ................valor: Cierto .....entonces ...........fijar asignatura superada a cierto Figura 2.6.9.g. Condición de finalización del guión. Método ..Guión ........................ ....Condición de finalización ......fijada propiedad asignatura superada a cierto Nótese que en este método no se especifica en ningún lugar dónde se actualizan las propiedades nota en el test y nota en el trabajo. Dicha actualización dependerá del entorno de ejecución del diseño. Por ejemplo, el reproductor podrá ofrecer a usuarios 83 con suficiente privilegio la posibilidad de modificar los valores de las propiedades de otros usuarios. De esta forma, el profesor podrá fijar las notas de cada uno de sus alumnos durante las respectivas actividades de soporte. Del mismo modo, dependiendo del grado de integración de los materiales con el entorno de ejecución, la actualización de algunas propiedades podría llevarse a cabo automáticamente (v.g. como resultado de la corrección automática del test: en este caso, la actividad de soporte Corrección del test no sería necesaria). 2.7. EL NIVEL C El nivel C añade un mecanismo que permite el envío de mensajes y la configuración de actividades dependiendo de la ocurrencia de determinados eventos. Dicho mecanismo está soportado por notificaciones e introduce un paradigma de ejecución guiado por eventos en IMS LD. Utilizando este mecanismo es posible, por ejemplo, hacer que se envíe un mensaje al profesor cada vez que un alumno concreto termine de realizar un trabajo. 2.7.1. Notificaciones La Figura 2.7.1.a esquematiza la estructura de la descripción de una notificación. Figura 2.7.1.a. Estructura de la especificación de las notificaciones. Dirigida a Notificación 0..1 Actividad (referencia) 0..1 Asunto De esta forma, la notificación incluye: § Una identificación del o los destinatarios a los que se dirige la notificación. Dicha identificación pueden realizarse: (1) indicando un rol, de tal forma que la identificación se dirigirá a todos los usuarios de dicho rol, (2) una referencia a una propiedad que contiene el e-mail del usuario concreto al que se dirige la notificación y, opcionalmente, una propiedad que contiene el nombre de dicho usuario. § Opcionalmente, una referencia a una actividad simple (de aprendizaje o de soporte). En el contenido de la notificación se incluirá un enlace a dicha actividad, que pasará a ser visible si no lo era ya. § Opcionalmente, un campo de asunto con la descripción de la notificación. 84 2.7.2. Extensiones en IMS LD nivel C La inclusión de notificaciones afecta a: § Las acciones de finalización de actividades, actos, guiones y unidades, que pueden incluir ahora múltiples notificaciones. § La parte de acción de las condiciones, que pueden incluir también notificaciones. § Los elementos globales, que pueden lanzar también notificaciones. 2.7.3. Ejemplo de diseño de nivel C En este apartado se utilizará el mecanismo de notificaciones para mejorar el diseño de la unidad de aprendizaje UACata2. El objetivo es que cada vez que un alumno termine el trabajo, se envíe a Corbinus una notificación a fin de que pueda corregirlo. El diseño resultante se integrará en la unidad de aprendizaje UACata3. Para obtener el diseño educativo de UACata3, el primer paso es modificar ligeramente el método de UACata2 para que las actividades Evaluación del trabajo y Revaluación del trabajo se realicen en los mismos actos que las actividades Realización del trabajo y Revisión y mejora del trabajo (en otro caso, el comienzo de las mismas dependería de la finalización de las actividades de realización y revisión de trabajos por parte de todos los alumnos). La Figura 2.7.3.a esboza la modificación. 85 Figura 2.7.3.a. En UACata3 el acto trabajo puede fundirse con el acto corrección, y el acto revisión con revaluación. ........................ ....Acto ......Título: trabajo y corrección ......Actuación ........Título: Actuación trabajo ........Rol(referencia): <referencia a Alumno nueva promoción> ........Actividad(referencia): <referencia a Realización Trabajo> ......Actuación ........Título: Actuación corrección ........Rol(referencia): <referencia a Profesor de seminario> ........Actividad(referencia): <referencia a Corrección de Trabajo> ......Condición de finalización: <finalizada Actuación corrección> ........................ ....Acto ......Título: revisión y re-evaluación ......Actuación ........Título: Actuación revisión ........Rol(referencia): <referencia a Alumno nueva promoción> ........Actividad(referencia): <referencia a Revisión y mejora del trabajo> ......Actuación ........Título: Actuación re-evaluación ........Rol(referencia): <referencia a Profesor de seminario> ........Actividad(referencia): <referencia a Re-Evaluación del Trabajo> ......Condición de finalización: <finalizada Actuación re-evaluación> El segundo paso consiste, simplemente, en incluir notificaciones en las acciones de finalización de las actividades Realización del trabajo y Revisión y mejora del trabajo (también es necesario dejar que sea el alumno el que decida la terminación de estas actividades). Dichas notificaciones irán dirigidas a los miembros del rol profesor del seminario y portarán un enlace a la correspondiente actividad de corrección. La Figura 2.7.3.b esboza estas extensiones. 86 Figura 2.7.3.b. Modificaciones de las actividades Realización del Trabajo y Revisión y Mejora del Trabajo para permitir que se notifique al profesor del seminario cada vez que se finalicen dichas actividades. ........................ ..Actividad de Aprendizaje ....Título: Realización Trabajo ....Entorno: <referencia a entorno Espacio de Archivos> ....Descripción: <referencia a recurso rdrealtrabajo> ....Condición de finalización: decidida por el usuario .... Acción de finalización ......Notificación ........dirigida a: rol <referencia a rol profesor de seminario> ........actividad (referencia): <referencia a actividad Corrección de Trabajo> ........................ ..Actividad de Aprendizaje ....Título: Revisión y mejora del trabajo ....Entorno: <referencia a entorno Espacio de Archivos> ....Descripción: <referencia a recurso rdrealtrabajo> ....Condición de finalización: decidida por el usuario .... Acción de finalización ......Notificación ........dirigida a: rol <referencia a rol profesor de seminario> ........actividad (referencia): <referencia a actividad Re-evaluación de Trabajo> 2.8. CODIFICACIÓN EN XML DE DISEÑOS EDUCATIVOS IMS LD utiliza XML para definir un lenguaje de marcado específico que permite describir los diseños educativos. De esta forma, las estructuras descritas informalmente en las secciones anteriores tienen una representación formalizada en XML, representación que puede ser procesada automáticamente por las herramientas de edición y reproducción de diseños educativos. En este apartado se describen los distintos tipos de elementos (las etiquetas) introducidos por dicho lenguaje y se ejemplifica su uso con el caso de estudio. 2.8.1. Codificación de la Estructura de Alto nivel del Diseño La descripción del diseño se encierra en un elemento learning-design. Dicho elemento tiene los siguientes atributos: § identifier. Atributo obligatorio que identifica unívocamente el elemento en el contexto del manifiesto de la unidad de aprendizaje. § version. Atributo opcional que indica el número de versión de IMS LD. § uri. Atributo obligatorio que asocia una URI al diseño (un identificador globalmente único). 87 § level. Atributo opcional que indica el nivel de IMS LD utilizado en el diseño (su valor puede ser A, B, C, a, b, c). § sequence-used. Atributo obligatorio que, en caso de ser true, permite utilizar IMS Simple Sequencing (IMS SS, 2003) como mecanismo de secuenciamiento en lugar de IMS LD. El título del diseño se encierra en un elemento title. Los objetivos de aprendizaje se encierran en un elemento learning-objectives. Los prerrequisitos se encierran en un elemento prerequisites. El contenido de estos dos elementos, que identifica un recurso que describe los objetivos y prerrequisitos, se describe mediante los siguientes elementos: § title. Elemento opcional, que encierra un título descriptivo. § Una o más ocurrencias de item. Elemento que, a su vez, sigue el formato especificado en IMS CP, y que permite referir a un recurso descriptivo del objetivo o del prerrequisito (IMS CP, 2004). § metadata. Elemento de metadatos opcional. Los componentes se describen mediante un elemento components. El método se describe mediante un elemento method. Los metadatos se encierran en un elemento metadata. La Figura 2.8.1.a esboza la codificación XML de la estructura de alto nivel del diseño para UACata1. Los identificadores han sido creados automáticamente utilizando una herramienta de autoría como las que se describirán en el capítulo dedicado a herramientas. Se ha añadido tambien una sección de objetivos de aprendizaje y de prerrequisitos para que se aprecie su codificación. Obsérvese que en el paquete IMS deberá haber sendos recursos identificados mediante robjetivoscurso y rprerequisitoscurso. 88 Figura 2.8.1.a. Codificación XML de la estructura de alto nivel del diseño de UACata1. <learning-design identifier="ld-1e523a0b-dcad-c0a7-d07b-9d7e52fe65fb" level="A" sequence-used="false" uri="http://www.cnice.mec.es/uri/ld-1e523a0b-dcad-c0a7-d07b-9d7e52fe65fb"> <title>Seminario de introducción a la cata</title> <learning-objectives> <title>Objetivos del curso</title> <item identifier="item-79b4a276-a911-444e-35fc-c0f8cf2db93e" identifierref="robjetivoscurso" isvisible="true" /> </learning-objectives> <prerequisites> <title>Prerequisitos del curso</title> <item identifier="item-784a1745-bb1f-5e86-1e2a-9102cb31082c" identifierref="rprerequisitoscurso" isvisible="true" /> </prerequisites> <components> ... </components> <method> ... </method> </learning-design> 2.8.2. Codificación de los roles La descripción de los roles se delimita con un elemento roles. Dicho elemento contempla los siguientes atributos: § identifier. Atributo obligatorio que identifica unívocamente el rol. En el interior de este elemento, los roles de tipo aprendiz se marcan con el elemento learner, mientras que los de tipo plantilla se marcan con staff. Ambos elementos contemplan los siguientes atributos: § create-new. Atributo obligatorio que indica si es o no posible asociar múltiples usuarios con este rol cuando se ejecuta la unidad de aprendizaje. Si el valor es not-allowed, únicamente se permitirá asociar un actor con dicho rol. Si no, es posible asociar varios. § href. Atributo opcional que asocia una URI con el rol, que permite identificar el rol como uno global definido a nivel institucional (v.g. un rol definido en un instituto). § identifier. Atributo obligatorio que identifica unívocamente al rol en el manifiesto. § match-persons. Atributo opcional que, en caso de existir varios subroles, permite decidir si el mismo usuario deberá asociarse de forma exclusiva a 89 uno de los subroles (valor exclusively-in-roles) o bien si puede asociarse de manera no exclusiva a los distintos subroles (valor notexclusively). § min-persons.Atributo opcional que indica el mínimo número de integrantes del rol. Si no está presente, se supone que el mínimo número de integrantes es 0. § max-persons. Atributo opcional que indica el máximo número de integrantes del rol. Si no está presente, se supone que el máximo número de integrantes no está limitado. El contenido de estos elementos contiene un elemento title opcional (con el título del rol), un elemento information opcional (que hace referencia a recursos que detallan el rol, mediante elementos title, item y metadata, al estilo de learning-objectives y prerequisites), una secuencia de 0 o más elementos describiendo los subroles (de nuevo con learner o staff, dependiendo del tipo de rol) y un elemento opcional metadata. La Figura 2.8.2.a esboza la codificación XML de los roles para las unidades de aprendizaje de nuestro caso de estudio. Los identificadores también se han generado automáticamente con una herramienta de autor y se asume, además, que en el paquete IMS deberá haber recursos identificados con rrolAlumnoNuevaPromocion, rrolAlumnoPromocionesAntiguas y rrolProfesorDeSeminario. 90 Figura 2.8.2.a. Codificación XML de los roles en las unidades de aprendizaje del caso de estudio. <roles> <learner identifier="role-512dc775-0d84-9461-bf67-0ca1a23b8907" create-new="allowed"> <title>Alumno de nueva promoción</title> <information> <item identifier="item-bcd3d171-72ad-7472-a49e-e1b9516f23fa" identifierref="rrolAlumnoNuevaPromocion" isvisible="true" /> </information> </learner> <learner identifier="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5" create-new="allowed"> <title>Alumno de promociones antiguas</title> <information> <item identifier="item-f1f510c6-ad57-277d-3332-068a5de3cf9a" create-new="allowed" identifierref="rrolAlumnoPromocionesAntiguas" isvisible="true" /> </information> </learner> <staff identifier="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" create-new="allowed"min-persons="1" max-persons="1"> <title>Profesor de seminario</title> <information> <item identifier="item-a9cd7404-186b-1f5d-2470-b650c126e5a4" identifierref="rrolProfesorDeSeminario" isvisible="true" /> </information> </staff> </roles> 2.8.3. Codificación de las actividades La descripción de las actividades se delimita con un elemento activities. Dentro de dicho elemento, cada actividad de aprendizaje se delimita mediante un elemento learning-activity, cada actividad de soporte mediante support-activity y cada actividad estructurada mediante activity-structure. Los elementos learning-activity contemplan los siguientes atributos: § identifier. Atributo obligatorio que identifica unívocamente al elemento en el manifiesto. § isvisible. Atributo obligatorio que permite controlar la visibilidad inicial de la actividad (si vale true la actividad será visible, si vale false será invisible). § parameters. Atributo opcional que permite especificar una lista de parámetros, en caso de que dicha lista se precise para lanzar la actividad. Asimismo, en la descripción el título se encierra en un elemento title, los objetivos de aprendizaje en un elemento learning-objectives, los prerrequisitos en un elemento prerrequisites, los entornos se referencian mediante elementos 91 environment-ref (estos elementos tienen un atributo ref que permite referir al entorno por su identificador único), la descripción de la actividad mediante un elemento activity-description (utilizando los ya familiares elementos title, item y metadata), la condición de finalización con un elemento complete-activity, la acción de finalización con un elemento on-completion y los metadatos asociados con un elemento metadata. Los elementos complete-activity pueden, a su vez, encerrar un elemento vacío user-choice (que indica que la finalización es decisión del usuario), un elemento time-limit (que indica la duración de la actividad de forma relativa al comienzo de la ejecución de la actividad, bien directamente, como contenido del elemento, bien haciendo referencia a una propiedad local que debe contener dicho valor, a través del atributo property-ref), o, a nivel B, un elemento when-property-value-is-set (que supedita la finalización a que una propiedad alcance un valor dado). El contenido de este último elemento se describirá mediante un elemento property-ref (este elemento tiene un atributo ref que refiere la propiedad por su nombre), así como mediante un elemento property-value, que indicará el valor que debe alcanzar la propiedad para que se cumpla la condición de finalización. Dicho valor puede indicarse de manera literal (delimitado el valor literal con un elemento langstring), mediante una expresión delimitada con calculate, o como el valor de otra propiedad, referida mediante otro elemento property-ref. Figura 2.8.3.a. Codificación XML de la actividad de aprendizaje Lectura Artículo Birra. <learning-activity identifier="la-53a23357-d67b-1991-d0bd-5751cfbc92f8" isvisible="true"> <title>Lectura Articulo Birra</title> <environment-ref ref="env-d2465bb9-5a4b-1b11-5897-70191e2de62b" /> <activity-description> <title>Descripcion</title> <item identifier="i tem-0e113665-6501-358a-7453-84c925ff020c" identifierref="rdalectartbirra" isvisible="true" /> </activity-description> <complete-activity> <time-limit>P1D</time-limit> <!— codificación de duración de un 1 día --> </complete-activity> </learning-activity> Por su parte, los elementos on-completion pueden encerrar un elemento feedback-description (proporciona realimentación al usuario, realimentación que se describe mediante la típica secuencia de elementos title, item y metadata). A nivel B, también puede encerrar la descripción del cambio de valor de una propiedad mediante un elemento change-property-value. El contenido de change-property-value es análogo al de property-value, aunque, por supuesto, la semántica difiere (ahora consiste en actualizar la propiedad referida al valor indicado). A nivel C puede encerrar también una notificación. La estructura de los elementos support-activity es análoga a la de los elementos learning-activity, salvo que también pueden incluir las referencias a los roles 92 soportados. Dichas referencias se marcan con role-ref, elemento que tiene un atributo obligatorio ref que refiere al rol soportado nombrando el identificador único de dicho rol. Por último, los elementos activity-structure atributos: contemplan los siguientes § identifier. Atributo obligatorio que identifica unívocamente al elemento en el manifiesto. § structure-type. Atributo opcional que indica el tipo de la actividad estructurada (sequence, para las actividades tipo secuencia y selection, para las actividades tipo selección). § number-to-select. Atributo que para las actividades de tipo selección permite indicar el número de actividades constituyentes que tienen que completarse para que la actividad total esté completada. § sort. Atributo opcional que determina el orden en el que las actividades constituyentes aparecen en la bandeja del usuario. Si vale as-is (valor por defecto) las actividades se ordenarán según aparecen en la estructura. Si vale visibility-order las actividades se ordenan por el momento en el que se han hecho visibles. Figura 2.8.3.b. Codificación XML de la actividad de soporte Corrección de trabajo. <support-activity identifier="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c" isvisible="true"> <title>Corrección de trabajo</title> <role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <environment-ref ref="env-123ba1c8-a943-8f96-59ba-c42365f43778" /> <environment-ref ref="env-8ddee08c-f267-253b-4ffa-c9836fed5f35" /> <activity-description> <item identifier ="item-355b4f47-3add-8e39-9bc1-9499ec873be6" identifierref="rdacorrtrabajo" isvisible="true" /> </activity-description> <complete-activity> <user-choice /> </complete-activity> </support-activity> En la descripción de las actividades estructuradas el título se marca mediante un elemento title, su descripción mediante un elemento information, la referencia a los entornos mediante environment-ref, las actividades refereridas mediante elementos de referencia apropiados y los metadatos mediante metadata. Los elementos de referencia a las actividades dependen del tipo de las mismas y todos ellos incluyen un atributo ref que permite referir a las actividades constituyentes por su identificador. Las actividades de aprendizaje se refieren mediante elementos learning-activity-ref, las actividades de soporte mediante 93 support-activity-ref, activity-structure-ref. y las estructuradas mediante Figura 2.8.3.c. Codificación XML de la actividad estructurada Examen Materiales. <activity-structure identifier="as-9c621522-af53-d875-81ab-741cd3097e39" structure-type="selection"> <title>Examen materiales</title> <learning-activity-ref ref="la-53a23357-d67b-1991-d0bd-5751cfbc92f8" /> <learning-activity-ref ref="la-2147820d-22b0-25ff-4387-65d7cc7d5e26" /> <learning-activity-ref ref="la-c04f2483-5479-b250-e031-5798d2923a94" /> </activity-structure> La Figuras 2.8.3.a, la Figura 2.8.3.b y la Figura 2.8.3.c esbozan la codificación XML de: (i) la actividad de aprendizaje Lectura Artículo Birra, (ii) la actividad de soporte Corrección de Trabajo y (iii) la actividad estructurada Examen Materiales. Al igual que en los puntos anteriores, los identificadores también se han generado automáticamente y se asume que en el paquete IMS deberán estar los recursos referidos desde la codificación. 2.8.4. Codificación de los entornos Los entornos se delimitan mediante environments. Cada entorno en sí se delimita con environment, elemento que puede exhibir los siguientes atributos: § identifier. Atributo obligatorio que identifica unívocamente al elemento en el manifiesto. El título del entorno se delimita con title. Cada objeto de aprendizaje se delimita mediante learning-object. Este elemento contempla los siguientes atributos: § class. Atributo opcional que etiqueta el objeto de aprendizaje con una clase o conjunto de clases, en el sentido de HTML 4.0 o XHTML. § identifier. Atributo obligatorio que identifica unívocamente al elemento en el manifiesto. § isvisible. Atributo obligatorio que determina la visibilidad o invisibilidad del entorno. § parameters. Atributo opcional con los parámetros requeridos para activar el entorno. § type. Atributo opcional que determina el tipo de objeto de aprendizaje. La estructura de dicho elemento puede seguir el patrón ya familiar title – item – metadata para referir los materiales del objeto de aprendizaje, aunque IMS LD contempla también el uso de cualquier otro formato de descripción de objetos de aprendizaje, mediante el uso de un vocabulario XML adecuado. 94 Por su parte, cada servicio se delimita mediante un elemento service. Dicho elemento acepta atributos class, identifier, isvisible and parameters análogos a los de learning-object. Igualmente, para describir cada tipo de servicio se incluye un vocabulario de marcado adecuado (dicho vocabulario se omitirá aquí por simplicidad, relegando al lector interesado a la especificación, aunque sí se dará un ejemplo de descripción de servicio). La Figura 2.8.4.a muestra la descripción del entorno Artículo Birra, que ilustra el uso de un objeto de aprendizaje en un entorno. Por su parte, en la Figura 2.8.4.b ejemplificamos la prometida descripción de un servicio (en este caso, servicio de conferencia), en el contexto del entorno Servicio Debate. Aunque los identificadores y referencias a identificadores han sido generados automáticamente, el lector puede comprobar cómo los participantes, gestor de la charla y moderador se corresponden con los distintos roles introducidos en la Figura 2.8.2.a. Figura 2.8.4.a. Codificación XML del entorno Artículo Birra. <environment identifier="env-d2465bb9-5a4b-1b11-5897-70191e2de62b"> <title>Articulo Birra</title> <learning-object identifier="lo-b6fa59c3-74f7-f4c7-484e-2fb290ee54cc" isvisible="true"> <title>articulo</title> <item identifier="item-16543567-5502-d539-034b-4a8e72c5ad4b" identifierref="rarticulobirra" isvisible="true" /> </learning-object> </environment> Figura 2.8.4.b. Codificación XML del entorno Servicio Debate. <environment identifier="env-083026bb-1a97-7ecf-63ef-8d772b7a2f99"> <title>Servicio Debate</title> <service identifier="service-bf953b45-c770-2c1e-c844-d424e1c8384a" isvisible="true"> <conference conference-type="synchronous"> <title>chat</title> <participant role-ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <participant role-ref="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5" /> <observer role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> <conference-manager role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> <moderator role-ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> </conference> </service> </environment> 2.8.5. Codificación de los métodos Los métodos se limitan con elementos de tipo method. Cada guión se marca mediante play. La condición de finalización del método (y por tanto, de la unidad de 95 aprendizaje) se marca mediante complete-unit-of-learning. El contenido de este elemento puede ser de alguno de los tipos siguientes: § Elemento when-play-completed. Este elemento hace referencia, a través de un atributo ref, al guión que ha de completarse para considerar que la unidad de aprendizaje ha terminado. § Elemento time-limit. Al igual que en las actividades, este elemento permite especificar un tiempo máximo, transcurrido el cual la unidad se considerará terminada. § Elemento when-property-value-is-set, que, con sentido y uso análogo al de las actividades, permite supeditar el final de un método a que una propiedad tome un determinado valor. Además, la acción a realizar tras la finalización del método se marca con oncompletion. La estructura es análoga a la ya descrita para las actividades. Cada elemento play puede tener asociado un identificador opcional (atributo identifier), así como un atributo isvisible obligatorio, que determina la visibilidad del guión. Asimismo, dentro de este tipo de elementos es posible utilizar los siguientes: § Elemento title para marcar el título del guión. § Elementos act para describir los actos § Elemento complete-play para describir la condición de finalización. Dicha condición puede indicarse con un elemento when-last-actcompleted para indicar que el guión termina cuando termine su último acto, con time-limit, o con when-property-value-is-set. § Elemento on-completion para describir la acción realizada tras la finalización. La estructura es análoga a la de las actividades y guiones. § Elemento metadata para delimitar el cuerpo de metadatos asociado al guión. Por su parte, los actos pueden exhibir también identificadores opcionales (atributo identifier), así como encerrar los siguientes tipos de elementos: § Elemento title con el título del acto. § Elementos role-part con cada actuación del acto. § Elemento complete-act con la condición de finalización. Dicha condición puede describirse como when-role-part-completed (elemento que, a través del atributo ref, hará referencia a la actuación que debe terminar para considerar el acto finalizado). También pueden usarse los ya familiares time-limit o when-property-value-is-set. § Elemento on-completion indicando la acción de finalización. La estructrura es análoga a la ya descrita para los otros elementos. 96 § Elemento metadata con los metadatos asociados. Por último, las actuaciones también pueden tener un identificador opcional (atributo identifier). Su contenido incluye: § Un título (elemento title). § El rol que participa en la actuación. Dicho rol se refiere mediante el atributo ref de un elemento role-ref. § La actividad que debe llevarse a cabo se refiere mediante learningactivity-ref (en caso de tratarse de una actividad de aprendizaje), support-activity-ref (en caso de tratarse de una actividad de soporte) o activity-structure-ref (en caso de ser una actividad estructurada). La referencia en sí se realiza mediante un atributo ref en el elemento correspondiente. IMS LD permite también referir directamente un entorno (a través de environment-ref) para abreviar actividades de aprendizaje muy simples que involucran únicamente el entorno referido. § Como es habitual, también es posible asociar metadatos con la actuación, mediante metadata. La Figura 2.8.5.a ilustra la codificación en XML del método para la unidad de aprendizaje UACata1 (método que fue descrito más informalmente en la Figura 2.5.5.d). 97 Figura 2.8.5.a. Codificación XML del método de UCata1. <method> <play identifier="play-d746ba58-9a56-0da7-b40e-ae1713641291" isvisible="true"> <title>Play</title> <act identifier="act-aabc540f-3d3c-a6a5-1384-bcd0d61b3c88"> <title>clase presencial</title> <role-part identifier="rolepart-d8aa496c-7152-453d-e9dc-f0d35cbbf9f6"> <title>Actuacion Imparticion</title> <role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> <learning-activity-ref ref="la-fb255f1c-cd59-208e-85c7-5f7820a0fb4f" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-d8aa496c-7152-453d-e9dc-f0d35cbbf9f6" /> </complete-act> </act> <act identifier="act-bee7ffd0-d092-0696-0b26-1108811b5f8f"> <title>periodo autoaprendizaje</title> <role-part identifier="rolepart-ab90c945-6918-d9b6-0945-c52afff5832b"> <title>actuacion autoaprendizaje</title> <role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <activity-structure-ref ref="as-b65b7cf6-6438-e9ca-ca41-f502a4a67133" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-ab90c945-6918-d9b6-0945-c52afff5832b" /> </complete-act> </act> <act identifier="act-5bbbfa6f-2c25-fdac-0046-1ef6a2e73a78"> <title>discusion</title> <role-part identifier="rolepart-512ead89-fb94-5a95-92da-21ebddc611b9"> <title>actuacion debate alumno nuevo</title> <role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" /> </role-part> <role-part identifier="rolepart-5da960cb-e0f0-05b5-66a8-8a91b2f464c5"> <title>actuacion debate alumno antiguo</title> <role-ref ref="role-605a48b5-9bb4-f0b2-5dfb-f74b59371fd5" /> <learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" /> </role-part> <role-part identifier="rolepart-aa5d278f-dd14-fa23-dcf2-d6ffe28c9f11"> <title>actuacion debate profesor</title> <role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> <learning-activity-ref ref="la-d52c0495-1687-a65a-3888-f4167abfe3fa" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-aa5d278f-dd14-fa23-dcf2-d6ffe28c9f11" /> </complete-act> </act> <act identifier="act-58133d9e-fd08-8055-a6e0-01838c03eed0"> <title>trabajo</title> <role-part identifier="rolepart-af8aaf22-a6f7-2420-813a-2c047718e38d"> <title>actuacion trabajo</title> <role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <learning-activity-ref ref="la-75c7788b-cc11-3db6-a881-921c5d214ed6" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-af8aaf22-a6f7-2420-813a-2c047718e38d" /> </complete-act> </act> <act identifier="act-bef87d0c-6b22-a464-6dd9-fce61033727f"> <title>evaluacion</title> <role-part identifier="rolepart-768cf77c-40c9-27ae-0b06-e211659cc04c"> <title>actuacion evaluacion</title> <role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> <support-activity-ref ref="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-768cf77c-40c9-27ae-0b06-e211659cc04c" /> </complete-act> </act> <act identifier="act-91023aab-d4e0-4762-e80c-0967b8a3d339"> <title>resultados</title> <role-part identifier="rolepart-60876a2e-371d-ebcc-f456-aa7997a5ee5b"> <title>Actuacion resultados</title> <role-ref ref="role-512dc775-0d84-9461-bf67-0ca1a23b8907" /> <learning-activity-ref ref="la-c8f0184c-bb4e-9241-b104-35add9ba30e3" /> </role-part> <complete-act> <when-role-part-completed ref="rolepart-60876a2e-371d-ebcc-f456-aa7997a5ee5b" /> </complete-act> </act> <complete-play> <when-last-act-completed /> </complete-play> </play> <complete-unit-of-learning> <when-play-completed ref="play-d746ba58-9a56-0da7-b40e-ae1713641291" /> </complete-unit-of-learning> </method> 98 2.8.6. Codificación de las propiedades Las propiedades se delimitan mediante un elemento properties. La descripción de cada propiedad en sí depende de su tipo: § Las propiedades locales generales se marcan mediante loc-property. § Las propiedades locales personales se marcan mediante locpersproperty. § Las propiedades locales de rol se marcan mediante locrole-property. § Las propiedades globales generales se marcan como glob-property. § Las propiedades globales personales se marcan como globpersproperty. Todos estos elementos tienen un identificador único (atributo identifier). Los elementos loc-property, locpers-property y locrole-property contienen, a su vez, los siguientes: § title. Elemento opcional que delimita el título de la propiedad. § role-ref (únicamente para locrole-property). Elemento obligatorio que refiere a través de un atributo ref al rol al que se refiere la propiedad local del rol. § datatype. Elemento obligatorio que determina el tipo (el formato de los posibles valores) de la propiedad. Dicho elemento posee un atributo también llamado datatype que permite determinar el citado tipo. El tipo puede ser: boolean (el valor de la propiedad ha de ser un valor lógico: true –cierto- o false –falso-), integer (valor número entero), real (valor número real), string (valor cadena de caracteres), duration (valor duración temporal), text (valor texto), uri (valor dirección web) o other (valor de tipo no especificado). § initial-value. Valor inicial de la propiedad (si no se especifica, el valor inicial es <no value>). § restriction. Este elemento, que puede ocurrir cero o más veces, constriñe el posible rango de valores que puede adoptar la propiedad. Para ello utiliza el atributo restriction-type, así como los convenios de descripción de restricciones de valores introducidos por la especificación XML Schema (véase XML Schema, 2004). § metadata. Metadatos asociados con la propiedad. Por su parte, globpers-property y glob-property pueden contener, bien un elemento existing, bien un elemento global-definition: § El elemento existing permite referir una propiedad global ya declarada en otra unidad de aprendizaje. Para ello utiliza un atributo href. Esto 99 permite introducir en un diseño educativo propiedades globales ya declaradas en otros. § El elemento global-definition permite definir una propiedad global en sí. Esta propiedad podrá entonces referirse desde otros diseños mediante elementos existing. El contenido de global-definition en sí viene dado por los elementos title, datatype, initial-value, restriction y metadata ya descritos anteriormente en relación con las propiedades locales. Por último, IMS LD también permite agrupar propiedades en grupos, a fin de permitir su edición conjunta (por ejemplo, a través de un formulario). Para ello las propiedades pueden agruparse mediante el elemento property-group. Dicho elemento tiene un identificador único (atributo identifier). Además, pueden contener los siguientes elementos: § title. Opcional. Título del grupo. § property-ref. Múltiples ocurrencias. Refiere a una propiedad que se incluye en el grupo (a través del atributo ref). § property-group-ref. Múltiples ocurrencias. Refiere a un grupo de propiedades que se incluye en el grupo (a través del atributo ref). La Figura 2.8.6.a ilustra la codificación en XML de las propiedades para la unidad de aprendizaje UACata2. Figura 2.8.6.a. Codificación XML de las propiedades de la actividad UACata2. <properties> <locpers-property identifier="prop-94680282-98c1-eae2-1836-ce7142ccb065"> <title>nota en el test</title> <datatype datatype="integer" /> </locpers-property> <locpers-property identifier="prop-19d3a408-8be8-c70f-58a9-05e385d4d1f3"> <title>nota en el trabajo</title> <datatype datatype="integer" /> </locpers-property> <locpers-property identifier="prop-63135b88-e236-6e85-709b-231f6be36808"> <title>recuperación finalizada</title> <datatype datatype="boolean" /> <initial-value>false</initial-value> </locpers-property> <locpers-property identifier="prop-5e3513ed-6eef-5a85-fdcc-617f9c14a551"> <title>asignatura superada</title> <datatype datatype="boolean" /> <initial-value>false</initial-value> </locpers-property> </properties> 100 2.8.7. Codificación de las expresiones, acciones y condiciones La codificación de las expresiones introducidas por IMS LD nivel B es como sigue: § Las expresiones “es miembro de rol” se codifican mediante elementos ismember-of-role. Estos elementos refieren el rol en cuestión mediante un atributo ref. § Las expresiones “es” se codifican mediante elementos is delimitando los dos operandos involucrados. § Las expresiones “no es” se codifican mediante elementos not-is que delimitan los dos operandos involucrados. § Las expresiones “y,” “o”, “suma”, “resta”, “mul”, “div”, “mayor que” , “menor que” y “no” se codifican respectivamente mediante elementos and, or, sum, substract, multiply, divide, greater-than, less-than, y not. § Las expresiones “usuarios en rol” se codifican mediante elementos usersin-role. El atributo role-ref refiere el rol al que se aplica la expresión, mientras que la expresión en sí aparece como hija del elemento. § Las expresiones “no valor” se codifican mediante no-value. § Las expresiones “inicio unidad” se codifican mediante time-unit-oflearning-started (mediante el atributo unit-of-learning-uri se refiere la unidad en sí), las de tipo “inicio actividad” mediante daytimeactivity-started (mediante el atributo ref se refiere la actividad) y las de tipo “día y hora” mediante current-datetime. § Las expresiones “finalizado” se codifican mediante elementos complete. Para referir el componente finalizado se usan alguno de los siguientes elementos: learning-activity-ref, support-activity-ref, unit-of-learning-href, activity-structure-ref, role-partref, act-ref o play-ref. En todos ellos se utiliza el atributo ref para realizar la referencia, excepto en unit-of-learning-href, donde se utiliza el atributo href con la dirección web de la unidad de aprendizaje referida. La Figura 2.8.7.a ejemplifica la codificación en XML de la primera de las condiciones esbozadas en la Figura 2.6.9.f. 101 Figura 2.8.7.a. Codificación XML de una condición. <conditions> <if> <less-than> <property-ref ref="prop-94680282-98c1-eae2-1836-ce7142ccb065" /> <property-value>5</property-value> </less-than> </if> <then> <hide> <activity-structure-ref ref="as-b65b7cf6-6438-e9ca-ca41-f502a4a67133" /> </hide> </then> <else> <hide> <activity-structure-ref ref="as-670cf498-d489-6adf-1dfb-a688cb00f6a3" /> </hide> </else> </conditions> En lo que se refiere a la codificación de las acciones: § La visualización de los componentes educativos o recursos se codifican mediante elementos show. La referencia al componente o recurso a visualizar se realiza mediante elementos hijo de los siguientes tipos: class, item-ref, environment-ref, learning-activity-ref, supportactivity-ref, activity-structure-ref, play-ref, unit-oflearning-href. En todos los elementos cuyo nombre termina por –ref se usa un atributo ref para realizar la referencia. En unit-oflearning-href se usa un atributo href. En class la referencia se lleva a cabo usando un atributo class. También es posible utilizar los atributos title y with-control para refinar la forma en la que se lleva a cabo la expansión y el colapso del componente. § La ocultación de los componentes o recursos se lleva a cabo mediante elementos hide. Las referencias se realizan en los mismos términos utilizados en show (elementos class, item-ref, environment-ref, etc). § El cambio del valor de propiedades se codifica mediante elementos change-property-value. Dentro de estos, mediante property-ref se refiere a la propiedad cuyo valor cambia (usando un atributo ref), y mediante property-value se delimita el nuevo valor que debe tomar la propiedad. Para ello es posible especificar un valor literal (delimitado mediante un elemento langstring), referir a otra propiedad (elemento property-ref) o especificar una expresión que debe utilizarse para llevar a cabo el cálculo (elemento calculate). Por último, las condiciones se delimitan mediante un elemento conditions. Este elemento encierra un grupo de condiciones, que puede tener un título (elemento 102 title), así como un cuerpo de metadatos (elemento medatata). Cada condición en sí se describe mediante dos o tres elementos consecutivos: § El primero, elemento if, representa la parte “si”. § El segundo, elemento then, representa la parte “entonces”. § El tercero, elemento else, representa la parte “en otro caso”. 2.8.8. Codificación de elementos globales y servicio de monitorización IMS LD proporciona elementos globales para visualizar propiedades (viewproperty) y grupos de propiedades (view-property-group), así como para fijar el valor de propiedades (set-property) y de grupos de propiedades (set-propertygroup). Asimismo, proporciona un vocabulario de marcas para describir servicios de monitorización de propiedades (elemento monitor y su contenido). Dado que el uso de estas características es avanzado y radica (en el caso de los elementos globales) en características técnicas de las tecnologías XML, se dirige al lector interesado a la especificación. 2.8.9. Codificación de notificaciones Las notificaciones se codifican mediante elementos de tipo notification. Dichos elementos pueden contener, a su vez, los siguientes: § email-data. Utilizado para posibilitar la notificación a través de e-mail a distintos participantes. Este elemento incluye un atributo emailproperty-ref que hace referencia a una propiedad que debe contener la dirección del destinatario de la notificación. Por su parte, mediante username-property-ref puede referirse a una propiedad con el nombre de dicho destinatario. § role-ref. Elemento que permite seleccionar el papel objetivo de la notificación. § learning-activity-ref. Elemento que permite seleccionar la actividad de aprendizaje que se activará como resultado de la notificación. § support-activity-ref. Elemento que permite seleccionar la actividad de soporte que se activará como resultado de la notificación. La Figura 2.8.9.a muestra la codificación de la notificación provocada por la actividad Revisión y Mejora del Trabajo en la Figura 2.7.3.b 103 Figura 2.8.9.a. Codificación XML de una notificación. <notification> <email-data> <role-ref ref="role-9ce4bc12-db16-5b5d-9cd7-45eb627bc1e9" /> </email-data> <support-activity-ref ref="sa-5b39a593-bc0e-daf8-27e7-3cb500c4e25c" /> </notification> 3. IMS LEARNER INFORMATION PACKAGE 3.1. INTRODUCCIÓN La especificación Learner Information Package de IMS (de ahora en adelante, IMS LIP) permite el almacenamiento de información sobre los alumnos para su procesamiento, mantenimiento e interoperabilidad en distintos sistemas de gestión del aprendizaje (IMS Global Consortium, 2005). Partiendo de una estructura modular que permite su aplicación en distintos contextos, la especificación plantea un formato digital estándar para representar información relativa a todo el proceso de formación del alumno, incluyendo su historial educativo, experiencia profesional, calificaciones y certificados obtenidos, objetivos educativos y habilidades adquiridas. En este capítulo se detallan las características de la especificación IMS LIP. Para ello, se comienza describiendo una visión conceptual de la especificación, haciendo especial énfasis en su estructura modular. Tras esto, se presenta un caso de estudio sencillo consistente en el modelado de un Curriculum Vitae empleando los distintos elementos de la especificación. Este caso de ejemplo será empleado para ilustrar las principales características de la especificación. 3.2. VISIÓN CONCEPTUAL La idea de partida de la especificación es ofrecer un modelo de datos para almacenar los distintos datos de los alumnos que puedan ser relevantes para el proceso de aprendizaje. Dado que los posibles tipos de información son ricos y variados, los datos sobre el alumno pueden provenir desde fuentes distintas e incluso estar ubicados en sistemas de almacenamiento distintos. La especificación IMS LIP intenta maximizar su flexibilidad permitiendo que cada dato se guarde de manera aislada. En este contexto, un dato podría ser la información de contacto del alumno, un certificado de estudios obtenido anteriormente, una actividad educativa ya completada, un objetivo educativo a largo plazo, etc. Dada esta riqueza y variedad, cada dato se 104 describe como perteneciente a una determinada categoría (actividades educativas, calificaciones, etc.) tal y como se describe en la sección 3.2.1. Similarmente, cada dato del perfil del alumno puede tener asociada su propia sección de metadatos, cuya estructura se detalla en la sección 3.2.2. También cabe señalar que, aunque cada dato individual se describe por separado en una jerarquía plana, es posible establecer conexiones entre datos que estén relacionados. Este modelo de organización se refleja en la Figura 3.2.a. Figura 3.2.a. Visión conceptual de un documento LIP. Los distintos datos del alumno se guardan de manera independiente, pudiendo añadir metadatos o establecer relaciones entre ellos. Alumno 1 metadatos Dato 1 metadatos Dato 2 metadatos Dato 3 metadatos Dato n relación 3.2.1. Categorías de datos La especificación IMS LIP propone once tipos de datos o categorías para almacenar la información del alumno. La especificación sigue un criterio de flexibilidad y de permitir que las distintas organizaciones usen estas categorías según sus necesidades. No es necesario usar todas estas categorías al crear los perfiles de alumno, algunas categorías incluso se pueden usar con distintos fines. Un documento IMS LIP constará por tanto de una serie de bloques de información desconectados, cada uno de ellos perteneciente a alguna de las categorías que se describen a continuación. Datos Personales La sección identification incluye información sobre los alumnos. Esta información puede incluir datos personales (nombre, edad, género, información demográfica, etc.) o datos de contacto (dirección, teléfono, email, etc.). Accesibilidad Aunque el término accesibilidad se emplea habitualmente en el contexto de facilitar el acceso a personas con discapacidades, el apartado accessibility de IMS LIP describe una mayor variedad de características relativas a la capacidad del alumno para interactuar con los entornos de aprendizaje. Así, esta sección incluye información sobre las habilidades idiomáticas del alumno, sus preferencias acerca de formatos de presentación, sus características cognitivas o, finalmente, sus limitaciones físicas que 105 requieran un trato especial. Para este último caso, la última versión de la especificación IMS LIP no detalla mecanismos concretos para expresar información relativa a discapacidades, limitándose a indicar que la especificación IMS ACCLIP (IMS Global Consortium, 2003) deberá ser empleada para completar dicha sección tal y como se describe en la sección 3.4.8. Calificaciones, Certificados y Licencias Esta sección, denominada qcl (del inglés, Qualifications, Certificates and Licenses), incluye aquellas acreditaciones oficiales de su formación, como pueden ser títulos obtenidos, licencias otorgadas. La especificación indica que se deberá añadir una de estas secciones para cada título, incluyendo información de los mismos tal como la agencia emisora, la fecha de obtención y posiblemente, una versión digitalizada de los mismos. Actividades Las secciones de tipo activity describen todo tipo de actividades realizadas por el alumno relativas al proceso educativo o de formación. También se incluyen como actividades los servicios prestados (militar, voluntariado, etc.) y productos creados (como trabajos o documentos). Cada actividad (por ejemplo, una asignatura) puede acompañarse de la calificación o evaluación correspondiente, con la excepción de los premios oficiales, que deben incluirse en secciones qcl. Objetivos Los objetivos educativos y las aspiraciones de los alumnos se definen mediante secciones de tipo goal. Estas secciones pueden incluir, opcionalmente, información para la monitorización del progreso del alumno de cara a alcanzar dichos objetivos. Competencias Las secciones de tipo competency describen habilidades adquiridas por el alumno. Estas competencias pueden asociarse opcionalmente con elementos descritos en secciones qcl o activity, indicando que son el resultado de dichas certificaciones o actividades. En este caso, la versión actual de la especificación IMS LIP también queda abierta, indicando que deberán usarse las estructuras identificadas por el grupo de trabajo IMS Competency Definition. En la actualidad, este grupo de trabajo ha publicado ya la primera versión de la especificación IMS Reusable Definition of Competency or Educational Objective Specification (IMS Global Consortium, 2002), que posteriormente ha sido publicada como estándar por el Institute of Electrical and Electronics Engineers (IEEE) bajo el nombre Reusable Competency Definition (IEEE RCD). El capítulo 4 incluye una descripción detallada de esta nueva especificación. Intereses Las secciones de tipo interest describen aficiones u otras actividades recreativas practicadas por el alumno. Estas secciones pueden incluir productos asociados (como, por ejemplo, fotos) y los intereses también pueden asociarse con premios formales descritos en secciones qcl. Transcripciones Ciertas informaciones como, por ejemplo, un informe emitido por una entidad académica, no siguen una estructura fija. Para estos casos, las secciones de tipo transcript son las más flexibles al no forzar estructuras internas específicas. 106 Afiliaciones Las secciones de tipo affiliation almacenan información de las organizaciones a las que el alumno está o ha estado asociado. La información a incluir en estas secciones contempla datos sobre la organización en cuestión, sobre la duración de dicha afiliación y sobre el rol del alumno en la organización. Códigos de Seguridad Las secciones securitykey se emplean para guardar claves y contraseñas para su uso en la comunicación con el alumno. Relaciones Como se ha mencionado en las descripciones de las estructuras anteriores, en muchos casos determinados elementos de distintas secciones están relacionados. Así, una determinada actividad educativa definida en una sección activity (por ejemplo, completar un curso de formación profesional), puede estar relacionada con la obtención de un certificado oficial descrito en una sección qcl y suponer la adquisición de una serie de habilidades descritas en una sección competency. Las secciones de tipo relationship indican relaciones entre estos elementos definidos en secciones distintas. 3.2.2. Metadatos Tanto el documento principal como todas las secciones incluidas en el documento incluyen una serie de metadatos que aportan información sobre dicha sección. La información de estos bloques de metadatos se divide en tres bloques: Datos de identificación/referencia Información empleada para identificar el contenido de manera única dentro del documento, del entorno de enseñanza o de manera universal. La especificación no detalla los mecanismos a emplear para gestionar los identificadores únicos, dejando este aspecto en manos de las distintas implementaciones. Datos temporales Cada sección del documento puede tener información que describe su vigencia temporal. Esta información incluye, por ejemplo, el periodo de validez de cada información (por ejemplo, para indicar que una cierta licencia sólo es válida hasta una fecha determinada). Datos de privacidad Cada elemento del documento puede tener asociada información relativa a los permisos de acceso a la misma. Así, es posible indicar que determinadas informaciones (demográficas, por ejemplo) sólo son accesibles por el propio alumno, que otras informaciones sólo son accesibles por los instructores del propio sistema (y por tanto no deben ser incluidas en el documento si va a ser exportado) e indicar que otras informaciones son de dominio público. Es importante destacar que la especificación sólo provee mecanismos para indicar esta información. Es 107 responsabilidad de las distintas implementaciones asegurar la correcta gestión de los problemas de privacidad. 3.3. UN CASO DE ESTUDIO Fulanito Pérez es un licenciado en informática que, para mantener sus conocimientos actualizados, decide inscribirse en una serie de cursos online dirigidos a complementar la formación de profesionales. Como parte de su proceso de inscripción, el Sr. Pérez entrega el siguiente currículum: Fulanito Pérez INFORMACIÓN PERSONAL • DNI: 12345678-A • Fecha de Nacimiento: 08-Abril-1981 • Lugar de nacimiento: Madrid, España • Nacionalidad: Española • Teléfono: 912 345 678 • Dirección postal: Calle del ejemplo 234, 28199 Villaejemplo, Madrid. • E-Mail: [email protected] FORMACIÓN • 1999 – 2004: Ingeniero en Informática por la Universidad Complutense de Madrid RESUMEN DE CALIFICACIONES • Nota media en enseñanza secundaria y Selectividad: 8,40 • Nota media en titulación universitaria (formato 1-4): 2,31 IDIOMAS • Nivel de Inglés Escrito y Oral: Muy Alto • University of Cambridge Certificate of Proficiency in English (1997) Calificación: A CONOCIMIENTOS TÉCNICOS • Programación • o Programación Imperativa: Pascal, C, Basic o Programación Orientada a Objetos: Java, C++, Div / Div 2 o Programación Declarativa (Lógica y funcional): Haskell, Prolog, Clips Experiencia con la plataforma J2EE o Arquitecturas J2EE o Tecnologías J2EE (JSP, JDBC, JNDI…) 108 EXPERIENCIA LABORAL • 2006– … : Ejemplo Consulting Inc. o Jefe de diseño AFICIONES • Fotografía digital (http://www.misfotosdigitales.es/fulanito) Al darse de alta en el sistema, se crea la primera versión de su currículum formalizada mediante la especificación IMS LIP. Dado que el currículum sólo indica la obtención del título universitario, el sistema solicita a la universidad de origen información más detallada sobre la formación del alumno. La universidad remite esta información, indicando las asignaturas superadas y las calificaciones detalladas siguiendo también el formato de IMS LIP para su integración con la información ya disponible. A medida que Fulanito va superando cursos dentro del propio sistema de formación, estas calificaciones y habilidades quedan también reflejadas en su perfil IMS LIP. Si en un futuro éste decidiese inscribirse en otro entorno de aprendizaje virtual compatible con IMS LIP, toda esta información puede ser exportada directamente para su uso en el nuevo sistema. En las siguientes secciones se analiza la estructura concreta de la especificación IMS LIP indicando cómo se puede usar para formalizar todos los elementos de este caso de estudio. 3.4. ESTRUCTURA XML El modelo de información de IMS LIP se puede expresar como lenguaje de marcado XML. En este apartado se describen los distintos tipos de elementos (las etiquetas) introducidos por dicho lenguaje. Para cada elemento discutido se muestra un ejemplo de cómo emplearlo para modelar fragmentos del caso de estudio anterior. 3.4.1. Metadatos y otros elementos comunes Como ya se ha indicado en la sección 3.2.2, todas las secciones y elementos de la especificación IMS LIP pueden incluir una sección con metadatos que afectan a la sección en la que se incluyan. Estos metadatos se introducen siempre mediante un bloque contenttype cuya estructura se puede observar en la Figura 3.4.1.a. El resto de esta sección describe estos elementos así como otras construcciones comunes a toda la especificación IMS LIP. 109 Figura 3.4.1.a. Estructura gramatical del elemento contenttype. Elemento opcional contenttype 0 .. 1 0 o más ocurrencias 0 .. ∞ referential 0 .. 1 0 .. 1 Debe constar al menos uno de estos elementos 0 .. ∞ 1 .. ∞ indexid typename temporalfield privacy 0 .. 1 1 .. ∞ 0 .. ∞ 0 .. 1 sourceid temporal 0 .. 1 0 .. ∞ Uno de los dos comment typename privacyfield date ext_contenttype Identificación/Referencia En el bloque referential se incluye la información de identificación. Esta referencia puede ser única para el documento, para una determinada institución o incluso globalmente. El mecanismo de identificación emplea una de las dos siguientes etiquetas: § Un elemento sourceid se emplea para identificar un registro de un alumno específico y consta de dos partes (source e id). La primera identifica de manera única un sistema de registro de alumnos (entorno virtual de enseñanza, universidad, escuela, etc.) mientras que la segunda especifica el indicador concreto del alumno. 110 § Un elemento indexid se emplea para identificar elementos dentro del perfil de un alumno concreto como pueden ser una calificación o la descripción de una actividad educativa. Temporalidad El bloque temporal incluye la información relativa a la vigencia de los datos a los que describe. Contiene, a su vez, dos tipos de elemento: § § El elemento typename aparece en diversos campos de la especificación para indicar un tipo dentro de una cierta taxonomía (en este caso, se emplea para indicar el tipo de limitación temporal del dato). A su vez, este elemento se divide en dos elementos: - El elemento tysource indica el vocabulario de los tipos posibles. La especificación IMS LIP ofrece vocabularios por defecto para los distintos contextos en los que puede aparecer un elemento typename, denominado imsdefault. En el caso de los metadatos temporales, este vocabulario ofrece los términos Expiry, Creation, Update y Purge. - El elemento tyvalue indica el tipo en sí, escogido del vocabulario especificado en el elemento anterior. El elemento temporalfield incluye el dato temporal en sí en forma de un par atributo-valor compuesto por los elementos fieldlabel y fieldata. Privacidad El bloque privacy incluye los datos de privacidad que definen quién puede acceder a cada dato del documento e incluye los siguientes elementos: § El elemento typename es similar al descrito en el apartado anterior. En este caso, indica qué personas pueden acceder al dato que se está definiendo, teniendo como vocabulario por defecto Creator, Owner, Steward, Learner, Default y All. § Los elementos privacyfield se emplean para describir la política de privacidad en sí mediante pares atributo-valor compuestos por los elementos fieldlabel y fielddata. § Se pueden incluir opcionalmente algunos elementos de tipo date para asociar fechas a la mencionada política de privacidad (por ejemplo, la fecha de implantación o expiración de la política de privacidad). Extensiones La especificación IMS LIP está diseñada para poder ser extendida para cubrir las necesidades emergentes de las distintas organizaciones que la adopten. En la terminología de IMS esto se denomina crear un Perfil de Aplicación (del inglés, Application Profile) tal y como se indica en (Fernández-Manjón et al., 2007). Así, en la Figura 3.4.1.a podemos observar también un elemento final denominado ext_contenttype. La especificación no indica el contenido de este elemento, 111 dejando en manos de las distintas implementaciones expandirlo según crean conveniente. Como se puede observar en el resto de secciones, este mismo patrón lo encontramos en prácticamente todos los elementos de la especificación, permitiendo así introducir modificaciones en distintas ubicaciones según sea necesario. Descripciones Muchos de los elementos de la especificación pueden incluir un campo denominado description en el que se pueden incluir descripciones textuales o referencias a ficheros externos. Estas descripciones, cuya estructura se puede observar en la Figura 3.4.1.b constan de los siguientes elementos: • El elemento short se emplea para incluir una descripción breve (inferior a 255 caractéres) en formato textual. • El campo long se emplea en cambio para incluir descripciones textuales de longitud mayor. • El elemento full se emplea para hacer referencia a ficheros externos mediante el elemento media. El elemento comment se emplea para incluir en el fichero comentarios sobre el fichero en cuestión. Figura 3.4.1.b. Estructura gramatical del elemento description. description 0 .. 1 Debe constar al menos uno de estos elementos 0 .. 1 0 .. 1 short long full 0 .. 1 1 .. ∞ 112 comment media 3.4.2. El elemento learnerInformation El elemento learnerInformation es el elemento raíz de los documentos marcados mediante la especificación IMS LIP. Toda la información de un documento IMS LIP se guarda por tanto dentro de este elemento, el cual se divide en subsecciones que se corresponden con los distintos tipos de información a almacenar. La Figura 3.4.2.a esquematiza la estructura gramatical del mismo. El primer elemento, de carácter opcional, es el elemento comment, empleado para añadir comentarios u observaciones sin formato formalizado para su interpretación por humanos. El siguiente elemento es el campo contenttype que, tal y como se describe en la sección 3.4.1, se emplea para indicar los metadatos del elemento activo. En este caso, el bloque contenttype del elemento learnerInformation incluye metadatos relativos al documento completo. Tras estos dos elementos opcionales, el elemento learnerInformation contiene una sucesión de secciones no ordenadas que se corresponden con las 11 categorías de datos descritas en la sección 3.2.1. Por último, encontramos el elemento ext_learnerinfo para que las distintas organizaciones puedan añadir aquellos elementos que consideren necesarios para extender la funcionalidad de la especificación. 113 Figura 3.4.2.a. Estructura gramatical del elemento learnerInformation. learnerInformation 0 .. 1 0 .. 1 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. 1 comment contenttype identification goal qcl activity competency transcript accesibility interest affiliation securitykey relationship ext_learnerinfo En nuestro caso de estudio, la estructura general del documento es la descrita en la Figura 3.4.2.b. El formato del contenido concreto de cada sección (indicado en la figura en forma de elipsis) se describe en los siguientes apartados. 114 Figura 3.4.2.b. Estructura de alto nivel de un documento IMS LIP. <learnerinformation> <!-- Metadatos --> <comment>Ejemplo de uso de IMS para almacenar datos de un alumno</comment> <contentype> <referential> <sourcedid> <source>Sistema de Ejemplo</source> <id>12345678-A</id> </sourcedid> </referential> </contentype> <!-- Secciones de contenido --> <identification> (…) </identification> <qcl> (…) </qcl> <activity> (…) </activity> <affiliation> (…) </affiliation> <transcript> (…) </transcript> <accesibility> (…) </accesibility> <goal> (…) </goal> <competency> (…) </competency> <interest> (…) </interest> <securitykey> (…) </securitykey> <relationship> (…) </relationship> <!-- Extensiones --> <ext_learnerinfo> (…) </ext_learnerinfo> </learnerinformation> 3.4.3. El elemento identification El propósito de la sección de contenido identification es incluir la información personal del alumno que no es directamente relevante para el proceso educativo, como pueden ser datos de contacto o información demográfica. 115 Figura 3.4.3.a. Estructura gramatical del elemento identification. identification 0 .. 1 0 .. 1 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. 1 comment contenttype formname name address contactinfo demographics agent ext_identification Tal y como se observa en la Figura 3.4.3.a, el elemento identification incluye, al igual que el elemento raíz learnerinformation, elementos opcionales comment y contenttype. En este caso, los mencionados elementos contienen los comentarios y metadatos aplicables específicamente a la sección de datos personales. Aparte de estos elementos, que son comunes a todas las secciones de contenido de la especificación, la sección identification también puede incluir tantas instancias como sea necesario de los siguientes elementos: § Los elementos formname se emplean para definir nombres completamente formateados, como por ejemplo “Sr. Fulanito Pérez”. § Los elementos name, en cambio, se emplean para almacenar el nombre del alumno separado en campos (nombre de pila, apellidos, prefijos, etc.). § En los elementos address se incluyen las posibles direcciones de contacto del alumno, usando los campos apropiados. § Cada elemento contactinfo se emplea para listar un modo de contactar con el alumno, como puede ser un teléfono, un número de fax, un teléfono móvil o una dirección de correo electrónico. Es reseñable que la especificación emplea un elemento contactinfo para cada dato, de modo que si queremos incluir por ejemplo dos números de teléfono y una dirección de correo electrónico, deberemos introducir tres instancias de contactinfo. 116 § El elemento demographics se emplea para registrar información demográfica como pueden ser la fecha de nacimiento, el género o una referencia a una fotografía. § Los elementos agent se emplean para incluir información sobre los posibles representantes del alumno. El caso más común de representante en enseñanza reglada son los padres o tutores del alumno y en caso de entornos corporativos, la organización empleadora. La figura Figura 3.4.3.b muestra el uso de estos elementos para codificar la información correspondiente del caso de estudio. En esta figura podemos apreciar también el uso del elemento ext_identification para extender la especificación y añadir un nuevo campo para almacenar la nacionalidad. Figura 3.4.3.b. Marcado en XML de la información de identificación del alumno del caso de estudio. <identification> <contactinfo> <name> <telephone> <partname> <countrycode>34</countrycode> <typename> <areacode>91</areacode> <tysource sourcetype="imsdefault"/> <indnumber>2345678</indnumber> <tyvalue>First</tyvalue> </telephone> </typename> </contactinfo> <text>Fulanito</text> <contactinfo> </partname> <email> <partname> [email protected] <typename> </email> <tysource sourcetype="imsdefault"/> </contactinfo> <tyvalue>Last</tyvalue> <demographics> </typename> <date> <text>Pérez</text> <typename> </partname> <tysource sourcetype="imsdefault"/> </name> <tyvalue>Birth</tyvalue> <address> </typename> <typename> <datetime>1981-04-08</datetime> <tysource sourcetype="imsdefault"/> </date> <tyvalue>Private</tyvalue> <placeofbirth>Madrid, España</placeofbirth> </typename> </demographics> <street> <ext_identification> <streetnumber>234</streetnumber> <fieldlabel> <streetname> <typename> Calle del ejemplo <tyvalue>Nacionalidad</tyvalue> </streetname> </typename> </street> </fieldlabel> <city>Villaejemplo</city> <fielddata>Española</fielddata> <statepr>Madrid</statepr> </ext_identification> <postcode>28199</postcode> </identification> </address> 3.4.4. El elemento qcl Cada elemento de tipo qcl se emplea para incluir información sobre una certificación oficial, un título académico, una licencia o, en general, calificaciones de carácter 117 general emitidas por organismos apropiados. Se debe emplear una sección qcl para cada certificación que se desee incluir. La Figura 3.4.4.a indica la estructura gramatical de un elemento qcl, cuyos campos más relevantes son los siguientes: § El elemento typename se emplea para indicar el tipo de certificado o licencia referido. La especificación IMS LIP incluye un vocabulario por defecto para este campo, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § El campo title se emplea para almacenar el título otorgado por la certificación. § El campo organization describe a la agencia u organismo emisor de la calificación. § En los casos en los que el certificado lleve asociado un número de serie o de licencia, se debe emplear el elemento registrationno para indicarlo. § El elemento level se emplea para indicar si el certificado se corresponde con algún nivel en especial (“Primera Clase”, “Con Honores”, etc.). § Se pueden incluir uno o varios elementos date, indicando, por ejemplo, la fecha en que fue obtenido o el vencimiento en el caso de licencias temporales. § El elemento description permite incluir textos explicativos o asociar ficheros adicionales relativos a la certificación (por ejemplo, una copia escaneada de un título oficial). 118 Figura 3.4.4.a. Estructura gramatical del elemento qcl. qcl 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 typename comment contenttype title organization registrationno level date description ext_qcl La Figura 3.4.4.b muestra cómo usar secciones qcl para registrar el título universitario y el certificado de inglés del currículum del caso de estudio. Es interesante observar el uso de los campos date para mostrar las fechas de inicio y graduación del alumno en el caso del título universitario, mientras que en el segundo ejemplo sólo se indica la fecha en la que fue obtenido el certificado. 119 Figura 3.4.4.b. Marcado en XML del título universitario y la certificación de idiomas del caso de estudio. <qcl> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Degree</tyvalue> </typename> <title>Ingeniero en Informática</title> <organization> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Educational</tyvalue> </typename> <description> <short> Universidad Complutense de Madrid </short> </description> </organization> <date> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Start</tyvalue> </typename> <datetime>1999</datetime> </date> <date> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Finish</tyvalue> </typename> <datetime>2004</datetime> </date> </qcl> <qcl> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Certification</tyvalue> </typename> <contentype> <referential> <indexid>qcl_cpe</indexid> </referential> </contentype> <title>Certificate of Proficiency in English</title> <organization> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Educational</tyvalue> </typename> <description> <short>University of Cambridge</short> </description> </organization> <date> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Award</tyvalue> </typename> <datetime>1999</datetime> </date> </qcl> 3.4.5. El elemento activity La secciones más relevantes de los perfiles de alumno son las descripciones de las actividades educativas llevadas a cabo. Estas actividades se describen mediante secciones activity, las cuales a su vez se organizan en subsecciones que separan la descripción de la actividad, los productos creados por el alumno durante la actividad, las evaluaciones obtenidas y los posibles informes que describan el rendimiento del alumno durante la realización de la actividad. En la Figura 3.4.5.a se puede observar la estructura general de una sección activity, cuyos elementos principales son los siguientes: § El elemento typename se emplea para indicar el tipo de informe o transcripción. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Work, Service, Education, Training, y Military, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. 120 § Se pueden incluir uno o varios elementos date para indicar las fechas de inicio o finalización de la actividad. § El elemento status refleja el estado actual de la actividad (Activa, Completada, etc.). Dentro de este elemento se pueden incluir, aparte del estado, la fecha en que se entró en dicho estado o una descripción más detallada del significado de dicho estado. § El elemento units se emplea si se quiere asociar a la actividad algún tipo de unidad de medida (como, por ejemplo, créditos) para cuantificar las posibles evaluaciones asociadas. § El campo learningactivityref se emplea para asociar un identificador único a la actividad correspondiente. § El uso de la sub-sección definition se describe en la sección 3.4.5.1. § El uso de la sub-sección product se describe en la sección 3.4.5.2. § El uso de la sub-sección testimonial se describe en la sección 3.4.5.3. § El uso de la sub-sección evaluation se describe en la sección 3.4.5.4. § El elemento description permite incluir textos explicativos o asociar ficheros adicionales relativos a la afiliación. § La posibilidad de incluir más elementos de tipo activity dentro de estas estructuras permite definir jerarquías de actividades y sub-actividades. 121 Figura 3.4.5.a. Estructura gramatical del elemento activity. activity 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype 0 .. ∞ 0 .. 1 0 .. 1 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. 1 0 .. ∞ 0 .. 1 date status units learningactivityref definition product testimonial evaluation description activity ext_qcl La respresentación en XML de esta estructura se puede observar en la Figura 3.4.5.b, que muestra la versión abreviada de la descripción de la actividad educativa correspondiente a la carrera universitaria del alumno del caso de estudio. El formato concreto de las secciones definition, product, testimonial y evaluation se describe en los siguientes apartados. 122 Figura 3.4.5.b. Estructura general de una actividad describiendo el título universitario del alumno del caso de estudio. <activity> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Education</tyvalue> </typename> <learningactivityref> <sourcedid> <source>Universidad_Complutense_de_Madrid</source> <id>306-Ingeniero_en_Informatica</id> </sourcedid> </learningactivityref> <definition> (...) </definition> <product> (...) </product> <testimonial> (...) </testimonial> <evaluation> (...) </evaluation> </activity> 3.4.5.1. Descripción de Actividades: definition Para la descripción detallada de las actividades se emplean secciones definition. Este elemento, aunque de estructura sencilla (ver Figura 3.4.5.1.a) permite crear definiciones complejas mediante anidamiento (ver Figura 3.4.5.1.a). Sus elementos más relevantes son los siguientes: § El elemento typename se emplea para indicar el tipo de definición que describe la sección. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Class, Course, Curriculum, Module, Topic y Unit, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § Los elementos definitionfield se emplean para incluir pares atributo-valor que aportan los contenidos de la definición. § En los casos en los que se prefiera emplear una descripción textual en lugar (o como complemento) de los pares atributo-valor, podemos emplear un elemento description para incluir textos explicativos o asociar ficheros relativos a la definción (por ejemplo, una copia escaneada de un título oficial). § La presencia de nuevo del elemento definition permite crear estructuras jerárquicas. Por ejemplo, un bloque definition que describa un curso puede incluir sub-definiciones para cada una de las clases que lo componen. 123 Figura 3.4.5.1.a. Estructura gramatical del elemento definition. definition 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ typename comment contenttype definitionfield 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 fieldlabel fielddata description definition ext_definition En el caso de estudio, cuando el alumno Fulanito Pérez se matricula en el sistema sus instructores requieren conocer en mayor profundidad el contenido concreto de los estudios del alumno. Para ello, solicitan a la universidad de origen una descripción formalizada mediante IMS LIP de los contenidos de la carrera estudiada empleando el identificador único descrito en el elemento learningactivityref (ver Figura 3.4.5.b). La respuesta generada por los sistemas de información de la universidad de origen podría asemejarse al contenido de la Figura 3.4.5.1.b, que comienza empleando una serie de pares atributo-valor para definir algunas características de la titulación (el tipo, el número de años, etc.) y posteriormente emplea la estructura jerárquica del elemento definition para estructurar los cursos y las asignaturas correspondientes a cada curso. 124 Figura 3.4.5.1.b. Marcado en XML de la descripción detallada de la estructura del programa educativo de la titulación del caso de estudio. <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Curriculum</tyvalue> </typename> <definitionfield> <fieldlabel> <typename> <tyvalue>Tipo de titulación</tyvalue> </typename> </fieldlabel> <fielddata>Ingeniería Superior</fielddata> </definitionfield> <definitionfield> <fieldlabel> <typename> <tyvalue>Número de años</tyvalue> </typename> </fieldlabel> <fielddata>5</fielddata> </definitionfield> <!-- Primer curso --> <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Course</tyvalue> </typename> <description> <short>Primer curso</short> </description> <!-- Asignaturas --> <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Class</tyvalue> </typename> <description> <short> Introducción a la programación </short> </description> </definition> <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Class</tyvalue> </typename> <description> <short>Análisis Matemático</short> </description> </definition> (…) </definition> <!-- Segundo curso --> <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Course</tyvalue> </typename> <description> <short>Segundo curso</short> </description> <!-- Asignaturas --> (…) </definition> <!-- Tercer curso --> <definition> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Course</tyvalue> </typename> <description> <short>Segundo curso</short> </description> <!-- Asignaturas --> (…) </definition> <!-- Resto de cursos --> (…) </definition> 3.4.5.2. Productos Generados en Actividades: product Los elementos de tipo product se emplean para incluir referencias a posibles productos generados por el alumno como parte de la actividad que está siendo descrita. La estructura de este elemento se puede observar en la Figura 3.4.5.2.a y estos son sus elementos principales: § El elemento typename se emplea para indicar el tipo de producto. La especificación IMS LIP incluye un vocabulario por defecto para este campo 125 que incluye los términos Exam, Coursework, Portfolio y Participation, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § Se pueden incluir uno o varios elementos date para indicar las fechas de ingreso o terminación del trabajo correspondiente. § El elemento description permite incluir textos explicativos que aporten más información sobre el producto, así como ficheros digitales del mismo. Figura 3.4.5.2.a. Estructura gramatical del elemento product. product 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 typename comment contenttype date description ext_product Para ejemplificar el uso de esta sección, tomamos la posibilidad de incluir junto con los datos del alumno, una copia de la memoria de su proyecto de fin de carrera tal y como se observa en la Figura 3.4.5.2.b. 126 Figura 3.4.5.2.b. Marcado en XML de la inclusión de un producto asociado a una actividad educativa. <product> <typename> <tysource sourcetype="imsdefault"></tysource> <tyvalue>Coursework</tyvalue> </typename> <description> <short>Memoria del proyecto de fin de carrera</short> <full> <media mediamode="Text" mimetype="text/pdf">alumno/proyecto.pdf</media> </full> </description> </product> 3.4.5.3. Informes sobre Actividades: testimonial La subsección testimonial se emplea para incluir posibles comentarios formales o informales sobre el rendimiento del alumno durante la realización de las actividades descritas. Estos testimonios pueden ser informes de los profesores, directores de estudios o de los superiores del alumno en el caso de actividades profesionales. Dado que el único objetivo de las subsecciones testimonial es la inclusión de estos informes, su estructura es realmente sencilla tal y como se puede observar en la Figura 3.4.5.3.a. Sus elementos principales son los siguientes: • El elemento typename se emplea para indicar el tipo de informe. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Academic, Personal, Work, Military y Service, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. • Se pueden incluir uno o varios elementos date para indicar las fechas relacionadas con el informe. • El elemento description se emplea para incluir el propio informe, bien como descripción textual dentro del propio documento o mediante una referencia a un fichero externo. 127 Figura 3.4.5.3.a. Estructura gramatical del elemento testimonial. testimonial 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 typename comment contenttype date description ext_testimonial Para ejemplificar el uso de esta sub-sección, añadimos al perfil del alumno de ejemplo una carta de recomendación escrita por su tutor durante la realización del proyecto de fin de carrera. Figura 3.4.5.3.b. Marcado en XML de la inclusión de un testimonio en forma de carta de recomendación. <testimonial> <typename> <tysource sourcetype="imsdefault"></tysource> <tyvalue>Academic</tyvalue> </typename> <description> <short>Informe del tutor del proyecto de fin de carrera</short> <full> <media mediamode="Text" mimetype="text/pdf">alumno/informeTutor.pdf</media> </full> </description> </testimonial> 3.4.5.4. Evaluación de Actividades: evaluation Las evaluaciones y notas obtenidas como parte de las actividades educativas se representan mediante sub-secciones evaluation. Aunque la estructura de estos apartados está muy relacionada con la especificación IMS Question and Test Interoperability (IMS Global Consortium, 2005), la descripción detallada de dichas relaciones queda fuera del ámbito de este informe concreto. Para mayor información, puede consultarse el informe número 16 de esta misma serie (Fernández-Manjón et 128 al., 2007). En cualquier caso, la estructura de estos elementos (detallada en la Figura 3.4.5.4.a) se puede emplear también de manera independiente. Estos son sus elementos más relevantes: • El elemento typename se emplea para indicar el tipo de evaluación. El vocabulario inicial se centra en la especificación IMS QTI, presentando las opciones QTI_Assessment, QTI_Section y QTI_Item. • El elemento result incluye la puntuación concreta de la evaluación. Este resultado puede incluir información adicional para facilitar su interpretación. • Podemos emplear el campo description para incluir textos explicativos o asociar ficheros relativos a la evaluación. • La presencia de nuevo del elemento evaluation permite crear estructuras jerárquicas. Por ejemplo, una nota que es el resultado de ponderar diversas calificaciones puede incluir sub-evaluaciones con dichas calificaciones. 129 Figura 3.4.5.4.a. Estructura gramatical del elemento evaluation. evaluation 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 0 .. ∞ 0 .. ∞ 0 .. 1 0 .. ∞ 0 .. 1 typename comment contenttype evaluationid date eval_metadata objectives status noofattempts duration result description evaluation ext_evaluation En el caso de estudio, el alumno indica en su currículum una calificación media en sus estudios universitarios. Esta calificación es el resultado de aplicar una media a las notas obtenidas durante la carrera y sigue un criterio de calificación entre 1 y 4 (1 = Aprobado, 2 = Notable, 3 = Sobresaliente, 4 = Matrícula de Honor). Toda esta información se puede formalizar mediante la especificación IMS LIP tal y como se ejemplifica en la Figura 3.4.5.4.b. 130 Figura 3.4.5.4.b. Marcado en XML de la calificación final del alumno junto con instrucciones para la interpretación del resultado. <evaluation> <interpretscore> <result> <fieldlabel> <interpretscore> <typename> <fieldlabel> <tyvalue> <typename> Matrícula de Honor <tyvalue>Aprobado</tyvalue> </tyvalue> </typename> </typename> </fieldlabel> </fieldlabel> <fielddata>1</fielddata> <fielddata>4</fielddata> </interpretscore> </interpretscore> <interpretscore> <fieldlabel> <!-- Puntuación final --> <typename> <score> <tyvalue>Notable</tyvalue> <fieldlabel> </typename> <typename> </fieldlabel> <tyvalue> <fielddata>2</fielddata> Calificación Global </interpretscore> </tyvalue> <interpretscore> </typename> <fieldlabel> </fieldlabel> <typename> <fielddata>2,31</fielddata> <tyvalue>Sobresaliente </tyvalue> </score> </typename> </fieldlabel> </result> <fielddata>3</fielddata> </evaluation> </interpretscore> 3.4.6. El elemento affiliation Las secciones de tipo affiliation se emplean para almacenar la información relativa a la pertenencia del alumno a distintos grupos profesionales, personales, militares o cívicos. Estas secciones son anidables, pudiendo incluir bloques affiliation dentro de otros para dar lugar a estructuras jerárquicas. La Figura 3.4.6.a indica la estructura gramatical de un elemento affiliation, cuyos campos más relevantes son los siguientes: § El elemento typename se emplea para indicar el tipo de afiliación (Profesional, Personal, Militar, etc.). La especificación IMS LIP incluye un vocabulario por defecto para este campo, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § El campo classification se emplea para almacenar el tipo de afiliación. § Si la afiliación lleva asociado una referencia (un número de socio o un identificador de empleado), ésta se puede almacenar empleando el elemento affiliationid. § Se pueden incluir varios campos role para almacenar los cargos que ha ocupado el alumno en la organización correspondiente. Cada uno de estos 131 campos incluye información adicional sobre las fechas de comienzo y finalización del cargo, así como otros datos relativos a las características del mismo. § El campo organization describe a la agencia u organismo correspondiente. § Se pueden incluir uno o varios elementos date para indicar las fechas de ingreso o terminación de la afiliación. § El elemento description permite incluir textos explicativos o asociar ficheros adicionales relativos a la afiliación. § La presencia de nuevo del elemento affiliation permite crear jerarquías de afiliaciones y sub-afiliaciones como, por ejemplo, la pertenencia a grupos específicos dentro de una organización. Figura 3.4.6.a. Estructura gramatical del elemento affiliation. affiliation 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 132 typename comment contenttype classification affiliationid role organization date status description affiliation ext_affiliation La Figura 3.4.6.b muestra una sección affiliation de ejemplo, describiendo la experiencia profesional del alumno del caso de estudio. Figura 3.4.6.b. Marcado en XML de la experiencia profesional del alumno del caso de estudio. <affiliation> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Professional</tyvalue> </typename> <role> <date> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Start</tyvalue> </typename> <datetime>2005</datetime> </date> <description> <short>Jefe de Diseño</short> </description> </role> <organization> <description> <short>Ejemplo Consulting Inc.</short> </description> </organization> </affiliation> 3.4.7. El elemento transcript Las secciones de tipo transcript se emplean para guardar resúmenes acerca del rendimiento del alumno en diversas áreas o en determinadas instituciones. Son el elemento más flexible, presentando la estructura de la Figura 3.4.7.a cuyos elementos principales son los siguientes. § El elemento typename se emplea para indicar el tipo de informe o transcripción. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Academic, Vocational y Training, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § El campo exrefrecord se emplea para indicar un fichero externo que contenga el informe correspondiente. Dentro de éste elemento se puede incluir, aparte del propio fichero, información adicional como fechas o una descripción del contenido del informe. § El elemento description permite incluir textos explicativos que describan el informe. 133 Figura 3.4.7.a. Estructura gramatical del elemento transcript. transcript 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype exrefrecord description ext_transcript Dada la naturaleza abierta de las secciones transcript, es común utilizarlas para almacenar textos o ficheros que no terminen de encajar en otras secciones. En nuestro caso de estudio, empleamos una sección transcript para almacenar los datos de conocimientos técnicos del currículum de ejemplo, tal y como se muestra en la Figura 3.4.7.b. Figura 3.4.7.b. Marcado en XML del resumen de conocimientos técnicos del caso de estudio. <transcript> <description> <short>Conocimientos Técnicos</short> <long> Programación Programación Imperativa: Pascal, C, Basic Programación Orientada a Objetos: Java, C++ Programación Declarativa (Lógica y funcional): Haskell, Prolog, LISP Experiencia con la plataforma J2EE Arquitecturas J2EE Tecnologías J2EE (JSP, JDBC, JNDI…) </long> </description> </transcript> 3.4.8. El elemento accessibility Los elementos accessibility se emplean para almacenar información relativa a las necesidades y preferencias del alumno de cara a interactuar con el contenido educativo. A pesar de que el término “accesibilidad” (traducción literal de 134 accessibility) se emplea a menudo en el campo de las tecnologías de comunicación en referencia a facilitar el acceso a personas con discapacidades, en el caso de la especificación IMS LIP se emplea este concepto de una manera más amplia, cubriendo aspectos como los idiomas dominados por el alumno o sus preferencias personales en cuanto al formato de contenido. Como se puede observar en la figura Figura 3.4.8.a, el elemento accessibility consta de cuatro subsecciones que cubren los distintos aspectos de accesibilidad contemplados por la especificación. § Los elementos language se emplean para incluir información sobre las capacidades lingüísticas del alumno. Debe incluirse un elemento de tipo language para la información de cada uno de los idiomas dominados por el alumno. Su uso se describe en la sección 3.4.8.1. § El elemento eligibility se emplea para indicar posibles recursos adicionales que el alumno pueda requerir, como podrían ser atenciones especiales o criterios de corrección específicos. En la versión actual de la especificación IMS LIP este elemento queda pendiente de ser extendido en versiones futuras de la especificación. Tal y como se describe en el capítulo 5, la especificación IMS ACCLIP emplea este elemento para detallar los servicios especiales que los alumnos con discapacidades puedan requerir a la hora de realizar, por ejemplo, exámenes de evaluación. § El propósito de los elementos preference es indicar las preferencias personales de acceso planteadas por el alumno y su uso se detalla en la sección 3.4.8.2. § Las limitaciones ambientales o debidas a discapacidades del alumno se expresan dentro del elemento accessForAll. Cabe señalar que la especificación IMS LIP, en su versión actual, incluye en realidad el elemento disability. Tal y como se describe en el capítulo 5, la especificación IMS ACCLIP introduce en su lugar el elemento accessForAll dejando el elemento disability obsoleto. 135 Figura 3.4.8.a. Estructura gramatical del elemento accessibility. accesibility 0 .. 1 0 .. 1 0 .. ∞ Debe constar al menos uno de estos elementos 0 .. ∞ 0 .. ∞ 0 .. ∞ 0 .. 1 comment contenttype language eligibility preference accessForAll ext_accesibility 3.4.8.1. Accesibilidad idiomática: language Dentro de una sección accessibility podemos incluir tantos elementos language como idiomas conozca el alumno. Para cada idioma se puede definir el nivel de habilidad en distintos aspectos siguiendo la estructura observable en la Figura 3.4.8.1.a cuyos elementos principales son los siguientes: § El elemento typename se emplea para indicar el lenguaje en cuestión. Como vocabulario por defecto se sugiere emplear los estándares ISO de denominación de lenguajes. § Para indicar el nivel emplearemos varios incluyen el atributo (hablar), OralComp (escribir). de habilidad del alumno en el idioma correspondiente elementos de tipo proficiency. Estos elementos profmode, cuyos posibles valores son OralSpeak (escuchar y comprender), Read (lectura) y Write 136 Figura 3.4.8.1.a. Estructura gramatical del elemento language. language 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype 0 .. ∞ 0 .. 1 proficiency ext_language La Figura 3.4.8.1.b muestra el uso de estructuras language para indicar las habilidades idiomáticas del alumno de ejemplo. Aparte de su conocimiento del castellano como su idioma nativo, su elevado nivel de inglés queda también reflejado en el ejemplo. Figura 3.4.8.1.b. Marcado en XML de los conocimientos idiomáticos del alumno. <language> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Spanish</tyvalue> </typename> <proficiency profmode="OralComp">Excelente</proficiency> <proficiency profmode="OralSpeak">Excelente</proficiency> <proficiency profmode="Read">Excelente</proficiency> <proficiency profmode="Write">Excelente</proficiency> </language> <language> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>English</tyvalue> </typename> <contentype> <referential> <indexid>acc_ingles</indexid> </referential> </contentype> <proficiency profmode="OralComp">Excelente</proficiency> <proficiency profmode="OralSpeak">Bueno</proficiency> <proficiency profmode="Read">Excelente</proficiency> <proficiency profmode="Write">Bueno</proficiency> </language> 137 3.4.8.2. Preferencias de acceso: preference Independientemente de sus posibles discapacidades o limitaciones, los alumnos en estos sistemas pueden expresar sus preferencias sobre el proceso de aprendizaje, sobre los formatos a emplear, sus horarios, etc. Existe, además, una tendencia en los entornos virtuales de enseñanza consistente en adaptar los itinerarios de aprendizaje en función de los perfiles psicológicos de los alumnos para favorecer sus estilos individuales de enseñanza. Este tipo de factores se describen empleando elementos de tipo preference siguiendo la estructura de la Figura 3.4.8.2.a. y empleando los siguientes elementos: § El elemento typename se emplea para indicar el tipo de preferencia. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Cognitive, Physical, InputTech y OutputTech, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § El campo principal de un bloque preference es el elemento prefcode. Dentro de este campo se incluye la referencia o descripción de la preferencia. El formato concreto a seguir para denominar dichas preferencias depende de las distintas implementaciones. § El elemento description permite incluir textos explicativos que describan con mayor detalle la preferencia o incluyan material adicional sobre la misma. Figura 3.4.8.2.a. Estructura gramatical del elemento preferente. z preference 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype prefcode description ext_preference Para ejemplificar el uso de estos elementos, se incluyen posibles preferencias del alumno del caso de estudio en relación a su estilo de aprendizaje (prefiere un proceso guiado en lugar de abierto) y su preferencia de formatos de contenido (prefiere recibir el contenido en formato PDF para imprimir los documentos) tal y como se observa en la Figura 3.4.8.2.b. 138 Figura 3.4.8.2.b. Marcado en XML de las preferencias del alumno para el proceso de aprendizaje. <preference> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Cognitive</tyvalue> </typename> <prefcode>Aprendizaje guiado</prefcode> </preference> <preference> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>OutputTech</tyvalue> </typename> <prefcode>Documentos PDF</prefcode> </preference> 3.4.9. El elemento goal Los distintos alumnos pueden tener distintos objetivos laborales, educativos o incluso de realización personal. Estos objetivos se pueden representar en secciones de tipo goal. Las estructuras goal presentan la estructura descrita en la Figura 3.4.9.a, cuyos elementos principales son los siguientes. § El elemento typename se emplea para indicar el tipo de objetivo. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Work, Education, Personal, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § Se pueden incluir varios elementos de tipo date describiendo las fechas relativas a dicho objetivo como, por ejemplo, la fecha en la que el alumno comenzó a perseguir dicho objetivo o el plazo propuesto para alcanzarlo. § El campo priority se emplea para reflejar la prioridad relativa del objetivo. Este elemento carece de estructura predefinida y no se aporta un vocabulario concreto para su uso. § El elemento status refleja el estado actual del objetivo (Activo, Conseguido, Pospuesto, etc.). Dentro de este elemento se pueden incluir, aparte del estado, la fecha en que se entró en dicho estado o una descripción más detallada del significado de dicho estado. § El elemento description permite incluir textos explicativos que describan el objetivo en cuestión. § La posibilidad de incluir más elementos de tipo goal dentro de estas estructuras permite definir jerarquías de objetivos y sub-objetivos que las componen. 139 Figura 3.4.9.a. Estructura gramatical del elemento goal. z goal 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ 0 .. 1 typename comment contenttype date priority status description goal ext_goal Como se mencionaba en la descripción del caso de estudio en la sección 3.3, el objetivo del alumno al inscribirse en estos cursos es mantener sus conocimientos informáticos actualizados. Dada su especialización, al recibir su registro, los responsables del programa educativo analizan el objetivo principal y lo dividen en dos sub-objetivos que quedan registrados en el perfil del alumno tal y como se puede observar en la Figura 3.4.9.b 140 Figura 3.4.9.b. Marcado en XML de los objetivos educativos del alumno del caso de estudio. <goal> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Educational</tyvalue> </typename> <priority>Objetivo Principal</priority> <status> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Active</tyvalue> </typename> </status> <description> <short>Mantener conocimientos actualizados</short> </description> <goal> <description> <short>Aprender nuevos lenguajes de programación</short> </description> </goal> <goal> <description> <short>Conocer las tendencias en el uso de J2EE</short> </description> </goal> </goal> 3.4.10. El elemento competency El propósito de las secciones de tipo competency es incluir información sobre las habilidades obtenidas por el alumno como resultado de su proceso formativo. Cuando la primera versión de IMS LIP fue publicada, estas secciones tenían un carácter temporal a la espera de los resultados del grupo de trabajo sobre definición de competencias (IMS Competency Definition working-group), por lo que su estructura es muy sencilla tal y como se observa en la Figura 3.4.10.a, incluyendo como campos relevantes sólo los siguientes: § El campo exrefrecord se emplea para indicar un fichero externo que contenga la descripción de las habilidades o competencias. § El elemento description permite incluir textos explicativos que describan la competencia. 141 Figura 3.4.10.a. Estructura gramatical del elemento competency. z competency 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype exrefrecord description ext_competency Las definiciones de competencias pueden emplearse también para ofrecer una vista más detallada de la sección de “Conocimientos Técnicos” del currículum de ejemplo. Tal y como se ejemplificó en la sección 3.4.7, la experiencia previa del alumno se puede almacenar dentro de un elemento transcript, pero esas descripciones no siguen un formato estandarizado. Asimismo, la última versión de IMS LIP publicada en enero de 2005 (1.0.1) no contempla ninguna estructuración concreta del elemento competency para aumentar su funcionalidad (IMS Global Consortium, 2005). En su lugar, la especificación IMS Reusable Definition of Competency or Educational Objective (IMS Global Consortium, 2002), descrita en mayor detalle en el capítulo 4, sugiere emplear el campo description para incluir referencias a documentos XML con la descripción detallada de las competencias, tal y como se observa en la Figura 3.4.10.b. La estructura detallada de este fichero externo con la definición de la competencia “Programación imperativa: Pascal” se puede encontrar más adelante en la sección 4.4.1. 142 Figura 3.4.10.b. Integración de documentos formalizados mediante la especificación IMS RDCEO en una sección competency. <competency> <description> <short>Programación imperativa: Pascal</short> <full> <media encoding="uri" mediamode="text" mimetype="text/xml"> ficheros/competencia-pascal.xml </media> </full> </description> </competency> 3.4.11. El elemento interest Las secciones de tipo interest carecen, en principio, de significado educativo. Su propósito es reflejar intereses o aficiones del alumno trascendiendo el ámbito educativo. Tal y como se puede ver en la Figura 3.4.11.a, que describe la estructura de estas secciones, las aficiones se describen mediante los siguientes campos: § El elemento typename se emplea para indicar el tipo de afición o actividad. La especificación IMS LIP incluye un vocabulario por defecto para este campo que incluye los términos Recreational, Vocational y Domestical, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § En los casos en que las aficiones del alumno se quieran ejemplificar mediante trabajos u otros ejemplos, el campo product permite relacionar la definición de la afición con ficheros externos siguiendo la estructura descrita en la sección 3.4.5.2. § El elemento description permite incluir textos explicativos que aporten más información sobre la afición. 143 Figura 3.4.11.a. Estructura gramatical del elemento interest. z goal 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype product description ext_interest En el caso de estudio, el alumno de ejemplo mencionaba su afición por la fotografía e incluso aportaba la dirección URL de su álbum de fotos en Internet. La Figura 3.4.11.b muestra el uso de IMS LIP para registrar esta información mediante una sección interest. Figura 3.4.11.b. Uso de la sintaxis IMS LIP para almacenar información relativa a la afición por la fotografía del alumno del caso de estudio. <interest> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Recreational</tyvalue> </typename> <product> <description> <short>Photo Album</short> <full> <media mediamode="Text" mimetype="text/html" contentreftype="uri"> http://www.flickr.com/photos/fulanitoperez/ </media> </full> </description> </product> <description> <short>Fotografía Digital</short> </description> </interest> 144 3.4.12. El elemento securitykey Las secciones securitykey se emplean para almacenar las contraseñas o credenciales de acceso del alumno. Se debe emplear una de estas secciones para cada conjunto de credenciales. La estructura general del elemento securitykey se puede observar en la Figura 3.4.12.a y sus campos más relevantes son los siguientes: § El elemento typename se emplea para indicar el tipo de credencial de acceso. El vocabulario por defecto incluye los términos Password, Certificates, PIN y Username, aunque se contempla la opción de extenderlo o adaptarlo por parte de las distintas implementaciones. § El elemento keyfields se emplea para indicar una credencial concreta, incluyendo los campos fieldlabel y fielddata para almacenar respectivamente la etiqueta y el valor de la credencial. § El elemento description permite incluir textos explicativos que describan el uso apropiado de la credencial. Figura 3.4.12.a. Estructura gramatical del elemento securitykey. securitykey 0 .. 1 0 .. 1 0 .. 1 0 .. ∞ typename comment contenttype keyfields 0 .. 1 0 .. 1 0 .. 1 0 .. 1 fieldlabel fielddata description definition En el caso de estudio, cuando el alumno se registra en el sistema de gestión del aprendizaje, éste recibe una contraseña para poder acceder al propio sistema. Esta contraseña se puede guardar junto con el resto de la información del alumno mediante la especificación IMS LIP tal y como se muestra en el ejemplo de la Figura 3.4.12.b. Nótese que, dado lo sensible de la información, se emplea el campo de metadatos 145 para indicar la privacidad de este dato empleando la sintaxis descrita en la sección 3.4.1. Figura 3.4.12.b. Uso de la especificación IMS LIP para guardar contraseñas de los alumnos. <securitykey> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Password</tyvalue> </typename> <contentype> <privacy> <typename> <tysource sourcetype="imsdefault"/> <tyvalue>Learner</tyvalue> </typename> <privacyfield> <fieldlabel> <typename> <tyvalue>Access</tyvalue> </typename> </fieldlabel> <fielddata>Read,Write,Delete</fielddata> </privacyfield> </privacy> </contentype> <keyfields> <fieldlabel> <typename> <tyvalue>Clave de acceso al sistema</tyvalue> </typename> </fieldlabel> <fielddata>clave_de_ejemplo</fielddata> </keyfields> </securitykey> 3.4.13. El elemento relationship Todos los tipos de sección vistos hasta este momento se emplean para almacenar distintos tipos de datos. En ocasiones, determinados hechos o datos que estén almacenados en secciones distintas pueden estar relacionados. El último tipo de sección, denominado relationship se encarga de establecer las conexiones entre estas secciones separadas. La estructura gramatical de este elemento se puede observar en la Figura 3.4.13.a y éstos son sus elementos más relevantes: § El elemento typename se emplea para indicar el tipo de relación establecida. El vocabulario por defecto incluye los tipos de sección principales de la especificación IMS LIP (Activity, Accessibility, Affiliation, Competency, Goal, Identification, Interest, Qcl, SecurityKey y Transcript). § El elemento tuple representa la asociación propiamente dicha, constando a su vez de los siguientes elementos: 146 § - tuplesource representa el origen de la relación y consta básicamente de una referencia al identificador del elemento que queremos relacionar. - tupledest representa el destino de la relación. Es interesante notar que puede haber más de un elemento tupledest, lo cual permite establecer relaciones desde un elemento de origen a varios elementos de destino. - Finalmente, el elemento tuplerelation se emplea para describir el tipo de asociación que estamos estableciendo, pudiendo usar para ello un elemento typename o un elemento text para incluir una cadena de texto libre. El elemento description permite incluir textos explicativos que describan con mayor detalle la relación entre los conceptos conectados. Figura 3.4.13.a. Estructura gramatical del elemento relationship. relationship 0 .. 1 0 .. 1 0 .. 1 0 .. 1 typename comment contenttype tuple 1 .. 1 1 .. 1 1 .. ∞ 0 .. 1 0 .. 1 tuplesource tuplerelation tupledest description ext_relationship En el caso de estudio, el alumno incluía referencia a la obtención de un certificado de idiomas (Certificate of Proficiency in English de la Universidad de Cambridge). La descripción de la certificación en sí la podemos encontrar en la Figura 3.4.4.b dentro de una estructura qcl. Similarmente, al definir su perfil de accesibilidad en la Figura 3.4.8.1.b. empleamos una entrada en la que se definían precisamente sus habilidades idiomáticas con el inglés. Las habilidades descritas en la sección de accesibilidad se basaban precisamente en haber obtenido la certificación. La Figura 3.4.13.b representa precisamente esta relación, indicando que se empleó la información de la 147 certificación (con el identificador qcl_cpe, ver Figura 3.4.4.b) para establecer las habilidades idiomáticas del alumno (con el identificador acc_ingles, ver Figura 3.4.8.1.b.). Figura 3.4.13.b. Uso de la especificación IMS LIP para representar una relación entre dos secciones separadas. <relationship> <tuple> <tuplesource> <indexid>acc_ingles</indexid> </tuplesource> <tuplerelation> <typename> <tyvalue>obtenido_de</tyvalue> </typename> </tuplerelation> <tupledest> <indexid>qcl_cpe</indexid> </tupledest> </tuple> </relationship> 4. IMS REUSABLE DEFINITION EDUCATIONAL OBJECTIVE OF COMPETENCY OR 4.1. INTRODUCCIÓN La especificación Reusable Definition of Competency or Educational Objective de IMS (de ahora en adelante, IMS RDCEO) permite la descripción, referencia e intercambio de definiciones de competencias principalmente orientadas al contexto de la enseñanza en línea y a distancia (IMS Global Consortium, 2002). El primer aspecto es qué se entiende por competencias ya que, aunque es el término habitualmente empleado como traducción de competency, ni siquiera aparece con esta acepción en el Diccionario de la Real Academia de la Lengua (www.rae.es). Una traducción alternativa sería “cualificación” que tiene el significado de preparación para ejercer determinada actividad o profesión. No obstante, y a pesar del abuso del lenguaje que supone, seguiremos utilizando el término competencia ya que en esta especificación se considera en un sentido muy general y engloba conceptos diversos como habilidades (en inglés skills), conocimientos, tareas, resultados aprendidos (en inglés learning outcomes) y objetivos del proceso educativo. El propósito de la especificación es representar formalmente las características clave de una competencia de forma general, es decir, independientemente de un uso particular determinado o de un contexto concreto de aplicación. De este modo se posibilita la interoperabilidad entre sistemas de enseñanza heterogéneos que 148 contemplen competencias ya que proporciona un método estándar para referirse a las mismas de una forma común y con un mismo significado. El núcleo de la información contemplada en RDCEO es una definición textual no estructurada de la competencia que puede ser referenciada mediante un identificador único. Esta información puede ser refinada si se dispone de un modelo definido por el usuario que proporcione una determinada estructura a dicha competencia. De este modo esta especificación permite que una comunidad de práctica determinada (un grupo social con intereses comunes como por ejemplo, la comunidad médica) formalice e intercambie información de competencias según el modelo propio que ellos utilicen. La formalización propuesta por la especificación RDCEO proporciona una forma de crear un punto de vista común de las competencias que aparecen como parte de la descripción de un diseño educativo o de un plan de formación ya sea como prerrequisitos de conocimiento o como resultados a obtener. El modelo de información en esta especificación se puede utilizar con distintos propósitos como, por ejemplo, para intercambiar las definiciones de competencias entre sistemas de enseñanza, entre sistemas de gestión de personal o de recursos humanos, entre sistemas de almacenamiento de contenido educativo (repositorios) o entre sistemas de almacenamiento de habilidades o competencias. RDCEO proporciona referencias únicas para la descripción de competencias u objetivos educacionales que se puedan incluir en otros modelos de información (e.g. en la información de los alumnos en un documento que siga la especificación IMS Learner Information Package tal y como se describe en el capítulo 3). RDCEO se basa en un marco general de competencias que puede incluir datos sobre (ver Figura 4.1.a): § Definición genérica y reusable de la competencia, incluyendo características clave como, por ejemplo, identificador, título y descripción, pero que no incluye aspectos contextuales de la competencia. § Contexto en el que se define la competencia o que define dicha competencia. El contexto puede incluir competencias asociadas con una persona o con la clasificación de un trabajo. § Evidencias de la competencia tales como resultados de evaluación, hora, fecha, método de evaluación o identificación de la autoridad de certificación de dicha competencia. § Dimensiones relacionadas con el contexto, tales como el nivel de interés de la persona en dicha competencia o la importancia de una competencia para un puesto de trabajo, o con la propia evidencia, tal como el nivel de alcanzado en una competencia. 149 Figura 4.1.a. Marco general de competencias de IMS RDCEO. Contexto Definición Evidencia Dimensiones No obstante, aunque el modelo formal propuesto por RDCEO simplifica procesos de intercambio e integración de competencias también tiene algunas limitaciones debido principalmente a que se centra en el formato de los datos en vez de en cómo deben utilizarse dichos datos. Por ejemplo, permite el intercambio automático de la información entre sistemas diferentes pero la interpretación de dicha información debe ser realizada por una persona. Además la especificación no contempla la agregación de competencias simples en otras competencias de mayor nivel ni aborda cómo dichas competencias pueden ser contrastadas, certificadas, almacenadas o utilizadas como parte de un proceso de diseño instructivo o de gestión del conocimiento. Finalmente, tampoco especifica cómo se estructuran, almacenan o intercambian los registros de competencias asociados con un individuo. Esta especificación RDCEO está relacionada con otras especificaciones de IMS como son IMS LIP, IMS Meta-Data (o su estándar relacionado IEEE LOM) o IMS Simple Sequencing. Quizás el ejemplo más directo es su uso con IMS LIP ya que en un perfil determinado las entradas a los objetivos (goals) o competencias (competency) pueden ser referencias RDCEO. Otro uso indirecto es cuando se referencia un certificado desde LIP y dicho certificado puede a su vez hacer referencia a una instancia RDCEO concreta. La relación con LOM es doble: por un lado un registro o instancia RDCEO puede tener su parte opcional de metadatos asociados que identifiquen aspectos relativos, por ejemplo, al autor, al catálogo, a la fecha de creación, etc. Por otro lado, hay campos de LOM que pueden hacer referencia a instancias RDCEO como, por ejemplo, objetivo educacional o prerrequisito. Tomando como partida IMS RDCEO la asociación IEEE ha propuesto un nuevo estándar denominado Reusable Competency Definition (IEEE RCD) que ha sido formalmente aprobado como el estándar 1484.20.1 (IEEE RCD, 2008) y publicado definitivamente el 25 de enero de 2008. Aunque todavía no existen clasificaciones o jerarquías estándar de competencias ni representaciones o métodos ampliamente aceptados y usados en la industria para articular organizar e intercambiar competencias entre sistemas sí hay un creciente interés en el tema. Dos ejemplos de esta situación son los esquemas para la representación de competencias en el mundo de los recursos humanos desarrollado 150 por el consorcio HR-XML (http://ns.hr-xml.org/2_3/HR-XML2_3/CPO/Competencies.html) y, en el mundo de la medicina, la iniciativa MedBiquitous (http://www.medbiq.org/working_groups/competencies/index.html) que trata de mejorar la educación en el campo médico mediante el desarrollo de estándares tecnológicos y tiene un grupo de trabajo centrado en competencias. En este capítulo se detallan las características de la especificación IMS RDCEO. Para ello, se comienza describiendo una visión conceptual de la especificación. Tras esto, siguiendo el caso de estudio planteado en la sección 3.3 se presenta un ejemplo de uso consistente en el modelado de una competencia del alumno de ejemplo. 4.2. VISIÓN CONCEPTUAL COMPETENCIAS DE LA DEFINICIÓN DE El modelo de datos planteado por RDCEO es minimalista pero extensible. El objetivo es que permita representar las competencias de una forma simple pero que a la vez no imponga restricciones sobre qué modelo de competencias se considere o de cómo se pretendan utilizar. Esto permite que la especificación sea utilizada por diferentes grupos de interés o comunidades de práctica para intercambiar información de acuerdo a su propio modelo de competencias (por ejemplo, el modelo HR-XML para el caso de la gestión de recursos humanos). La extensibilidad se puede lograr de dos maneras: o bien mediante la propia definición de competencia u objetivo educacional o bien mediante la inclusión de metadatos (este aspecto se describe más adelante con mayor nivel de detalle). El modelo de información propuesto para una definición de competencia reutilizable es bastante simple y consta de cinco elementos principales (Figura 4.2.a): Identificador El campo identificador (identifier) es una etiqueta que identifica de forma unívoca una definición de competencia o un objetivo educacional. Este identificador es suficiente para poder hacer referencia a una competencia en cualquier sistema. Este identificador consta de dos partes: un catálogo y una entrada. Título El campo título (title) es una etiqueta obligatoria que identifica la competencia de forma que pueda ser comprensible para las personas. Habitualmente la referencia unívoca que es el identificador no da idea de lo que representa dicha competencia. El título puede repetirse en distintos idiomas. Descripción El campo descripción (description) es un campo de texto opcional que describe la competencia de forma que sea interpretable por una persona. Esta descripción puede repetirse en varios idiomas. Definición El campo definición (definition) es una descripción opcional y estructurada de la competencia, en la que normalmente se usan atributos tomados de un modelo 151 específico sobre cómo deben estructurarse o definirse estas competencias u objetivos educativos. Con este propósito una definición puede incluir un identificador opcional del modelo usado (model) y una colección arbitraria de asertos o expresiones (statements) que determinan dicha competencia. En una definición reutilizable pueden aparecer varias definiciones, por ejemplo, para describir una misma competencia de acuerdo con distintos modelos. Metadatos Los metadatos (metadata) son opcionales y corresponden a toda la definición. Se recomienda que para este campo se empleen los elementos que se consideren relevantes de los definidos por LOM. Figura 4.2.a. Estructura de una definición de competencia IMS RDCEO. 1 1 competencia identificador título 0.. ∞ descripción 0.. ∞ 0..1 definición Metadatos 4.3. EJEMPLOS DE POSIBLES APLICACIONES Como ya se ha mencionado la especificación se centra en la representación de los datos de las competencias dentro de su marco general de referencia pero no entra en cómo deben usarse. No obstante en el documento de buenas prácticas y guía de implementación que se incluyen con la especificación también se describen algunas posibles formas en las que se puede aplicar RDCEO. 4.3.1. Casos de uso Uno de los usos descritos es su aplicación como bloques constructivos para crear mapas o taxonomías de competencias. Estos mapas o taxonomías serían básicamente una colección organizada de referencias a definiciones de competencias RDCEO. Esto normalmente implica incluir información de relación y clasificación y la forma de realizarlo es mediante el uso del campo de metadatos para cada competencia. Un segundo ejemplo típico es el uso de RDCEO en el análisis de habilidades de una persona. Normalmente los registros de competencias personales contienen información sobre la evidencia de habilidades o conocimientos (o la ausencia de ellos) 152 conjuntamente con una referencia a una definición de competencia. Estas definiciones de competencia también se pueden referenciar desde un determinado modelo de competencias. Por tanto haciendo la correspondencia entre estos dos usos se puede generar una colección de referencias de definición de competencias donde se relacionan habilidades y competencias sin tener que repetir información. Además de este modo la información se almacena de una forma estándar y, por tanto, de una forma más interoperable. Este aspecto podría usarse, por ejemplo, en los sistemas de enseñanza que son capaces de adaptar y personalizar el comportamiento del sistema para cada usuario concreto, de modo que tener una descripción de sus conocimientos previos y sus objetivos es crucial en todo el proceso. Pero quizás el mayor campo de aplicación es en e-learning en relación con el nuevo modelo introducido con el modelo de objetos de aprendizaje (OA) (Polsani, 2003; Balatsoukas et al., 2008) y su evolución a unidades de aprendizaje (con el significado introducido por la especificación IMS LD descrita en la sección 1.5). Si el sistema de elearning que usa OA tiene incluidos procesos de evaluación del conocimiento adquirido al superar cada OA, entonces la relación con competencias RDCEO puede establecerse directamente. En el caso de unidades de aprendizaje que tienen un mayor tamaño las competencias y objetivos educativos pueden agregarse en competencias de mayor complejidad. Esto permite crear nuevos escenarios de uso en el diseño de cursos ya que un educador podría comenzar el diseño de un curso especificando cuáles son sus objetivos educativos (learning outcomes) para, a continuación, buscar o desarrollar los OA o unidades de aprendizaje que mediante su composición permiten obtener los objetivos educativos deseados. Esto mismo se podría hacer con los procesos de evaluación formal de la adquisición de dichas competencias (si es que existen). Este enfoque permite también nuevas oportunidades para los usuarios ya que simplificaría la localización de cursos en función de los intereses que tengan, del conjunto de carencias que se quieran resolver o de las habilidades que se necesiten adquirir para resolver una determinada necesidad (por ejemplo, habilidades o capacidades laborales necesarias para obtener un mejor puesto de trabajo). 4.3.2. Ejemplo de uso Para ejemplificar el uso de la especificación RDCEO en las siguientes secciones, se trata de complementar el caso de estudio propuesto en el capítulo 3. Dicho caso de estudio incluía un ejemplo de currículum vítae de un alumno con informaciones diversas que podían ser formalizadas empleando la especificación IMS Learner Information Package (IMS Global Consortium, 2005). Desde el punto de vista de la definición de competencias, resulta especialmente interesante el siguiente fragmento extraído del currículum de ejemplo de la sección 3.3, que nos servirá para ejemplificar el uso de RDCEO para definir competencias. 153 (…) CONOCIMIENTOS TÉCNICOS • Programación Imperativa: Pascal (…) En el caso de estudio, este fragmento correspondiente a los conocimientos técnicos del alumno se describía informalmente como parte un bloque de tipo transcript como se observa en la Figura 3.4.7.b. Tal y como se indicaba en la sección 3.4.10, el campo description de una definición de competencia en un documento IMS LIP puede incluir una referencia a un documento externo codificado de acuerdo con la especificación RDCEO (ver Figura 3.4.10.b). Este documento contiene una descripción más formal y estructurada de las competencias del alumno. La siguiente sección describe la estructura detallada de estos documentos de definición de competencias. 4.4. ESTRUCTURA XML El modelo de información de IMS RDCEO se puede expresar como lenguaje de marcado XML. En este apartado se describen los distintos tipos de elementos (las etiquetas) introducidos por dicho lenguaje en el esquema documental (XML schema) propuesto en la especificación. En la definición de las competencias hay dos elementos comunes que se utilizan en distintas partes: § Cadenas de caracteres. Las cadenas de caracteres representan frases orientadas a ser interpretadas por una persona. Se usa el elemento langstring que tiene el atributo xml:lang para permitir especificar el idioma en el que está dicha frase. § Términos de un vocabulario. Los términos de un vocabulario vienen determinados por el elemento source que identifica el vocabulario fuente y por el elemento value que describe el término concreto (token) dentro de dicho vocabulario. 4.4.1. El elemento rdceo El elemento rdceo es el elemento raíz de los documentos marcados mediante la especificación IMS RDCEO. § § El primer elemento, de carácter obligatorio, es el elemento identifier, que identifica de forma única a la competencia. El siguiente elemento es el campo title que debería ser una etique concisa para que una persona pueda saber de qué trata la competencia. 154 § § § El elemento description permite añadir una descripción en lenguaje natural que describa la competencia y puede aparecer varias veces, por ejemplo, en distintos idiomas. El elemento definition es opcional y contiene una definición estructurada de la competencia. Esta definición estructurada consiste en una posible referencia a un modelo y una serie de expresiones (como se describe más adelante). Si se repite el elemento cada ocurrencia debe corresponder a un modelo distinto. El elemento metadata es opcional y contiene metadatos globales a la competencia. Se recomienda que estos metadatos sigan el estándar LOM. La Figura 4.4.1.a esquematiza la estructura gramatical del elemento rdceo. Figura 4.4.1.a. Estructura gramatical del elemento rdceo. Siguiendo esta estructura, la competencia “Programación Imperativa: Pascal” del caso de estudio se puede describir con mucho detalle. En la figura Figura 4.4.1.b podemos encontrar la descripción de acuerdo con el Currículo Conjunto en Computación definido por el Institute of Electrical and Electronics Engineers (IEEE) y la Association for Computing Machinery (ACM) (http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf ). 155 Figura 4.4.1.b. Ejemplo de documento IMS RDCEO que define la competencia “Programación imperativa: Pascal” según el currículo propuesto por los organismos IEEE y ACM. <?xml version="1.0" encoding="utf-8"?> <rdceo> <identifier> http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/cc2001/cc2001.pdf#PF1 </identifier> <title> <langstring xml:lang="es-ES">Programación Imperativa: Pascal</langstring> </title> <description> <langstring xml:lang="es-ES"> Domina los conceptos de la programación imperativa estructurada y el lenguaje de programación Pascal </langstring> </description> <definition> <model>IEEE and ACM Join Computing Curricula</model> <statement statementname="Condition"> <statementtext> <langstring xml:lang="es-ES"> Ha superado un curso de Introducción a la Programación centrado en los principios de la programación estructurada </langstring> </statementtext> </statement> <statement statementname="Condition"> <statementtext> <langstring xml:lang="es-ES"> Domina la sintaxis del lenguaje de programación Pascal </langstring> </statementtext> </statement> <statement statementname="CoreKnowledge"> <statementtext> <langstring xml:lang="es-ES"> Construcciones fundamentales de la programación imperativa </langstring> </statementtext> </statement> <statement statementname="CoreKnowledge"> <statementtext> <langstring xml:lang="es-ES">Algoritmos y solución de problemas</langstring> </statementtext> </statement> <statement statementname="CoreKnowledge"> <statementtext> <langstring xml:lang="es-ES">Fundamentos de estructuras de datos</langstring> </statementtext> </statement> </definition> <metadata> <rdceoschema>IMS RDCEO</rdceoschema> <rdceoschemaversion>1.0</rdceoschemaversion> <lom xmlns="http://www.imsglobal.org/xsd/imsmd_rootv1p2p1"> <!-- Metadatos LOM --> </lom> </metadata> 156 4.4.2. El elemento identifier El propósito del elemento identifier es tener una identificación unívoca de la competencia. De hecho una vez publicada una competencia nunca debería ser modificada y si es necesario modificarla habría que crear una nueva o incluso una copia. Este identificador es obligatorio y está compuesto de un identificador de catálogo y una entrada en dicho catálogo que se concatenan con el carácter “#” formando una cadena única. La idea es que el identificador sea un URN (Universal Resource Name) o una URI (Universal Resource Indicator). Si no aparece el carácter “#” se asume que la cadena es la entrada del catálogo y el valor del catalogo es nulo. Por ejemplo, en la figura Figura 4.4.1.b encontramos la siguiente cadena: http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/education/ cc2001/cc2001.pdf#PF1 La primera parte es la dirección web del informe que describe los contenidos del currículo, mientras que la entrada concreta en dicho catálogo sería “PF1”. 4.4.3. El elemento title El propósito del elemento title es tener una etiqueta de la definición de competencia que sea comprensible por una persona. Tiene que haber un único título para cada definición de competencia pero dicho título puede aparecer en distintos idiomas. Por ejemplo, una definición con un título tanto en inglés americano como en español sería: <title> <langstring xml:lang="en-US">Imperative Programming: Pascal </langstring> <langstring xml:lang="es-ES">Programación Imperativa: Pascal</langstring> </title> 4.4.4. El elemento description El propósito del elemento description es tener un campo de texto opcional que describe la competencia de forma más extensa y que sea entendible por una persona. Esta descripción también puede repetirse en varios idiomas. 4.4.5. El elemento definition El elemento definition es opcional y su propósito es poder proporcionar una definición estructurada de la competencia. Como se observa en la Figura 4.4.5.a, una definición puede incluir un identificador opcional del modelo usado (model) y una colección arbitraria de asertos o expresiones (statements) que determinan dicha 157 competencia. En una competencia pueden aparecer varias definiciones, por ejemplo, para describir esa misma competencia de acuerdo con distintos modelos. Figura 4.4.5.a. Estructura gramatical del elemento definition (omitiendo atributos). 0..1 definition 1.. ∞ model statement 0.. ∞ 0.. ∞ statementtext statementtoken El elemento opcional model permite incluir una cadena que identifique qué modelo se utiliza como referencia para proporcionar la definición estructurada de la definición. Este modelo debe ser suficientemente específico para evitar conflictos de nombres, por tanto, se recomienda que sea una URI (Universal Resource Indicator). El elemento statement es una colección arbitraria de uno o más asertos o expresiones que determinan la definición de estructura de la competencia. Cada expresión es una descripción de una característica de la definición. Una expresión está compuesta de las siguientes partes: § statementid, este atributo opcional es una cadena de texto que actúa como identificador local de la expresión dentro del modelo § statementname, este atributo opcional es un token que se usa para etiquetar la expresión. Este token se toma del vocabulario fuente definido en el modelo identificado por el elemento model. § statementtext, este elemento opcional es una descripción textual de los aspectos de la competencia. Este texto puede aparecer repetido en varios idiomas. § statementtoken, este elemento opcional es un token que se obtiene de una fuente controlada como, por ejemplo, un vocabulario. Es un término de un vocabulario y como se ha descrito previamente, está compuesto por dos elementos que determinan el propio token (value) y la fuente de de la que proviene (source). Aunque propiamente dichos todos los elementos y atributos de una expresión son opcionales, en la práctica en una expresión debe aparecer por lo menos uno de dichos componentes para que la expresión sea útil. Normalmente si aparece el elemento statementtext entonces no aparece el elemento statementtoken y viceversa. 158 4.4.6. El elemento metadata El elemento metadata es opcional y su propósito es proporcionar un contenedor para cualquier tipo de metadatos (aunque se recomienda que para estos metadatos se use el estándar LOM). Los componentes de este elemento son: § rdceoschema, es un elemento opcional que determina el esquema (schema) documental RDCEO utilizado en la definición de competencia. Si no aparece se asume que su valor es “IMS RDCEO”. Si aparece otro valor puede indicar que se está usando un perfil de aplicación concreto (eso sí, no debe usarse para indicar qué modelo concreto se está empleando). § rdceoschemaversion, es un elemento opcional que permite especificar la versión del esquema RDCEO que se utiliza. Si no aparece se asume que es la versión 1.0. 4.5. EXTENSIBILIDAD Esta especificación contempla desde un principio que, a pesar de la generalidad con la que se tratan de definir las competencias, puede darse el caso de aplicaciones que consideren que dichas definiciones son demasiado restrictivas y, por tanto, necesiten ampliarlas o extenderlas para lograr sus objetivos concretos. La extensibilidad se puede lograr de dos maneras: o bien mediante la ampliación de la propia definición de competencia con nuevos elementos y atributos, o bien mediante la utilización del elemento de metadatos. En la especificación se recomienda que se emplee la primera de las formas. La extensibilidad mediante la inclusión de elementos adicionales es posible en los siguientes elementos: § <rdceo> § <title> § <description> § <definition> § <statement> § <statementtext> § <statementtoken> § <metadata> Los elementos adicionales deben cumplir dos condiciones: la primera es que deben ir después de los elementos ya definidos en la especificación, y la segunda es que los elementos de extensión deben contener una declaración de espacio de nombres 159 diferente a la del elemento contenedor. En este segundo caso el espacio de nombres puede ser expresado mediante mecanismos de bloque o de prefijo. Figura 4.5.a. Visualización del schema RDCEO en XMLSpy donde aparece el mecanismo de extensibilidad extelement para el elemento rdceo. 5. IMS ACCESS FOR ALL 5.1. INTRODUCCIÓN Una de las principales características de los entornos virtuales de enseñanza es que universalizan el acceso a la información y el conocimiento, facilitando los procesos de aprendizaje “en cualquier momento” y “en cualquier lugar”. Pero esta característica realmente no se extiende a “cualquier persona” ya que muchos de estos sistemas tienden a excluir a las personas con distintos tipos de discapacidad. Las más afectadas suelen ser las personas con ceguera total o parcial. Lo más habitual en estos casos es que los usuarios accedan a Internet empleando navegadores textuales con capacidad de leer el texto de las páginas web en voz alta, pero la mayoría de las aplicaciones web, en un intento de mejorar sus diseños y estética, tienden a ignorar este hecho y emplean elementos que resultan muy 160 disruptivos para este tipo de navegadores (como interfaces realizadas con Flash u otros elementos activos no textuales). Existen distintos esfuerzos que intentan conseguir que la Web sea universalmente accesible, la mayoría de ellos encaminados a crear páginas limpias y organizadas empleando aquellos elementos del estándar HTML que casan mejor con el uso de navegadores adaptados para personas con discapacidad. Estándares y recomendaciones como los propuestos por el Consorcio W3C a través del Grupo de Trabajo para Guías de Accesibilidad del Contenido Web (Web Content Accessibility Guidelines Working Group o WCAG WG - http://www.w3.org/WAI/GL/) tratan este problema de una manera genérica, intentando mejorar la accesibilidad de la web en general. En el caso de los entornos virtuales de enseñanza el problema es incluso más acuciante. Muchos contenidos educativos se basan en el uso de diagramas, imágenes y vídeos que no son aptos para personas ciegas. Similarmente, un vídeo en el que el sonido juegue un papel importante (por ejemplo, al incluir una voz que describe los eventos) no resulta accesible para personas sordas. Cuanto más ricos y variados son los formatos en los que se plasma el contenido educativo, más necesario se hace ir más allá de las recomendaciones publicadas por el Consorcio W3C para la generación de documentos accesibles. 5.1.1. Una problemática compleja AccessForAll es la denominación genérica empleada por el consorcio IMS para designar sus iniciativas y esfuerzos relacionados con potenciar la accesibilidad de los contenidos educativos a personas con necesidades especiales derivadas de su entorno, circunstancias o discapacidades. Es importante señalar que en aunque otros estándares y recomendaciones emplean el término “accesibilidad” para referirse a la habilidad de ciertos sistemas de información para ajustarse a las necesidades de personas con discapacidades, desde IMS se amplía la definición de este concepto defendiendo que, en ciertos contextos, cualquier usuario puede necesitar contenidos especialmente adaptados independientemente de su condición física (por ejemplo, una persona en un sitio público no puede acceder a contenidos sonoros independientemente de sus condiciones físicas) . Se redefine por tanto el concepto de “accesibilidad” para incluir cualquier desajuste entre las necesidades del alumno y las características del contenido educativo presentado. Un sistema se considera accesible si es capaz de modificar su comportamiento y contenido para ajustarse a las necesidades de los distintos alumnos en los distintos contextos de aprendizaje. Esto supone ampliar la noción específica de “discapacidad” por la noción de “diversidad funcional”. Esto añade una complejidad más en el proceso, al exigir que el proceso de adaptación para accesibilidad no se centre en alumnos concretos, sino en una combinación del alumno y el entorno. Para ejemplificar esta problemática, planteamos el siguiente ejemplo, adaptado a partir de uno de los casos de uso de la especificación IMS ACCLIP (IMS Global Consortium, 2003): 161 Los técnicos de mantenimiento de una compañía aérea tienen acceso a un repositorio de materiales didácticos con información sobre los procesos de reparación y mantenimiento de los motores de los distintos aviones con los que trabajan. Los trabajadores suelen acceder a estos contenidos como parte de su programa de entrenamiento, habitualmente desde su casa. Por otro lado, durante muchos procedimientos, estos trabajadores emplean ordenadores portátiles para seguir los contenidos y tutoriales mientras realizan las reparaciones. Pero estos procedimientos se realizan en entornos ruidosos (como un hangar de un aeropuerto) y la normativa de seguridad exige que los trabajadores empleen protecciones auditivas. Por tanto, uno de estos trabajadores que accede al sistema desde su casa puede seguir sin dificultad contenidos en forma de, por ejemplo, video-tutoriales. Pero si el mismo trabajador accede desde el hangar, el sistema deberá adaptar o sustituir estos contenidos para permitir su consulta sin necesidad de escuchar los contenidos sonoros (por ejemplo, añadiendo subtítulos al vídeo). 5.1.2. Tres aspectos de un mismo problema La idea de partida de la iniciativa IMS AccessForAll es que para garantizar que los alumnos con necesidades especiales (debidas a condiciones personales o de su entorno) puedan acceder a los contendos educativos digitales es necesario un enfoque que ataque el problema desde varias perspectivas distintas (ver Figura 5.1.2.a). En primer lugar, es necesario ser consciente durante la creación de los contenidos de aquellas características de los mismos que los pueden hacer poco accesibles, como por ejemplo el uso de materiales sonoros sin subtítulos descriptivos o el uso de diagramas que no puedan ser interpretados por sistemas sonoros para personas de visión limitada. Este primer tema, de gran importancia y complejidad, no es tratado por IMS a nivel de especificación al considerar que existen numerosos recursos y materiales con indicaciones sobre la creación de contenidos accesibles. Aún así, el grupo de trabajo AccessForAll ha publicado un documento con una descripción abreviada y muy general de algunas de las ideas que deberían aplicarse (IMS Global Consortium, 2005). Este documento incluye numerosas referencias a información sobre la creación de contenidos más accesibles. Pero este problema no es el principal desde el punto de vista de la creación de entornos virtuales de enseñanza. El problema que debe abordarse y en el que se centran los esfuerzos de AccessForAll es el de alinear las necesidades de los distintos usuarios y entornos con los materiales educativos apropiados. Para cada alumno es necesario conocer sus necesidades personales concretas así como los posibles contextos que puedan añadir nuevas necesidades puntuales. Una vez se dispone de esta información, es necesario encontrar los contenidos apropiados para satisfacer estas necesidades concretas. Por este motivo, el grupo de trabajo IMS AccessForAll ha publicado dos especificaciones distintas, las cuales se describen en este capítulo. La especificación 162 IMS Accessibility for LIP (IMS Global Consortium, 2003) extiende la especificación IMS LIP descrita en el capítulo 3, permitiendo registrar las preferencias y necesidades de accesibilidad de los alumnos registrados en el sistema en sus distintos contextos. La especificación IMS AccessForAll Metadata (IMS Global Consortium, 2004), por su parte, se centra en asociar metadatos relativos a la accesibilidad a los contenidos educativos desplegados en el sistema. El proceso de permitir el acceso universal consiste por tanto en encontrar y servir contenidos cuyos metadatos sobre accesibilidad coincidan con las necesidades del perfil de cada alumno específico. Figura 5.1.2.a. Especificaciones y documentos producidos por el grupo de trabajo IMS AccessForAll. Guidelines for the Development of Accessible Applications AccessForAll IMS AccessForAll MetaData specification IMS Accessibility for LIP specification 5.2. IMS ACCESSIBILITY FOR LIP La especificación IMS Accessibility for LIP (de ahora en adelante, IMS ACCLIP) supone una extensión de la especificación original IMS LIP (descrita en el capítulo 3) orientada a permitir la inclusión en los perfiles de los alumnos información acerca de sus necesidades derivadas de características ambientales o fisiológicas. La especificación se centra en dos modificaciones concretas que se realizan sobre la especificación IMS LIP. La primera, tal y como se describe en la sección 5.2.1 es la inclusión de estructuras para indicar las preferencias y necesidades de cada alumno de cara a interactuar con el contenido del sistema. La otra modificación, descrita en la sección 5.2.2, es la inclusión de mecanismos para definir peticiones especiales de los alumnos de cara a interactuar con determinados elementos de contenido, como podría ser la necesidad de usar un intérprete durante un examen. 163 5.2.1. Definición de Preferencias Las preferencias que se pueden definir mediante la especificación IMS ACCLIP se dividen en tres categorías fundamentales: § Formato: Los perfiles de los alumnos pueden incluir peticiones sobre los dispositivos de salida especiales que pudiesen necesitar así como el formato de los contenidos a mostrar, incluyendo elementos como los tamaños de los textos, las combinaciones de colores o el comportamiento de la interfaz de usuario. § Control: En esta categoría incluimos las necesidades especiales referidas a los mecanismos de entrada mediante los cuales el alumno interactúa con el sistema como pueden ser un teclado, un ratón, un sistema de comandos de voz, un dispositivo de braille, etc. § Contenido: Ciertos contenidos incluyen características que los hacen poco accesibles como pueden ser diagramas explicativos o recursos sonoros. La especificación IMS ACCLIP permite definir las necesidades que un alumno pueda tener de cara a disponer de contenidos alternativos en estos casos. Por otro lado, como ya se mencionaba en el ejemplo de la sección 5.1.1, los requisitos de AccessForAll incluyen la posibilidad de que un mismo alumno tenga necesidades distintas en distintos contextos (distinguiendo por ejemplo entre acceder desde un ambiente tranquilo o un entorno ruidoso). Partiendo de estos requisitos, la especificación IMS ACCLIP extiende la funcionalidad del elemento accessibility de la especificación IMS LIP (ver sección 3.4.8) añadiendo un nuevo elemento denominado accessForAll2, cuya estructura podemos observar en la Figura 5.2.1.a. Figura 5.2.1.a. Estructura gramatical del elemento accessForAll empleado para indicar las preferencias y necesidad de accesibilidad de los alumnos. accessForAll 1 .. ∞ context 0 .. 1 display 0 .. 1 control 0 .. 1 content El elemento accessForAll del perfil de cada alumno puede contener uno o más elementos de tipo context. Esto permite definir, para un mismo alumno, distintos 2 La especificación IMS LIP incluye el elemento disability originalmente pensado para cubrir algunos de los aspectos ahora cubiertos por IMS ACCLIP. Con la introducción del elemento AccessForAll, el elemento disability queda obsoleto y no debe usarse. 164 perfiles de accesibilidad en función del entorno o la situación en que se encuentre, de acuerdo con las necesidades identificadas en el ejemplo de la sección 5.1.1, tal y como se observa en la Figura 5.2.1.b. Cada posible perfil definido puede contener, opcionalmente, los siguientes elementos: § El elemento display se emplea para definir requerimientos y preferencias relativas a los formatos y tecnologías de salida empleados por el sistema. Este elemento, de gran complejidad, permite indicar cuestiones como la necesidad de emplear software que lea la información textual de la pantalla (así como todos sus parámetros de configuración), la necesidad de emplear técnicas que aumenten la legibilidad de los contenidos (por ejemplo, ampliando el tamaño de las letras o aumentando el contraste), el uso de dispositivos que traduzcan los textos a braille, etc. § El elemento control se emplea para definir requerimientos y preferencias relativas a los mecanismos de entrada. Mediante este elemento se pueden indicar necesidades como el empleo de teclados especiales (con teclas más accesibles o mostrados por pantalla), emulación del uso del ratón mediante mecanismos alternativos (uso del teclado o de dispositivos que detectan el lugar hacia donde apuntan los ojos) o incluso interacción mediante reconocimiento de voz. § El elemento content, por su parte, se emplea para indicar los tipos de contenido alternativo que el alumno puede usar en caso de que los contenidos por defecto no se ajusten a sus necesidades de accesibilidad. Mediante este elemento se definen, por ejemplo, posibles alternativas al uso de elementos visuales, alternativas a los elementos sonoros, necesidad de evitar textos o incluso la necesidad de emplear materiales adicionales como diccionarios o calculadoras de cara a interactuar con el contenido. Este elemento se refleja directamente en la especificación IMS AccessForAll Metadata, empleada para indicar las modalidades de cada unidad de contenido y para describir las características de los posibles recursos alternativos tal y como se describe en la sección 5.3. 165 Figura 5.2.1.b. Ejemplos de definición de contextos para su inclusión en el perfil de un usuario concreto formalizados mediante la especificación IMS ACCLIP. Se muestran definiciones de contextos para casos de discapacidad visual o para acceso mediante un dispositivo móvil. <context identifier="Discapacidad-Visual"> <display> <braille> <brailleGeneric> <grade usage="required" value="1"/> <numDots value="8"/> <numCells value="80"/> <dotPressure value="0.5"/> <statusCell value="left"/> </brailleGeneric> </braille> </display> <control> <voiceRecognition> <voiceRecognitionGeneric> <microphoneGain value="0.5"/> <controlsWindow value="true"/> </voiceRecognitionGeneric> </voiceRecognition> </control> <content> <alternativesToVisual> <audioDescription usage="required" type="expanded"/> </alternativesToVisual> </content> </context> <context identifier="Dispositivo-Movil "> <display> <structuralPresentation> <contentDensity usage="preferred" value="overview"/> <contentViews usage="notUse" value="imageIntensive"/> </structuralPresentation> </display> <control> <tactile> <tactileGeneric/> </tactile> </control> <content> <alternativesToVisual> <audioDescription usage="preferred" type="expanded"/> <longDescriptionLang usage="preferred"/> </alternativesToVisual> </content> </context> 5.2.2. Solicitud de servicios adicionales Los alumnos con necesidades especiales de accesibilidad pueden necesitar de apoyos o servicios adicionales cuando interactúan con determinadas unidades de contenido. Esto es especialmente aplicable cuando tratamos con exámenes y tests para los cuales un alumno puede solicitar estos apoyos adicionales de cara a realizar la prueba en las mejores condiciones posibles. Estos apoyos podrían incluir el uso de un intérprete, ubicarse en una sala distinta al resto de participantes, usar dispositivos de entrada/salida alternativos o disponer de tiempo adicional para realizar la prueba. La especificación IMS ACCLIP presenta los elementos necesarios para formalizar y almacenar el proceso de solicitar estos servicios y la gestión de su autorización si procede. Según la visión de esta especificación, una autorización para el uso de servicios adicionales se descompone en las siguientes partes: § Descripción del objeto de aprendizaje: Consiste en identificar a qué examen o prueba se refiere la solicitud. 166 § Petición de servicios: Un texto que contiene la solicitud realizada por el alumno para disponer de servicios adicionales durante la realización de la prueba. § Descripción de los servicios autorizados: Un texto que contiene la respuesta de la institución ante la petición del alumno. Este texto puede coincidir o no con la petición original, en función de si todos los servicios solicitados son autorizados. § Autorización: Persona responsable de la autorización/denegación de los servicios solicitados. § Fechas: La fecha en la que se firmó la autorización y el tiempo de expiración de la misma (si procediese). Para incluir este tipo de transacciones en el perfil del alumno, la especificación IMS ACCLIP modifica el elemento eligibility de la especificación IMS LIP (ver sección 3.4.8) añadiendo un nuevo elemento denominado accommodation cuya estructura se puede observar en la Figura 5.2.2.a. Figura 5.2.2.a. Estructura gramatical del elemento accommodation empleado para almacenar las peticiones de servicios de apoyo realizadas por el alumno. authorizedDate expirationDate accommodation 1 .. ∞ atributos accommodatationPackage 1 .. 1 learningObjectDescription 0 .. 1 requestForAccommodation 1 .. 1 1 .. 1 accommodationDescription authorizedBy El elemento accommodation consta básicamente de una serie de ocurrencias del elemento accommodationPackage. Cada una de estas instancias, describe un proceso de solicitud de servicios de apoyo realizado por el alumno. Este elemento incluye los atributos authorizedDate y expirationDate empleados para indicar, respectivamente, la fecha en la que fue autorizada la petición de servicios de apoyo y la fecha de expiración de dicha autorización. El campo incluye además los siguientes elementos: 167 § El elemento learningObjectDescription incluye una cadena de texto en la que se incluye la descripción del examen o prueba al que se refiere la petición. § El elemento requestForAccommodation contiene una cadena de texto con la petición original realizada por el alumno. § A su vez, el elemento accommodationDescription contiene la descripción de los servicios autorizados (o no) por parte del instructor responsable. § El elemento authorizedBy se emplea para identificar al instructor responsable de la decisión de autorizar o no la solicitud. El uso de estos elementos se ejemplifica en la Figura 5.2.2.b, donde se representa una petición de servicios de apoyo solicitada por un alumno con discapacidad visual de cara a realizar un examen de inglés. Figura 5.2.2.b. Ejemplo de una petición de servicios de apoyo formalizado mediante la especificación IMS ACCLIP. <accomodationPackage authorizedDate="2008-07-01" expirationDate="2008-07-30"> <learningObjectDescription> Examen de Inglés - Nivel 5 - Junio de 2008 </learningObjectDescription> <requestForAccomodations> Se solicitan los siguientes elementos de apoyo: Realización del examen en una habitación aparte; disponer de un sistema de lectura automática para escuchar el contenido; disponer de una máquina Braille para leer el contenido; tiempo adicional para la realización del examen (un 25% adicional). </requestForAccomodations> <accomodationDescription> El alumno podrá realizar el examen en una habitación aparte, podrá emplear la máquina Braille y dispondrá del tiempo adicional solicitado. No se aprueba el uso de tecnología de lectura automática pues podría comprometer la neutralidad de la parte oral del examen. </accomodationDescription> <authorizedBy> Pedro Fernández - Director de la Escuela de Idiomas UCM </authorizedBy> </accomodationPackage> 5.3. IMS ACCESSFORALL METADATA Existen distintas especificaciones y estándares para añadir metadatos a los contenidos educativos con el propósito de facilitar su catalogación, interoperabilidad o su descubrimiento en repositorios (Fernández-Manjón, Sierra et al. 2007). Pero estas especificaciones no cubren las necesidades relativas a la accesibilidad de los contenidos. La especificación IMS AccessForAll Metadata (IMS ACCMD) intenta cubrir este hueco definiendo las estructuras de metadatos a emplear para indicar las características relativas a la accesibilidad de los contenidos educativos. 168 La especificación fue diseñada para actuar como complemento de la especificación IMS ACCLIP (ver sección 5.2), pudiendo emplear los metadatos definidos mediante IMS ACCMD para identificar si un determinado contenido se ajusta a las necesidades indicadas por un alumno concreto en su perfil IMS ACCLIP. 5.3.1. Descripción general En lugar de emplearse meramente como instrumento para comprobar si un recurso es apropiado para un determinado alumno en un determinado contexto, la especificación IMS ACCMD define también los mecanismos para complementar o sustituir los contenidos que no cumplan determinados requisitos de accesibilidad. Por poner un ejemplo, una pieza “contenido” puede consistir en un vídeo con narración y gráficos explicativos. Sus metadatos indicarán por tanto que no es accesible para personas con discapacidad auditiva (o en ambientes ruidosos) ni para personas con discapacidad visual (o que escuchan una narración del contenido mientras realizan alguna otra actividad). Pero estos mismos metadatos pueden incluir referencias a otros contenidos que extienden o sustituyen al vídeo principal. Si el perfil del alumno indicase necesidades relacionadas con el uso de imágenes (discapacidad visual o uso de navegadores que sólo interpreten texto), será necesario incluir una referencia a un fichero que en lugar del vídeo contenga una descripción textual del mismo. Este tipo de fichero secundario se denomina “equivalente” dado que proporciona la misma información que el fichero principal y puede ser empleado en lugar del mismo. Por otro lado, si el perfil del alumno indica necesidades especiales relacionadas con el sonido (discapacidad auditiva, ambiente ruidoso, carencia de equipo sonoro en dispositivo de acceso…), los metadatos pueden incluir una referencia a un fichero adicional que contenga los subtítulos para la narración del vídeo. Este fichero secundario se denomina “equivalente suplementario” ya que modifica el fichero principal ampliando su usabilidad, siendo posible emplear ambos a la vez. Como se observa en la Figura 5.3.1.a, un recurso primario puede relacionarse con distintos recursos equivalentes, pero los recursos equivalentes sólo pueden relacionarse con un único recurso primario. Esto simplifica las dependencias e impide que se puedan llegar a crear cadenas de referencias circulares. 169 Figura 5.3.1.a. Relación entre un recurso primario y distintos recursos equivalentes. Recurso Equivalente (texto explicativo) Recurso Equivalente (subtítulos español) Recurso Primario (video explicativo) suplementario Recurso Equivalente (subtítulos ingles) Recurso Equivalente (subtítulos francés) La especificación IMS ACCMD distingue por tanto distintos tipos de metadatos para los recursos primarios y equivalentes. Los recursos primarios consisten en los documentos originales y es posible que sus creadores no sigan ningún tipo de recomendación o estándar para garantizar o evaluar la accesibilidad de los contenidos. Los metadatos de este tipo de recursos se reducen por tanto al mínimo, limitándose a indicar aspectos como las capacidades sensoriales requeridas (visual, auditiva, etc.), si el contenido se puede transformar directamente (permitiendo por ejemplo cambios de tamaño de fuente o distintas combinaciones de colores) y si existe un fichero alternativo equivalente. Por otro lado, los recursos equivalentes se crean específicamente para tratar con problemas de accesibilidad, por lo que los metadatos de este tipo de recursos son mucho más ricos y detallados. Como es el caso con todas las especificaciones de IMS, los metadatos de la especificación IMS ACCMD se definen mediante documentos XML. El elemento base para los metadatos de un determinado recurso se denomina accessibility y podemos observar su estructura general en la Figura 5.3.1.b. Los dos elementos fundamentales para describir la accesibilidad de un determinado recursos son precisamente los dedicados a definir el recurso primario y los posibles recursos equivalentes asociados. Los siguientes apartados describen con mayor detalle estos dos conjuntos de metadatos. 170 Figura 5.3.1.b. Estructura gramatical de una sección de metadatos sobre accesibilidad. accesibility 1 .. 1 Elemento opcional resourceDescription 0 .. 1 0 .. ∞ primary equivalent 0 o más ocurrencias 5.3.2. Metadatos para recursos primarios Como se mencionaba en la sección anterior, los metadatos empleados para describir recursos primarios se centran fundamentalmente en tres aspectos: § Modalidades de acceso: Las modalidades de acceso indican los sentidos y capacidades necesarios para interactuar con el contenido (visión, oído, tacto o lectura de texto). § Adaptabilidad: Los contenidos primarios de por sí pueden tener la capacidad de adaptarse a determinadas condiciones. § Recursos equivalentes: El recurso primario puede incluir referencias a aquellos ficheros equivalentes (suplementarios o no) inicialmente conocidos. Dado que los ficheros equivalentes incluyen obligatoriamente una referencia al recurso primario, el uso de referencias en los recursos primarios es opcional (aunque recomendable). En la Figura 5.3.2.a podemos observar la estructura de un bloque de metadatos de un recurso primario, tomando como raíz el elemento primary. Dicho elemento raíz incluye los siguientes atributos que tratan los aspectos relacionados con las modalidades de acceso: § El atributo hasAuditory indica si el recurso incluye una componente auditiva, como puede ser un fichero de sonido o un vídeo con pista de sonido. § El atributo hasTactile indica si es necesario emplear el tacto para interactuar con este contenido. § Para indicar la presencia de texto que deba ser leído (o interpretado por un sistema de lectura automática) se emplea el atributo hasText. 171 § Por último, el atributo hasVisual indica la presencia de contenidos visuales como imágenes, vídeos o animaciones. Figura 5.3.2.a. Estructura gramatical de una sección de metadatos de un recurso primario. ? hasAuditory ? hasTactile atributo opcional ? hasText ? hasVisual atributos type 0 .. ∞ adaptability 0 .. ∞ equivalentResource primary Dentro del elemento primary podemos incluir varios elementos adaptability, que describen la adaptabilidad del contenido. Cada uno de estos elementos incluye un atributo type cuyos posibles valores son “displayTransformability” y “controlFlexibility”, para indicar respectivamente las alternativas contempladas para modificar la apariencia del contenido (tamaños de letra, combinaciones de colores, etc.) y los mecanismos de control (teclado, ratón, lector de braille, etc.). El contenido de estos elementos es una referencia a un fichero externo con la descripción de estos mecanismos de adaptabilidad. La especificación IMS ACCMD sugiere emplear informes EARL (http://www.w3.org/TR/EARL10/) para crear estos ficheros. Por último, en caso de conocer a priori uno o más recursos equivalentes, podemos emplear elementos equivalentResource para indicar la ubicación de los mismos, tal y como se observa en la Figura 5.3.2.b Figura 5.3.2.b. Ejemplo de metadatos de un recurso primario. <resourceDescription> <primary hasAuditory="true" hasTactile="false" hasText="false" hasVisual="true"> <equivalentResource>documentos/descripcionDelVideo.html</equivalentResource> <equivalentResource>video/subtitulosEspañol.srt</equivalentResource> <equivalentResource>video/subtitulosIngles.srt</equivalentResource> <equivalentResource>video/subtitulosEspañol.srt</equivalentResource> </primary> </resourceDescription> 172 5.3.3. Metadatos para recursos equivalentes En los casos en los que un recurso primario tenga asociado uno o varios recursos equivalentes, los metadatos correspondientes a dicho recurso incluirán un bloque describiendo cada uno de los mencionados recursos equivalentes. La definición de los metadatos para recursos equivalentes cubre los siguientes aspectos: § Suplementario o alternativo: Como ya se ha mencionado en la sección 5.3.1, los recursos equivalentes pueden ser alternativas completas (se emplean en lugar del recurso primario) o suplementarios (se emplean junto con el recurso primario). § Recurso principal: Todo recurso equivalente va siempre asociado a un único recurso principal mediante una referencia al mismo. § Contenido: Como se describe en la sección 5.3.2, los recursos primarios indican sus modalidades de contenido (texto, imágenes, sonido, etc.). Los recursos equivalentes ofrecen alternativas a dichas modalidades. Así, un recurso con los subtítulos de un vídeo puede actuar como alternativa a la modalidad sonora, pero no a la modalidad visual. Por este motivo es necesario especificar para qué modalidades un determinado recurso equivalente supone una alternativa al recurso primario. La estructura gramatical de los metadatos para un recurso equivalente se puede observar en la Figura 5.3.3.a. Como indica la figura, el elemento raíz se denomina equivalent. Este elemento incluye un atributo supplementary empleado para indicar si es un recurso equivalente suplementario o alternativo. Dentro del elemento equivalent encontramos también los siguientes elementos: § El elemento primaryResource es obligatorio y consiste en una referencia al recurso primario relacionado con este elemento equivalente. § Los elementos opcionales primaryFile se emplean para incluir también referencias a los ficheros concretos que forman el recurso primario. § El elemento content refleja qué tipo de alternativas ofrece este recurso equivalente ante las modalidades del recurso primario. Sus elementos constituyentes se relacionan directamente con el modelo de datos del elemento content de la especificación IMS ACCLIP: - El elemento alternativesToVisual indica en qué manera el recurso equivalente supone una alternativa a la modalidad visual del recurso primario. - El elemento alternativesToText por su parte indica las alternativas ofrecidas a la modalidad textual del recurso primario. 173 - El elemento alternativesToAuditory indica en qué manera el recurso equivalente supone una alternativa a la modalidad sonora del recurso primario. - El elemento learnerScaffold se emplea para indicar recursos adicionales requeridos por el alumno para interactuar con el contenido como pueden ser un diccionario o una calculadora. En este caso, el recurso secundario no supone una alternativa en sí, sino que representa una herramienta externa que el alumno necesita usar para poder interactuar con el recurso primario. Figura 5.3.3.a. Estructura gramatical de una sección de metadatos de un recurso equivalente. ? supplementary equivalent 1 .. 1 primaryResource 0 .. ∞ primaryFile 0 .. 1 content 0 .. 1 alternativesToVisual 0 .. 1 alternativesToText 0 .. 1 alternativesToAuditory 0 .. 1 learnerScaffold En la Figura 5.3.3.b podemos encontrar un ejemplo del uso del elemento equivalent para marcar dos de los recursos equivalentes del ejemplo de la Figura 5.3.1.a. 174 Figura 5.3.3.b. Ejemplo de metadatos de un recurso primario. <resourceDescription> <equivalent supplementary="false"> <primaryResource>videos/video1</primaryResource> <primaryFile>videos/video1.avi</primaryFile> <content> <alternativesToVisual> <audioDescription type="standard" xml:lang="es"/> </alternativesToVisual> </content> </equivalent> </resourceDescription> <resourceDescription> <equivalent supplementary="true"> <primaryResource>videos/video1</primaryResource> <primaryFile>videos/video1.avi</primaryFile> <content> <alternativesToAuditory> <camption type="standard" xml:lang="es"/> </alternativesToAuditory> </content> </equivalent> </resourceDescription> 6. HERRAMIENTAS EDUCATIVOS DE SOPORTE PARA LOS DISEÑOS Otra forma alternativa de ver los lenguajes de modelado educativo (EMLs de su término en inglés Educational Modeling Languages) es como lenguajes que proporcionan un mecanismo a los profesores para que puedan controlar y adaptar un sistema de gestión de aprendizaje (LMS de su término en inglés Learning Management System). Como se ha descrito en el capítulo 1 existen diversos EMLs que varían principalmente en su generalidad y potencia expresiva. Desde el punto de vista tecnológico, podemos dividir las herramientas de soporte a EMLs en diversos tipos: § Herramientas de autoría. Dentro de este conjunto se encuentran las herramientas que son utilizadas principalmente por los profesores para crear las unidades de aprendizaje (UAs o UoL, por sus siglas del inglés Units of Learning). Estas UAs pueden verse como plantillas, de modo que la misma plantilla puede ponerse en práctica, es decir ejecutarse, múltiples veces con distintos participantes en cada reproducción. El proceso requerido para poner en práctica una UA una vez creada recibe el nombre de proceso de publicación. § Herramientas de reproducción. Estas herramientas son utilizadas por los profesores y estudiantes (los participantes) para interactuar con ejecución concreta de una UA. En el caso de los alumnos, estas herramientas permiten acceder a todas las actividades que se incluyen en una UA, además de realizar la función de portal para el resto de herramientas de apoyo que se utilizan en las actividades. En el caso de los profesores, estas 175 herramientas sirven para monitorizar el estado de la UA para cada uno de los alumnos participantes, así como para llevar a cabo las actividades que tengan asignadas los profesores. § Intérpretes. Los intérpretes son aplicaciones informáticas encargadas de interpretar el diseño educativo descrito en una UA. Su misión es gestionar las actividades que deben llevar a cabo los participantes de la UA y la sincronización necesaria que haya entre participantes y actividades. Las herramientas de interpretación interactúan con las herramientas de reproducción para coordinar la secuenciación y la sincronización entre los distintos participantes de la UA. § Herramientas de soporte. Estas herramientas son utilizadas dentro de las actividades educativas definidas en las UAs. Habitualmente se tratan de herramientas informáticas que ya existen y que se utilizan directamente o con ligeras modificaciones para poder ser aplicadas con propósitos pedagógicos. En IMS LD los requisitos de herramientas de soporte son especificados en los entornos asociados a las actividades. Algunos ejemplos de herramientas son los reproductores de contenidos educativos (e.g vídeos, objetos educativos SCORM, etc.), herramientas de comunicación para promover el trabajo colaborativo (e.g. chat, foros, etc.), intercambio de contenidos (e.g. espacio personal, Wiki, etc.), etc. El uso de estas herramientas enriquecen los diseños de aprendizaje a costa, habitualmente, de un mayor trabajo por parte del profesor o el personal técnico. Para simplificar su aplicación, los EMLs normalmente permiten definir de una forma bastante abstracta las herramientas o servicios educacionales que estarán disponibles a la hora de crear una UA. De este modo, las herramientas de interpretación y reproducción de un EML concreto ya pueden tener en cuenta la necesidad de proporcionar un conjunto de herramientas de soporte de forma que las tareas de administración y gestión se ven simplificadas. En la actualidad podemos encontrar diversas herramientas informáticas aplicadas en la educación y más en particular en la creación y publicación de unidades de aprendizaje. Como se introdujo en el capítulo 1 existen diversas aproximaciones a la hora de crear unidades de aprendizaje. En las siguientes sub-secciones se introducirán las WebQuest (sección 6.1) como mecanismo de creación de unidades de aprendizaje informal y JClic (sección 6.2) como herramienta para la creación de unidades de aprendizaje estructurado. La sección 6.3 introducirá la herramienta LAMS que, si bien en la actualidad no sigue ningún estándar educativo particular, ha tenido una gran acogida por la comunidad educativa. La sección 6.4 pone en práctica el caso de estudio del seminario de enología descrito a lo largo del capítulo 2 utilizando LAMS. Finalmente la sección 6.5 describe cómo poner en práctica el caso de del seminario de enología utilizando herramientas concretas para la especificación IMS LD. 6.1. WEBQUEST El concepto de WebQuest fue desarrollado en 1995 por Bernie Dodge y Tom March en la Universidad Estatal de San Diego (Dodge, 1995; Adell, 2004 y Fernández CarballoCalero, 2008). Uno de los objetivos principales de las WebQuest es la integración de las TIC, en particular internet, en las escuelas. Las WebQuest pueden ser 176 consideradas como un mecanismo informal (o en el mejor de los casos estructurado) para definir unidades de aprendizaje en las que el proceso de aprendizaje está guiado y descrito en lenguaje natural. Una WebQuest es una actividad orientada a la investigación en la que la información con la que interactúan los alumnos proviene total o parcialmente de recursos de internet (Dodge, 1995). Las WebQuest pretenden rentabilizar el tiempo del alumno, centrando su actividad en el uso de la información más que en su búsqueda, apoyando la reflexión del alumno en los niveles de análisis, síntesis y evaluación. La estructura que debería tener una WebQuest es la siguiente: § Introducción. Establece el escenario y proporciona la información previa necesaria para llevar a cabo la tarea. § Descripción de la tarea a realizar. Descripción de la tarea investigadora a realizar. Se recomienda que sea una tarea factible en tiempo y que, en particular, sea una tarea de investigación interesante desde el punto de vista del alumno. § Descripción del proceso a seguir. Descripción del proceso recomendado a los alumnos para llevar a cabo su tarea. Es recomendable que este proceso se divida en pasos y tareas más simples. § Descripción de los recursos necesarios. Descripción de los recursos necesarios para llevar a cabo la tarea propuesta en la WebQuest, en particular, enlaces a los recursos web necesarios. § Guía para la recolección de información. Descripción acerca de cómo organizar la información obtenida por los alumnos (e.g. mapas de conceptos, preguntas y respuestas, etc.) que formará parte de los resultados de la actividad y que serán entregados por los alumnos. § Conclusiones. Proporciona unas conclusiones para finalizar la tarea propuesta en la WebQuest. En particular las conclusiones deben hacer referencia a los conceptos con los que el alumno ha trabajado y los conceptos que ha aprendido. La promoción de actividades de investigación siguiendo el paradigma de las WebQuest ha tenido y tiene una gran aplicación en todo el mundo. Algunos sitios web interesantes acerca de la creación, aplicación, uso y herramientas aplicables a las WebQuest son: § http://www.webquest.org § http://questgarden.com/ § http://www.xtec.es/~cbarba1/ § http://www.aula21.net/index.htm § http://www.isabelperez.com/webquest/ La creación de unidades de aprendizaje en base a las WebQuest se lleva a cabo mediante la creación de una página web que guíe a los alumnos tanto en el proceso 177 como a los recursos que estos utilizarán durante el uso de la WebQuest. La estructura de la página web utilizada para guiar el proceso de la WebQuest habitualmente es la misma, por lo que se han creado un conjunto de plantillas básicas (ver Figura 6.1.a) para facilitar la creación de un WebQuest por parte de profesores con conocimientos limitados en informática. Algunas de estas plantillas y herramientas gratuitas para la creación de WebQuest pueden encontrarse en los enlaces mencionados anteriormente. Figura 6.1.a Ejemplo de plantilla web para la creación de una WebQuest. 6.2. JCLIC La iniciativa JClic (http://clic.xtec.net/es/jclic/) proporciona un conjunto de aplicaciones informáticas que permiten la autoría y la publicación de unidades de aprendizaje. En el contexto de JClic una unidad de aprendizaje, denominada proyecto, incluye una o más actividades educativas junto a una o varias secuencias de dichas actividades. Las distintas herramientas que se encuentran dentro del contexto de la iniciativa JClic han sido desarrolladas tras la experiencia del proyecto Clic iniciado en 1992. Además la iniciativa JClic aloja un repositorio de actividades que pueden ser descargadas y modificadas (habitualmente bajo licencias que permiten la libre distribución con ciertas condiciones). 178 La iniciativa JClic distribuye las siguientes herramientas: § JClic Author. La herramienta de autor que permite crear, editar y modificar actividades a través de una interfaz sencilla y amigable. § JClic Player. Es una aplicación de escritorio que permite ejecutar secuencias JClic que se encuentran en el ordenador donde está instalado JClic Player. También existe una versión web, denominada JClic Applet, que permite incrustar el reproductor JClic dentro de una página web. § JClic Reports. Permite recolectar la información generada por los JClic Player en una red de ordenadores, por ejemplo un aula, permitiendo la generación de informes estadísticos sobre los resultados obtenidos por todos los alumnos. Como se ha descrito anteriormente una unidad de aprendizaje en JClic se compone de un conjunto de actividades educativas y la definición de secuencias de actividades simples. JClic permite la creación actividades educativas de los siguientes tipos: § Asociaciones. Los alumnos tendrán que asociar los conceptos que se presentan en dos conjuntos de elementos. § Juegos de memoria. Los alumnos tendrán que ir descubriendo parejas de elementos relacionados que se encuentran escondidos. § Exploración, identificación e información. Permite definir un conjunto de elementos interactivos. En el caso de las actividades de exploración los elementos mostrados son reactivos de modo que al hacer clic con el ratón se muestra información adicional acerca del elemento. En el caso de actividades de identificación permite definir un conjunto de elementos de modo que el alumno tiene que elegir cuáles de ellos cumplen una condición. Finalmente la actividad de información permite definir un conjunto de elementos interactivos que permiten lanzar contenidos textuales y multimedia al hacer clic en alguna de las opciones mostradas. § Puzzles. Plantean actividades en las que el alumno debe reconstruir la información que se presenta inicialmente desordenada. Los tipos de información que pueden ser incluidos son: gráficos, texto y sonidos. También es posible combinar distintas fuentes de información. § Respuesta escrita. Permiten la creación de actividades en las que la respuesta se basa en la escritura de una palabra o frases completas. § Texto. Plantean ejercicios basados siempre en las letras, palabras, frases y párrafos de un texto que hay que completar, entender, corregir u ordenar. Además de contenido textual la actividad puede contener contenidos multimedia y contenidos interactivos. § Sopas de letras y crucigramas. Estas actividades son variantes interactivas de los conocidos pasatiempos del mismo nombre. Las secuencias de los proyectos JClic permiten especificar el orden en el que se muestran las actividades del proyecto a los alumnos. El orden de las actividades de una secuencia puede definirse de las siguientes formas: 179 § Automáticamente. Transcurrido un cierto tiempo desde la finalización de una actividad se pasa a la siguiente actividad. § Interacción con la actividad. Haciendo clic en alguna casilla que tenga como contenido activo la acción de saltar a un determinado punto de la secuencia. § Elegido por el alumno. Haciendo clic en los botones de avance y retroceso de la interfaz de JClic. Durante la autoría, el profesor puede definir el comportamiento de los botones de avance y retroceso que aparecen en la interfaz de JClic Player y que, por defecto, avanzan a la siguiente actividad o retroceden a la actividad anterior. De forma adicional, se pueden especificar saltos a actividades concretas de la secuencia e incluso se pueden definir saltos condicionales en base a los resultados obtenidos o el tiempo empleado por el alumno en una actividad. Como ejemplo de proyectos que se pueden encontrar en el repositorio de actividades de la iniciativa JClic la Figura 6.2.a muestra un conjunto de actividades relacionadas con la conversión entre sistemas de numeración (Redondo Templado, 2006). La Figura 6.2.b muestra el informe generado por JClic Player donde se incluyen distintas medidas que resumen el progreso del alumno con la unidad de aprendizaje: tiempo invertido, número de actividades y secuencias completadas, porcentaje de completitud global. Además también se incluye un resumen detallado por actividad en forma tabular con las mismas medidas. Finalmente, la Figura 6.2.c muestra la unidad de aprendizaje cargada en el editor de secuencias JClic Author. 180 Figura 6.2.a Ejecución de una secuencia de actividades en JClic sobre el sistema binario (Redondo Templado, 2006). 181 Figura 6.2.b Informe generado durante la ejecución de las secuencias de actividades. 182 Figura 6.2.c. Captura de JClic abriendo el proyecto acerca del Sistema Binario (Redondo Templado, 2006). 6.3. LAMS 6.3.1. Introducción La herramienta Learning Activity Management System (LAMS) es uno de los proyectos que se llevan a cabo dentro del Centro de Excelencia en e-learning de la Universidad de Macquarie en Australia (Macquarie University’s E-Learning Centre Of Excellence, MELCOE) dirigido por James Dalziel, creador del propio sistema LAMS. El objetivo de LAMS es proporcionar una herramienta informática para diseñar y automatizar secuencias de actividades educativas. Dentro del conjunto de actividades disponibles en la herramienta se pueden encontrar desde actividades que los alumnos deben llevar a cabo de manera individual (e.g. análisis de contenidos educativos, 183 entregas de trabajos, etc.) a actividades colaborativas que pueden desarrollarse en grupos reducidos de alumnos dentro de una misma clase o incluso la clase completa (e.g. sesiones de chat, foros de debate, etc.). La herramienta LAMS puede utilizarse de manera aislada o en colaboración con otros sistemas de gestión de aprendizaje ampliamente utilizados como, por ejemplo, Moodle, Sakai y Blackboard. Esta integración permite la utilización de LAMS desde el LMS que actualmente se esté usando de manera oficial en la organización o institución educativa pasando a formar parte del repertorio de recursos disponibles a través de dichas plataformas. LAMS surge alrededor de 2002 como herramienta informática que cubre algunas de las deficiencias detectadas en los sistemas de gestión de aprendizaje y en las propuestas de estandarización educativas de la época y que, al menos en parte, permanecen en la actualidad. LAMS aborda los mismos problemas que los lenguajes de modelado educativo (ver capítulo 1), en particular, la tendencia de los sistemas y estándares a centrarse en los contenidos educativos y en los problemas técnicos que surgen con motivo de facilitar el intercambio de dichos contenidos educativos, dejando un poco de lado a profesores y alumnos y sus necesidades pedagógicas. LAMS aborda este problema utilizando las actividades educativas como pieza fundamental y facilitando la aplicación de diseños de aprendizaje en la creación de secuencias de actividades. Cabe destacar que LAMS se inspira en las ideas propuestas en los lenguajes de modelado educativo, en particular, en los lenguajes: Educational Modeling Language (EML-OUNL) e IMS Learning Design (IMS LD) (ver capítulo 1), sin embargo, LAMS no es una implementación de referencia de ninguno de estos lenguajes, sino que pone en práctica el concepto de diseño de aprendizaje promovido por los EMLs. En la actualidad LAMS (en su versión 2.2) es capaz de exportar las secuencias de aprendizaje utilizando IMS LD nivel A, sin embargo no permite la importación de unidades de aprendizaje IMS LD en ninguno de sus niveles. La herramienta LAMS se ofrece con una licencia doble similar a la licencia del servidor de base de datos MySQL. El resultado es que LAMS es una herramienta de software libre bajo las condiciones de la licencia GNU GPL de la Fundación de Software Libre. En particular, la herramienta LAMS puede obtenerse de manera gratuita desde la página de la Fundación LAMS (http://www.lamsfoundation.org/) en sus distintas versiones. Como complemento también se ofrece una licencia comercial dirigida principalmente a empresas. Esta sección no pretende ser un manual completo de la herramienta LAMS, sino una breve introducción a la herramienta y a las posibilidades que ofrece a los profesores para crear secuencias de aprendizaje. Para un mayor detalle acerca del uso de la herramienta LAMS, puede consultar las siguientes fuentes de información: § Wiki oficial de LAMS (en inglés). Esta Wiki se actualiza continuamente con los cambios y características que se incluyen en las nuevas versiones de LAMS. Pueden encontrase varias secciones dirigidas a desarrolladores de herramientas, a administradores de LAMS y, principalmente, a profesores. Gran parte del contenido de esta sección está basado en el material que está disponible en esta Wiki. http://wiki.lamsfoundation.org/display/lamsdocs/Home 184 § Wiki LAMS en castellano. Esta Wiki es una traducción de la Wiki en inglés, y aunque se actualiza regularmente, su información puede estar desfasada respecto a la Wiki en inglés. En particular en esta Wiki (al igual que en su versión en inglés) se proporcionan unas instrucciones muy detalladas para la instalación de LAMS. http://wiki.lamsfoundation.org/display/lamsdocses/Home § Comunidad LAMS. La comunidad de LAMS permite la comunicación y el intercambio de experiencias entre los profesores que actualmente están utilizando LAMS. Dentro de esta comunidad se pueden encontrar muchos ejemplos de secuencias de actividades LAMS, que se pueden importar directamente en la herramienta de autor para su modificación y posterior publicación. Además la comunidad LAMS informa acerca de los distintos eventos de la comunidad en todo el mundo (e.g. conferencias, seminarios, etc.). Finalmente, esta comunidad sirve como mecanismo para contactar e intercambiar experiencias con los desarrolladores de LAMS. http://www.lamscommunity.org § Monográfico sobre LAMS en el Observatorio Tecnológico del ITE (antiguo CNICE). Proporciona un conjunto de tutoriales que cubren diversos aspectos de LAMS (de la versión 2.0.4 en la fecha de escritura de este trabajo), desde su instalación hasta la puesta en práctica de varios casos de estudio. http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag e&pageid=72. 6.3.2. La herramienta LAMS La herramienta LAMS proporciona una solución completa que puede ser utilizada no sólo de apoyo y refuerzo a las clases presenciales si no también como una herramienta de soporte para un curso totalmente online. LAMS ofrece cuatro perspectivas complementarias basadas en la distinción del papel que juegan los actores involucrados en el proceso pedagógico: § Reproducción. Esta perspectiva se centra en el papel de los alumnos proporcionando un reproductor web utilizado para interactuar con las distintas actividades que se proponen en las secuencias. A través del reproductor los alumnos pueden acceder a los contenidos y a las herramientas suministradas en las actividades. Además pueden hacer anotaciones de su progreso en cada una de las actividades, a modo de apuntes, y realizar la entrega de ejercicios y trabajos que se propongan en dichas actividades. § Autoría. Esta perspectiva se centra en el papel de los profesores encargados de crear las secuencias educativas. La herramienta de autor proporciona una notación gráfica que permite la creación, almacenamiento y reutilización de secuencias de actividades. También ofrece la posibilidad de previsualizar la secuencia que actualmente se está editando. 185 § Monitorización y seguimiento. Esta perspectiva se centra en el papel de los profesores y de los ayudantes del profesor. La herramienta de monitorización y seguimiento permite al profesor que creó la secuencia (o a un ayudante del mismo) monitorizar el progreso de los alumnos dentro de la secuencia. En particular, una parte de las tareas de monitorización es permitir el avance de los alumnos cuando se han establecido puntos de sincronización (hitos) dentro de la secuencia de actividades. La herramienta de seguimiento también se utiliza para evaluar los trabajos enviados por los alumnos a través de LAMS. Finalmente, cabe destacar que es posible realizar una edición en vivo (con ciertas restricciones) de las secuencias de actividades que se están ejecutando. Esto es útil, por ejemplo, para añadir alguna actividad extra o para modificar alguna de las actividades cuando se ha cometido un error ortográfico al crear los contenidos o en las descripciones de las actividades. § Administración. Esta perspectiva se centra en el papel de los administradores de la instalación de LAMS. LAMS proporciona una interfaz web simple y a la vez versátil para realizar las tareas básicas de administración del servidor LAMS. Permite, por ejemplo, la creación de clases, grupos, usuarios y la asignación de usuarios a grupos y clases. LAMS incluye una administración jerárquica, de modo que un profesor pueda administrar sus propias clases lo que simplifica la administración general del servidor. El administrador de LAMS es el encargado de la creación de los distintos usuarios que tendrán acceso a la herramienta y, en particular, la asignación de los privilegios del usuario permitiendo el acceso a una o varias de las perspectivas descritas. LAMS es una aplicación web permitiendo que una única instalación de LAMS pueda ser utilizada por múltiples usuarios. Desde el punto de vista técnico la estructura interna de LAMS ha sufrido una gran modificación en el paso de la versión 1.0 a la versión 2.0 con el objetivo de facilitar la integración de LAMS con otras herramientas y plataformas educativas ya existentes. Esto permite que LAMS pueda ser utilizada como un recurso adicional dentro de dichas herramientas. No obstante, con la versión 2.2 los desarrolladores de LAMS han dado un paso más allá permitiendo que los recursos y herramientas de los sistemas en los que LAMS está integrado también puedan ser utilizados y configurados desde la propia herramienta de autor de LAMS. Esta nueva característica (que en la redacción de este trabajo estaba todavía en fase de pruebas) permite que los profesores puedan crear secuencias LAMS utilizando herramientas que ya conocen, e incluso que colaboren con otras actividades LAMS. Uno de los casos prueba es el de la configuración de los foros de Moodle desde LAMS cuando LAMS está integrado dentro de la plataforma Moodle. Finalmente, como detalle técnico cabe destacar que la herramienta LAMS está desarrollada utilizando la plataforma Java Enterprise Edition. Para facilitar la creación de una interfaz atractiva visualmente y que soporte una gran interactividad, la interfaz web ha sido desarrollada con tecnología Adobe Flash. De este modo los usuarios finales de la herramienta, profesores y alumnos, pueden utilizar LAMS a través de un navegador web con la única condición de que tenga soporte para Flash (activado el complemento o plug-in de Flash). Además, como la herramienta LAMS se ha 186 desarrollado sobre la plataforma Java, un servidor LAMS es compatible con todos los sistemas operativos comúnmente utilizados como Windows, Linux y Mac. 6.3.3. Actividades, adaptación secuencias de actividades y mecanismos de Los dos conceptos fundamentales en LAMS son las actividades educativas y las secuencias de actividades. A lo largo de esta sección se introducen estos dos conceptos describiendo sus posibles equivalencias o relaciones con elementos de IMS LD. Las actividades educativas LAMS proporcionan un mecanismo simple para configurar y adaptar herramientas que habitualmente se encuentran en los LMS y en las plataformas de trabajo colaborativo. De este modo, lo importante son las posibilidades pedagógicas ofrecidas por la herramienta, pretendiendo simplificar al máximo los conocimientos técnicos necesarios para su configuración. En comparación con IMS LD las actividades de LAMS pueden verse como plantillas de las Actividades de Aprendizaje y sus Entornos asociados (ver sección 2.5.2). En particular, las actividades LAMS pueden verse como plantillas para los recursos y herramientas que se proporcionarían en un Entorno IMS LD equivalente. LAMS ofrece una gran variedad de actividades. A continuación se describen los distintos tipos de actividades junto a las que están incluidas dentro de dichos tipos: § Actividades de comunicación y colaboración: Foro, Chat, Wiki, DimDim (herramienta de conferencia web). § Actividades de distribución de contenidos: Cartelera, Compartir Recursos. § Actividades para evaluar al alumno y entrega de trabajos: Enviar Archivos, Opción múltiple, Anotador, Preguntas y Respuestas, Lista de tareas, Votación, Encuestas y Colección de datos. § Otras Herramientas. Mapas (Google Maps), Hojas de cálculo. § Actividades combinadas. Permiten configurar dos herramientas a la vez de modo que el alumno tenga la pantalla dividida en dos mitades permitiendo el uso de ambas herramientas al mismo tiempo. Estas herramientas son particularmente útiles, por ejemplo, para escenarios en los que uno de los alumnos actúa de escriba o secretario en una sesión de chat resumiendo los aspectos más importantes debatidos durante la sesión. Las secuencias de actividades no son más que un conjunto de actividades LAMS sobre las que se ha definido un orden concreto. La Figura 6.3.3.a muestra un ejemplo de secuencia de actividades LAMS compuesta por las actividades: Actividad 1 (de tipo Cartelera), Actividad 2 (de tipo Encuesta) y Actividad 3 (de tipo Envío de Archivos). Sin embargo, en este ejemplo aún no se ha establecido el orden entre actividades. El orden entre las actividades de una secuencia LAMS se define mediante el uso de una notación de flecha. Estas flechas se denominan “transiciones” en LAMS. La figura Figura 6.3.3.b muestra las mismas actividades de ejemplo y su ordenación utilizando 187 la notación flecha, donde el orden concreto de las actividades es: primero la Actividad 2, después la Actividad 1 y finalmente la Actividad 3. Figura 6.3.3.a. Ejemplo de notación gráfica para actividades LAMS sin definir el orden de las actividades. Figura 6.3.3.b. Ejemplo de notación gráfica para actividades y la definición del orden entre las actividades. Además de secuencias de actividades puramente lineales, LAMS ofrece la posibilidad de incluir los siguientes elementos dentro de una secuencia: § Grupos. Los grupos permiten definir agrupaciones de alumnos dentro de una clase, de modo que una actividad pueda ser asignada a un grupo de estudiantes en vez de a la clase completa [ver Figura 6.3.3.c 1)]. Este mecanismo permite la creación de pequeños grupos de trabajo facilitando el uso de las herramientas de comunicación como el chat y el foro. Los grupos pueden ser elegidos y creados por el profesor cuando se llega a la actividad de grupo (a través de la interfaz de seguimiento) o LAMS puede generarlos aleatoriamente en base a la configuración de número de grupos y/o participantes por grupo. Es posible crear varios grupos en una misma secuencia, dejando que en cada actividad se pueda seleccionar si se usa o no algún tipo de agrupación. Los grupos de LAMS se asemejan a los roles de IMS LD pero su aplicación es diferente. Los roles en IMS LD se utilizan para asignar actividades a un grupo de alumnos concreto, sin embargo, en LAMS los alumnos deben llevar a cabo todas las actividades de la secuencia y los grupos se usan como mecanismo para establecer grupos de trabajo reducido en tareas colaborativas. § Actividades Opcionales. Este mecanismo define un conjunto de actividades de las cuales el alumno puede elegir cuales desea llevar a cabo [ver Figura 6.3.3.c 2)]. El profesor puede configurar cuál es el número mínimo y máximo de actividades que el alumno debe llevar a cabo para considerar que la actividad opcional ha sido completada. Nótese que es posible incluir una actividad opcional dentro de otra actividad opcional 188 permitiéndose la creación de actividades complejas. Este mecanismo es similar a las Actividades Estructuradas de tipo selección que existen en IMS LD. § Puertas. Las puertas permiten que los profesores puedan definir puntos de espera dentro de una secuencia de actividades [ver Figura 6.3.3.c 3)]. De este modo, los alumnos no pueden avanzar a la siguiente actividad hasta que la puerta se "abra". Las puertas pueden configurarse para que se abran cuando lo decida el profesor (a través de la interfaz de seguimiento) o cuando todos los alumnos han finalizado la actividad previa a la puerta. Las puertas son similares a los mecanismos de finalización de las Actividades, Actos y Guiones de IMS LD. Figura 6.3.3.c. Notación visual para distintos elementos de control utilizados en las secuencias de actividades. 1) Notación visual para la definición de grupos. 2) Notación visual para la definición de actividades opcionales y 3) notación visual para las puertas. Con las versiones 2.1 y 2.2 de LAMS se han introducido nuevos tipos de actividades y características que enriquecen los mecanismos para adaptar las secuencias a los conocimientos y destrezas de los alumnos. Estos nuevos mecanismos se basan en la ramificación de la secuencia principal, de modo que cada alumno o grupos de alumnos puedan pasar por distintas ramas de la secuencia principal. Las nuevas características que influyen en la personalización y adaptación de las secuencias de actividades son: § Puertas mejoradas. Se introducen la espera basada en tiempo y la espera condicional. Las puertas con espera basada en tiempo se abren automáticamente transcurrido un cierto lapso de tiempo desde el comienzo de la ejecución de la secuencia. Las puertas de espera condicional bloquean el paso de un alumno hasta que la condición no se haga cierta para dicho alumno. Las posibles condiciones de espera son iguales a las condiciones que se pueden utilizar en las ramificaciones (por simplicidad se 189 describen más adelante). En ambos casos el profesor (o ayudante del profesor) puede abrir la puerta saltándose las restricciones temporales o las condiciones. § Grupos mejorados. Se permite que los estudiantes se agrupen ellos mismos. Desde LAMS se puede establecer el número máximo de grupos (y sus nombres) y los estudiantes elegirán en qué grupo desean participar. También se ofrece la posibilidad de especificar el número máximo de estudiantes por grupo, de modo que LAMS generará automáticamente los grupos según se vayan llenando los que ha creado. § Secuencias opcionales. Este nuevo mecanismo permite la definición de un conjunto de secuencias (hasta diez) de las cuales el alumno puede elegir algunas secuencias a realizar [ver notación gráfica en Figura 6.3.3.d 2)]. De manera similar a las actividades opcionales, el profesor define el número mínimo y máximo de secuencias que el alumno debe realizar para considerar finalizada la actividad de secuencias opcionales. La Figura 6.3.3.d 2) muestra un ejemplo de secuencias opcionales. Las actividades de cada una de las secuencias aparecen en la misma fila y con un color de fondo distinto. Las actividades están identificadas por su icono correspondiente. El orden de las actividades de una secuencia se define ordenando las actividades (de izquierda a derecha) dentro de cada una de las filas que representan a las secuencias, es decir, la actividad más a la izquierda se ejecuta en primer lugar y la que está en el extremo derecho en último lugar. En el caso del ejemplo, la primera secuencia contiene (en este orden): una actividad de tipo Colección de datos, una actividad de tipo Compartir Recursos y una actividad de tipo Encuesta. La segunda secuencia contiene (en este orden): una actividad de tipo Cartelera y una actividad de tipo Foro de discusión. Nótese que las secuencias que se incluyen dentro de la actividad opcional no tienen por qué tener la misma longitud. Al igual que con las actividades opcionales, es posible incluir dentro de una secuencia cualquier tipo de actividad (incluidas las actividades opcionales, secuencias opcionales y ramificaciones) permitiendo crear secuencias complejas. § Actividades de Ramificación. Las ramificaciones son similares a las actividades y secuencias opcionales ya que permiten crear secuencias de actividades paralelas. Sin embargo, en las ramificaciones el alumno no decide la actividad o secuencia que va seguir sino que automáticamente se le asigna una secuencia concreta. Al igual que con las secuencias opcionales dentro de una actividad de ramificación se pueden incluir otras ramificaciones y otras actividades opcionales. Este mecanismo de ramificación es similar al uso de las condiciones de IMS LD para ocultar y mostrar Actividades dentro de un mismo Acto. Los mecanismos para decidir automáticamente qué rama sigue un alumno concreto son: - Seleccionado por el profesor. El profesor (o el ayudante) a través de la herramienta de seguimiento asigna a los alumnos una rama concreta al llegar a la actividad de ramificación. - Basado en grupos. Los alumnos son asignados automáticamente a las distintas ramas dependiendo de alguna agrupación que se haya realizado en la secuencia. Durante la creación de la actividad de 190 ramificación el profesor decide cómo se asignan los grupos a cada una de las ramas. - § Condicional basado en el resultado de otras actividades. Los alumnos son asignados automáticamente a las distintas ramas dependiendo de los resultados que hayan obtenido en alguna de las actividades anteriores a la actividad de ramificación. Al igual que en las puertas, la descripción de las condiciones se realiza más adelante. Notificaciones. Las notificaciones son un mecanismo de comunicación de LAMS con los alumnos y profesores que están involucrados en la ejecución de una secuencia de actividades. LAMS notifica, enviando un correo electrónico, eventos importantes que han sucedido durante la ejecución de alguna de las actividades de la secuencia. Por ejemplo, en las actividades de tipo Enviar Archivo el autor de la secuencia puede configurar que se envíe un correo electrónico cuando los alumnos hayan enviado sus trabajos y, de manera similar, los alumnos pueden recibir una notificación indicando que las notas de los trabajos enviados ya están disponibles. Aunque las notificaciones no modifican el número o tipo de actividades que realiza un alumno, sí modifican el modo de trabajo tanto de los alumnos como de los profesores. Con el uso de las notificaciones, profesores y alumnos no tienen que acceder al sistema para comprobar si se han enviado trabajos o si ya están corregidos. Las notificaciones recuerdan al mecanismo de notificación de IMS LD. Sin embargo, a diferencia de las notificaciones de LAMS, las de IMS LD pueden modificar el número de actividades que un alumno debe realizar. 191 Figura 6.3.3.d. Notación visual para distintos elementos de control avanzados utilizados en las secuencias de actividades. 1) Notación visual las actividades de ramificación. 2) Notación visual para la definición de secuencias opcionales. Las condiciones juegan un papel importante en las ramificaciones y en las puertas, ya que permiten personalizar la secuencia de las actividades teniendo en cuenta la participación y contribución del alumno en las actividades. Las condiciones LAMS son expresiones que, como resultado de su evaluación, generan los valores cierto indicando que la condición se cumple y falso en caso contrario. A modo de ejemplo, durante la creación de una actividad de ramificación el profesor crea condiciones y las asigna a cada una de las ramas. Cuando el alumno llega a la actividad de ramificación LAMS evalúa las condiciones y automáticamente asigna al alumno la ramificación cuya condición es cierta. Las condiciones tienen en cuenta los resultados generados en las actividades, por ejemplo, la nota que ha obtenido un alumno en una actividad de tipo Opción Múltiple. LAMS proporciona una interfaz amigable para definir condiciones basadas en los resultados que generan las actividades. LAMS distingue dos tipos de resultados de actividades: § Resultados específicos. Los creadores de LAMS han identificado algunas medidas que pueden ser útiles para medir el rendimiento o desempeño del alumno en la actividad. Un ejemplo es la actividad de tipo Foro que permite crear condiciones en base al número de contribuciones del alumno en dicho foro. Otro ejemplo es la actividad de tipo Opción Múltiple que permite definir condiciones en base a la puntuación que ha obtenido el alumno en el test o simplemente si ha acertado todas las preguntas o no. En la versión 2.2 de LAMS sólo las actividades de tipo Foro y Opción Múltiple ofrecen resultados específicos que se pueden utilizar en la creación de condiciones. No obstante, los propios desarrolladores fomentan la participación de la comunidad para identificar nuevas medidas que sean útiles a la hora de crear estas condiciones. § Resultados textuales. Existen varias actividades dentro del repertorio que ofrece LAMS donde el resultado que genera el alumno es texto. Estos resultados textuales permiten la creación de condiciones basadas en la 192 búsqueda de palabras clave, fragmentos de frases, etc. Los tipos de actividades que generan resultados textuales y que, por tanto, permiten crear condiciones basadas en texto son: Encuesta, Foro, Preguntas y Respuestas, Anotador, Chat y Foro. 6.3.4. Configuración y uso básico de LAMS A lo largo de esta sección se introducen los conceptos básicos y se describen los primeros pasos necesarios para trabajar con LAMS versión 2.2 y abordar así el caso de estudio de la sección 6.4. A modo de repaso de algunos conceptos ya introducidos a lo largo del capítulo y como base para introducir nuevos, se definen, a continuación, los conceptos básicos necesarios para trabajar con LAMS: § Clases. Una clase en LAMS puede verse como una asignatura o curso. Desde el punto de vista LAMS una clase es un mecanismo para asociar un grupo de estudiantes con uno o más profesores. Dentro de una clase se pueden crear grupos de estudiantes. Nótese que estos grupos de alumnos no están relacionados con los grupos que se pueden incluir dentro de una secuencia. § Roles. Los roles permiten definir las funcionalidades de LAMS a las que tiene acceso un usuario. Los roles se asignan dentro de una clase (o grupo) de modo que es posible que un usuario pueda tener distintos roles en distintas clases (o grupos). Los roles disponibles dentro de LAMS son: § - Autor. Este rol permite crear secuencias de actividades con la herramienta de autoría y permite publicarlas en alguna de las clases o grupos en los que el profesor tiene rol de autor. El rol de autor es uno de los roles que típicamente tiene asignado un profesor. - Monitor. Este rol da acceso a la herramienta de seguimiento. La herramienta de seguimiento es utilizada por los profesores para monitorizar el progreso de los alumnos, corregir trabajos enviados por los alumnos, creación de agrupaciones de estudiantes, abrir puertas, etc. El rol de monitor está asociado a los profesores y ayudantes del profesor. - Alumno. Este rol da acceso al reproductor de secuencias. El reproductor de secuencias permite interactuar con las actividades que el profesor ha definido en una secuencia. - Roles administrativos. LAMS ofrece un conjunto adicional de roles que habitualmente son asignados a los profesores. Estos roles permiten realizar tareas típicamente administrativas, como la creación de grupos, usuarios y asignación de usuarios a grupos. No obstante, las tareas administrativas están restringidas a una clase concreta y no al servidor completo. Actividades. Desde el punto de vista del profesor, las actividades son las distintas herramientas que puede utilizar en la herramienta de autoría para 193 crear secuencias de actividades. Desde el punto de vista del alumno, las actividades son las tareas educativas que debe realizar como parte del proceso de aprendizaje. § Secuencias de actividades. Las secuencias de actividades son un conjunto de actividades para las que se ha definido un orden concreto. Un profesor puede crear progresivamente varias secuencias que residen en un espacio de trabajo privado al que únicamente tiene acceso dicho profesor. § Publicación de secuencias de actividades. Las secuencias de actividades pueden ser consideradas como plantillas en las que los participantes concretos no están definidos. El proceso de publicación permite al profesor crear una instancia concreta de la plantilla para un conjunto concreto de alumnos. Es posible publicar una plantilla en una clase o en un grupo particular que se haya definido dentro de la clase. Nótese que es posible tener publicadas múltiples secuencias dentro de una clase o grupo de modo que el alumno puede ir progresando en cada una de ellas. Como paso previo a la puesta en práctica del caso de estudio de la sección 6.4, es necesario tener acceso a un servidor LAMS donde se puedan realizar las pruebas, para ello se puede: § Instalar el servidor LAMS. La documentación de la Wiki del proyecto LAMS (ver sección 6.3.1) describe cómo obtener e instalar el servidor LAMS, así como integrar LAMS con otros LMS. § Utilizar el servidor LAMS de demostración. La Fundación LAMS proporciona un servidor de demostración (disponible en http://demo.lamscommunity.org/) que se puede utilizar para realizar pruebas básicas. Se puede solicitar una cuenta de usuario que tiene asignada los roles de autor, monitor y estudiante en un grupo que existe por defecto en ese servidor de demostración. Para un primer contacto con LAMS es recomendable el uso del servidor de demostración para poder realizar las primeras pruebas, no obstante, si finalmente se desea poner en práctica una secuencia con alumnos reales es recomendable la instalación de un servidor LAMS propio. Si se opta por la instalación del servidor LAMS, en la sección 6.3.4.1 se proporciona una guía básica de configuración de dicho servidor. Tanto si se ha optado por la instalación del servidor LAMS como si se utiliza el servidor de demostración, la sección 6.3.4.2 describe brevemente las características principales de la interfaz gráfica de la herramienta de autoría y la publicación de secuencias previamente creadas. Finalmente, la sección 6.3.4.3 proporciona una breve introducción a la herramienta de seguimiento utilizada para la monitorización y para realizar el seguimiento en las secuencias publicadas. 194 6.3.4.1. Administración básica de LAMS Una vez instalado el servidor LAMS 2.2 se puede acceder utilizando un navegador (con las opciones de instalación por defecto) a través de la dirección web http://localhost:8080/lams. La instalación por defecto de LAMS permite el uso de la mayoría de características que ofrece LAMS. No obstante, se recomienda llevar a cabo los siguientes pasos: 1. Configurar las opciones de correo. Con el objetivo de enviar notificaciones desde el servidor de LAMS, es necesario configurar el servidor de correo saliente (servidor SMTP) que utilizará LAMS para enviar notificaciones. 2. Verificar las herramientas habilitadas. El administrador del servidor puede habilitar o deshabilitar las herramientas que ofrece LAMS. Por ejemplo, el administrador puede deshabilitar la herramienta de chat si no se tiene acceso a ningún servidor de chat. El conjunto de herramientas habilitadas serán las herramientas que están disponibles a través de la herramienta de autoría. 3. Crear clases y grupos de ejemplo. Como paso previo a la puesta en práctica del caso de estudio del seminario de Iniciación a la Cata descrito a lo largo del capítulo 2, es recomendable crear una nueva clase de ejemplo con dos grupos. 4. Crear cuentas de usuario para la clase de ejemplo. Para poder probar las distintas perspectivas que ofrece LAMS es recomendable crear al menos un par de cuentas de usuario: una como profesor y otra como alumno. No obstante, por completitud, más adelante se crearán cuentas de usuario para todos los personajes que se describen en el caso de estudio. 5. Asignación de usuarios a una clase (o grupo) y su rol. Una vez creadas las clases, grupos y las cuentas de usuario hay que asignar (matricular) las cuentas de usuario a la clase (o grupo) correspondiente. Además, como parte de la asignación de usuarios a clases (o grupos) es necesario asignar el rol (o roles) con el que participará el usuario en la clase (o grupo). Para configurar las opciones del servidor es necesario conectarse al sistema como administrador (nombre de usuario sysadmin, contraseña sysadmin en la instalación por defecto). Una vez que el administrador se ha conectado al sistema es necesario: 1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a). 2. Seleccionar la opción Editar Configuración de Sistema (ver Figura 6.3.4.1.b). 3. Introducir el nombre del servidor SMTP que utilizará LAMS para enviar notificaciones. El nombre del servidor SMTP (o servidor de correo saliente) puede consultarse en las opciones de cuenta de correo en las aplicaciones de gestión de correo electrónico como Microsoft Outlook o Mozilla Thunderbird (ver Figura 6.3.4.1.c). 195 Figura 6.3.4.1.a. Captura de pantalla con la página inicial del administrador del sistema. Figura 6.3.4.1.b. Captura de pantalla de parte de las opciones disponibles en la Administración de Sistema. 196 Figura 6.3.4.1.c. Captura de pantalla parcial del editor de configuración del sistema. Los valores que aparecen son meramente informativos. Para verificar las herramientas que están habilitadas en el servidor LAMS es necesario: 1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a). 2. Seleccionar la opción Administración de Actividades de Enseñanza (una de las últimas opciones disponibles). 3. Comprobar el valor de la columna Función (columna más a la derecha de la Figura 6.3.4.1.d). Las actividades que tienen valor Desactivado, se encuentran actualmente activadas. Las actividades que tienen valor Activado, se encuentran actualmente desactivadas. Todas las actividades que aparecen en la Figura 6.3.4.1.d menos la herramienta de Escriba se encuentran actualmente activadas. Con la configuración por defecto, sólo están desactivadas las actividades de Escriba y DimDim. Para activar o desactivar una herramienta, simplemente hay que hacer clic sobre el valor correspondiente de la columna Función, de modo que si el valor que aparece es Activado la herramienta se activará. Del mismo modo, si el valor que aparece es Desactivado, al hacer clic sobre el valor la herramienta se desactivará. 197 Figura 6.3.4.1.d. Captura de pantalla parcial de la opción de Administración de Actividades de Enseñanza. Tras realizar la configuración básica del servidor, es conveniente crear una clase para realizar las pruebas con las secuencias de actividades. Como complemento también pueden crearse grupos de alumnos dentro de la clase. LAMS ofrece dos posibilidades para crear nuevas clases y grupos: mediante un formulario web o utilizando un documento de hoja de cálculo. Para simplificar el proceso de creación de la clase de prueba, se describirán los pasos necesarios para crear la clase de prueba Iniciación a la Cata (utilizada en el caso de estudio de la sección 6.4) usando un documento de hoja de cálculo. Al igual que el resto de tareas administrativas es necesario conectarse al servidor como administrador y seguir los siguientes pasos: 1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a). 2. Seleccionar la opción Importar Clases y descargar el documento de hoja de cálculo lams_groups_template.xls. Dentro de esta opción se describe brevemente la sintaxis que deben seguir los datos del documento de hoja de cálculo para que se puedan procesar correctamente. Una vez descargado este documento se puede editar con cualquier herramienta que soporte el formato de archivos .xls como, por ejemplo, Microsoft Excel, Open Office Calc o incluso Google Docs. 3. Una vez editado el documento de hoja de cálculo el contenido del mismo debería ser similar al que aparece en la figura Figura 6.3.4.1.e. La primera línea del documento proporciona una cabecera para las columnas útiles del documento. El resto de filas del documento están agrupadas en bloques separados por una fila en 198 blanco. Cada bloque representa la definición de una clase y de grupos dentro de la clase. La primera fila del bloque representa la definición de la clase (en la Figura 6.3.4.1.e se está definiendo la clase Iniciación a la Cata) y las filas restantes representan definiciones de grupos dentro de dicha clase (en la Figura 6.3.4.1.e se definen los grupos Nuevos alumnos y Antiguos alumnos). El significado de las columnas es el siguiente: § Name(250). Nombre de la clase (o grupo) a crear con una longitud máxima de 250 caracteres. § Code(20). Código de la clase (o grupo) a crear con una longitud máxima de 20 caracteres. § Description(250). Descripción de la clase (o grupo) a crear con una longitud máxima de 250 caracteres. § Locale_id. Entero que identifica el idioma que tiene asociada la clase (o grupo). El valor 1 equivale al idioma inglés y el valor 2 equivale al idioma español. § admin_add_new_users, admin_browse_all_users, admin_change_status. Son columnas relativas a permisos de administración dentro de la clase. Se recomienda asignar el valor "0" a estas columnas. Figura 6.3.4.1.e. Captura de pantalla del documento de hoja de cálculo utilizado para crear la clase de prueba Iniciación a la Cata. Tras crear la clase de prueba, también es necesario crear cuentas de usuarios para los participantes ficticios del seminario Iniciación a la Cata que fue descrito a lo largo del capítulo 2. Al igual que el resto de tareas administrativas es necesario conectarse al servidor como administrador y seguir los siguientes pasos: 1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a). 2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de cálculo lams_users_template.xls. Dentro de esta opción se describe brevemente la sintaxis que deben seguir los datos del documento de hoja de cálculo para que puedan ser procesados correctamente. 3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería ser similar al que aparece en la Figura 6.3.4.1.f. La primera línea del documento proporciona una cabecera para las columnas útiles del documento. El resto de filas 199 del documento representan nuevas cuentas de usuarios que serán creadas en el servidor LAMS. En la Figura 6.3.4.1.f se están definiendo cuentas de usuario para cada uno de los usuarios ficticios que aparecen en la Figura 2.5.2.c del capítulo 2. Las columnas marcadas con un asterisco representan las columnas para las que obligatoriamente se debe proporcionar un valor. El significado de las columnas obligatorias es el siguiente: § login. Nombre de la cuenta de usuario con la que se accederá a LAMS. Todas las cuentas de usuario deben tener nombres distintos. § password. Contraseña de acceso a LAMS. § First_name. Nombre real del usuario. § Last_name. Apellidos del usuario. § Email. Dirección comunicaciones. de correo electrónico utilizada para el envío de Figura 6.3.4.1.f. Captura de pantalla del documento de hoja de cálculo utilizado para crear las cuentas de usuario para los usuarios ficticios del caso de estudio del capítulo 2. Finalmente, una vez creadas la clase y las cuentas de usuario, es necesario asignar las cuentas de usuario a la clase (o grupo) y además asignarle el rol (o roles) que tendrá el usuario dentro de la clase (o grupo). Al igual que en el resto de tareas administrativas es necesario conectarse al servidor como administrador y seguir los siguientes pasos: 1. Seleccionar la opción Administración de Sistema (ver Figura 6.3.4.1.a). 2. Seleccionar la opción Importar Usuarios y descargar el documento de hoja de cálculo lams_roles_template.xls. Dentro de esta opción se describe brevemente la sintaxis que deben seguir datos del documento de hoja de cálculo para que se puedan procesar correctamente. 200 3. Una vez editado el documento de hoja de cálculo, el contenido del mismo debería ser similar al que aparece en la Figura 6.3.4.1.g. La primera línea del documento proporciona una cabecera para las columnas útiles del documento. El resto de filas del documento representan la asignación de roles por usuario y clase (o grupo). En la Figura 6.3.4.1.g se están asignando los permisos a cada una de las cuentas de usuario y grupos definidos anteriormente. En particular, todas las cuentas de usuario tienen asignado el rol learner (estudiante) salvo la cuenta del profesor Corbinus Bodeguero que tiene además asignados los roles: author (autor) y monitor (monitor). Las columnas marcadas con un asterisco representan las columnas para las que obligatoriamente se debe proporcionar un valor. El significado de las columnas obligatorias es el siguiente: § login. Nombre de la cuenta de usuario a la que se le va a asignar un rol. § organisation. Identificador de la clase o grupo donde se va asignar el rol. El identificador de clase o grupo puede consultarse en el listado de clases a través de la opción Administración de Cursos y Clases que se encuentra accesible desde la página inicial de las opciones de administración (ver Figura 6.3.4.1.a). § roles. Lista de roles (separados por el carácter "|") que serán asignados a la cuenta de usuario en la clase (o grupo) especificado. Los posibles valores para los roles son: learner, author y monitor. Figura 6.3.4.1.g. Captura de pantalla del documento de hoja de cálculo utilizado para asignar los roles a los usuarios ficticios del caso de estudio del capítulo 2. 201 6.3.4.2. Autoría y publicación de secuencias LAMS En esta sección se proporcionará una introducción a las herramientas que habitualmente maneja un profesor dentro de LAMS para crear nuevas secuencias de actividades y para publicarlas en alguna de sus clases. La Figura 6.3.4.2.a muestra la página inicial del Profesor Corbinus cuando se conecta a LAMS. Ya que el profesor Corbinus tiene asignado el rol de autor, esta página contiene la opción Diseño de ... [ver Figura 6.3.4.2.a 1)] que permite acceder a la herramienta de autoría. Figura 6.3.4.2.a. Captura de pantalla de la página inicial del Profesor Corbinus al conectarse a LAMS. 1) Botón para abrir la herramienta de autor. 2) Botón para publicar una secuencia creada. Una vez que se hace clic sobre el botón Diseño de ... se abre una nueva ventana que incluye la herramienta de autoría (ver Figura 6.3.4.2.c). Utilizando esta herramienta, Corbinus puede crear secuencias para representar cada uno de los escenarios educativos que tiene en mente (ver sección 3.2). En la parte superior de la herramienta se puede encontrar el menú de opciones y justo debajo una barra de botones de acceso rápido. Algunas de las funcionalidades que se ofrecen a través del menú Archivo son: § Las opciones Abrir, Guardar y Guardar como ofrecen las funciones básicas para poder abrir, guardar y crear una nueva secuencia de actividades dentro del espacio privado de trabajo que cada usuario tiene asignado. Estas opciones también están disponibles a través de la barra de botones. 202 § La opción Exportar permite exportar la secuencia que actualmente se está editando. La exportación de secuencias facilita que la secuencia pueda ser reutilizada por otro profesor. LAMS ofrece la posibilidad de exportar una secuencia utilizando el formato interno de LAMS o utilizando IMS LD (sólo nivel A). § La opción Importar permite importar secuencias que han sido creadas por otro profesor, sin embargo, sólo se admiten secuencias en formato LAMS. § La opción de Insertar permite insertar una secuencia previamente guardada en la secuencia que se está editando actualmente. § La opción Salir permite salir de la herramienta de autoría, también es posible cerrar el editor cerrando directamente la ventana del navegador. En cualquiera de los casos, la herramienta verifica si la secuencia se ha guardado, ofreciendo la posibilidad de realizarlo si todavía no se había hecho. El menú Editar contiene las opciones habituales para Copiar y Pegar actividades, además de ofrecer la posibilidad de Deshacer y Rehacer las operaciones que se han realizado en el editor. Aunque no aparezca en el menú editar de manera explícita, los comandos copiar, pegar y deshacer pueden invocarse con las teclas de acceso rápido habituales. Al seleccionar alguna de las opciones Abrir o Guardar se abre una ventana (ver Figura 6.3.4.2.b) similar al explorador de archivos del sistema operativo, que permite gestionar el espacio personal del profesor. Este espacio personal tiene una parte privada (identificada por el nombre del usuario) donde el profesor almacena las secuencias que ha creado e importado. Además, el profesor también tiene acceso a las secuencias que han sido publicadas en cada una de las clases (y grupos) en las que es profesor, las haya creado o no él mismo. A través del explorador se permiten gestionar carpetas y archivos (secuencias de actividades) del espacio privado del profesor. En el ejemplo de la Figura 6.3.4.2.b aparece el espacio de trabajo de Corbinus con tres secuencias (UACata1, UACata1_1 y UACata2) dentro de su espacio privado, sin embargo no aparece ninguna secuencia en el espacio de trabajo para la clase de Iniciación a la Cata ya que todavía no se ha publicado ninguna. 203 Figura 6.3.4.2.b. Interfaz gráfica del gestor de espacio de trabajo del usuario. En la parte central de la herramienta de autoría [ver Figura 6.3.4.2.c 1)] se encuentra el espacio de trabajo donde se crean las secuencias de actividades. En la parte izquierda de la herramienta de autoría [ver Figura 6.3.4.2.c 2)] se encuentra la librería de actividades donde se listan todas las actividades que pueden ser incluidas en las secuencias de actividades, en particular, las básicas y las combinadas descritas en la sección 6.3.3. Para añadir una actividad simplemente hay que arrastrarla desde la librería al espacio de trabajo. Dentro del espacio de trabajo también hay una papelera que se usa para borrar elementos de la secuencia (tanto actividades como transiciones). Para borrar un elemento de la secuencia hay que arrastrarlo a la papelera. En la barra de botones [ver Figura 6.3.4.2.c 3)] también se ofrece acceso a (de izquierda a derecha): § La herramienta de transición. Esta herramienta se usa para definir el orden entre las actividades. Una vez pulsado el botón Transición el puntero del ratón cambia a un lápiz para advertir que se va a crear una transición. Si se desea crear una transición entre las actividades A y B (de modo que la actividad A se lleva a cabo antes que la B) hay que hacer clic sobre A y arrastrar el puntero del ratón hasta que esté sobre B. Una vez creada la transición aparece una flecha entre las actividades A y B. 204 § Actividades y secuencias opcionales. Al pulsar el botón Opcional se despliega una lista que incluye las opciones de creación de una actividad o secuencia opcional. Al seleccionar cualquiera de las dos opciones el puntero del ratón cambia indicando que la herramienta está activa, para crear el elemento simplemente hay que hacer clic sobre el espacio de trabajo. § Elementos de control de flujo. Al pulsar el botón Flujo se despliega una lista que incluye las opciones de creación de una puerta o una actividad de ramificación. Al seleccionar cualquiera de las dos opciones el puntero del ratón cambia indicando que la herramienta está activa, para crear el elemento simplemente hay que hacer clic sobre el espacio de trabajo. § Previsualización. Utilizando esta opción es posible previsualizar y probar la secuencia que se está creando desde la propia herramienta de autoría. Figura 6.3.4.2.c. Interfaz gráfica de la Herramienta de Autoría. 1) Espacio de trabajo. 2) Librería de actividades. 3) Herramienta de transición, actividades de adaptación y previsualización. 4) Botón de expansión de la sección de propiedades. 205 Una vez creada una actividad es necesario precisar los detalles de la misma (e.g. nombre, descripción, si se aplica a grupos, etc.). La personalización de una actividad se lleva a cabo a través de las Propiedades de la actividad. Las propiedades de una actividad pueden modificarse en dos lugares: § § Inspector de propiedades. El inspector de propiedades incluye las propiedades más comunes. El inspector de propiedades de una actividad puede abrirse seleccionando la actividad en el espacio de trabajo (hacer clic sobre la actividad) y pulsando el icono con forma de ventanas [ver Figura 6.3.4.2.c 4)] que se encuentra en la parte inferior derecha de la herramienta de autoría. El resultado será similar al mostrado en la Figura 6.3.4.2.d. Las propiedades que comúnmente se pueden modificar a través del inspector de propiedades son: - Título. Permite editar el nombre de la actividad que aparece dentro del icono de cada actividad que hay en el espacio de trabajo. - Grupos. Permite seleccionar si hay una única actividad para toda la clase (valor ninguno) o si hay una actividad por cada grupo. Nótese que en la lista desplegable aparecerán los nombres de las agrupaciones disponibles. La Figura 6.3.4.2.e muestra un ejemplo de secuencia con una actividad (Introducción) y tres actividades de agrupación (Agrupación 1, Agrupación 2 y Agrupación 3). En el ejemplo, sólo las actividades de agrupación: Agrupación 1 y Agrupación 2, participan en la secuencia, por lo que sólo estas dos aparecerán entre las posibilidades ofertadas en la propiedad Grupos para la actividad Introducción. - Actividad Offline. Permite marcar una actividad como actividad a realizar fuera de LAMS, por ejemplo, una clase presencial. - Definir en seguimiento. Una actividad que tiene marcada esta propiedad puede ser modificada mientras la secuencia se está ejecutando. El profesor puede cambiar el contenido de la actividad a través de la herramienta de seguimiento. - Conectar objetivos. A partir de LAMS 2.2 es posible definir una lista de objetivos educativos que el autor de la secuencia desea cubrir con las actividades de la secuencia. El profesor puede crear y editar esta lista a través del editor de objetivos educativos que puede abrirse seleccionando el menú Herramientas, Editor de Objetivos (Figura 6.3.4.2.f). Una vez que la lista de objetivos ha sido creada, las actividades de la secuencia pueden conectarse a los objetivos educativos a través de la opción Conectar objetivos del inspector de propiedades (ver Figura 6.3.4.2.g), que permite al profesor marcar aquellos objetivos educativos que son cubiertos total o parcialmente por la actividad. Página de propiedades. La página de propiedades permite modificar el contenido y el comportamiento de las actividades. Para acceder a la página de propiedades de una actividad es necesario hacer doble clic sobre la actividad. Las opciones de la página de propiedades se describirán más adelante. 206 Figura 6.3.4.2.d. Detalle de las propiedades de una actividad y de la edición de objetivos educativos. Figura 6.3.4.2.e. Detalle de la edición de la propiedad Grupos para una actividad. 207 Figura 6.3.4.2.f. Editor de Objetivos Educativos. Figura 6.3.4.2.g. Diálogo de conexión de objetivos educativos con actividades. La página de propiedades de una actividad permite configurar su contenido y su comportamiento. Al hacer doble clic sobre una de las actividades que se encuentra dentro del espacio de trabajo de la herramienta de autor, aparece una ventana similar a Figura 6.3.4.2.h. Esta página contiene un conjunto de propiedades que son comunes a todas las actividades LAMS e incluso permite editar propiedades que son particulares de cada una de las actividades. La página de propiedades se encuentra divida en tres secciones: § Básico. Dentro de este apartado se permite editar el contenido de la actividad. Todas las actividades permiten dar un título y redactar una descripción (que puede incluir contenidos multimedia) de la actividad. Este título y el contenido se muestran a los alumnos, de modo que pueden ser utilizados para describir la actividad. Además, cada tipo de actividad puede 208 incluir dentro de esta sección contenidos adicionales, por ejemplo, en la actividad de tipo Compartir Recursos se permite añadir los recursos (e.g archivos, enlaces) que van a ser compartidos en la actividad. § Avanzado. Dentro de esta sección se pueden editar algunas propiedades relacionadas que modifican el comportamiento de la actividad. Una propiedad que siempre está disponible es la de Añadir Anotaciones. Al activar Añadir Anotaciones el alumno tiene la posibilidad de, tras finalizar la actividad, anotar el proceso que ha seguido para completar la actividad. De forma adicional, cada actividad tiene otras propiedades, por ejemplo, la actividad de tipo Compartir Recursos incluye propiedades que pueden ser activadas para permitir a los alumnos compartir sus propios recursos (e.g. archivos y enlaces) con sus compañeros. § Instrucciones. Dentro de esta sección se permite al autor de la secuencia incluir las pautas que se deben seguir para llevar a cabo esta actividad, tanto si la actividad se realiza dentro de LAMS como si la actividad es externa (actividad offline). Estas instrucciones sólo están disponibles para los profesores (y ayudantes del profesor). De este modo, las instrucciones pueden servir para que el profesor que ha creado la secuencia pueda documentar su diseño pedagógico y describir las instrucciones o pautas que considere oportunas para llevar a cabo la actividad. Figura 6.3.4.2.h. Página de propiedades de la actividad Introducción. 209 Una vez que Corbinus ha creado las secuencias que ha considerado oportunas, debe publicarlas para ponerlas en práctica con los alumnos del seminario de Iniciación a la Cata. Corbinus puede publicar la secuencia utilizando la opción Agregar Lecciones que aparece en su pantalla inicial [ver Figura 6.3.4.2.a 2)]. Al seleccionar Agregar Lecciones aparece una ventana similar al explorador de archivos (ver Figura 6.3.4.2.i), en la que se puede seleccionar alguna de las secuencias a las que Corbinus tiene acceso. Estas secuencias pueden ser privadas, es decir, secuencias que todavía no ha publicado o puede ser alguna secuencia publicada de alguno de los cursos en los que está registrado como profesor (con rol autor). En el ejemplo mostrado en la Figura 6.3.4.2.i aparecen tres secuencias privadas: UACata1, UACata1_1 y UACata2, junto a las secuencias que están publicadas en las clases en las que Corbinus está registrado como profesor (cursos MATH111 e Iniciación a la Cata). Figura 6.3.4.2.i. Diálogo de selección de secuencias utilizado al añadir secuencias a clases y grupos. 210 Una vez que Corbinus selecciona la secuencia UACata1 para ser publicada, al pulsar el botón Continuar aparece un nuevo diálogo en el que Corbinus puede seleccionar a los estudiantes y ayudantes del profesor que participarán en la secuencia. La Figura 6.3.4.2.j muestra todos los usuarios que están registrados en la clase Iniciación a la Cata divididos en los grupos Antiguos alumnos y Nuevos alumnos. Corbinus selecciona a todos los alumnos y a él mismo para participar dentro de la secuencia que está publicando. Figura 6.3.4.2.j. Diálogo de selección de participantes. Una vez que Corbinus ha seleccionado a los participantes y pulsa el botón Continuar, aparece el último cuadro de diálogo del proceso de publicación (ver Figura 6.3.4.2.k). Este último diálogo, permite dar un nombre y una descripción a la secuencia que se está publicando. De manera complementaria, se puede seleccionar si se permitirá editar la secuencia durante su ejecución (edición en vivo) utilizando la herramienta de seguimiento y si los alumnos podrán guardar el trabajo que han realizado a lo largo de la secuencia (exportar porfolio). Finalmente se puede decir si la secuencia estará 211 disponible inmediatamente para los alumnos (opción por defecto) o si estará disponible a partir de una fecha y horas concretas. Figura 6.3.4.2.k. Diálogo utilizado para ultimar los detalles de publicación de la secuencia de actividades. Una vez publicada la secuencia, ésta aparece (identificada por el título que le hemos dado en Figura 6.3.4.2.k) dentro de la clase o grupo donde ha sido creada. En la Figura 6.3.4.2.l aparece la secuencia UACata1 que Corbinus acaba de publicar dentro de la clase de Iniciación a la Cata. Se incluyen, además, los enlaces para participar dentro de la secuencia [ver Figura 6.3.4.2.l 1)] y para monitorizar la secuencia [(ver Figura 6.3.4.2.l 2)]. 212 Figura 6.3.4.2.l. Página inicial de Corbinus una vez publicada la secuencia UACata1. 1) Enlace que permite a Corbinus interactuar con la secuencia como un alumno. 2) Enlace que permite abrir la herramienta de seguimiento. 6.3.4.3. Monitorización y Seguimiento. El objetivo de la herramienta de seguimiento es triple: permitir al profesor monitorizar el progreso de los estudiantes, realizar tareas administrativas dentro de la secuencia publicada y evaluar los trabajos de los alumnos. La herramienta de seguimiento está divida en tres secciones: § Lección. Dentro de esta pestaña pueden realizarse tareas administrativas respecto a la secuencia publicada (ver Figura 6.3.4.3.a), por ejemplo, se puede acceder a la lista de estudiantes que actualmente participan en la secuencia y editarla. Dentro de esta sección también se encuentra una lista de las actividades que obligatoriamente requieren la intervención del profesor (o de un ayudante). En la Figura 6.3.4.3.a aparecen tres actividades que requieren la intervención del profesor. Estas actividades corresponden a tres puertas que están incluidas dentro de la secuencia. Al seleccionar la opción Ir de la actividad Permiso Corbinus se abre una nueva ventana (ver Figura 6.3.4.3.b) que permite administrar la puerta, permitiendo la apertura de la misma para toda la clase o para alumnos concretos. 213 § Secuencia. Dentro de la pestaña secuencia, se tiene acceso a una vista similar al espacio de trabajo de la herramienta de autor (ver Figura 6.3.4.3.c). Esta vista permite realizar un seguimiento de la secuencia desde el punto de vista de las actividades. Al hacer doble clic sobre alguna de las actividades se abre una ventana que permite: - Acceder a información acerca del número de alumnos que ya han finalizado la actividad. - Acceder a las instrucciones que el autor de la secuencia ha podido incluir durante la creación de la secuencia. - Acceder a los trabajos enviados por los alumnos para que puedan ser evaluados por el profesor. - Permitir la creación de grupos en las actividades de grupo y la asignación de estudiantes a ramas dentro de actividades de ramificación. - Edición en vivo del contenido de la actividad. La edición del contenido debería de estar restringida a eliminar erratas dentro de la descripción o enunciado de la actividad, ya que la actividad puede haber sido comenzada por algún alumno. De manera adicional, también es posible realizar una edición en vivo de la propia secuencia, es decir, se pueden modificar las actividades existentes dentro de la secuencia o añadir nuevas actividades. Nótese que esta edición de una secuencia está restringida, de modo que no se pueden modificar actividades que ya han sido comenzadas por alumnos. Finalmente, dentro de la secuencia aparecen unos iconos que representan a los participantes de la secuencia (ver región resaltada en Figura 6.3.4.3.c). Estos iconos pueden ser desplazados a otras actividades de modo que el profesor puede forzar el avance del estudiante hasta una actividad concreta. § Estudiantes. En esta sección (ver Figura 6.3.4.3.d) se muestra una representación lineal gráfica de la secuencia de cada uno de los estudiantes que están participando. Esta sección permite observar el progreso de los estudiantes dentro de la secuencia, mostrando si el alumno ha completado la actividad (círculos azules), cuál es la actividad que actualmente está realizando (cuadrado rojo) y cuáles son las actividades que le quedan (triángulo verde). También se permite, dentro de esta sección, que el profesor pueda exportar las contribuciones de un alumno en una o varias actividades. 214 Figura 6.3.4.3.a. Pestaña Lección de la herramienta de seguimiento. 215 Figura 6.3.4.3.b. Opciones de administración de la puerta Permiso Corbinus. 216 Figura 6.3.4.3.c. Pestaña secuencia de la herramienta de seguimiento. 217 Figura 6.3.4.3.d. Pestaña de estudiantes de la herramienta de seguimiento. En las siguientes secciones 6.4 y 6.5 se pone en práctica la unidad de aprendizaje utilizada como caso de estudio a lo largo de todo el capítulo 2 empleando la herramienta LAMS (sección 6.4) y haciendo uso de herramientas de soporte para IMS LD (sección.6.5). A modo de resumen, en el caso de estudio del capítulo 2 se proponen tres escenarios educativos entorno a un seminario/taller de Iniciación a la Cata (ver Figura 2.3.b) donde cada escenario es una evolución del anterior: § UACata1. Describe un proceso de enseñanza tradicional presencial que incluye algunas actividades soportadas por las TICs. El resumen de los componentes principales y el método pedagógico se pueden encontrar en las figuras: Figura 2.5.5.a, Figura 2.5.5.b, Figura 2.5.5.c y Figura 2.5.5.d. § UACata2. En base al escenario 1, se personaliza el método pedagógico en base a las necesidades particulares de los alumnos. El resumen de los componentes principales y el método pedagógico se pueden encontrar en las figuras: Figura 2.6.9.a, Figura 2.6.9.b, Figura 2.6.9.c, Figura 2.6.9.d, Figura 2.6.9.e, Figura 2.6.9.f y Figura 2.6.9.g. 218 § UACata3. En base al escenario 2, se incluye un mecanismo de notificación de la entrega de trabajos. El resumen de los componentes principales y el método pedagógico se pueden encontrar en las figuras: Figura 2.7.3.a y Figura 2.7.3.b. 6.4. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON LAMS En esta sección se codificarán los escenarios educativos UACata1, UACata2 y el escenario UACata3. Nótese que para el escenario UACata2 es necesario tener acceso a un servidor de LAMS 2.1 o superior y que para crear el escenario UACata3 es necesario tener acceso a un servidor de LAMS 2.2 o superior. Una vez que ya se ha instalado LAMS o se tiene acceso a un servidor LAMS propio, los pasos a seguir son: 1. Diseñar la secuencia. Es necesario conectarse a LAMS como profesor (con rol de autor). Una vez creada la secuencia, ésta se almacena en el espacio privado del profesor. 2. Publicar las secuencia. Mediante este proceso el profesor configura una secuencia para una clase y alumnos concretos. Es posible configurar varias secuencias para los mismos alumnos, de modo que puedan llevar a cabo varias tareas a la vez. También es posible configurar la disponibilidad de una secuencia publicada a partir de una fecha y hora concretas. 3. Realizar las actividades de la secuencia. Una vez que una secuencia de actividades se ha publicado y se encuentra activa, tanto el alumno como los profesores pueden acceder a ella. De este modo: - Los alumnos podrán llevar a cabo las actividades propuestas en la secuencia. - Los profesores pueden monitorizar y gestionar ciertas actividades de la secuencia. En particular, las tareas habituales de gestión son la creación de grupos, el control de puertas y la asignación de estudiantes a ramas dentro de una actividad de ramificación. 6.4.1. Diseño de las unidades de aprendizaje / secuencias de actividades LAMS para el caso de estudio Utilizando secuencias de actividades LAMS se pueden poner en práctica los escenarios educativos UACata1, UACata2 y UACata3. No obstante, el comportamiento no será exactamente el mismo a las UA creadas con IMS LD (que fueron descritas a lo largo del capítulo 2). A continuación se describen algunas pautas para traducir (si es posible) los elementos de IMS LD a LAMS: § Actividades Educativas y Entornos. Las actividades LAMS representan las actividades educativas de IMS LD junto a un entorno preconfigurado. 219 Las actividades IMS LD contenían una información básica (e.g. título, descripción, etc.) que se complementa con el entorno donde se realiza la actividad. Estos entornos necesitan ser configurados uno a uno. En el caso de LAMS, las actividades ya contienen un entorno preconfigurado, de modo que la configuración a realizar es mínima. § Actividades de Soporte. El concepto de actividad de soporte no existe como actividad separada en LAMS. No obstante, existen diversas actividades que requieren de la participación de un profesor como, por ejemplo, la actividad de tipo Enviar Archivos, en la que el profesor evalúa los trabajos que han enviado los alumnos. § Roles. Los roles no existen directamente en LAMS. Un concepto similar son las clases y grupos. Dentro de las clases (o grupos) pueden crearse pequeños grupos de alumnos y publicar secuencias de actividades para cada uno de los grupos de manera independiente. Sin embargo, no se pueden asignar actividades específicas a grupos de una clase. Una manera de simular el comportamiento de los roles y actuaciones es adelantar a los alumnos de un grupo concreto (utilizando la herramienta de seguimiento) hasta la actividad o actividades que es preciso que lleven a cabo. § Actividades Estructuradas. Las actividades estructuradas de IMS LD se pueden simular con las actividades opcionales: - Actividades estructuradas de tipo selección. Se pueden simular con las actividades opcionales de LAMS. Todas las actividades educativas que eran referenciadas en la actividad estructurada se incluyen dentro de la actividad opcional. - Actividades estructuradas de tipo secuencia. Se pueden simular con las secuencias opcionales de LAMS con una única secuencia. No obstante, este uso es demasiado complejo ya que se pueden obtener resultados similares utilizando actividades simples y la herramienta de transición para definir el orden entre las mismas. § Método, Guiones y Actos. Estos elementos de IMS LD permitían a los creadores de unidades de aprendizaje definir el orden de las actividades simples. Los actos servían como mecanismos de sincronización entre los participantes de la unidad de aprendizaje. En LAMS no existen elementos equivalentes, sin embargo, se pueden diseñar secuencias de actividades con el mismo comportamiento utilizando actividades y definiendo las transiciones entre ellas. En particular, el uso de las puertas permite simular el comportamiento de sincronización entre participantes. Un problema que surge cuando se crean secuencias complejas es que se ofrecen muy pocos mecanismos para estructurar una secuencia, de hecho, el único mecanismo que permite la estructuración de las secuencias es la posibilidad de insertar secuencias previamente creadas en la secuencia que se está editando actualmente. § Actuaciones. Las actuaciones de IMS LD asocian tipos de participantes (roles) con las actividades que deben realizar estos participantes. En LAMS no existe el concepto de rol como tal y, por tanto, no tienen sentido las actuaciones. Todas las actividades de una secuencia LAMS pueden ser consideradas como si estuvieran asignadas a un rol de alumno de IMS LD. 220 § Propiedades. El concepto de propiedad no existe como tal en LAMS. En IMS LD los diseñadores de las unidades de aprendizaje deben definir las propiedades que habitualmente representan medidas de rendimiento del alumno y se utilizan dentro de las condiciones para adaptar el flujo de aprendizaje en base a estas medidas. No obstante, ciertas actividades LAMS ofrecen acceso a medidas del rendimiento del alumno en la actividad, por lo que podrían ser consideradas como propiedades predefinidas. § Condiciones. Las condiciones no tienen un equivalente directo en LAMS. Sin embargo, las actividades de ramificación pueden utilizarse para simular el comportamiento para el que habitualmente se usan las condiciones: adaptar el flujo de aprendizaje en base a resultados previos. § Notificaciones. A partir de LAMS 2.2 se incluye el concepto de notificación que es similar al de las notificaciones de IMS LD. LAMS puede enviar mensajes de notificación cuando suceden ciertos eventos durante la ejecución de una secuencia. Durante el diseño de la secuencia, el profesor puede seleccionar si desea que se envíen notificaciones o no. La diferencia principal entre las notificaciones de LAMS y de IMS LD es que en IMS LD una notificación puede hacer visible una actividad que inicialmente estaba oculta, sin embargo, LAMS no ofrece esta posibilidad. Finalmente, un concepto que afecta a las actividades de una UA en IMS LD es el concepto de finalización. En IMS LD las actividades (simples o estructuradas), actuaciones, actos y guiones pueden finalizar de las siguientes maneras: § A elección del participante. Las actividades simples, actos y guiones pueden finalizar por elección del participante. Este comportamiento es similar al que tienen las actividades LAMS ya que el alumno elige cuándo finaliza la actividad. § Transcurrido un lapso de tiempo. Las actividades, actos y guiones IMS LD pueden finalizar automáticamente transcurrido un lapso de tiempo. Este comportamiento puede simularse en LAMS utilizando una puerta. Sin embargo, esta solución requiere que se establezca una puerta por cada actividad LAMS y, adicionalmente, la definición del lapso de tiempo se define respecto al instante en el que comenzó la secuencia completa, por lo que puede ser engorrosa la definición de varias puertas en diferentes partes de la secuencia de actividades. § En base a la finalización de los elementos anidados. Los elementos de IMS LD se pueden anidar durante la definición de la unidad de aprendizaje. Este anidamiento concreta una relación entre los distintos elementos de la unidad de aprendizaje que en IMS LD puede utilizarse para definir la finalización del elemento externo en base a los elementos que contiene. Por ejemplo, la finalización de un acto puede definirse en base a la terminación de las actuaciones que contiene. En LAMS sólo existe esta relación de anidamiento para las actividades opcionales y las actividades de ramificación. Para el resto de situaciones en las que es necesario sincronizar actividades se recurre habitualmente al uso de puertas controladas por el profesor. 221 En los escenarios IMS LD planteados para el caso de estudio del capítulo 2 existen numerosas actividades cuya finalización se define utilizando lapsos de tiempo. Ya que en LAMS el uso de esta sincronización requiere un elevado esfuerzo durante la creación de la secuencia, y que desde el punto de vista del alumno puede ser poco intuitivo, se ha optado por utilizar el mecanismo por defecto de LAMS para acabar las actividades, es decir, a elección del usuario. En casos puntuales, se han definido puntos de control (equivalentes a los actos de IMS LD) para sincronizar a los participantes de la secuencia. La Figura 6.4.1.a muestra la secuencia de actividades LAMS creada por Corbinus para implementar el escenario UACata1. Las actividades (incluyendo el orden en el que son llevadas a cabo) son: 1. Presentación. Es una actividad de tipo Cartelera que Corbinus ha utilizado para saludar a los nuevos alumnos del seminario y para indicarles que la primera actividad será una clase presencial. En particular, ha sido necesario introducir esta actividad que no se incluía en el escenario IMS LD ya que una actividad LAMS marcada como offline no muestra ni su título ni su contenido a los alumnos, sino que muestra un mensaje indicando a los alumnos que contacten con su profesor para más instrucciones. 2. Clase Presencial. Actividad de tipo Cartelera que representa la primera clase presencial del curso. Ya que esta actividad no será realizada en LAMS se ha marcado como actividad offline. LAMS presenta las actividades offline con colores invertidos para diferenciarlas del resto de actividades. 3. Puerta de permiso. Esta puerta es controlada por Corbinus para permitir avanzar a los alumnos una vez que haya finalizado la clase presencial. 4. Autoaprendizaje. Actividad opcional que incluye tres actividades: - Artículo Bebo. Actividad de tipo Compartir Recursos en la que se comparte el artículo de la profesora Bebo. - Artículo Birra. Actividad de tipo Compartir Recursos en la que se comparte el artículo del profesor Birra. - Visionado de vídeo. Actividad de tipo Compartir Recursos en la que se comparte el vídeo del profesor Bacus. La actividad ha sido marcada para que termine cuando las tres actividades incluidas hayan finalizado. Nótese que esta actividad se ha traducido como una actividad opcional utilizando las pautas de traducción descritas anteriormente. Sin embargo existen otras formas de implementar esta actividad, por ejemplo, empleando una única actividad de tipo Compartir Recursos y compartir todos los recursos a la vez (especificando en las propiedades avanzadas de la actividad, que hay que visitar todos los recursos compartidos). Finalmente, si se aplicaran estrictamente las pautas de traducción se llegaría a una secuencia similar a la mostrada en la Figura 6.4.1.b donde la actividad opcional Autoaprendizaje y la actividad Examen del sitio web han sido fusionadas en una sola de tipo Secuencia Opcional con una única secuencia, donde la primera actividad es la actividad opcional Autoaprendizaje y la segunda (y última) actividad es el Examen del sitio web. 222 5. Examen del sitio web. Actividad de tipo Compartir Recursos donde se comparte el enlace al sitio web www.lacatadelvinotinto.org. 6. Puerta sincronizada. Esta puerta simula la finalización de un acto de IMS LD, de modo que la puerta no se abrirá hasta que todos los estudiantes hayan terminado la actividad anterior. 7. Debate. Actividad de tipo Chat, donde los alumnos debaten acerca de los contenidos educativos visionados y la lectura de los artículos. 8. Puerta de permiso. Puerta que controla Corbinus para marcar el avance a la siguiente actividad del seminario. 9. Entrega de trabajos. Actividad de tipo Enviar Archivos, que será utilizada por los alumnos de Corbinus para enviarle los trabajos escritos. 10. Puerta de permiso. Puerta que controla Corbinus que sirve para marcar el final del seminario. Figura 6.4.1.a. Estructura final de la secuencia LAMS completa que formaliza la descripción de unidad de aprendizaje UACata1. 223 Figura 6.4.1.b. Estructura final de la secuencia LAMS completa que formaliza la descripción de la unidad de aprendizaje UACata1. La actividad estructurada Autoaprendizaje se ha definido como una secuencia opcional. Al igual que en las unidades de aprendizaje IMS LD, Corbinus crea las secuencias de actividades de manera incremental. Tras guardar la secuencia de actividades correspondiente al escenario UACata1, puede modificar esta secuencia para las nuevas características del escenario UACata2, que podrá guardar de manera independiente. La Figura 6.4.1.c muestra la secuencia de actividades que implementa el escenario UACata2, el tipo y orden de las actividades es el siguiente: 1. Presentación. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 2. Clase Presencial. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 3. Puerta de permiso. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 4. Test. Actividad de tipo Opción Múltiple utilizada como examen tipo test para evaluar los conocimientos previos del alumno. 5. Evaluación de conocimientos. Actividad de tipo ramificación que utiliza la nota que se ha generado en la actividad Test para redirigir al alumno a una rama concreta dentro de la actividad. Las ramas de la actividad pueden editarse haciendo doble clic sobre la actividad, de modo que aparecerá un nuevo espacio de trabajo particular para la actividad de ramificación (Figura. 6.4.1.d). En el espacio de trabajo de una ramificación aparecen dos iconos especiales con forma de puerta. Estos dos iconos representan: el punto de entrada a la actividad de ramificación (puerta verde), donde se crearán las distintas ramas de la secuencia, y el punto de salida (puerta roja), que es el punto donde se vuelven a unir las ramificaciones para proseguir a la siguiente actividad. En el ejemplo mostrado en la Figura. 6.4.1.d aparecen definidas dos ramas: 224 - Conocimientos suficientes. Esta rama representa la secuencia de actividades que debe seguir el alumno si demuestra que tiene conocimientos suficientes de enología. Contiene la actividad opcional Autoaprendizaje descrita en la implementación del escenario UACata1. - Conocimientos insuficientes. Esta rama representa la secuencia de actividades que debe seguir el alumno que no tenga los conocimientos mínimos de enología para desarrollar las actividades posteriores. Esta rama incluye la lectura del libro Enología Básica escrito por Corbinus y, posteriormente, la realización de la actividad Autoaprendizaje. Nótese que esta actividad ha sido copiada en ambas ramas ya que no puede haber transiciones entre actividades de distintas ramas. Una vez creadas las ramas Corbinus crea un par de condiciones, utilizando el editor de condiciones accesible desde el inspector de propiedades. La Figura 6.4.1.e muestra dos condiciones: la primera con nombre Suficientes cuya condición es que los puntos totales del estudiante sean mayor o igual que 5 y la segunda, con nombre Insuficientes, cuya condición es que los puntos totales del estudiante estén en el rango 0 a 4. Finalmente, Corbinus asocia las condiciones con las ramas de secuencias. La Figura. 6.4.1.f muestra como la rama Conocimientos suficientes está asignada a la condición Suficientes y la rama Conocimientos insuficientes está asignada a la condición Insuficientes. 6. Examen del sitio web. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 7. Puerta sincronizada. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 8. Debate. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 9. Puerta de permiso. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 10. Entrega de trabajos. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. 11. Evaluación de trabajos. Actividad de tipo ramificación en la que Corbinus redirige a los alumnos a la rama correspondiente tras corregir los trabajos que los alumnos han entregado en la actividad anterior. Nótese que esta asignación de alumnos a ramas debe hacerse manualmente ya que la actividad de tipo Enviar Archivos no genera ningún valor que pueda ser utilizado en una condición. La Figura 6.4.1.g muestra las dos ramas que incluye esta actividad: - Trabajo suficiente. Por esta rama serán encauzados los alumnos cuyo trabajo cumpla los requisitos mínimos exigidos por Corbinus. Como puede observarse, en esta rama no hay ninguna actividad, de modo que el alumno simplemente finalizará automáticamente la actividad. - Trabajo insuficiente. Por esta rama pasarán todos los alumnos cuyo trabajo no cumpla los requisitos mínimos exigidos por Corbinus. Dentro de esta rama aparece una secuencia de tres actividades: Necesitas Repasar, Repaso y Revisión del trabajo. La actividad Necesitas Repasar es de tipo Cartelera donde se informa al estudiante de que debe revisar el material y rehacer el trabajo de nuevo (adicionalmente puede revisar los comentarios acerca del trabajo volviendo a la 225 actividad Evaluación de Trabajos). La actividad Repaso es opcional y contiene tres actividades de tipo Compartir Recursos donde cada una de estas actividades propone el repaso de los contenidos más relevantes: libro del profesor Corbinus, artículo del profesor Birra y visita al sitio web www.lacatadelvinotinto.org. Finalmente, en la actividad Revisión del trabajo el alumno debe enviar de nuevo el trabajo incluyendo las correcciones que considere oportunas. 12. Puerta de permiso. Esta actividad es la misma que se ha descrito para implementar el escenario UACata1. Figura 6.4.1.c. Estructura final de la secuencia LAMS completa que formaliza la descripción de la unidad de aprendizaje UACata2. 226 Figura. 6.4.1.d. Detalle de la actividad de ramificación Evaluación de conocimiento. 227 Figura. 6.4.1.e. Detalle del editor de condiciones asociado a la actividad Evaluación de conocimiento. Figura. 6.4.1.f. Detalle del diálogo utilizado para asignar condiciones a ramas de la actividad Evaluación de conocimiento. 228 Figura 6.4.1.g. Detalle de la actividad de ramificación Evaluación de trabajos. En último lugar, la secuencia que implementa el escenario UACata3 es una ligera modificación de la secuencia de actividades que implementa el escenario UACata2. En particular sólo se han modificado las propiedades de las actividades Entrega de Trabajos y Revisión del Trabajo, de modo que se notifique a Corbinus mediante un mensaje de correo electrónico que un alumno ha enviado su trabajo (ver Figura 6.4.1.h). Como complemento, también se ha configurado que los alumnos sean notificados cuando Corbinus haya evaluado los trabajos y que los alumnos puedan revisar tanto su nota como los comentarios que Corbinus haya añadido a la corrección. 229 Figura 6.4.1.h. Página de propiedades de la actividad Entrega de Trabajos. Las propiedades de notificación a profesores y alumnos se encuentran activadas. Como se mencionó en la sección 6.3.4.2, es posible exportar una secuencia de actividades LAMS desde la herramienta de autoría. La secuencia exportada se empaqueta en un archivo comprimido en formato zip que contiene una descripción de la secuencia de actividades y todos los archivos de contenidos que se utilizan en las actividades de la secuencia. La Figura 6.4.1.i muestra el contenido (en formato XML) del archivo que representa la secuencia de actividades. A diferencia del formato XML de IMS LD, que tiene como objetivo ser un formato simple de intercambio para unidades de aprendizaje que incluso puede ser editado directamente por un profesor, el formato XML de LAMS no está pensado para ser modificado directamente, ya que incluye numerosos detalles técnicos como, por ejemplo, las coordenadas dentro del espacio de trabajo donde se encuentra cada una de las actividades, el instante en el que se creó la actividad, etc. Figura 6.4.1.i. Extracto del contenido del documento XML donde se define la secuencia de actividades del escenario UACata2. 230 <org.lamsfoundation.lams.learningdesign.dto.LearningDesignDTO> <learningDesignID>36</learningDesignID> <title>UACata2</title> <firstActivityID>525</firstActivityID> <firstActivityUIID>34</firstActivityUIID> <maxID>118</maxID> <validDesign>true</validDesign> <readOnly>false</readOnly> <editOverrideLock>false</editOverrideLock> <userID>10</userID> <copyTypeID>1</copyTypeID> <createDateTime class="sql-timestamp"> 2008-12-03 13:27:53.0</createDateTime> <version>2.1.0.200806131057</version> <designVersion>1</designVersion> <workspaceFolderID>50</workspaceFolderID> <lastModifiedDateTime class="sql-timestamp">2008-12-03 16:35:17.0</lastModifiedDateTime> <contentFolderID>ff8080811ded4e44011def28de5a006c</contentFolderID> <groupings/> <activities> <org.lamsfoundation.lams.learningdesign.dto.AuthoringActivityDTO> <activityID>514</activityID> <activityUIID>1</activityUIID> <description>Tool for displaying HTML content including external sources such as images and other media.</description> <activityTitle>Clase Presencial</activityTitle> <helpText>Displays formatted text and links to external sources on a read only page.</helpText> <helpURL> http://wiki.lamsfoundation.org/display/lamsdocs/lanb11</helpURL> <xCoord>166</xCoord> <yCoord>43</yCoord> <activityTypeID>1</activityTypeID> <defineLater>false</defineLater> <learningDesignID>36</learningDesignID> <createDateTime class="sql-timestamp"> 2008-12-03 13:27:53.0</createDateTime> <runOffline>true</runOffline> <toolSignature>lanb11</toolSignature> <toolID>2</toolID> <toolContentID>452</toolContentID> <toolDisplayName>NoticeboardX</toolDisplayName> <toolVersion>20070524</toolVersion> <authoringURL>tool/lanb11/authoring.do</authoringURL> <monitoringURL>tool/lanb11/monitoring.do</monitoringURL> <activityCategoryID>4</activityCategoryID> <applyGrouping>false</applyGrouping> <groupingSupportType>2</groupingSupportType> <libraryActivityUIImage> tool/lanb11/images/icon_htmlnb.swf</libraryActivityUIImage> <readOnly>false</readOnly> <initialised>false</initialised> <stopAfterActivity>false</stopAfterActivity> <inputActivities/> <languageCode></languageCode> <supportsOutputs>false</supportsOutputs> </org.lamsfoundation.lams.learningdesign.dto.AuthoringActivityDTO> ... 231 Para finalizar esta sección, la Figura 6.4.1.j muestra el curso de Moodle que Corbinus utiliza como apoyo al curso de Enología Presencial que imparte en la de Escuela Estudios y Prospecciones Vinícolas (EEPV). Moodle es el LMS utilizado dentro de los diferentes cursos de la EEPV, sin embargo, ya que Corbinus ha dedicado un gran esfuerzo al desarrollo de secuencias de actividades, la instalación de Moodle de la escuela se encuentra integrada con el servidor de LAMS. De este modo, Corbinus puede utilizar la herramienta de autoría y publicar secuencias LAMS desde la propia interfaz de Moodle. Figura 6.4.1.j. Publicación de la secuencia de actividades UACata1 dentro de Moodle. 6.5. PUESTA EN PRÁCTICA DEL CASO DE ESTUDIO CON IMS LD Existen numerosas iniciativas, en particular en el ámbito de la investigación, para crear herramientas de autoría y herramientas de reproducción entre otras, que faciliten el uso de los lenguajes de modelado educativo con énfasis en IMS LD. Entre estas iniciativas se encuentra el proyecto RELOAD (http://www.reload.ac.uk) que ofrece varias herramientas para dar soporte a las especificaciones ADL SCORM e IMS LD. 232 Las herramientas que el proyecto RELOAD ofrece para IMS LD son dos: § RELOAD LD Editor. Esta herramienta permite crear una UA compatible con IMS LD. RELOAD LD Editor fue una de las primeras herramientas de autoría compatible con los tres niveles de la especificación IMS LD. § RELOAD LD Player. Esta herramienta es un reproductor de unidades de aprendizaje IMS LD pensado para complementar a RELOAD LD Editor. Este reproductor permite reproducir unidades de aprendizaje desde el ordenador del propio creador de las unidades de aprendizaje. Proporciona una interfaz simple para publicar una UA y crear usuarios de prueba. Internamente, RELOAD LD Player utiliza el intérprete CopperCore para reproducir las unidades de aprendizaje. En la actualidad los desarrolladores de RELOAD participan en el proyecto internacional TENCompetence (http://www.tencompetence.org) desarrollando una nueva versión de RELOAD LD Editor, llamada ReCourse, que tiene como objetivo proporcionar una herramienta más amigable y simple de usar para un usuario que no sea experto en IMS LD. No obstante, en la actualidad, ReCourse soporta la expresividad de IMS LD nivel A, aunque según los autores (Griffiths et al., 2008) en poco tiempo estará disponible una versión de ReCourse que soporte la expresividad de los niveles B y C de IMS LD. La especificación de IMS LD propone la aplicación de la metodología Análisis, Diseño, Desarrollo, Implementación y Evaluación (ADDIE) (Dick y Carey, 1996) ampliamente utilizada en la creación y desarrollo de materiales educativos y cursos. Esta metodología se compone de 5 fases, cuyos objetivos son: § Análisis. En esta fase se analiza un escenario educativo concreto teniendo en cuenta los distintos tipos de participantes que están involucrados en el escenario educativo. El objetivo de esta fase es crear un documento en lenguaje natural en el que se narre brevemente cómo se pondría en práctica el caso de estudio. En particular, este documento narrativo podría incluir una lista con todas las tareas a llevar a cabo en el escenario educativo. § Diseño. En la fase de diseño se propone que, utilizando el documento narrativo como entrada, se cree un diagrama de actividad UML (OMG, 2007). Los diagramas de actividad UML son un tipo de diagrama utilizados habitualmente en el desarrollo de aplicaciones informáticas y en la descripción de procesos de negocio, por ejemplo, para describir gráficamente el orden de las tareas que intervienen en un proceso de negocio. Este diagrama se utiliza como base para generar el documento XML que represente la UA compatible con IMS LD. Durante esta fase del desarrollo, se puede utilizar la herramienta RELOAD LD Editor para facilitar la creación de este documento XML sin tener que trabajar directamente con el archivo XML. § Desarrollo. Durante esta fase se crean los recursos necesarios para la UA. Estos recursos se tienen que haber declarado en los Entornos utilizados en las actividades. Una vez creados estos recursos, se puede utilizar RELOAD LD Editor para incluirlos dentro de la UA. 233 § Implementación. Durante esta fase, se publica la UA con alumnos concretos para su puesta en práctica. Para esto es necesario crear un paquete IMS que incluya tanto la UA como todos los recursos necesarios. Reload LD Editor permite crear y validar un paquete IMS para que pueda ser utilizado en un reproductor compatible con IMS LD. § Evaluación. Esta fase tiene como objetivo evaluar la UA para que se pueda mejorar para una ejecución posterior. Como se ha descrito, RELOAD LD Editor se puede usar durante la fase de diseño para crear la UA compatible con IMS LD. El proceso de creación de una UA utilizando RELOAD LD Editor es el siguiente: 1. Crear un nuevo diseño de aprendizaje (del inglés learning design). Un diseño de aprendizaje puede ser considerado como un proyecto de UA. 2. Crear las actividades. A partir de la descripción narrativa del escenario educativo, pueden identificarse las actividades de la UA. Las actividades educativas y de soporte pueden agregarse en actividades estructuradas más complejas. 3. Crear los entornos donde se llevarán a cabo las actividades y asociarlos a sus correspondientes actividades. La definición de las actividades sólo incluye una descripción de la tarea a realizar. Esta definición de actividades se complementa con la definición de entornos y su asociación a las actividades. 4. Crear los roles de los participantes del diseño de aprendizaje. El escenario educativo puede incluir distintos tipos de participantes, por lo que será necesario definir un rol por cada uno de los tipos de personaje identificados. 5. Crear el método de la unidad del diseño de aprendizaje. En el método se define el orden, la sincronización y la asignación de las actividades individuales (definidas en el paso 2) a roles identificados en el escenario educativo. Además, si la UA incluye aspectos de personalización, es necesario definir las distintas propiedades que se utilizarán en dicha personalización. 6. Importación y vinculación de los recursos a los entornos. Como parte de la fase de desarrollo, el profesor creará los distintos materiales educativos que serán enlazados desde los distintos entornos. Una vez creados los recursos educativos, el profesor importará los recursos en RELOAD LD Editor, en particular los objetos educativos u objetos de aprendizaje (learning objects en inglés) y reeditará los entornos para enlazar los materiales educativos importados. 7. Verificación del diseño de aprendizaje. Una UA compatible con IMS LD debe cumplir ciertas restricciones para que pueda ser ejecutada en un reproductor compatible. RELOAD LD Editor permite que el creador de una UA pueda validarla respecto a estas restricciones. En caso de que alguno de los elementos no cumpla los requisitos mínimos, se proporciona un mensaje de error con una pequeña ayuda que indica cómo arreglar el fallo. 8. Exportación del diseño de aprendizaje. Una vez creada y validada la UA, ésta está lista para ser exportada. La UA junto a todos los recursos necesarios serán empaquetados en un archivo comprimido (con formato zip) listo para ser ejecutado en un reproductor compatible con IMS LD. 234 Una vez creada la UA es recomendable que el profesor la pruebe antes de ponerla en práctica con usuarios reales y más si la UA es adaptativa. RELOAD Player puede utilizarse para probar una UA compatible con IMS LD. Sin embargo, RELOAD LD Player es un reproductor completo y real de IMS LD, de modo que al probar la UA será necesario cumplir con todas las restricciones que se especifiquen en ella. En particular, las actividades educativas de los escenarios de ejemplo pasarán a estar completadas transcurrido un lapso de tiempo, de modo que el profesor tendría que esperar dicho lapso de tiempo durante las pruebas, lo que no es efectivo. Para facilitar el proceso de prueba de la UA que se está creando, es recomendable crear una UA "trucada", donde: § Las actividades deberían configurarse para ser completadas a elección del usuario. De este modo, el profesor podrá ir completando las actividades y probando las adaptaciones incluidas en la UA. § El profesor debería poder modificar el valor de las propiedades que modifican el proceso de adaptación. Por tanto, es necesario crear recursos de tipo imsldcontent que incluyan los elementos globales de IMS LD necesarios para ver y modificar el valor de las propiedades que afecten al proceso de adaptación. Una vez que se ha probado la UA, las actividades pueden configurarse con los mecanismos de finalización que inicialmente se habían ideado, y los recursos accesorios que se habían creado para la prueba y que ya no son necesarios se pueden eliminar. La interfaz gráfica de RELOAD LD Editor ofrece una pestaña por cada uno de los diferentes aspectos relativos a la edición de una UA. Cada pestaña proporciona el soporte necesario para cada uno de los ocho pasos anteriormente descritos. Las unidades de aprendizaje que ponen en práctica los escenarios educativos descritos en el capítulo 2 han sido creadas y probadas con las últimas versiones (hasta la fecha de escritura del presente trabajo) de las siguientes herramientas: § RELOAD LD Editor versión 2.1.3 (herramienta de autoría). § RELOAD LD Player versión 2.1.3 (herramienta de pruebas). § CopperCore Runtime Environment (CCRT) versión 3.1.1 + SLeD versión 3.0 (herramienta de pruebas). A continuación, se describe brevemente el proceso de creación de la UA para el escenario de aprendizaje UACata3 descrito en el capítulo 2. El caso de estudio UACata3 se ha modificado mínimamente para poder probarlo completamente. Las modificaciones realizadas son: § La finalización de actividades se ha configurado para que el usuario elija cuando finalizan. § Se ha añadido la propiedad global personal email. Esta propiedad es necesaria para crear las notificaciones para profesores. 235 La Figura 6.5.a muestra la interfaz de RELOAD LD Editor que permite editar el resumen de la UA que se está creando. Esta interfaz permite definir: § Un título (title). Este título es utilizado habitualmente por las herramientas de reproducción para mostrar el listado de unidades de aprendizaje publicadas. En el ejemplo el título es Seminario de introducción a la cata. § Una URI y versión. La URI proporciona un identificador único para la UA. Este identificador puede utilizarse para hacer referencia a la UA que se está creando desde otra UA, por ejemplo, para ejecutar una UA como parte de otra UA. En el ejemplo, la URI de la UA es http://www.e-ucm.es/uacata3/1 que tiene la estructura habitual de la dirección de una página web, sin embargo, en el caso de las URI esta dirección es meramente descriptiva y no tiene por qué existir una página web con dicha dirección. § Nivel. Este atributo especifica cuál es la compatibilidad mínima que debe soportar un reproductor para reproducir la unidad de aprendizaje que se está editando. § Objetivos de aprendizaje. Editor que permite asociar una lista de recursos para definir el conjunto de objetivos de aprendizaje que se cubren en la unidad de aprendizaje. Estos recursos pueden ser tanto archivos como enlaces web. § Prerequisitos. Editor que permite asociar una lista de recursos para definir el conjunto de prerrequisitos que se cubren en la unidad de aprendizaje. Estos recursos pueden ser tanto archivos como enlaces web. 236 Figura 6.5.a. Pestaña de edición del resumen de una unidad de aprendizaje. 237 La Figura 6.5.b muestra la interfaz que permite definir la jerarquía de roles de la unidad de aprendizaje. En la parte izquierda se encuentra el editor, en forma de árbol, para los dos tipos de roles principales de la unidad de aprendizaje: rol alumno (Learners) y rol plantilla (Staff). A través de este editor se pueden añadir nuevos sub-roles tanto de los roles principales como de alguno particular que se haya definido. En la parte derecha se permite editar los detalles particulares del rol que actualmente se encuentre seleccionado. En concreto, se puede asociar una lista de recursos para describir la finalidad del rol dentro de la unidad de aprendizaje. En el ejemplo mostrado en la Figura 6.5.b se aprecian los dos roles de estudiante Alumno de nueva promoción y Alumno de promociones antiguas, además del rol del tipo plantilla Profesor del seminario. Figura 6.5.b. Pestaña de creación de los roles de la unidad de aprendizaje. 238 La Figura 6.5.c muestra la interfaz que permite crear y editar las actividades individuales de la unidad de aprendizaje. En la parte izquierda se encuentra un editor donde se pueden crear nuevas actividades y, para el caso particular de las actividades estructuradas, es posible crear las referencias a las actividades que se incluirán. Además también es posible crear las referencias al entorno donde se llevará a cabo la unidad de aprendizaje. En la parte derecha se permiten editar los detalles particulares de la actividad que se encuentre seleccionada, en concreto, establecer la visibilidad de la actividad, el mecanismo de finalización de la actividad y configurar la notificación de finalización de la actividad. Figura 6.5.c. Pestaña de creación de las actividades de la unidad de aprendizaje. 239 La Figura 6.5.d muestra la interfaz para crear los entornos de la unidad de aprendizaje. Como parte de los entornos pueden definirse los objetos educativos y, en particular, configurar los servicios de comunicación. En el ejemplo mostrado en la Figura 6.5.d se está configurando el servicio de comunicación que se utilizará en la actividad de debate. Este servicio de comunicación está configurado como servicio de comunicación síncrono (i.e. un chat) y tiene asignados a los roles de alumnos como participantes activos del chat y el rol de profesor como observador, moderador y administrador de la sesión de chat. Figura 6.5.d. Pestaña de creación de los entornos de la unidad de aprendizaje. 240 La Figura 6.5.e muestra la interfaz para crear el método de la unidad de aprendizaje. En la parte izquierda se encuentra el editor donde se pueden añadir nuevos guiones, actos y actuaciones. Al seleccionar alguno de los elementos del editor, en la parte derecha pueden editarse los detalles del elemento. En el caso particular del método, parte de los detalles que se pueden definir son las condiciones del método. Figura 6.5.e. Pestaña de creación del método de la unidad de aprendizaje. 241 La Figura 6.5.f muestra el diálogo que permite crear las condiciones de la unidad de aprendizaje. En el ejemplo mostrado, aparecen las dos condiciones que permiten la adaptación de la unidad de aprendizaje dependiendo del test previo y de los resultados en el trabajo (ver Figura 2.6.9.f). Figura 6.5.f. Diálogo de creación de las condiciones de la unidad de aprendizaje. 242 La Figura 6.5.g muestra la interfaz del editor para crear las propiedades de la unidad de aprendizaje. En la parte izquierda aparece la lista de propiedades definidas y en la parte de la derecha se pueden editar los detalles particulares de la propiedad que actualmente se encuentre seleccionada. En el ejemplo de la Figura 6.5.g se muestra la edición de detalles de la propiedad email. Ya que ésta es una propiedad global personal, su definición global (opción Global Definition) puede crearse a través del editor, o se puede hacer referencia a una propiedad global ya existente (opción Existing). Figura 6.5.g. Pestaña de creación de propiedades de la unidad de aprendizaje. 243 La Figura 6.5.h muestra la interfaz del editor para gestionar los recursos de la unidad de aprendizaje. A través de esta pestaña se muestran los archivos que actualmente están dentro del directorio content del directorio del proyecto que se ha creado para la unidad de aprendizaje. A través de esta interfaz el profesor puede importar otros recursos dentro del proyecto de la unidad de aprendizaje. No obstante, el profesor puede utilizar el explorador de archivos de su sistema operativo para copiar archivos y recursos en el directorio content. Figura 6.5.h. Pestaña de gestión de archivos de la unidad de aprendizaje. 244 En último lugar, la Figura 6.5.i muestra la interfaz de exportación del editor de unidades de aprendizaje. El objetivo de esta sección del editor es triple: § Asignar un tipo a los recursos de la unidad de aprendizaje. A través del apartado de Validación de Recursos (Check Resources) el profesor verifica los recursos que actualmente tiene disponibles en la unidad de aprendizaje y adicionalmente puede asignar un tipo (opción Type...) al recurso que esté seleccionado. En particular, imsldcontent es el tipo de recurso que se utiliza en los recursos web que incluyan elementos globales de IMS LD. § Validación de la unidad de aprendizaje. A través del apartado de Lista de tareas (Checklist) el profesor verifica la unidad de aprendizaje respecto a todas las reglas y restricciones que impone la especificación IMS LD. En caso de error se mostrará un mensaje indicando el error y proporcionando alguna pista acerca de cómo se puede solucionar el problema. Es recomendable que la unidad de aprendizaje se valide cada cierto tiempo para comprobar que los nuevos elementos introducidos se han configurado adecuadamente. § Exportación. Una vez que la unidad de aprendizaje ha sido validada, ya está lista para ser empaquetada. El apartado de exportación (Export) permite exportar la unidad de aprendizaje y todos los recursos asociados en un paquete IMS. 245 Figura 6.5.i. Pestaña de validación, asignación de tipos a recursos y exportación de la unidad de aprendizaje. Para finalizar este capítulo se muestran algunas capturas de la ejecución de las unidades de aprendizaje utilizando el motor de ejecución CopperCore junto a la herramienta de reproducción SLeD (ambas herramientas están descritas en el capítulo 1). SLeD es una herramienta web de reproducción de unidades de aprendizaje compatibles con IMS LD que utiliza el motor de ejecución CopperCore para interpretar las unidades de aprendizaje. 246 Nótese que para emplear SLeD es necesario tener instalado y funcionando el motor CopperCore (disponible gratuitamente en: http://www.coppercore.org/). Una vez instalado, es necesario instalar SLeD (que también se puede obtener de manera gratuita en: http://sled.open.ac.uk/). En ambos sitios web se encuentra la documentación necesaria para instalar ambas herramientas informáticas (en inglés). La Figura 6.5.j muestra la reproducción de la unidad de aprendizaje UACata1 para un usuario con rol Nuevo Alumno. Figura 6.5.j. Captura de pantalla de la reproducción de la unidad de aprendizaje UACata1 dentro de SLeD. Además de CopperCore existen otros reproductores de unidades de aprendizaje compatibles con IMS LD, entre ellos, destaca la iniciativa GRAIL (Escobedo del Cid et al., 2007) desarrollado por el Grupo de Aplicaciones y Servicios Telemáticos (GAST) de la Universidad Carlos III de Madrid. GRAIL es un reproductor de unidades de aprendizaje que se encuentra integrado dentro de la plataforma educativa .LRN (http://dotlrn.org) y que, por tanto, permite reproducir unidades de aprendizaje como una herramienta más de la plataforma educativa, además de estar integrada con los servicios que ofrece .LRN. 247 Para utilizar el reproductor, se puede: § Utilizar el servidor de pruebas que ofrece el grupo GAST. Este servidor permite publicar unidades aprendizaje propias y reproducirlas. Este servidor está disponible en: https://gradient.it.uc3m.es/xowiki/main_page § Descargar una máquina virtual, compatible con VMWare, en la que se encuentra instalado el LMS .LRN y el reproductor de IMS LD. Esta máquina virtual contiene un sistema operativo configurado con todos los requisitos para poder utilizar .LRN utilizando un reproductor de máquina virtual como VMWare, QEMU, VirtualBox o Virtual PC entre otros. El Observatorio Tecnológico del ITE (antiguo CNICE) ofrece un monográfico de Máquinas Virtuales que se encuentra disponible en: http://observatorio.cnice.mec.es/index.php?module=subjects&func=viewpag e&pageid=63 248 7. BIBLIOGRAFÍA Esta bibliografía es parte de la que se ha utilizado en la redacción del presente informe pero dista mucho de ser completa. Debido a la propia naturaleza del campo del elearning en general que es relativamente joven a la vez que muy activo, y por tanto en continuo cambio, hace que muchas de las referencias puedan quedar obsoletas muy rápidamente. Esto es todavía más cierto si cabe en los aspectos de modelado educativo donde, como hemos comentado previamente, todavía no existen consensos ni prácticas comúnmente aceptadas. Por tanto algunas de estas referencias son realmente meta-referencias ya que son menciones a sitios web que contienen la información actualizada. Por otro lado a lo largo del trabajo se han proporcionado muchas referencias a información disponible directamente en Internet, por ejemplo, sobre herramientas o sistemas concretos. Aunque en muchos casos no se podrían considerar referencias propiamente dichas son parte muy importante de la información disponible. • • • • • • • • • • • Adell, J. (2004). Internet en el aula: las WebQuest. Edutec: Revista Electrónica de Tecnología Educativa [en línea] 17, pp. 3-4. Disponible en: [2008, 5 de http://www.uib.es/depart/gte/edutec-e/revelec17/adell_16a.htm diciembre]. ADL SCORM (2009). Sharable Course Object Reference Model 2004 4th Edition Documentation Suite Public Draft, [en línea]. Disponible en: http://adlnet.gov/Technologies/scorm/SCORMSDocuments/SCORM 2004 4th Ed V1.1/Documentation Suite/SCORM_2004_4ED_v1_1_Doc_Suite.zip [2009, 12 de noviembre]. AICC (2004). CMI guidelines for interoperability AICC revision 4.0. Technical Report CMI001, Aviation Industry CBT Committee -AICC Subcommittee. AICC Aviation Industry CBT Committee. Disponible en: http://www.aicc.org [2008, 27 de noviembre]. ALFANET. Alfanet project (2007). Disponible en: http://alfanet.ia.uned.es [2007, 16 de mayo]. ARIADNE Alliance of Remote Instructional Authoring and Distribuion Networks for Europe. Disponible en: http://www.ariadne-eu.org/ [2008, 27 de noviembre] Balatsoukas, P., Morris, A. et al. (2008). Learning Objects Update: Review and Critical Approach to Content Aggregation. Educational Technology & Society 11 (2), 119-130. Berggreen, A., Burgos, D., Fontana, J. M., Hinkelman, D., Hung, V., Hursh, A. y Tielemans, G. (2005). Practical and pedagogical issues for teacher adoption of ims learning design standards in moodle LMS. Journal of Interactive Media in Education, 2005 (2), 1-24. Berlanga, A. J. y García, F. J. (2005). IMS ld reusable elements for adaptive learning designs. Journal of Interactive Media in Education, 11, 1-16. Botturi, L. (2006). E2ML: A visual language for the design of instruction. Educational Technology Research and Development, 54 (3), 265-293. Brickley, D. (1998). Tutorial Markup Language (TML), [en línea]. Bristol: Institute for Learning and Research Technology, University of Bristol. Disponible en: http://www.ilrt.bris.ac.uk/netquest/about/lang/ [2008, 27 de noviembre]. 249 • • • • • • • • • • • • • • • • • Britain, S. (2004). A review of learning design: Concept, specification and tools. JICS E-learning Pedagogy Programme report, [en línea]. Disponible en: www.jisc.ac.uk/uploaded_documents/ACF83C.doc [2008, 27 de noviembre]. Buendia, F., Agustí, M. Benlloch, J.V., Bisbal, E. y Lluesma, M (2003). Xedu, a proposal of learning management system implementation. In International Conference on Network Universities and e-Learning, Valencia (España), Mayo 8-9 2003. Buendía, F., Agustí, F., Benlloch, J. V., Bisbal, E. y Lluesma, M. (2004). Xedu, a proposal of learning management system implementation. Journal of Information Technology Impact, 4 (1), 12. Burgos, D. y Grif?ths, D. (2005). The unfold project. Understanding and using learning design. Herleen: Open University of The Netherlands. Caeiro Rodríguez, M., Marcelino, M. J., Llamas-Nistal, M., Anido Rifón, L. E., Mendes, A. J. (2007). Supporting the Modeling of Flexible Educational Units PoEML: A Separation of Concerns Approach, [en línea]. Disponible en: J. UCS 13 (7), 980-990. CopperAuthor (2007). Disponible en: http://sourceforge.net/projects/copperauthor [2008, 17 de mayo]. CopperCore (2008). Disponible en: http://www.coppercore.org [2008, 27 de noviembre] Dalziel, J. (2003). Implementing learning design: The learning activity management system (lams). En G. Crisp, D. Thiele, I. Scholten, S. Barker & J. Baron (Eds.), 20th Annual Conference of the Australasian Society for Computers in Learning in Tertiary Education (ASCILITE 2003). Adelaide, Australia. Dalziel, J. (2005). From re-usable e-learning content to re-usable learning designs: Lessons from lams. LAMS Foundation. Dick, W. y Carey, L. (1996). The Systematic Design of Instruction (4a. ed.). Nueva York: Haper Collins College Publishers. Dick, W., Carey, L. y Carey, J. O. (2000). The Systematic Design of Instruction (5a ed.). Allyn & Bacon. Dodero, J. M., Tattersall, C., Burgos, D. y Koper, R. (2006). Nonrepresentational authoring of learning designs: from idioms to model-driven development, [en línea]. Disponible en: http://hdl.handle.net/1820/783. [2008, 27 de mayo]. Dodge, B. (1995). Some thoughts about WebQuests, [en línea]. Disponible en: http://webquest.sdsu.edu/about_webquests.html [2008, 5 de diciembre]. Escobedo del Cid, J. P., de la Fuente Valentín, L., Gutiérrez, S., Pardo, A. y Delgado Kloos, C. (2007). Implementation of a Learning Design Run-Time Environment for the LRN Learning Management System. Journal of Interactive Media in Education. Fernández Carballo-Calero, M. V. (2008). WebQuests: Un modelo educativo basado en el uso de internet. Revista de Formación e Innovación Educativa Universitaria, 1 (2), 58-60. Fernández-Manjón, B., Moreno-Ger, P., Sierra, J.L. y Martínez-Ortiz, I. (2007). Uso de estándares aplicados a TIC en Educación. Informe Nº 16. CNICE. Griffiths, D., Beauvoir, P. y Sharples, P. (2008). Advances in Editors for IMS LD in the TENCompetence Project. En Proc. of 8th IEEE International Conference on Advanced Learning Technologies (ICALT 08), pp. 1045-1047. 250 • • • • • • • • • • • • • • • • • • Hernández-Leo, D., Villasclaras-Fernández, E. D., Asensio-Pérez, J. I., Dimitriadis, Y., Jorrín-Abellán, I. M., Ruiz-Requies, I. y Rubia-Avi, B. (2006). Collage: A collaborative learning design editor based on patterns. Educational Technology & Society, 9 (1), 58–71. HR-XML Consortium (2004). Competencies Schema, [en línea]. Disponible en: http://ns.hr-xml.org/2_3/HR-XML-2_3/CPO/Competencies.html [2008, 27 de noviembre]. IEEE (2007). 1484.20.1/Draft Standard for Learning Technology— Data Model for Reusable Competency Definitions (último borrador publicado de acceso público y gratuito). Disponible en: http://www.ieeeltsc.org:8080/Plone/workinggroup/competency-data-standards-working-group20/IEEE_1484.20.1.D5.WD11.zip [2008, 12 de noviembre]. IEEE LOM (2002). IEEE Standard for Learning Object Metadata. IEEE Standard 1484.12.1-2002. Autor. IEEE RCD (2008). IEEE Standard for Learning Technology - Data Model for Reusable Competency Definitions, IEEE Std 1484.20.1-2007. Autor. IMS CP (2004). IMS Content Packaging Specification v 1.1.4. [en línea]. Disponible en www.imsglobal.org/content/packaging/ [2008, 15 de noviembre]. IMS Global Consortium (2002). IMS Reusable Definition of Competency or Educational Objective Specification, Version 1.0 Final Specification, [en línea]. Disponible en: http://www.imsglobal.org/competencies/index.html [2008, 27 de noviembre]. IMS Global Consortium (2003). IMS Learner Information Package Accessibility for LIP, Version 1.0 Final Specification, [en línea]. Disponible en: http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre]. IMS Global Consortium (2004). IMS AccessForAll Meta-data, Version 1.0 Final Specification, [en línea]. Disponible en: http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre]. IMS Global Consortium (2005). IMS Guidelines for Developing Accessible Learning Applications, Version 1.0 White Paper, [en línea]. Disponible en: http://www.imsglobal.org/accessibility/index.html [2008, 27 de noviembre]. IMS Global Consortium (2005). IMS Learner Information Package, Version 1.0.1 Final Specification, [en línea]. Disponible en: http://www.imsglobal.org/profiles/index.html [2008, 27 de noviembre]. IMS Global Learning Consortium (2008). Disponible en: http://www.imsproject.org [2008, 27 de noviembre]. IMS LD (2003). IMS Learning Design, [en línea]. Disponible en: http://www.imsglobal.org/learningdesign/ [2008, 27 de noviembre]. IMS META (2006). IMS Meta-Data Version 1.3., [en línea]. Disponible en: www.imsglobal.org/metadata/#version1.3. [2008, 15 de noviembre]. IMS QTI (2005). IMS Question & Test Interoperablity Specification, Version 2.0 Final Specification, [en línea]. Disponible en: http://www.imsglobal.org/question/index.html [2008, 27 de noviembre]. IMS QTI (2006). IMS Question & Test Interoperability Specification v2.1. , [en línea]. Disponible en: www.imsglobal.org/question [2008, 15 de noviembre]. IMS RDCEO (2002). IMS Reusable Definition of Competency or Educational Objective Specification v 1., [en línea]. Disponible en: www.imsglobal.org/competencies [2008, 15 de noviembre]. IMS SS (2003). IMS Simple Sequencing Specification v1.0., [en línea]. Disponible en: www.imsglobal.org/simplesequencing [2008, 15 de noviembre]. 251 • • • • • • • • • • • • • • • • Institute of Electrical and Electronics Engineers (IEEE) Learning Technology Standards Committee (LTSC) (2008). Disponible en: http://ltsc.ieee.org [2008, 27 de noviembre]. Karampiperis, P. y Sampson, D. (2004). A ?exible authoring tool supporting adaptive learning activities. En Proceedings of IADIS International Conference on Cognition and Exploratory Learning in Digital Age. Lisboa, Portugal. Koch, M. (2002). Interoperable community platforms and identity management in the university domain. International Journal on Media Management, 4 (1), 21–30. Koper, R. (2000). From change to renewal: Educational technology foundations of electronic learning environments. Holanda: Open University of the Netherlands. Koper, R. (2001). Modelling units of study from a pedagogical perspective: the pedagogical meta-model behind EML. Holanda: Educational Technology Expertise Centre (OTEC), Open University of the Netherlands. Li, X. (1991). What's So Bad About Rule-Based Programming?. IEEE Software 8, 103-105. Martínez-Ortiz, I., Moreno-Ger, P., Sancho-Thomas, P., y Fernández-Manjon, B. (2005). Using docbook to aid in the creation of learning content. En A. Rettberg & C. Bobda (Eds.), New Trends and Technologies in Computer-Aided Learning for Computer-Aided Design, (pp. 11–23). Springer. Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2006). Using docbook and xml technologies to create adaptive learning content. International Journal of Computer Science and Applications, 3 (2), 91–108. Martínez-Ortiz, I., Moreno-Ger, P., Sierra, J. L. y Fernández-Manjón, B. (2008). A Flow-Oriented Visual Language for Learning Designs. En Proceedings of the 7th International Conference on Web-based Learning (ICWL 2008). Jinhua, China. Lecture Notes in Computer Science 5145, pp 486-496. Mayes, T., de Freitas, S. (2004). Stage 2: Review of e-learning theories, frameworks and models. JICS E-learning Model Desk Study, [en línea]. Disponible en: http://www.jisc.ac.uk/uploaded_documents/Stage%202%20Learning%20Model s%20(Version%201).pdf [2008, 27 de noviembre]. McAndrew, P., Woods, W. I. S., Little, A., Weller, M. J., Koper, R. y Vogten, H. (2004). Implementing learning design to support web-based learning. En Proceedings of the Australasian World Wide Web Conference (AusWeb04). MedBiquitous Competencies Working Group (2008). Disponible en: http://www.medbiq.org/working_groups/competencies/index.html [2008, 27 de noviembre]. Merrill, M. D. (1994) Instructional Design Theory. Educational Technology Publications. Englewood Cliffs. Miao, Y. (2005). Cosmos: Facilitating learning designers to author units of learning using ims ld. En D. Jonassen & I. Mitsuru (Eds.), International Conference on Computers in Education (pp. 275–282). Singapore: IOS Press. Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I. y Fernández-Manjón, B. (2007). A Documental Approach to Adventure Game Development. Science of Computer Programming 67 (1), 3-31. Moreno-Ger, P., Sierra, J. L., Martínez-Ortiz, I., Fernández-Manjón, B. (2008). A Content-Centric Development Process Model. IEEE Computer 41 (3), 24-30. 252 • • • • • • • • • • • • • • • • OMG (2007). Unified Modeling Language: Superstructure version 2.1.1, [en línea]. Disponible en: http://www.omg.org/cgi-bin/doc?formal/07-02-05 [2008, 27 de noviembre]. Paquette, G. (2004). Educational modeling languages, from an instructional engineering perspective. En McGreal, R. (ed.), Online education using learning objects (pp 331–246). Londres: Routledge/Falmer. Paquette, G., Teja, I., Leonard, M., Lundgren-Cayrol, K. y Marino, O. (2005). An Instructional engineering method and tool for design of Units of Learning. En Learning Design, a Handbook on Modelling and Delivering Networked Education and Training (pp 161–184). Heidelberg: Springer. Polsani, P. (2003). Use and Abuse of Reusable Learning Objects. En Journal of Digital Information 3 (4). Rawlings, A., van Rosmalen, P., Koper, R., Artacho-Rodriguez, M. y Lefrere, P. (2002). Survey of educational modelling languages (EML). En CEN/ISSS WS/LT Learning Technologies Works-hop, September 19. Redondo Templado, F. M. (2006). Sistema Binario [en línea]. Disponible en: http://clic.xtec.net/db/act_es.jsp?id=3259 [2008, 5 de diciembre]. Reigeluth, C. M. (1983). Instructional Design Theories and Models: An Overview of Their Current Status. Lawrence Erlbaum Associates. [2008, 27 de RELOAD (2008). Disponible en: http://www.reload.ac.uk noviembre]. Rodríguez-Artacho, M., Verdejo, M. F., Mayorga, J. I. y Calero, M. Y. (1999). Using high-level language to describe and create web-based learning scenarios. En IEEE Frontiers In Education FIE ’99 (pp 10-13). San Juan, Puerto Rico. SCORM (2004). Scorm 2004 overview 2nd edition. Advanced Distributed Learning. Sierra, J. L., Moreno-Ger, P., Martínez-Ortiz, I. y Fernández-Manjón, B. (2006). A highly modular and extensible architecture for an integrated ims based authoring system: The <e-aula> experience. Software-Practice & Experience, 37 (4), 441–461. Van Durm, R., Duval, E., Verhoeven, B., Cardinaels, K. y Olivié, H. (2001). Extending the ariadne web-based learning environment. En World Conference on Educational Multimedia, Hypermedia & Telecommunications (ED-MEDIA 2001) (pp 1932–1937). Tampere, Finlandia. Vantroys, T. (2003). Du langage métier au langage technique, une plateforme ?exible déxécution de scénarios pédagogiques. Lille: Computer sciences, Université des Sciences et Technologies de Lille. Verbert, K. y Duval, E. (2004). Towards a global component architecture for learning objects: A comparative analysis of learning object content models. En P. Kommers & G. Richards (Eds.), World Conference on Educational Multimedia, Hypermedia and Telecommunications 2004 (pp. 202–208), Chesapeake, VA: AACE. Walsh, N. y Muellner, L. (1999). DocBook: The De?nitive Guide (1a ed.). Sebastopol, CA, EE.UU.: O’Reilly. Weitl, F., Süß, Ch., Kammerl, R. y Freitag, B. (2002). Presenting Complex eLearning Content on the Web: A Didactical Reference Model. En Proc. e-learn 2002 world conference on E-Learning in Corporate, Government, Healthcare, and Higher Education. 253 • • Weller, M., Little, A., McAndrew, P. y Woods, W. (2006). Learning design, generic service descriptions and universal acid. Educational Technology & Society, 9 (1), 138–145. XML Schema (2004). W3C Recommendation: XML Schema (2a ed.) [en línea]. Disponible en: www.w3.org/TR [2008, 15 de noviembre]. 254