sábado, 3 de abril de 2010

Diferencias entre IMS Common Cartridge y SCORM

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:

4 comentarios:

  1. Hola Juan, veo muchas intenciones pero poca realidad:-)
    No entiendo algunas cosas como las que comentas, dices:
    "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."
    a que te refieres que las actividades EN SI SE INTEGRAN DE FORMA NATIVA ¿alguna forma tendran que tener para "hablar" con su contenedor ¿telepatia?
    Un Saludo

    ResponderEliminar
  2. Hola Jorge,

    lo primero de todo te aclaro mi postura respecto a esta especificación, yo no soy un defensor de IMS CC, lo que procuro es dar información lo más objetivamente posible. (Tengo pendiente un post sobre mi opinión sobre esta especificación)

    Te explico lo de "forma nativa", poniendo como ejemplo como funciona SCORM en Moodle.
    Mientras un paquete SCORM en Moodle se importa como una actividad más y es lanzada usando un "módulo reproductor del SCORM" un paquete IMS CC se incorporaría transformando los tipos de recurso del paquete a actividades o recursos de Moodle.
    De esta forma:
    Contenido Web -> Tipo recurso página html Moodle
    Enlace -> Tipo recurso enlace en Moodle
    IMS QTI -> Actividad (módulo Quiz) en Moodle
    Tienes más info aquí: http://docs.moodle.org/en/Development:IMS_common_cartridge_Implementation_specifics

    Es decir, se integran como las propias actividades del LMS, pudiendo hacer tu lo que quieras con ellas (e incluso intercalar algunas propias entre medias).

    Comunicarse con el contendor, en principio, no habrá forma ya que es el LMS quién se encarga de guardar los resultados de los quiz, registrar en dónde se quedó el usuario, etc..

    Eso sí, si por algún motivo quieres hacer un cuestionarios en Flash, o meterlos dentro de un objeto de aprendizaje desarrolado en Flash tendrás que seguir empaquetándolo como un SCORM, y si se quiere, meter el SCORM dentro de un paquete IMS CC.

    La cuestión está en que IMS CC no es un reemplazo de SCORM, ni busca hacer lo que hace SCORM, sino algo diferente que viene a convivir con él.

    Veremos como evoluciona todo, yo le veo cierto futuro contando con que en la alianza de Cartridge están metidos peces gordos como blackboard y grandes productores de contenidos

    ResponderEliminar
  3. blackboard no es un pez gordo, de momento:-)
    Ya veremos. pero de momemto le veo todo muy verde:-(

    ResponderEliminar
  4. Hola Jorge,

    ¿a qué te refieres con que no es un pez gordo? ¿Te refieres en influencia? ..En USA dominan el mercado y con diferencia aún.

    Independientemente de que vaya a menos y perdiendo cuota, una empresa con 1100 empleados y 240 millones de dólares de facturación anual (en 2007) creo que se puede considerar gorda.

    Por otro lado otras empresas metidas en el consorcio son McGrawHill, Pearson, elsevier, sakai, moodle.com, oracle e incluso Microsoft que ya ha desarrollado herramientas de conversión entre SOCORM e IMS CC

    Tengo pendiente también un post sobre recursos de IMS CC, por otro lado, yo tengo esperanza en que esto madure hacia algo bueno :)

    Un saludo

    ResponderEliminar