nueva página del texto (beta)
Español (pdf)
Artículo en XML
Referencias del artículo
Traducción automática
Enviar artículo por email
Citado por SciELO 
Similares en
SciELO 
Permalink
INTRODUCCIÓN
La rápida evolución de los sistemas de aprendizaje en línea caracterizados principalmente por el uso de internet se debe a que cada vez más éstos son usados como alternativa formativa tanto en la educación formal como en la informal; dichos sistemas presentan claras ventajas en el aprovechamiento de los contenidos de aprendizaje, así como una favorable desvinculación de los problemas asociados al espacio, tiempo y distancia (Cabero, 2006) .
La posibilidad tecnológica que hoy se tiene para crear recursos digitales de alta calidad a través de las muy diversas opciones que encontramos para e-learning aporta, sin duda, gran valor a los procesos de formación, sobre todo en aquellos casos en que existe posibilidad de reutilización o adaptación de dichos recursos en cursos distintos para los que fueron creados (Cechinel, Rebollo y Sánchez-Alonso, 2011) ; no obstante, si analizamos la conveniencia de que estos recursos sean independientes de la plataforma tecnológica, la cual responde, en general, a criterios no necesariamente acordes con las necesidades específicas de los usuarios, nos enfrentamos al requisito de establecer relaciones de operabilidad, compartición y distribución de los recursos pedagógicos y aplicaciones de aprendizaje particulares, con los diferentes sistemas de gestión de aprendizaje (LMS: Learning Management Systems) que permitan maximizar su uso, durabilidad y permanencia.
Este artículo tiene como objetivo promover un mejor aprovechamiento de los recursos educativos de alta calidad al recurrir a prácticas que garanticen la compatibilidad, reusabilidad y unificación de los recursos tanto pedagógicos como tecnológicos en beneficio de los estudiantes y del singular trabajo, esfuerzo y empeño que algunos maestros dedican al diseñar y desarrollar contenidos educativos especialmente complejos y que, por lo tanto, implican una importante combinación de recursos no sólo pedagógicos y computacionales, sino también económicos y de tiempo invertido.
A continuación, analizamos de manera breve el estado conceptual que encontramos en la industria educativa para resolver algunos problemas de distribución de aplicaciones educativas mediante estándares de interoperabilidad; compartimos un ejemplo de vinculación entre un desarrollo externo y el LMS Moodle; y finalmente, describimos una de las prestaciones de los servicios de información de aprendizaje con el IMS-LTI y presentamos nuestras conclusiones al haber experimentado con los estándares antes citados.
ESTÁNDARES DE INTEROPERABILIDAD
La proliferación de recursos educativos virtuales creció sin un marco común de desarrollo en cuanto al uso de metodologías, técnicas documentales y psicopedagógicas, que en primera instancia permitieran garantizar la accesibilidad, interoperabilidad, durabilidad y reutilización de los contenidos curriculares a través de las redes de comunicación; lo anterior reflejó la necesidad de estándares que regularan estas diferencias. Organismos como ISO (International Organization for Standardization), IEEE (Institute of Electrical and Electronics Engineers) e IMS Global Learning Consortium, Inc. atienden hoy en día esta singular tarea.
La oferta en la industria educativa para crear materiales pedagógicos digitales es amplia, y en la mayoría de los casos cubre las necesidades más comunes requeridas por educadores y maestros para crear los diferentes tipos de cursos; es posible estructurar una gran variedad de recursos pedagógicos, como cursos en formato web, indexación de contenidos, glosarios, videos, cuestionarios, wikis, blogs, web-quest, enlaces a URL, foros, chats, etcétera. Sin embargo, cuando el diseño instruccional no se ajusta a la norma estandarizada, se presentan situaciones en las que es complicado implementar el recurso (pedagógico) de un curso específico en dichas plataformas (LMS) o simplemente no encaja el recurso pedagógico con el formato que ofrece el LMS; de ahí la importancia de utilizar estándares (normalizaciones) de interoperabilidad para vincular ambos recursos (aplicación de uso específico + LMS).
El SCORM (Sharable Content Object Reference Model) es un estándar liberado por ADL (Advanced Distributed Learning) (2011) y una de las especificaciones más utilizadas en la actualidad para distribución de recursos educativos en numerosas herramientas, como Exe-Learning y Reload; permite importar y exportar contenidos y objetos de aprendizaje a través de distintas plataformas que son compatibles entre sí o se encuentran certificadas para su uso.
Dicho recurso de empaquetado es bastante poderoso y, en cierta medida, ofrece la posibilidad de reutilizar y distribuir contenidos pedagógicos digitales muy variados; por ejemplo, un paquete SCORM de un curso de matemáticas que incluye presentaciones en PowerPoint, diseño de actividades y acceso a webs de práctica y ejercitación puede ser compartido entre los LMS Reload y Moodle, o viceversa, sin la necesidad de reprocesar dichos contenidos. El SCORM resulta una alternativa adecuada para los casos en los que las características del curso están más o menos alineadas dentro de un marco regular de formatos comunes de diseño instruccional.
Cuando el diseño de un curso demanda recursos de software con características muy específicas (lenguaje de programación, uso de manipulativos, simulaciones, etcétera), el SCORM tiene problemas de representación, ya que no ofrece un soporte completo de interoperabilidad ni accesibilidad a los recursos. En estos casos, la necesidad estriba en saber cómo vincular de forma más integral un curso o actividad de aprendizaje externa con el LMS institucional y, además, establecer una comunicación de datos entre ambos sistemas sin comprometer la funcionalidad ni la seguridad de acceso; por ejemplo, evaluar a los estudiantes de un curso ofrecido en un LMS a partir de las actividades realizadas en una aplicación externa; en situaciones como éstas, es necesario recurrir a estándares de interoperabilidad más avanzados, como el IMS-LTI (IMS-Learning Tools Interoperability).
INTEROPERABILIDAD ENTRE MOODLE Y APLICACIONES WEB
El éxito de un contenido de aprendizaje está mediado hoy en día por su capacidad de ser reusable y distribuible, por lo cual es muy importante cuidar aspectos como la accesibilidad (a los contenidos del usuario), empaquetamiento de contenidos (estándar de almacenamiento) e interoperabilidad (protocolo de intercambio de información). En cuanto al LMS utilizado, debe ser lo suficientemente robusto para satisfacer las diversas necesidades de los estudiantes, administradores, creadores de contenidos y profesores de manera simultánea. Los patrones de uso variarán con consideración dependiendo del contexto específico de la implementación.
Moodle es un LMS muy usado en el ámbito del e-learning por la diversidad de herramientas que ofrece en un entorno integrado, lo que permite establecer múltiples escenarios de aprendizaje (Moodle, 2012a); presenta una interfaz basada en web que ayuda a que los aprendices, tutores y administradores inicien sesión de manera permanente y ejecutar sus actividades de enseñanza y aprendizaje diarias, además de operar con una amplia variedad de tecnologías de servidores web y bases de datos.
Entre los recursos y las herramientas educativas que ofrece Moodle, se encuentra una denominada "external tool" (Moodle, 2012b; Henrick, 2011), un componente que crea un vínculo entre el LMS y las herramientas externas de aprendizaje basadas en web que sean compatibles con el estándar de interoperabilidad IMS-LTI (Moodle, 2011). Su objetivo es la integración de cualquier LMS con toda aplicación de aprendizaje desarrollada por terceros (IMS, 2012; IMS, 2013).
El estándar IMS-LTI favorece la conexión de un LMS con aplicaciones alojadas en forma externa (Vickers, 2012a) ; técnicamente, las aplicaciones externas son denominadas herramientas proveedoras (TP:toolsproviders) y al LMS se le conoce como herramienta consumidora (TC:toolconsumer), ya que consume la solicitud o recurso generado por el proveedor (Vickers, 2012b).
Esta interconectividad se presenta cuando el LMS institucional (por ejemplo, Moodle) de un profesor de física en España accede a un recurso denominado FISC, creado por un profesor en México y alojado en un servidor en este país, con el cual es posible generar simulaciones a través de un equipo especializado en México, que no son posibles de exportar a través del SCORM; por lo tanto, se decide utilizar LTI para comunicar ambas aplicaciones, que seguirán residiendo en su ubicación original y simplemente se les vincula para brindar al LMS de España accesibilidad al recurso FISC alojado en México.
En este contexto de interoperabilidad, cuando un usuario cambia del LMS a otro sistema externo, es posible compartir información como la siguiente: detalles del perfil (nombre, correo electrónico), detalles del contexto instruccional (LMS utilizado) y del contexto específico del que provienen (curso) y rol dentro del contexto (alumno) (Henrick, 2012) .Este proceso de "lanzamiento" se produce de manera segura utilizando esquemas de cifrado de datos mediante el navegador web del usuario (IMS, 2010). Una conexión entre los dos sistemas se crea con sólo introducir la URL, la identificación del consumidor (consumer key) y una llave secreta (shared secret) para asegurar la conexión con el LMS (Leyva, 2012) .En Moodle, dichas acciones son definidas de forma sencilla. La Figura 1 ilustra un ejemplo de configuración de una herramienta externa.
El IMS-LTI utiliza el protocolo OAuth (2012) como un mecanismo de seguridad diseñado para proteger las peticiones POST y GET en el lanzamiento y los mensajes que serán serializados y enviados entre las dos aplicaciones. El OAuth describe el modo de construir dichos mensaje de texto y luego firmarlos usando una llave secreta. La firma se envía como parte de la solicitud POST y es validada por la TP.
La Tabla 1 sintetiza algunos elementos de datos que se transmiten como parte del método POST cuando se realiza un lanzamiento básico; dichos elementos pueden variar dependiendo del tipo de datos necesario que requerirá la TP y el nivel de detalle que puede transmitir la TC (Mcfall & Neumann, 2010) .
Tabla 1 Elementos de datos transmitidos durante un lanzamiento IMS-LTI
| Campo | Ejemplo de valor | Descripción |
|---|---|---|
| lti_message_type= | basic-lti-launch-request | Mensaje básico de lanzamiento. |
| lti_version= | LTI-1p0 | Indica la versión de la especificación que se utiliza para este mensaje en particular. |
| resource_link_id= | 88391-e1919-bb3456 | Valor único que garantiza que el identificador del recurso TP será único dentro de la TC para cada ubicación del enlace. Si la herramienta/actividad se coloca varias veces en el mismo contexto, cada una de estas ubicaciones será distinta; este valor también cambiará si el recurso se importa a otro sistema o contexto. |
| resource_link_title= | UADY_FMAT_MCC | Título para el recurso; texto que aparece en el enlace. |
| user_id= | 0ae836b9-7fc9-4060-006f-27b2066ac545 | Identificador único del usuario (no contiene información del usuario); en un enfoque de buenas prácticas, este campo debería ser la llave primaria (primary key) del registro de usuario generada por la TC. |
| roles= | Instructor, user, etcétera | Si esta lista no está vacía, debe contener al menos un rol del sistema de roles definidos por IMS Standard Vocabularies (LIS) (Feng & Lee, 2010). |
| lis_person_name_given; lis_person_name_family; lis_person_name_full; lis_person_contact_email_primary | NA | Estos campos contienen información acerca de la cuenta de usuario que está realizando este lanzamiento. Los nombres de estos elementos de datos se toman del LIS. |
| context_id= | 8213060-006f-27b2066ac545 | Valor que identifica de forma única el contexto que contiene el enlace que se puso en marcha. |
| context_type= | Course, section, group, etcétera | Esta cadena es una lista separada por comas de valores URN que identifican el tipo de contexto. Como mínimo, la lista debe incluir un valor URN extraído del vocabulario LIS. |
| lti_errormsg | Si la herramienta se ha ejecutado normalmente y pretende que un mensaje se muestre al usuario, puede incluir un mensaje de texto como parámetro lti_msg a la dirección URL de retorno. Si la herramienta está terminando en forma normal e intenta dar a la TC un mensaje para iniciar la sesión, utilice el parámetro lti_log. Estos datos deberán enviarse en el URL como GET, por lo cual la TP debe tener cuidado de mantener lo suficientemente pequeña la longitud total de los parámetros como para caber dentro de los límites de una cláusula GET. |
La Figura 2 presenta una imagen de la arquitectura IMS-LTI 1.0, conocida como servicio básico de lanzamiento LTI.
Durante el proceso, un usuario, tal vez un estudiante, hace clic en un enlace LTI (en un recurso external_tool de Moodle, como el que ilustramos en la Figura 1, que solicita un lanzamiento a la herramienta); el LMS (TC) prepara un conjunto de parámetros de lanzamiento incluyendo los parámetros estándar, opcionales y personalizados, que son parte del paquete de datos incluidos en el mensaje de lanzamiento. Después, el OAuth firma digitalmente la carga útil para asegurar su integridad; la TC envía este mensaje de vuelta al navegador con un pequeño trozo de javascript auto-enviado al proveedor de la herramienta (TP) (IMS, 2010). Además, a partir de la versión de IMS-LTI1.1, se ofrece un retorno del servicio de resultados, que permite a la TP leer, escribir o borrar un valor del libro de calificaciones de la TC (para un usuario y el contexto específico) (Mcfall & Neumann, 2012).
La Figura 3 ilustra la arquitectura IMS-LTI v.1.1; en esta imagen, observamos que la fase de lanzamiento es estructuralmente idéntica a la v. 1.0 IMS-LTI (la línea de puntos es una forma rápida para representar las diversas flechas del lanzamiento en 1.0). Sin embargo, al menos dos parámetros adicionales se pasan en el lanzamiento: lis_outcome_service_url, que es la URL de la TC en la cual se recibirán las notificaciones del resultado del lanzamiento y un oauth_consumer_key, que identifica de manera única a la TC que lo ha ejecutado.
Esta arquitectura emplea un modelo de seguridad en el cual no es necesario que los servicios sean llamados sincrónicamente en el contexto de la sesión del usuario particular: la TP puede retener los valores de lis_outcome_service_url y lis_result_sourcedid de un lanzamiento y luego llamar a la TC tiempo después de que la sesión del usuario ha terminado; esto facilita a la TP recoger calificaciones y enviarlas a la TC en bloques o cuando un instructor dé clic en algún botón de la TP. Lis_result_sourcedid es un código proporcionado por la TC (LMS) para asegurar que el resultado se ha etiquetado de modo correcto para el usuario particular (idusuario/curso/recurso) involucrado en esta interacción. En síntesis, podemos decir que esta versión de IMS-LTI incorpora un punto de espera para que el resultado de una actividad de aprendizaje realizada en una aplicación externa pueda ser notificado al LMS en el momento que se considere más apropiado.
En la arquitectura IMS-LTI 1.2 (ver Figura 4) se soluciona la situación del registro de los resultados de las evaluaciones mediante un componente que simplifica la navegación por los libros de calificaciones y la selección del libro (registrar los resultados de una actividad en diversos libros de calificaciones).
SERVICIOS DE INFORMACIÓN DE APRENDIZAJE CON IMS-LTI
Sin duda, uno de los recursos que más ha alentado el uso de los servicios de información de aprendizaje (LIS: Learning Information Services) es la posibilidad de retorno de calificaciones de TP a TC; en este apartado, describimos cómo la TC ofrece datos a la TP con el fin de permitir a esta herramienta llamar a un subconjunto de LIS (Feng & Lee, 2010). La Figura 5 ilustra la arquitectura del servicio LIS.
Este servicio de actualización de calificaciones recibe mensajes de tipo POX (Plain Old XML) firmados con OAuth. Es compatible con la configuración, actualización y borrado de valores LIS asociados con una determinada combinación usuario/recurso. El único tipo de calificación que soporta este servicio es numérico decimal en el intervalo de [0.0 a 1.0]. La Figura 6 muestra la ficha técnica LTI para este servicio (IMS Final Release).
Figura 6 Ficha técnica del servicio LTI para la devolución de calificaciones.
Para poder utilizar los servicios LIS, la TC (LMS) debe tener un enlace de recursos en un curso e indicar que se recibirán las calificaciones de la TP; deberá configurar cualquier enrutamiento necesario entre el enlace LTI y el libro de calificaciones (ver figura 7).
Un valor importante durante este proceso es el definido para el parámetro lis_result_sourcedid, en el cual se señala el identificador de resultado LIS (si lo hay) asociado con este lanzamiento; en éste se define una única fila y columna en el libro de calificaciones de la TC, y el valor es único para cada combinación de resource_link_id/user_id. Otro valor importante es el definido en el parámetrolis_outcome_service_url="", cuyo valor no debe cambiar de un lanzamiento al siguiente y, en general, la TP puede esperar un mapeo uno a uno entre el lis_outcome_service_url y un oauth_consumer_key particular; por lo regular, la TP asume que este URL no cambia de un lanzamiento a otro.
El formato de actualizaciones de calificaciones depende de la configuración de la TC en cuanto a si esta operación en realidad reemplaza una calificación o si mantiene un historial de las calificaciones. Si la TC conserva el historial de calificaciones, la TP sólo opera sobre la "más reciente"; es decir, no tiene idea del enfoque de la TC respecto al historial de calificaciones y lo trata como si hubiera una única calificación para cada lis_result_sourcedid.
Por último, otro elemento significativo lo encontramos en el parámetro replaceResultResponse, que indica el éxito o fracaso de la operación en el área de encabezado de la respuesta y, como tal, la zona del cuerpo está vacía; por lo tanto, la TC debe responder a estas operaciones replace Result con un imsx_codeMajor de "fracaso". A continuación, mostramos un ejemplo de éxito:
<imsx_statusInfo>
<imsx_codeMajor>success</imsx_codeMajor>
<imsx_severity>status</imsx_severity>
<imsx_description>Score for 3124567 is now 0.92</imsx_description>
<imsx_messageRefIdentifier>999999123</imsx_messageRefIdentifier>
<imsx_operationRefIdentifier>replaceResult</imsx_operationRefIdentifier>
</imsx_statusInfo>
Existen algunas otras funciones útiles de los servicios LIS, las cuales se pueden consultar y revisar con detalle en su sitio web.
CONCLUSIONES
En este artículo, presentamos dos estándares reconocidos y utilizados de manera amplia para distribuir recursos pedagógicos de alta calidad y complejos por lo general o que usan tecnología muy específica para ciertas áreas de aprendizaje: SCORM y LTI. Apreciamos cómo éstos ofrecen soluciones prácticas y relativamente fáciles de implementar para garantizar el acceso, compatibilidad y distribución de algunos recursos pedagógicos. Describimos el SCORM como una introducción a los estándares y ofrecimos mayores detalles sobre el uso y alcance del IMS-LTI; revisamos aspectos importantes de su arquitectura, como la toolconsumer (TC), que se refiere a la aplicación o sistema, por ejemplo, Moodle, que consume los datos generados por una herramienta externa, así como la toolprovider (TP), la herramienta externa que provee el contenido para ser usado por la TC; el contexto es equivalente a un curso o podría ser también un grupo u otro tipo de contexto. La figura 8 muestra un aspecto general del proceso.
El IMS-LTI representa una opción viable, económica y sencilla que nos permite extender la vida útil de los sistemas sin necesidad de hacer programas a la medida que demandan tiempo y recursos adicionales al diseño instruccional y computacional; conocer, aprovechar y utilizar estos recursos, sin duda, nos ayudará a invertir nuestro tiempo en diseñar y elaborar mejores estrategias de enseñanza y no en los aspectos técnicos que hay que realizar para compartir y distribuir estos recursos pedagógicos mediante el uso de las diversas tecnologías digitales.
Desde la perspectiva del programador, al utilizar el IMS-LTI no es necesario tener experiencia en cada plataforma. Puede usar su propio entorno y lenguaje de programación preferido; sólo se requiere desarrollar un código base para soportar múltiples LMS. Se pueden construir plug-ins para plataformas específicos, como un módulo de Moodle o un bloque de Blackboard Building (Blackboard, 2012) si se desea lograr un nivel más profundo de la integración o la interfaz de usuario más consistente.
Desde la perspectiva de los maestros, éstos pueden tener una mayor capacidad de seleccionar y conectar a la perfección sus aplicaciones y recursos ajustados a las necesidades de aprendizaje de sus estudiantes, las cuales no son tan populares como para ser apoyadas por la institución. También, se puede compartir una única instancia de una aplicación con usuarios de diferentes aplicaciones o instituciones.
Actualmente, son cada vez más las empresas que utilizan IMS-LTI; por mencionar algunas, Noteflight (2012) está aprovechando IMS-LTI para favorecer que su herramienta de composición musical sea utilizada por sus estudiantes; en el ámbito editorial, empresas como McGraw-Hill (2011) están desplegando de manera activa contenido usando IMS-LTI.
