En post anteriores he descrito las características de IMS Common Cartridge (IMS CC en adelante) y las críticas que ha despertado. Algunas de esas críticas hacían énfasis en que en la práctica IMS CC no presenta grandes diferencias con SCORM.
En este post voy a procurar sintetizar las mayores diferencias de estas especificaciones partiendo de la base inicial que sus cometidos, teóricamente, son diferentes.
Cito inicialmente este párrafo en inglés de las
FAQ de IMS CC en su página oficial:
SCORM was developed to support portability of self-paced computer-based training content. This is a very different set of needs than those of digital course materials that are used to support an online course where there is a cohort of students and an instructor, teacher, or professor. Common Cartridge was developed primarily to support the use of digital course materials and digital books in the instructional context. It was not designed as a replacement for SCORM. As the answers to the questions below indicate, educational scenarios require advances in assessment, interactive content, sequencing of content, collaboration, facilitation, and authorization that SCORM was not designed to address, but Common Cartridge was
Haciendo una traducción y resumen libre lo que se viene a indicar es que mientras SCORM se desarrolló para facilitar la portabilidad de objetos de aprendizaje orientados principalmente a la autoformación, el enfoque de IMS CC es el de habilitar el uso de materiales educativos así como libros digitales en un contexto instruccional donde interviene un conjunto de estudiantes y un profesor-instructor.
Un ejemplo al que se suele recurrir para ilustrar lo anterior es que un contenido en formato SCORM podría formar parte de un contenido en formato IMS CC pero no lo contrario.
En la práctica, la realidad es que SCORM se ha utilizado como un estándar de facto para la distribución de contenidos y cursos dado la inexistencia de especificaciones alternativas.
Para continuar hablando de las diferencias voy a utilizar una
tabla que aparece en las FAQ de IMS CC donde se hace una comparación entre SCORM e IMS CC:
Esta tabla no refleja la situación actual de IMS CC, sino lo esperado incluyendo funcionalidades que no figuran en la especificación actual.
- Estándar para el empaquetado: Ambas usarán IMS CC (diferentes versiones). Esto facilita la conversión directa de un SCORM a un IMS CC
- Estándar para metadatos: IMS CC utiliza un subconjunto del empleado por SCORM mapeando al estánar Dublin Core
- Estándar para secuenciación: Aquí hay una gran diferencia, mientras SCORM soporta IMS simple sequencing, IMS CC delega la configuración de secuenciación al propio LMS, aunque se indica que se está estudiando dar soporte a IMS Learning Design y también IMS simple sequencing. En Moodle 2.0, por ejemplo, se podría implementar secuenciación utilizando las actividades condicionales posteriormente a la importación del paquete.
- Estándar para registro, comunicación con la plataforma: Esto es una gran diferencia, mientras con SCORM mediante Javascript y uso de IEEE se puede leer y enviar información al LMS con IMS CC no hay intercomunicación con la plataforma, motivado principalmente porque las activiades en sí se integran de forma nativa.
Así mientras con SCORM hay que enviar los resultados de un cuestionario utilizando javascript, con IMS CC automáticamente los resultados del mismo irían al libro de calificaciones del curso proporcionado por el LMS.
Por otro lado, a futuro cercano IMS CC dará soporte para
IMS Basic LTI, lo que permitirá integración a nivel de SSO con herramientas externas.
- Estándar para evaluación: IMS CC soporta un subconjunto de IMS QTI y como ya se ha mencionado anteriormente los resultados de las evaluaciones se registran nativamente en el LMS, con SCORM los cuestionarios se deben elaborar mediante flash o html/javascript (utilizando herramientas de autor, por ejemplo) que envíen los resultados usando el API Runtime mediante Javascript.
- Estándar para integrar herramientas web 2.0 y otras: IMS CC soportará a futuro IMS LTI, con SCORM las integraciones se deben hacer a medida y no hay capa de webservices o similar.
- Estándar para la autorización de contenidos: IMS CC soporta un webservice que permitirá validar si un usuario tiene permisos para visualizar ciertos contenidos.
- Soporte para foros: SCORM no trae soporte a no ser que sea mediante herramientas externas al LMS.
- Soporte para estándares de curriculum: IMS CC incorporará a futuro soporte mediante otros estándares.
- Soporte para envío de resultados: IMS CC lo incorporará a futuro mediante otros estándares.
- Soporte para accesibilidad: IMS CC lo incorporará a futuro mediante otros estándares.
A destacar de nuevo que la importación por parte de un LMS de un paquete IMS CC se realizará convirtiendo los contenidos del paquete a actividades/recursos nativos-propios del LMS.
Se podría decir que IMS CC podrá actuar como un sistema de copia de seguridad universal (limitado a un subconjunto de actividades comunes entre diferentes LMS) para todos aquellos LMS que soporten Importación y Exportación en este formato.
Una de las ventajas de que el paquete se importe a través actividades nativas es que el profesor o editor del curso una vez haya importado el paquete en formato IMS tendrá libertad para:
- Modificar los recursos de contenido desde el propio LMS (si estos son de tipo HTML)
- Modificar los cuestionarios
- Crear nuevos cuestionarios a partir del banco de preguntas que incorpora el paquete
- Habilitar y deshabilitar los recursos importados
- Reordenar los contenidos del paquete para definir una nueva organización del mismo
- Utilizar herramientas adicionales del propio LMS (por ejemplo en Moodle 2.0 los condicionales para definir los criterios en base a los cuales se habilita el acceso un contenido o actividad)
- Exportar de nuevo el paquete con los cambios que haya realizado (siempre y cuando se puedan reflejar en el paquete por estar soportados)
Referencias y más información:
