SCORM y Tin Can API

Resumen: Describimos brevemente el estándar SCORM y su evolución, la denominada Tin Can API o Experience API (x-API).

SCORM (Shareable Content Object Reference Model) es un estándar que se utiliza para la creación y compartición de cursos entre plataformas de formación.

La idea detrás de SCORM es paquetizar diferentes objetos formativos en un formato común (paquete SCORM) capaz de ser cargado y reproducido en cualquier plataforma.

El estándar SCORM define:

• La manera en que se paquetizan los objetos formativos.
• El modo en el que los objetos formativos se secuencian.
• Los mecanismos utilizados en la visualización de los contenidos.
• La manera en la que los paquetes SCORM se relacionan con la plataforma de formación, fundamentalmente para registrar eventos de usuario.

Los objetos formativos incluidos en un paquete SCORM pueden ser creados con cualquier tecnología o herramienta de generación de contenidos: Flash, HTML5, etc.

SCORM agrupa los objetos formativos en el denominado paquete SCORM y genera un índice que describe qué objetos forman parte del paquete SCORM y cuál es su secuenciamiento.

Paquetización SCORM

El estándar SCORM también define qué información relativa a la navegación del usuario debe registrarse: tiempo de estancia en el curso, último objeto visitado, calificación en cuestionarios, etc. No se especifica, sin embargo, en qué sistema o formato debe almacenarse esta información.

El estándar SCORM posee relevancia desde dos puntos de vista importantes:

• Estandariza el modo en el que se paquetizan los cursos y, de este modo, permite la portabilidad de cursos entre plataformas.
• Permite la recogida de un conjunto de información predefinida acerca del comportamiento del usuario durante su navegación a través de los contenidos.

Existen diferentes versiones del estándar SCORM:

• SCORM 1.2 (Octubre 2001): Es la versión más extendida y soportada en las plataformas de formación. Se ha convertido en el estándar de facto, ya que versiones posteriores del estándar han gozado de menor aceptación.
• SCORM 2004 (Enero 2004 a Marzo 2009 – diferentes versiones):  Es la evolución de SCORM 1.2. Aporta mecanismos complejos de secuenciación de contenidos y corrige algunas ambigüedades del estándar 1.2.

Desde abril de 2013, se habla también de Tin Can API. Tin Can API se presenta como la nueva versión de SCORM. ¿Hasta que punto es esto cierto?

Tin Can API es, de hecho, una evolución de la manera en que la interacción del usuario con la formación es registrada. Estas son las novedades que aporta Tin Can API:

• Los registros de actividad de usuario, se almacenan en una nueva entidad denominada LRS (Learning Record Store). El LRS es independiente de la plataforma de formación utilizada. En Tin Can API, la plataforma de formación recoge los eventos de navegación de usuario y se los hace llegar al servidor LRS. El conjunto de eventos registrados, se conoce como “Flujo de Actividad” o “Activity Stream”.

• Se estandariza el modo en el que los eventos de usuario son registrados. Para el registro de estos eventos se utiliza u modelo actor-verbo-objeto:

         Actor: SALLY

         Verbo: VISUALIZÓ

         Objeto: CONTENIDO A

         Evento registrado: “SALLY VISUALIZÓ CONTENIDO A”

• Los eventos se registran en una estructura de datos de tipo JSON (ver ejemplo) en la que los campos que definen el actor, los verbos a utilizar en cada tipo de evento registrado y el formato en que se expresa el objeto están predefinidos.

            Ejemplo de registro en Tin Can API:

           {

           "actor": {

           "name": "Sally Glider",

           "mbox": "mailto:sally@example.com"

           },

          "verb": {

             "id": "http://adlnet.gov/expapi/verbs/experienced",

             "display": {"en-US": "experienced"}

          },

         "object": {

            "id":"http://example.com/activities/solo-hang-gliding",

            "definition": {

               "name": { "en-US": "Contenido A" }

           }

          }

• El LRS permite la recogida de eventos externos a la plataforma de formación de modo que, en teoría, otras experiencias formativas que no ocurren a nivel de plataforma también podrían registrarse. Imaginemos que desarrollamos una aplicación de pregunta/respuesta.  Los resultados de esta aplicación también podrían volcarse en el LRS en el mismo formato que si fueran generados por una plataforma.

Arquitectura Tin Can API

La estandarización del formato de registro de eventos presenta la gran ventaja de que permite la creación de herramientas de análisis aplicables a múltiples plataformas de formación con independencia de su fabricante o tecnología, siempre que estas sean compatibles con Tin Can API.

Con respecto a Tin Can API, cabe nombrar algunos aspectos que no necesariamente favorecen su adopción:

• La implantación de Tin Can API requiere cambios en las plataformas de formación y en el contenido SCORM de los cursos. (Los cambios en el contenido se realizan habitualmente a través de las herramientas de autor que deberán ser capaces de generar SCORMs compatibles con Tin Can API).
• La separación entre plataforma de formación y LRS implica o bien el despliegue de un LRS propio o la subcontratación de un LRS de terceros, lo que se traduce en costes adicionales. En este sentido, entendemos que muchas plataformas de formación desarrollarán funcionalidad adicional que les permita ser utilizadas también como LRS.
• El conjunto de verbos definidos en el estándar no necesariamente contempla las necesidades de todos los eventos que se deseen registrar. Además, existe cierto grado de libertad en la interpretación de los verbos lo que podría dar lugar a ambigüedades en el registro y análisis de eventos.
• Por último, Tin Can API prevé que aplicaciones o sistemas ajenos a la plataforma de formación registren otras experiencias formativas de los usuarios. No sabemos hasta qué punto esto se materializará en algo tangible.

Tin Can API es conocida también como “Experience API” o “x-API” porque su arquitectura permite que en el LRS se registren no sólo las experiencias formativas que ocurren a través de la plataforma de formación, sino aquellas otras que el usuario pudiera experimentar en otras entornos tales como aplicaciones móviles, intranets, etc. En este sentido, Tin Can API se presenta como un registro universal de experiencias formativas de usuario (de ahí su nombre de “Experience”). Para que esta expectativa se materializara, debería generarse suficiente tracción en la industria para que otros elementos, más allá de las plataformas de formación, utilizaran Tin Can API.

Convertir el LRS en un registro de todas las experiencias formativas de un usuario genera otras preguntas relativas a la privacidad que van más allá de las puramente técnicas.

Por último,  el nombre de Tin Can API hace referencia clara a que Tin Can se entiende como una API (Application Programming Interface) que no es sino la definición y especificación de cómo se establece la comunicación entre dos entidades software: el LRS y cualquier otra entidad (plataforma de formación, aplicación, etc.) que decida utilizar el LRS para registrar eventos formativos de usuario.

Para conocer más:

• Advanced Distributed Learning Network (ADL): http://www.adlnet.org
• SCORM versions: http://scorm.com/scorm-explained/business-of-scorm/scorm-versions/
• Tin Can API specification: https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md