* U D G R H Q ,Q J H Q LH U ¯D 0 X OWLP H G LD€¦ · 4, un nuevo est andar para las aplicaciones de e-learning que estructura y permite alma- cenar las interacciones de una persona

Enero 2019

Trabajo Fin de GradoAutor:Mariano López EscuderoTutor/es:Mª Pilar Escobar EstebanManuel Marco Such

Grado en Ingeniería Multimedia

Analisis e implementacion deExperience API para recursos

online

Implementacion sobre en vıdeos Lengua de Signos Espanola,Biblioteca Virtual Miguel de Cervantes

AutorMariano Lopez Escudero

DirectoresMaPilar Escobar Esteban

Departamento del Lenguajes y Sistemas Informaticos

Manuel Marco SuchDepartamento del Lenguajes y Sistemas Informaticos

Grado en Ingenierıa Multimedia

ALICANTE, 3 de febrero de 2019

Resumen

En el sector educativo es sumamente importante disponer de datos suficientes quepermitan analizar la utilizacion de los recursos multimedia para poder conocer la efi-ciencia de los objetos en el proceso de aprendizaje. El segmento mas importante dondese centrara este trabajo es el campo educativo, en particular a instituciones que elaborenmateriales educativos en vıdeo online.

Los problemas que se han detectado y a los que se pretende dar solucion son el des-conocimiento sobre la calidad de los contenidos online y la falta de informacion sobre laexperiencia de aprendizaje del usuario. Despues del estudio del problema se puede decirque los estandares de interoperabilidad mas antiguos como Shareable Content ObjectReference Model (SCORM) se estaban quedando obsoletos. En los ultimos anos estacobrando relevancia en el mundo del e-learning un nuevo estandar, Experience API, queestructura y permite almacenar las interacciones de una persona ante distintas activi-dades de aprendizaje online. Empresas tan importantes como Google o Adobe Systemestan apostando por esta nueva tecnologıa aplicandola en algunos de sus productos.

El objetivo del proyecto es crear una aplicacion para monitorizar y analizar las interac-ciones del usuario ante los recursos multimedia en la plataforma de Youtube. En la partetecnica de Experience API, se analiza mas a fondo la estructura de las declaraciones yse descubre su utilidad para capturar experiencias. En el nivel mas simple, la estructurade la declaracion Experience API se puede expresar en la forma de object, verb, actor.

Para llevar a cabo esta tarea se han utilizado recursos de la Biblioteca Virtual Mi-guel de Cervantes, en particular, un conjunto de vıdeos signados en Lengua de SignosEspanola (LSE). La propuesta, por tanto, esta enfocada a integrar un metodo para op-timizar los procesos de aprendizaje de la lengua de signos online.

v

Preambulo

El ritmo vertiginoso de la sociedad actual hace necesaria la incorporacion de Tecnologıasde Informacion y Comunicacion (TIC) al contexto educativo. De esta manera se puedengenerar nuevos paradigmas que favorezca el desarrollo de habilidades cognitivas en elusuario, a partir del diseno de tecnicas que favorezcan la construccion de un aprendizajeactivo, participativo y constructivo capaz de permitir a los estudiantes dar respuesta aproblematicas y situaciones de su contexto real.

En la actualidad Internet se ha convertido en un facilitador de conocimiento, puespone a disposicion de la sociedad informacion que, bajo una estructura logica, secuen-ciada y adecuadamente analizada, puede derivar en el diseno de programas educativossocialmente pertinentes impartidos a traves de esta innovadora red, dando paso a lo quese conoce como e-learning, generando nuevos modelos de ensenanza aprendizaje, permi-tiendo que las TIC ayuden en la mejora de resultados en el ambito educativo.

La posibilidad de poder mejorar los contenidos tanto en rendimiento como en validezanima a realizar al presente estudio. Sobretodo por centrarlo para personas con disca-pacidad auditiva, la lengua de signos es vital y no solo deben aprenderlo ellos.

Por tanto, el objetivo de este Trabajo Fin de Grado (TFG) es analizar e implementarun sistema para analizar el contenido de vıdeos de LSE. Este estudio servira en el futuropara crear aplicaciones capaces de analizar la calidad de sus cursos y poder compartirlos.

A mis padres, por estar siempre cuando los necesito. Su confianza y apoyo me han convertidoen la persona que soy ahora. A mi tutora Pilar, por la oportunidad de hacer este proyecto, por

su ayuda y consejo durante el proceso del mismo. A todos los profesores que durante estos anosno solo me han ensenado sus asignaturas y han ido un paso mas alla. Y por ultimo a mi

familia, companeros y amigos porque todos ellos han puesto su granito de arena ademas deaguantarme durante este proyecto.

ix

Cuando invente la web,no tuve que pedirle permiso a nadie.

Ahora, millones de personas la utilizan libremente.

Tim Berners-Lee.

xi

Indice general

Resumen V

1. Introduccion 1

2. Modelo de negocio 32.1. Lean Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1. Segmentos de cliente . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2. Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.3. Propuesta de valor unica . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4. Solucion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.5. Canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.6. Estructura de costes . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.7. Metricas clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.8. Fuentes de ingreso . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.9. Ventaja especial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. DAFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1. Debilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.2. Fortalezas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3. Amenazas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.4. Oportunidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Analisis de los riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Objetivos 113.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4. Estudio del problema 134.1. Evolucion del proyecto Tin Can . . . . . . . . . . . . . . . . . . . . . . . . 144.2. xAPI vs SCORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3. Experience API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.4. Estructura de las declaraciones . . . . . . . . . . . . . . . . . . . . . . . . 17

4.4.1. Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4.2. Verbo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4.3. Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.4. Verbos vs Actividades . . . . . . . . . . . . . . . . . . . . . . . . . 274.4.5. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4.6. Resultado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4.7. Extensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

xiii

xiv Indice general

4.4.8. Otros campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5. Learning Record Store . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5. Metodologıa 37

6. Analisis y especificacion 416.1. Descripcion general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2. Perspectiva de producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3. Funciones del producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.5. Requisitos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . 42

7. Diseno 477.1. Arquitectura seleccionada . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.2. Tecnologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.3. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.4. Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8. Implementacion 538.1. Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538.2. Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9. Resultados 59

10.Conclusiones 6310.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6310.2. Lıneas de trabajo futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Bibliografıa 66

A. Glosario 67

Glosario 68

B. Anexo. Esquema de base de datos 69

Indice de figuras

2.1. Analisis Lean Canvan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2. Analisis DAFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.1. Trello en el proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2. Ejemplo de panel GitCraken . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.1. Arquitectura orientada a servicios . . . . . . . . . . . . . . . . . . . . . . . 487.2. Tecnologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.3. Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507.4. Mockup galerıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.5. Mockup video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.1. Objeto xAPI creado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558.2. Objeto xAPI con descripcion . . . . . . . . . . . . . . . . . . . . . . . . . 56

9.1. Extracto de la galerıa de vıdeos con los que se ha trabajado . . . . . . . . 599.2. Extracto de visualizacion de vıdeo . . . . . . . . . . . . . . . . . . . . . . 60

B.1. Base de datos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

xv

Indice de tablas

2.1. Riesgos sobre la tecnologıa. . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2. Riesgos sobre el personal. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Riesgos sobre la organizacion. . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Riesgos sobre las herramientas. . . . . . . . . . . . . . . . . . . . . . . . . 92.5. Riesgos sobre los requerimientos. . . . . . . . . . . . . . . . . . . . . . . . 92.6. Riesgos sobre la estimacion. . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1. Lista de SCORM vs Experience API [Software Advice, 2018] . . . . . . . 164.2. Lista de propiedades del Agente [ADL.net, 2018] . . . . . . . . . . . . . . 204.3. Lista de propiedades de un grupo anonimo [ADL.net, 2018] . . . . . . . . 214.4. Lista de propiedades de un grupo identificado [ADL.net, 2018] . . . . . . 214.5. Lista de propiedades del Verbo [ADL.net, 2018] . . . . . . . . . . . . . . . 244.6. Lista de propiedades de la actividad [ADL.net, 2018] . . . . . . . . . . . . 274.7. Lista de propiedades de contexto [ADL.net, 2018] . . . . . . . . . . . . . . 294.8. Lista de propiedades de resultado [ADL.net, 2018] . . . . . . . . . . . . . 31

6.1. Requerimiento funcional navegar . . . . . . . . . . . . . . . . . . . . . . . 426.2. Requerimiento funcional reproducir vıdeo . . . . . . . . . . . . . . . . . . 426.3. Requerimiento funcional pausar vıdeo . . . . . . . . . . . . . . . . . . . . 436.4. Requerimiento funcional crear evento pausa . . . . . . . . . . . . . . . . . 436.5. Requerimiento funcional aumentar contador de pausas . . . . . . . . . . . 436.6. Requerimiento funcional cambiar volumen . . . . . . . . . . . . . . . . . . 436.7. Requerimiento funcional crear evento volumen . . . . . . . . . . . . . . . . 436.8. Requerimiento funcional cambiar calidad . . . . . . . . . . . . . . . . . . . 446.9. Requerimiento funcional crear evento calidad . . . . . . . . . . . . . . . . 446.10. Requerimiento funcional mutear . . . . . . . . . . . . . . . . . . . . . . . . 446.11. Requerimiento funcional crear evento muteo . . . . . . . . . . . . . . . . . 446.12. Requerimiento funcional detectar vıdeo completado . . . . . . . . . . . . . 446.13. Requerimiento funcional crear evento completado . . . . . . . . . . . . . . 456.14. Requerimiento funcional aumentar contador completados . . . . . . . . . 456.15. Requerimiento funcional generar grafica . . . . . . . . . . . . . . . . . . . 45

8.1. Lista de datos extraıdos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

xvii

Indice de Listados

4.1. Ejemplo base en formato JSON . . . . . . . . . . . . . . . . . . . . . . . . 174.2. Ejemplo de Agente conocido en JSON . . . . . . . . . . . . . . . . . . . . 184.3. Ejemplo de Agente anonimo en JSON . . . . . . . . . . . . . . . . . . . . 184.4. Otro ejemplo actor en JSON . . . . . . . . . . . . . . . . . . . . . . . . . 194.5. Ejemplo de grupo en formato JSON . . . . . . . . . . . . . . . . . . . . . 204.6. Ejemplo de verbo en JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 244.7. Ejemplo de objeto en JSON . . . . . . . . . . . . . . . . . . . . . . . . . . 254.8. Ejemplo de objeto agregando type description y extensions en JSON . . . 264.9. Ejemplo basico con contexto en JSON . . . . . . . . . . . . . . . . . . . . 284.10. Ejemplo de resultado en JSON . . . . . . . . . . . . . . . . . . . . . . . . 304.11. Ejemplo con extensiones en JSON . . . . . . . . . . . . . . . . . . . . . . 324.12. JSON ejemplo completo xAPI . . . . . . . . . . . . . . . . . . . . . . . . . 34

xix

1. Introduccion

En el conocimiento para el analisis de la utilizacion de los componentes multimedia,que se utilizan cada vez mas en los diferentes sitios web, se necesitan tecnicas sofisticadasy medios mas complejos para poder saber exactamente las interrelaciones que realizanlos usuarios con dichos objetos multimedia.

En el sector educativo esto es sumamente importante para poder conocer la eficienciade los objetos en el proceso de aprendizaje. Por ejemplo, saber el tiempo que dedica unusuario en ver un determinado vıdeo, si realiza muchas pausas, cambia algun parametroo simplemente si lo completa.

Despues de diversas alternativas como SCORM, el estandar que ha cobrado mas rele-vancia ha sido Experience API [xAPI.com Homepage, 2019] que se describe en la seccion4, un nuevo estandar para las aplicaciones de e-learning que estructura y permite alma-cenar las interacciones de una persona ante distintas actividades de aprendizaje online.

Hoy en dıa cada estudiante online es unico y esto hace que no haya las mismas facili-dades para todos. Cada uno de ellos puede navegar por el contenido de multiples modosy elegir la estrategia de aprendizaje que mas le encaje.

Actualmente 466 millones de personas en todo el mundo padecen perdida de audiciondiscapacitante, de las cuales 34 millones son ninos. Se calcula que, en 2050, mas de 900millones de personas sufriran una perdida de audicion discapacitante, segun publica laOMS [OMS Organizacion Mundial de la Salud, 2018]. A lo largo de la historia han su-frido falta de medios para su maxima integracion en la sociedad. Sin embargo, hoy en dıasu situacion mejora con la evolucion tecnologica y el desarrollo sanitario, incrementandoası su bienestar.

La llegada de una nina o un nino sordo a una familia, a un aula, o a cualquier grupoo actividad en la que participe, suscita muchas dudas. Esto hace pensar que algo no seestan haciendo bien o que podemos cambiar algo para que su llegada no suponga esacantidad de interrogantes.

La propuesta, por tanto, esta enfocada a integrar un metodo para optimizar los pro-cesos de aprendizaje de la lengua de signos online. Principalmente a las personas quetengan esta discapacidad pero tambien a las que no. ¿De que sirve que ellos aprendan ausarlo si el resto les dan la espalda? Los ninos tienen la oportunidad de aprenderlo desdemuy jovenes y se debe concienciar a que lo hagan.

1

2

Por un lado se pretende conseguir en este trabajo es poder hacer un seguimiento de laexperiencia de aprendizaje de contenidos online por medio de las interacciones del usua-rio, en el caso particular de vıdeos signados en LSE procedentes de la Biblioteca VirtualMiguel de Cervantes, de su portal Ver la Poesıa http://www.cervantesvirtual.com/

portales/ver_la_poesia/ cuyo objetivo es, como indicaba su director Angel Herrero,”la creacion y difusion internacional de contenidos digitales relacionados con la poesıaespanola vertida en LSE, modernizando la incipiente industria cultural de este sector,mejorando su calidad y su acceso, y fomentando ası el conocimiento de este patrimoniocultural por parte de la comunidad sorda (espanola e internacional) y a su vez, por partede la comunidad oyente, el conocimiento de la propia virtualidad poetica de esta lenguade signos para la comprension general de la poesıa”[Cervantesvirtual.com, 2018].

Esto hara que los usuarios se focalicen en lo que de verdad es relevante, a sus necesi-dades educativas y a un aprendizaje por interes, lo que llevara a mejoras medibles en elaprendizaje.

Por otro lado se pretende ayudar aquellas personas que se dedican a la gestion y crea-cion de recursos para el aprendizaje. Se debe facilitar la migracion del contenido paraası poder reutilizarlo y compartirlo. Ademas los materiales hay que hacerlos adaptadospara todos, para ello se busca alertar de los problemas existentes que puedan impactaren el desarrollo del usuario y utilizarlo para mejorar la calidad y asegurarse que cubrenlas necesidades previstas. Para poder llevarlo a cabo se necesita generar un conjunto deanalıticas de aprendizaje que permiten tomar acciones proactivas encaminadas a mejorarlos procesos de ensenanza y a mitigar los riesgos detectados.

Finalmente, esto no solo beneficiara a los usuarios sino a todas las plataformas. Estasreduciran su tasa de abandono, ya que permitiran desarrollar una experiencia de apren-dizaje individualizada orientada a ofrecer contenidos y experiencias relevantes, ademasde despertar el interes por la formacion gracias a la User Experience (UX).

La gran importancia de migrar e importar contenido de una manera economicamenteviable o incluso gratuita es poder reutilizar los los materiales formativos ya existentessin necesidad de crear uno propio. Por otro lado les permite conocer las necesidades delos usuarios para ası mejorar estrategias y planes de formacion mediante el conjunto deanalıticas.

Con el fin de aportar un granito de arena, durante el proyecto se estudiara la situacionactual de los formatos educativos para buscar solucion a sus problemas actuales, reali-zando una aplicacion para monitorizar y analizar las interacciones del usuario. Como seha comenta anteriormente, para llevar a cabo esta tarea se han utilizado recursos de laBiblioteca Virtual Miguel de Cervantes, en particular un conjunto de vıdeos signados enLSE.

http://www.cervantesvirtual.com/portales/ver_la_poesia/


2. Modelo de negocio

Se ha realizado un estudio de viabilidad del proyecto con el objetivo de definir cadauno de los puntos clave de el sistema. Examinar a fondo todas las cuestiones y evaluar suprobabilidad de exito antes de iniciar el proyecto nos hace tener una mejor perspectivadel mismo y aumentar la probabilidad de exito al descubrir los distintos factores que,desde el principio, podrıa afectar al proyecto y perjudicar a sus resultados.

2.1. Lean Canvas

Para ello se utiliza Lean Canvas, una metodologıa muy extendida a la hora de realizarestudios de viabilidad en el ambito tecnologico ya que se centra exclusivamente en elproducto o servicio ofrecido. El Lean Canvas propuesto para el proyecto queda reflejadoen la figura 2.1.

2.1.1. Segmentos de cliente

En este primer modulo es donde se definen los diferentes grupos de personas o ins-tituciones a los que se dirige este TFG. Los clientes son el centro de cualquier modelode negocio y el segmento mas importante donde se centrara este trabajo es el cam-po educativo, en particular a instituciones que elaboren materiales educativos en vıdeoonline.

Complementariamente ayuda a mejorar el Search Engine Optimization (SEO) dondetener buen contenido se valora de forma positiva y finalmente Return On Investment(ROI) ya que es necesario un seguimiento para la correccion de errores. Ambos factoresresultan beneficiados aunque no sea el objetivo principal de este trabajo.

2.1.2. Problema

Los problemas mas importantes que se han detectado y a los que se pretende dar so-lucion con este trabajo son: el desconocimiento sobre la calidad de los contenidos onliney la falta de informacion sobre la experiencia de aprendizaje del usuario.

Cuando un usuario interacciona sobre el contenido se encuentra un vacıo, una faltade informacion sobre las acciones que ha realizado y por lo tanto sobre la experienciaque ha tenido. Esto lleva a un desconocimiento si el contenido es optimo, entendible yde buena calidad.

3

4 2.1. Lean Canvas

En este caso se va a centrar en vıdeos de LSE ya que la sordera, por sı misma, no debesuponer una limitacion para su desarrollo emocional, cognitivo, linguıstico, y relacional.Se quiere ayudar a la mejora de este tipo de contenido ya que la base de toda relacionhumana es la comunicacion y se debe ayudar no solo a personas con esta limitacion, sino a que las generaciones futuras aprendan este lenguaje.

Registrar y poder analizar los eventos o interacciones que hacen los usuarios es necesa-rio para aportar una informacion muy valiosa en la evaluacion de un material educativoy ası poder apoyar con hechos la toma de decisiones en cuanto si un material esta siendoutil o no, si necesita ser modificado, actualizado o esta teniendo exito y podemos seguirese patron para hacer mas materiales.

Alternativas

Hasta ahora, el estandar de SCORM ha sido el que ha impulsado el reusabilidad y lainteroperabilidad de los contenidos en los entornos de e-learning. Este estandar permitıaque el contenido y los resultados de una plataforma fueran conectados y validados paracualquier otra plataforma que empleara el mismo sistema. SCORM se focaliza en elcontenido y en el resultado de una actividad de evaluacion, pero el aprendizaje es muchomas. Se necesita un nuevo estandar capaz de compartir y unificar algo mas que contenido.Esta parte se vera con mas detalle en la seccion 4.

2.1.3. Propuesta de valor unica

El objetivo es crear un sistema para monitorizar y analizar las interacciones del usua-rio ante los recursos multimedia online.

Se trata por tanto de captar microcontenido de las interacciones de los usuarios paramonitorizar y analizar las mismas con los recursos multimedia en la plataforma de You-tube. Esto ayudara a obtener informacion valida y de esta manera facilitar la toma dedecisiones y mejorar los objetos de aprendizaje. La mayor importancia esta en recopilartoda la informacion posible y compartirla.

2.1.4. Solucion

Es necesario estudiar las interacciones del usuario en todo momento y capturar cadauna de las experiencias que tiene sobre el contenido para ası tener un mejor seguimientode las experiencias. Para ello, se ha desarrollado un sistema que recoge, transforma yalmacena las interacciones del usuario con los recursos educativos, en este caso centradoen los vıdeos de LSE. Donde se recogen todos los eventos que realiza el usuario sobre losdistintos vıdeos que se ofrecen. Una vez recogidos son almacenados y trasformados parael estudio de diversos parametros que ayudaran a tomar decisiones en el futuro sobre elcontenido visto por el usuario. Finalmente se puede ver el sistema de visualizacion queayude a la toma decisiones y analizar las respuestas de los usuarios de una manera massencilla. Las funcionalidades mas importantes por lo tanto son:

Modelo de negocio 5

Recoger informacion sobre la experiencia de aprendizaje de los usuarios.

Transformar los datos en informacion util par estudiar la interaccion del usuariocon el recurso online.

Definir KPIs que faciliten la medicion y evaluacion de la experiencia.

Hacer un mejor seguimiento de las experiencias de usuario mediante un sistema devisualizacion de la informacion.

2.1.5. Canales

Lo primero a tener en cuenta es que es exclusivamente online, el prototipo de sistemadesarrollado es una aplicacion accesible con un cliente web. La difusion de la aplicacionse realizara usando la web oficial de Experience API (xAPI) donde se encontrara lainformacion mas tecnica y relevante, por otro lado por medio de las distintas RRSSsobretodo Twitter, publicidad presencial ya sea en eventos, charlas, cursos o exposicionesy finalmente el boca a boca, aunque no sea de las mas importantes en este caso.

2.1.6. Estructura de costes

El mayor coste se centra en el valor del tiempo. Estudio de la tecnologıa, el tiempoque dura el desarrollo del mismo y el analisis de los resultados.

2.1.7. Metricas clave

Se generan un conjunto muy reducido de indicadores que luego ayudan a la toma dedecisiones, son los KPIs comentados en el apartado 2.1.4.

El primero de ellos es el tiempo de visualizacion de un vıdeo, si ha estado mas omenos tiempo que la duracion del mismo.

El siguiente es si ha habido cambios de velocidad en la reproduccion para saber sinecesita mas pausa o un mayor ritmo.

El volumen o el muteo del mismo ya que puede que interese mas el contenido visualque lo que se dice o bien que tenga algun defecto de audio.

Finalmente, contadores de pausa, lugar donde las hacen, a que puntos retrocedeno si completan el vıdeo son otros de los puntos importantes.

Se empezaran a ver resultados si hay una mayor interaccion con el contenido, estosignificara que se habran mejorado alguna de sus decadencias y ahora es un contenidode mayor calidad. A su vez se consiguen mejores resultados analıticos, si el usuario nopausa y retrocede para repetir alguna parte, si no se saltan trozos o si solo es necesarioverlo una vez para entenderlo indicara que el usuario ha tenido una experiencia positiva.

6 2.2. DAFO

Figura 2.1.: Analisis Lean Canvan

2.1.8. Fuentes de ingreso

Aunque inicialmente este trabajo es un prototipo y no tiene caracter economico, seidentifican dos formas de monetizar el producto final. La primera de ellas es mediantepublicidad en los recursos online y otra es el pago por el modulo de analisis y visualizacionde informes sobre la experiencia de aprendizaje del usuario.

2.1.9. Ventaja especial

Empresas de gran relevancia han apostado por esta tecnologıa en productos comoYoutube de Google o Acrobat de Adobe Systems. Ademas se cuenta con contenido dela LSE, ya que la Biblioteca Virtual Miguel de Cervantes (BVMC) Biblioteca VirtualMiguel de Cervantes cuenta con un repositorio de vıdeos signados tanto en LSE comoen Lengua de Signos Inglesa (LSI).

2.2. DAFO

Por otro lado de se ha realizado un analisis de Debilidades, Amenazas, Fortalezas yOprtunidades (DAFO), una metodologıa que permite disenar la estrategia en la que

Modelo de negocio 7

Figura 2.2.: Analisis DAFO

se basara el proyecto para afrontar su futuro a corto, medio y largo plazo. El DAFOpropuesto para el proyecto queda reflejado en la figura 2.2.

2.2.1. Debilidades

Aun esta en desarrollo y por lo tanto no hay mucha informacion sobre ello, ademas espoco conocido aun.

2.2.2. Fortalezas

Mejora la tecnologıa actual ya que esta estudia el microcontenido y gracias a esto pro-porciona mucha informacion. Es mas eficiente y podemos personalizarlo segun nuestrasnecesidades. Genera tanta informacion que abre un abanico sobre el mundo de los datospara poder compartirlo de una manera sencilla.

2.2.3. Amenazas

La primera de todas es la seguridad ya que se genera muchısima informacion y degran utilidad, la segunda la competencia ya que es posible que nazcan nuevas formas

8 2.3. Analisis de los riesgos

u otros que utilicen la misma tecnologıa y finalmente la idea de que solo sirve parasistemas de aprendizaje, ya que cualquier plataforma que exponga contenido deberıatenerlo optimizado y de una calidad alta para que los usuarios tengan la experiencia quebuscan en todo momento.

2.2.4. Oportunidades

La base del proyecto es saber mas sobre las interacciones del usuario y ası poderrevolucionar la experiencia de aprendizaje. De esta manera descubrirıamos los procesosde aprendizaje para cada caso concreto haciendolo a medida para cada uno. Esto nosconducira a una mejor formacion del usuario. Finalmente gracias a la posibilidad decompartir la informacion la posibilidad de extension en distintas areas y sistemas.

2.3. Analisis de los riesgos

TECNOLOGIA

Posible riesgo Probabilidad Efectos Estrategias

xAPI Baja Catastrofico

1. Prevencion: Hacer estudio ex-haustivo y testeo.

2. Minimizacion: Hacer una pla-nificacion a corto plazo.

3. Plan de contingencia: pediropinion a una persona exter-na.

Angular Muy baja Serio

MariaDB Baja Serio

Tabla 2.1.: Riesgos sobre la tecnologıa.

PERSONAS

Posible riesgo Probabilidad Efectos

Errores en programacion Moderada Tolerable

Tiempo limitado Moderada Serio

Falta de conocimientos Moderada Serio

Enfermedad Baja Tolerable

Tabla 2.2.: Riesgos sobre el personal.

ORGANIZACIONAL


Planificacion inadecuada Moderada Serio

Deficiente revision de iteracion Muy baja Serio

Tabla 2.3.: Riesgos sobre la organizacion.

HERRAMIENTAS


Trello: version gratuita incompleta Alta Tolerable

Git: falta de formacion Moderada Tolerable

Tabla 2.4.: Riesgos sobre las herramientas.

REQUERIMIENTOS

Posible riesgo Probabilidad Efectos Estrategias

BBDD: modifica-ciones en datos otablas

Moderada Catastrofico

1. Prevencion: Testeo y corregirerrores

2. Minimizacion: Hacerla lo me-nos rıgida posible.

3. Plan de contingencia: Se co-menta al cliente, se vuelve a re-disenar el modelo.

IEEE: cambios deconcepto o funcio-nalidad

Baja Serio

Tabla 2.5.: Riesgos sobre los requerimientos.

ESTIMACION


Descubrimiento de nuevas tareas Moderada Serio

Mala organizacion de precedencias Baja Serio

Gestion pobre de holgura Baja Serio

Tabla 2.6.: Riesgos sobre la estimacion.

3. Objetivos

3.1. Generales

El objetivo del proyecto es crear una aplicacion para monitorizar y analizar las inter-acciones del usuario ante los recursos multimedia en la plataforma de Youtube.

3.2. Especıficos

Conocer la situacion actual de los formatos educativos.

Estudio de modelo de negocio para el aprendizaje.

Estudio e implementacion sobre el formato educativo xAPI.

Creacion de un repositorio de objetos xAPI.

Usar la aplicacion en un caso real de la Biblioteca Virtual Miguel de Cervantespara monitorizar las interacciones, en particular sobre los vıdeos en LSE.

Creacion de una interfaz de visualizacion del contenido.

Creacion de una interfaz de cuadro de mandos y analisis del contenido.

11

4. Estudio del problema

Desde la llegada de Internet, las posibilidades de acceso a la formacion han ido in-crementando a la vez que se ofrece ambientes de aprendizaje mas complejos y elaborados.

E-Learning es una de las palabras que mas utilizamos para facilitar la formacion depersonas a traves de internet. Aun ası, se sabe que hay distintas acepciones y definicionespara este concepto, y sobretodo distintas maneras de ponerlo en practica.

Actualmente se tiende a pensar en e-learning como aprendizaje online a traves deinternet y si algo ha posibilitado la expansion de este concepto eso ha sido el desarrollode SCORM. Este sigue siendo a dıa de hoy el formato rey del e-learning y su flexibilidadle permitira seguir siendolo en el futuro por un tiempo.

La historia de este formato se remonta a 1999, ano en el que fue creado por los laborato-rios Advanced Distributed Learning (ADL) del Departamento de Defensa de los EstadosUnidos [Adlnet.gov, 2018]. Este centro aglutino, compilo y mejoro algunas iniciativasya existentes como Aviation Industry Computer-Based Training Committee (AICC)[eLearning Learning, 2018], Institute of Electrical and Electronics Engineers (IEEE)[IEEE, 2018] e IP Multimedia Subsystem (IMS) [IMS Global Learning Consortium, 2018]para crear este nuevo modelo de referencia, que facilita el empaquetado de contenidos apersonas sin necesidad de grandes conocimientos tecnicos.

Desde entonces, SCORM ha contado con diferentes versiones, la 1.0, lanzada en el ano2000, la cual contenıa los elementos basicos que se convertirıan en la base del mismo. Enparticular, se especifica como el contenido debe ser envasado (envasado contenido), comoel contenido debe comunicarse con un LMS (tiempo de ejecucion) y como el contenidodebe ser descrito (metadatos). Pronto se mejoro con la 1.1, fue la primera version realy aplicable. En octubre de 2001 se presento la version 1.2,fue entonces cuando SCORMalcanzo el exito, una de las mas extendidas incluso en la actualidad por todo tipo deLearning Management System (LMS) y herramientas de generacion de contenidos.

Por ultimo, en 2004 se puso a disposicion de los usuarios la actualizacion 1.3. Con ellase corrigieron algunas deficiencias anteriores, especialmente en cuanto a secuenciacion ynavegacion en los contenidos.

Pero ya han pasado 21 anos de su nacimiento y las facilidades que nos brinda la tec-nologıa hoy en dıa ya no se trata solamente de iniciar sesion en el LMS y comenzar lacapacitacion. Hoy en dıa, se aprende del microcontenido localizado en varios lugares.

13

14 4.1. Evolucion del proyecto Tin Can

Se estan desarrollando formatos como Tin Can API enfocados a mejorar aspectosconcretos, como por ejemplo, SCORM en un examen tipo test solo facilita el resultadofinal mientras que con Experience API puede obtener el tiempo trascurrido en cadapregunta o si el usuario cambia de opcion en las respuestas entre otras. Por lo que capturamas informacion que su predecesor, lo cual facilita enormemente evaluar las experienciasde aprendizaje. Sera interesante comprobar en los proximos anos la evolucion de estetipo de archivos y comprobar si acaban universalizandose como lo hizo en su momentoSCORM.

4.1. Evolucion del proyecto Tin Can

Segun cuenta [xAPI, 2019] en 2008, fue evidente que los estandares de interoperabi-lidad mas antiguos como SCORM eran demasiado limitantes. La interoperabilidad deLearning Education Training Systems Interoperability (LETSI) solicito solicito informestecnicos de partes interesadas que estaban interesadas en contribuir a SCORM 2.0, eneste caso ideas de la comunidad. El resultado fue una coleccion bastante grande de do-cumentos que han sido importantes para la industria del e-learning y que tuvieron unagran parte de importancia en la configuracion de la API de experiencia.

ADL, el organo rector de SCORM, emitio un comunicado para que alguien se pre-sentara y consolidara el estandar de aprendizaje electronico de la proxima generacion.Rustici Software [Rustici Software, 2019] recibio el premio y comenzo el trabajo. Rusti-ci Software examino los informes de LETSI SCORM 2.0 y realizo entrevistas extensascon gran parte de la industria del e-learning. A este proyecto lo llamaron Tin Can[Ben Clark, 2019]. El proyecto Tin Can significo que la industria finalmente estaba to-mando pasos reales para mejorar los estandares de aprendizaje electronico.

Antes de MLearnCon’12 [Trivantis, 2019] en San Jose, California, en junio de 2012,ADL y la comunidad de especificaciones completaron la version .9 de la Tin Can API,y ADL la anuncio a la comunidad de aprendizaje electronico. Para este punto, ya habıa15 companıas/productos que habıan adoptado la API de Tin Can. En agosto de 2012,se finalizo la version .95 de la API de Tin Can. Muchos mostraron sus implementacionesy para finales de 2012, habıa mas de companıas/productos.

La lista de empresas en implementar Tin Can continuo creciendo, a medida que lacomunidad de e-Learning anticipo el lanzamiento de la version 1.0 de Tin Can API,que tuvo lugar en abril de 2013. El nombre oficial de ADL para la API de Tin Canes Experience API, o xAPI. La version 1.0.1, se lanzo en octubre de 2013 para aclararalgunos puntos. Las versiones de parches hacen que la especificacion sea mas facil de leere implementar, pero no afecta el comportamiento requerido.

Una segunda version, la 1.0.2 se lanzo en octubre de 2014 para aclarar algunas delas tablas en la especificacion. El documento de especificacion de la version 1.0.2 sigue

Estudio del problema 15

siendo muy similar a la version 1.0.0. La tercera version del parche, version 1.0.3 estabaprevista para 2015 pero no fue hasta finales de 2016, incluye mejoras significativas en laclaridad y legibilidad de la especificacion en funcion de los comentarios, pero no incluyeningun cambio en el comportamiento requerido.

Actualmente se sigue trabajando en la proxima version, la cual le permita asentar-se definitivamente. la version actual es la 1.0.3, no hay fechas de lanzamiento para laproxima pero ya son cientos de empresas las que han apostado por esta tecnologıa.

4.2. xAPI vs SCORM

En los ultimos anos, Tin Can ha comenzado a desplazar a SCORM. En abril de 2015se lanzo la version 1.0. La sucesora de SCORM. Tambien conocida como xAPI, rapida-mente se adopto ampliamente. Al igual que SCORM, la especificacion es una ApplicationProgramming Interface (API) y define un protocolo de comunicaciones para rastrear laactividad relacionada con el aprendizaje. La diferencia clave, que se puede ver en la tabla4.1, es que xAPI es mas que una parte de la API de JavaScript (JS) que se encuentraen un LMS. Tin Can puede seguir el aprendizaje en casi cualquier contexto. Como re-sultado, el estandar se utiliza para rastrear una variedad mas amplia de escenarios delmundo real a traves de una gama mas amplia de dispositivos y herramientas.

La especificacion xAPI tambien se define mejor que la API SCORM y utiliza tecno-logıas mas nuevas para lograr sus objetivos. Eso hace que sea mas facil de usar, masaccesible para los desarrolladores y mas robusto. Si bien SCORM es adecuado para losusuarios que solo quieren ofrecer e informar sobre cursos simples en lınea, Tin Can ofreceuna serie de ventajas segun [Elucidat, 2018]:

1. Tin Can es mas confiable: como el protocolo de Tin Can se desarrollo mas recien-temente, es menos susceptible a errores.

2. Tin Can ofrece mas opciones de seguimiento: una de las principales ventajas dexAPI es la amplitud y la profundidad de las experiencias de aprendizaje que com-prende. Si bien SCORM se limita al seguimiento del aprendizaje de escritorio, TinCan se adapta mejor al panorama moderno, en el que el ’aprendizaje ocurre entodas partes’. La creciente demanda de aprendizaje movil es una de las razonespor las que Tin Can se esta volviendo cada vez mas popular.

3. Tin Can entrega datos mas ricos: Tin Can puede rastrear datos mas ricos y conmayor confiabilidad que SCORM. Un buen LMS le permitira automatizar informespara aprovechar los datos detallados de las pistas de estano. Si se elige xAPI, tam-bien se puede integrar su LMS con una tienda de registro de aprendizaje (LearningRecord Store (LRS)) para aprovechar al maximo el poder de generacion de informesde xAPI.

16 4.3. Experience API

4. Tin Can sigue evolucionando: es la mejor opcion para el futuro del contenido deaprendizaje electronico que desarrolle. Mientras que Tin Can continuara evolucio-nando, SCORM ahora esta estancado.

SCORM Experience API

Se utiliza para rastrear un estilo par-ticular de curso de e-learning carga-do en un LMS.

Se utiliza para rastrear cualquier ex-periencia de aprendizaje, muchas delas cuales ocurren fuera del LMS.

Incluye comunicacion en tiempo deejecucion, agregacion de contenido ysecuenciacion y navegacion.

Solo cubre la comunicacion. La agre-gacion de contenido es menos im-portante en el mundo conectado mo-derno; La secuenciacion y la navega-cion se dejan al contenido para ad-ministrar y no es necesario estanda-rizarlas.

Utiliza una API de JavaScript conmarcos o ventanas emergentes.

Utiliza solicitudes HTTP RESTful.

Limitado a contenido basado en Ja-vaScript.

Puede ser utilizado con cualquierlenguaje de programacion.

Definicion estricta de los datos quese comunican con lımites restrictivosde longitud.

Muy flexible con menos limitacio-nes.

Tabla 4.1.: Lista de SCORM vs Experience API [Software Advice, 2018]

4.3. Experience API

xAPI proporciona un marco de trabajo mas flexible que permite comunicarnos entre2 sistemas de cualquier tipo, no solamente el contenido de capacitacion y la LMS. Segun[Wang, 2017] utilizar un LRS con la xAPI es una manera sencilla de unir varios sistemasusando un enfoque ya estandarizado, que recopila los datos del modo en que las orga-nizaciones lo requieren. El uso de xAPI de un formato compartido para la recepcion yel envıo de datos hace que esta sea una herramienta ideal para compartir el aprendizajeentre varios sistemas.

Para ello utilizaremos xAPI (Experience API), una especificacion de aprendizaje electroni-co que permite recopilar datos sobre la amplia gama de experiencias que una personatiene dentro de las actividades de capacitacion en lınea y fuera de lınea. Actualmente laindustria ya cuenta con sistemas para realizar el seguimiento de las interacciones. Entreotros y el mas comun es SCORM nombrado anteriormente, el cual permite el empaque-tado de cursos para desplegar en un LMS y registrar quien ha comenzado, completado


o aprobado cada curso.

4.4. Estructura de las declaraciones

En la parte tecnica de xAPI [xAPI.com, 2018], se describen conceptos basicos a ana-lizar sobre las declaraciones. Se analiza mas a fondo la estructura de las declaraciones yse descubre su utilidad para capturar experiencias. En el nivel mas simple, la estructurade la declaracion xAPI se puede expresar en la forma de objeto,verbo,actor. LearningRecord Stores registra todas las afirmaciones realizadas. Un LRS puede compartir estasdeclaraciones con otros LRS y tambien puede existir solo o dentro de un LMS.

Listado 4.1: Ejemplo base en formato JSON

1 {

2 "actor": {

3 "name": "Sally Glider",

4 "mbox": "mailto:[email protected]"

5 },

6 "verb": {

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

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

9 },

10 "object ": {

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

12 "definition ": {

13 "name": { "en-US": "Solo Hang Gliding" }

14 }

15 }

16 }

Usando este ejemplo como base, se va a explorar y expandir los elementos de las decla-raciones xAPI.

4.4.1. Actor

Las personas, no las empresas, estaban mas interesadas en la propiedad a largo plazode sus experiencias y resultados. Y se entendio que el aprendizaje se esta convirtiendo,y deberıa volverse, cada vez mas centrado en la persona. Pasar de una educacion mastradicional y global a una mas personalizada y moderna donde cada detalle cuente.En xAPI, las personas no tienen que estar identificadas unicamente por un sistema o ID.Ese es un paso importante para hacer que xAPI se centre en la persona. Se puede ima-ginar una vista consolidada de su actividad en todos los sistemas con los que interactua.

Una de las suposiciones es que alguien, o un group de alguien, tiene que ser el experi-mentador. Hay que anadir el termino actor, a menudo denominado I en una declaracion

18 4.4. Estructura de las declaraciones

xAPI, o gramaticalmente, el sujeto. Hay mucha abstraccion en la creacion de sentenciasxAPI, y a primera vista, definir el yo de una afirmacion parece simple, desafortunada-mente, no es tan facil. ¿Quien soy yo? Es una pregunta bastante grande en cualquierentorno y esa pregunta no se hizo mas pequena en Tin Can. Para complicar el problema,no solo tiene que definir el yo, o tal vez el nosotros, sino que tambien tiene que decirle aotra persona que fue usted. Y para complicar aun mas las cosas, tal vez no este interesadosolo en ser yo, pero quiere traer a su amigo el (o amigos, nosotros).

Para entender la parte del actor de una declaracion, es util dar un paso atras y com-prender la distincion entre una clave o propiedad (lado izquierdo de una asignacion) yel valor (lado derecho de una asignacion) en un objeto JSON. En ultima instancia, unadeclaracion se compone de propiedades que tienen valores asignados a ellos, emphactores una de esas propiedades y, en el caso de actor, su valor debe ser un Agent o Group.Esto significa que actor es simplemente un marcador de posicion (o puntero) y no tieneuna representacion independiente y concreta. Lo que se pretende es que a pesar de quepubliques usando tu usuario en Twitter, cuando se ve toda la actividad, ves la expe-riencia mas en los terminos de ese sistema y el mismo tu que usa otra plataforma pararealizar otra accion. Debido a problemas de privacidad, cada declaracion contendra solouna representacion de usted, sin embargo, los sistemas de informes que son conscientesde estas multiples personas pueden agregarlos.

Agentes

Con esa explicacion en mente, se puede ver el ejemplo de objeto actor en el listado 4.2:

Listado 4.2: Ejemplo de Agente conocido en JSON

1 {

2 name: "Sally Glider",

3 mbox: "mailto:[email protected]"

4 objectType: "Agent"

5 }

Listado 4.3: Ejemplo de Agente anonimo en JSON

1 {


3 mbox: "f427d80dc332a166bf5f160ec15f009ce7e68c4c"


5 }

Este objeto actor tiene dos propiedades, name y mbox. Solo mbox describe de formaunica al Agent Sally (id). Puede que haya muchas personas con el nombre de Sally, pero


solo una de ellas posee [email protected] o f427d80dc332a166bf5f160ec15f009ce7e68c4c.

Mas alla del correo electronico, un agent puede ser identificado de forma unica porsu identificador unico (ID) de OpenID. Si bien el correo electronico sigue siendo unconcepto bastante aceptado universalmente y OpenID ha despegado en algunos cırculos,la especificacion tambien proporciona una variacion mas especıfica del sistema, de maneraque un agent se puede identificar al combinar un identificador unico para un sistemadeterminado, por ejemplo, Twitter.com, y su representacion unica en ese sistema, porejemplo, su cuenta de Twitter; la combinacion se conoce simplemente como una cuenta.Si bien algunos sistemas apareceran y desapareceran, y eventualmente podremos ver elfinal de las direcciones de correo electronico, el concepto de una ID unica para un sistemamas la ID unica del sistema para una entidad ( la cuenta como un concepto) debe ser losuficientemente flexible como para durar el tiempo que lo permita la especificacion.

En el listado 4.4 se puede ver otra forma de representar al Agent Sally:

Listado 4.4: Otro ejemplo actor en JSON

1 {


3 account: {

4 homePage: "http :// twitter.com",

5 name: "sallyglider434"

6 }


8 }

En este caso, se identifica al agent Sally por su cuenta de twitter con el identificadorsallyglider434. Esta flexibilidad para identificar personas es una caracterıstica importantede xAPI.

En los ejemplos anteriores tambien se incluye explıcitamente la propiedad objectTypeestablecida en Agent, esa propiedad se puede omitir siempre que un objeto debe ser unagent o un group y de manera predeterminada a un agent (como en la propiedad actor).

En la tabla 4.2 se detallan las propiedades del agent en la que se pueden identificarque:

Un agente debe ser identificado por uno de los cuatro tipos de identificadoresfuncionales inversos.

Un agente no debe incluir mas de un Identificador funcional inverso;

Un agente no debe usar identificadores funcionales inversos que tambien se usencomo un identificador de group.


Propiedad Tipo Descripcion Requisito

objectType string Agent Opcional

name string Nombre completo del Agente Opcional

IFI string Identificador unico del Agente Obligatorio

Tabla 4.2.: Lista de propiedades del Agente [ADL.net, 2018]

Grupos

Son similares a los agents porque son un tipo de objeto utilizado para representaruna entidad, pero con el potencial de una propiedad adicional que permite a un groupenumerar todos o algunos de sus constituyentes, especıficamente la propiedad member.Los groups deben proporcionar a la propiedad objectType un valor de Group. Los groupspueden ser de dos tipos: identificados y no identificados (o anonimos). En el primer caso,un group identificado tiene un identificador funcional inverso (o ID unico) tal como lohace un agent, y puede o no incluir su propiedad member. Si un group identificado incluyeuna propiedad member con una lista, no se debe asumir que es una lista exhaustiva, loque significa que una declaracion puede llamar a un subconjunto especıfico de agentsmiembros para una experiencia (tal vez los famosos, o el mas grande donantes, o losmejor vestidos, o los primeros en llegar). En este ultimo caso, un group anonimo noesta asociado con ninguna informacion de identificacion unica, por lo tanto, no tieneun identificador funcional inverso, pero debe incluir la propiedad member. Aunque laespecificacion, a partir de la 1.0.0, deja abierto que la lista de miembros en este casono tiene que ser exhaustiva, es una buena practica hacerlo ası, ya que no hay formade asociar a otros Agents con esa parte de la declaracion. Y aunque es una inclinacionnatural asociar groups no identificados con el mismo conjunto exacto de agents queel mismo group, la especificacion llama la atencion sobre el hecho de que los sistemasimplementadores no deben hacer esta suposicion. Ademas, las listas de miembros deambos tipos de groups solo deben incluir agents, por lo tanto, no es posible anidargroups.

Listado 4.5: Ejemplo de grupo en formato JSON

1 {

2 mbox: "mailto:[email protected]",

3 name: "Info at xapi.com",

4 objectType: "Group",

5 member: [

6 {

7 mbox_sha1sum: "48010

dcee68e9f9f4af7ff57569550e8b506a88d"

8 },

9 {

10 mbox_sha1sum: "

ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"

11 },


12 .

13 .

14 .

15 ]

16 }

17 {

18 objectType: "Group",

19 member: [

20 {

21 mbox_sha1sum: "90

f96ca8c3ae315f0e40df4e16772eb6d05e3937"

22 },

23 {

24 mbox_sha1sum: "

ca3ffdb44c4727137e29ebf42ee80c2afdd8d328"

25 }

26 ]

27 }

Detalles:Un grupo anonimo se utiliza para describir un grupo de personas donde no hay unidentificador listo para este grupo, en la tabla 4.3 se ven sus propiedades.


objectType string Group Obligatorio

name string Nombre del grupo Opcional

member Array Los miembros del grupo en una lista desordenada Obligatorio

Tabla 4.3.: Lista de propiedades de un grupo anonimo [ADL.net, 2018]

Un group identificado se utiliza para identificar de manera unica un group de agents.La tabla 4.4 muestra las propiedades de un grupo identificado.


objectType string Group Obligatorio

name string Nombre del grupo Opcional

member Array Los miembros del grupo en una lista desordenada Opcional

IFI string Identificador unico del grupo Obligatorio

Tabla 4.4.: Lista de propiedades de un grupo identificado [ADL.net, 2018]

Requisitos:

Un consumidor de registro de aprendizaje debe considerar que cada group anonimoes distinto, incluso si tiene un conjunto identico de miembros.

Los proveedores de registros de aprendizaje deberıan utilizar un group identifi-cado cuando deseen emitir varios estados de cuenta, agregar datos o almacenar y


recuperar documentos relacionados con un group.

Un proveedor de registro de aprendizaje puede incluir una lista completa o parcialde agents en la propiedad member de un group anonimo o identificado determinado.

Un LRS que devuelva una Declaracion puede devolver la lista de miembros delgroup en cualquier orden.

Requisitos para grupos anonimos:

Un grupo anonimo debe incluir una propiedad member que incluya agents cons-tituyentes.

Un grupo anonimo no debe contener objetos de grupo en los identificadores demember.

Requisitos para grupos identificados:

Un grupo identificado debe incluir exactamente un identificador funcional inverso.

Un grupo identificado no debe contener objetos de grupo en la propiedad member.

Un grupo identificado no debe utilizar identificadores funcionales inversos quetambien se utilicen como identificadores de agents.

Un grupo identificado puede incluir una propiedad member que incluya agentsconstituyentes.

Agente como Objeto en las declaraciones

Ahora, ya se ha visto como crear un objeto de agent/group, simplemente los colocamosen la propiedad del actor y hecho; sin embargo, hay otros lugares en una declaraciondonde tambien se puede usar un agent. La instancia mi mencionada anteriormente sepuede lograr colocando a mi agent o group (nosotros) en la propiedad objeto para formaruna declaracion similar a Sam ( agent 1) me ayudo ( agent 2). En ese caso, la declaracionusa dos agents, la propiedad del actor todavıa contiene uno, Sam en este caso, junto conel que se usa en objeto, Brian (o mi) en este caso. Los agents o groups tambien puedenincluirse en el context de una declaracion como instructor, lo que lleva a declaraciones dela forma Brian (actor) aprendio xAPI de Ben (instructor). El contexto tambien puedeincluir una propiedad de equipo pero debe ser un group.

Por ultimo, pero no menos importante, se utiliza un agent para rellenar la propiedadde autoridad de una declaracion, pero generalmente la creacion de una declaracion serealiza sin esto, dejando que la LRS lo rellene.


Fuera de las declaraciones

Dado que los agents se establecen en algunas de las partes mas valiosas de la com-posicion de una declaracion, deben poder consultarse. Se envıa una solicitud con elindicador de consulta related agents activado para encontrar las declaraciones dondeexiste un agent en una de las otras ubicaciones posibles tambien.

Los agents son lo suficientemente completos como para obtener sus propios metodos deAPI, conocidos como el perfil del agent. Los perfiles de los agents realmente garantizan supropia publicacion para el futuro, pero por ahora es suficiente decir que se puede asociardatos arbitrarios con un agent en particular en un LRS que los utiliza. Un ejemplo decaso de uso es el almacenamiento de las preferencias del usuario. Junto con el perfil delagent, los agents tambien se componen en las llamadas a la API del estado.

Observaciones

Ademas de formar parte de innumerables groups en la mayorıa de los casos, en es-tos dıas una persona probablemente tenga tambien muchos identificadores funcionalesinversos. Se tienen tres cuentas de correo electronico que se consideran separadas, unapersonal, una de negocios y otra para otras cosas. Y cada uno de ellos tiene alias tecni-camente en otros diez nombres de dominio. Cada uno de estos podrıa considerarse comoidentificadores funcionales inversos distintos, por lo que significa que existen distintasformas de identificacion, solo por correo electronico, sin mencionar que se tienen perfilespublicos (como Twitter, Github, Facebook, LinkedIn, Google+, etc.) que tienen un con-cepto de cuenta que se podrıa usar en las comunicaciones de Experience API, y son sololas publicas. El punto clave aquı es que los sistemas que trabajan con Experience APIdeben tener en cuenta la premisa de que una ”Persona”puede tener cualquier numerode identificadores unicos.

Ademas, en todos los casos de identificador funcional inverso, es difıcil o no se puedesaber si esa direccion de correo electronico o cuenta es compartida o no, por lo tanto, sibien un agent puede estar asociado de manera flexible con una persona, no se debe asumirque representa una persona soltera. Tambien esta la cuestion del tiempo y el hecho deque las direcciones de correo electronico o las cuentas pueden cambiar de manos. Enultima instancia, esa es solo una de las razones por las que existe una propiedad de’marca de tiempo’.

4.4.2. Verbo

Los verbos en xAPI son uniform resource identifier (URI), y deben emparejarse conuna cadena de visualizacion corta. Son un elemento crucial de las declaraciones ya quedescriben lo que sucedio entre el actor y el objeto de la declaracion. La especificacionxAPI (1.0.0 en el momento de esta escritura) permite que cualquier URI como un verbo.Se ha creado un espacio como un lugar para almacenar y agregar verbos, junto con unlugar para que se resuelvan los URI de sus verbos.


Hay un conjunto inicial de verbos publicados por ADL, que se pueden ver en el RegistroxAPI. Ciertamente es una buena idea al menos considerar estos verbos antes de crearunos propios. Esa lista incluye experienced, interacted, attempted, completed, passed, fai-led, answered, imported, created, shared y voided. En el listado 4.6 se muestra un ejemplode verbo basico.

Listado 4.6: Ejemplo de verbo en JSON

1 {


3 "display ": {

4 "en -US": "experienced"

5 }

6 }

Detalles: Los verbos aparecen en Declaraciones como Objetos que consisten en unURI y un conjunto de nombres de visualizacion correspondientes a multiples idiomas odialectos que proporcionan significados legibles por humanos del Verbo. En la tabla 4.5se ven sus propiedades.


id URI Corresponde a una definicion verbal. Cada defi-nicion de Verbo corresponde al significado de unVerbo, no a la palabra.

Obligatorio

display Language Map La representacion legible por humanos del Ver-bo en uno o mas idiomas. Esto no tiene ningunimpacto en el significado de la Declaracion, perosirve para dar una visualizacion legible.

Recomendado

Tabla 4.5.: Lista de propiedades del Verbo [ADL.net, 2018]

Requisitos de identificacion de verbos:

Un sistema que lea una Declaracion debe usar el Internationalized Resource Iden-tifier (IRI) del verbo para inferir significado.

El IRI contenido en un ID debe contener una parte legible por el hombre quedebe proporcionar un significado suficiente para que una persona que revisa la de-claracion sin procesar desambigua el Verbo de otros Verbos similares (en sintaxis).

Un solo verbo IRI NO debe usarse para referirse a multiples significados.

Requisitos del proveedor de registros de aprendizaje de visualizacion verbal:

La propiedad display debe ser utilizada por todas las declaraciones.

La propiedad display debe usarse para ilustrar el significado que ya esta determi-nado por el IRI Verbo.


Requisitos de LRS para visualizacion de verbos:

Cuando se le solicitan declaraciones con un formato exacto, el LRS debe devolver lapropiedad display exactamente como se incluye (u omite) dentro de la declaracion.

Cuando se consultan las declaraciones con un formato de ID, el LRS no debeincluir la propiedad display.

Cuando se le solicitan declaraciones con un formato canonico, el LRS debe devolveruna visualizacion canonica para ese verbo.

El LRS puede determinar su visualizacion canonica basada en la propiedad displaydel Verbo incluida en las Declaraciones que recibe, la propiedad name incluida enlos metadatos.

4.4.3. Objeto

Una vez vista la estructura de la declaracion central, se considera el campo ’objeto’.Normalmente, el objeto sera una actividad xAPI, aunque podrıa ser otro actor, y tambienesta el caso de anular otra declaracion. Por ahora, nos centraremos en las actividadescomo objetos.

Mientras que los actores en xAPI generalmente estan relacionados con personas exis-tentes, y los verbos tienden a tener una definicion clara y precisa, es mas probable quelas actividades sean definidas y proporcionadas por los informes de los sistemas. Todaslas actividades deben estar definidas de forma unica por un URI y, opcionalmente, pue-den incluir informacion descriptiva. Se puede observar echando otro vistazo al objeto denuestra declaracion de ejemplo 4.7:

Listado 4.7: Ejemplo de objeto en JSON

1 {


3 "definition ": {


5 }

6 }

Esta es una actividad identificada unicamente por su campo id. Es un principio im-portante de xAPI que nunca se hace referencia a dos actividades con la misma ID.Por definicion, un ID corresponde unicamente con la actividad logica que identifica. Esposible que la definicion logica de una actividad se confunda si los identificadores seeligen mal, pero sigue siendo una actividad logica. Por esta razon, los creadores de IDde actividad deben tener cuidado de solo crear ID de actividad utilizando los dominiosque controlan, o se les ha dado una ruta dentro de ese dominio para controlar, y debenestablecer un esquema para garantizar la singularidad dentro de ese dominio. A menos


que tambien esten haciendo declaraciones que nunca pretenden transmitir un significa-do real a nadie, eso no se debe de hacer, ya que una de las bases es compartir y globalizar.

La definicion de un objeto de actividad se puede refinar con el tiempo, aunque nuncadeberıa cambiarse lo suficiente como para describir lo que deberıa haber sido alguna otraactividad nueva. Los campos descriptivos en la definicion de actividad ofrecen una formapara que xAPI respalde de forma nativa la internacionalizacion. El listado 4.8 muestracomo quedarıa el objeto de ejemplo despues de agregar mas informacion como el type,description y extensions.

1 {2 ” id ” : ” http :// example . com/ a c t i v i t i e s / so lo−hang−g l i d i n g ” ,3 ” d e f i n i t i o n ” : {4 ” type ” : ” http :// ad lnet . gov/ expapi / a c t i v i t i e s / course ” ,5 ”name ” : {6 ”en−US” : ” Solo Hang Gl id ing ” ,7 ” es ” : ” Solo Ala Delta ”8 } ,9 ” d e s c r i p t i o n ” : {

10 ”en−US” : ”The ’ Solo Hang Gliding ’ course provided by TheHang Glider ’ s Club ” ,

11 ” es ” : ”El curso de ’ Solo Ala Delta ’ s iempre por e l Club dePlaneadores Hang”

12 } ,13 ” ex t en s i on s ” : {14 ” http :// example . com/ g l ide rC lub Id ” : ” course −435”15 }16 }17 }

Listado 4.8: Ejemplo de objeto agregando type description y extensions en JSON

Aquı se ha agregado un campo de type, que indica que la actividad es un curso sobreel ala delta en solitario. Tambien hemos agregado un campo de description, que, como seesperaba, contiene una breve descripcion del curso. En el caso de name y description, seha agregado la version en espanol. De esta manera, las herramientas de informes u otrascapas de visualizacion podrıan cambiar automaticamente la salida del idioma segun laspreferencias de un usuario.Tambien se ha agregado al campo extensions, donde se pueden anadir pares de valor/cla-ve arbitrarios URI que son personalizados para una aplicacion particular. En la seccion4.4.7 se comenta con mas detalle las extensiones.

Detalles y propiedades en la tabla 4.6:Requisitos de identificacion de la actividad:

Una identificacion de actividad debe ser unica.

Un identificador de actividad debe siempre hacer referencia a la misma actividad.



name Language Map El nombre legible/visual de la Actividad. Recomendado

description Language Map Una descripcion de la actividad. Recomendado

type IRI El tipo de actividad. Recomendado

moreInfo IRL Se resuelve en un documento con infor-macion legible para las personas sobre laActividad, que podrıa incluir una manerade iniciar la actividad.

Opcional

extensions Object Un mapa de otras propiedades segun seanecesario

Opcional

Tabla 4.6.: Lista de propiedades de la actividad [ADL.net, 2018]

Un identificador de actividad debe usar un dominio que el creador esta autorizadoa usar para este proposito.

Un ID de Actividad DEBE ser creado de acuerdo con un esquema que asegure quetodos los ID de Actividad dentro de ese dominio sean unicos.

Un ID de actividad PUEDE apuntar a los metadatos o el IRL para la actividad.

4.4.4. Verbos vs Actividades

A veces, la lınea entre un verbo y un objeto puede volverse borrosa. En la declaracionde ejemplo sobre Sally, hay una implicacion de que Solo Hang Gliding es una actividadunica y bien definida. Tal vez sea un curso o examen definido por la escuela de HangGliding. Pero ¿y si quisieramos decir Sally hang-glide over Mount Magazine? ¿Es HangGliding over Mount Magazine una actividad especıfica que Sally esta experimentando?¿O Sally se deslizo, con Mount Magazine como el objeto de la declaracion?

Por lo general, resolver esta ambiguedad dependera de las intenciones de informar losdatos y de la relacion de estas piezas con otras declaraciones. En un sistema que hara unseguimiento de muchas actividades en Mount Magazine, puede mejorar los datos paraaislar a Mount Magazine como un objeto. Tambien podras aislar mas facilmente todaslas experiencias de Hang Gliding de Sally en muchos objetos diferentes, si puedes filtrarel verbo Hang Gliding.

En otros casos, Hang Gliding over Mount Magazine podrıa tener sentido como unaactividad unica si ha sido definida por alguna organizacion o especificacion, y significaalgo muy especıfico en terminos de instrumentos utilizados, ruta volada, etc. En ese caso,lo que es importante es que Sally experimento Hang Gliding over Mount Magazine.

La mejor manera de obtener verbos y actividades es buscar primero si ya existen enel registro de xAPI, en caso de que no exista o no se encuentre uno que se adapte a lasnecesidades puedes consultar o directamente crearlo tu mismo.


4.4.5. Contexto

El campo context proporciona un lugar para agregar informacion contextual a unadeclaracion. Se puede agregar informacion como el instructor para una experiencia, siesta experiencia sucedio como parte de una actividad de equipo, o como una experienciaencaja en alguna actividad mas amplia. Se exploran algunos de estos elementos en nuestradeclaracion de ejemplo:

Listado 4.9: Ejemplo basico con contexto en JSON

1 {

2 "actor ": {



5 },

6 "verb": {


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

9 },

10 "object ": {


12 "definition ": {

13 "type": "http :// adlnet.gov/expapi/activities/course",

14 "name": { "en -US": "Solo Hang Gliding" }

15 }

16 },

17 "context ": {

18 "instructor ": {

19 "name": "Irene Instructor",


21 },

22 "contextActivities ":{

23 "parent ": { "id": "http :// example.com/activities/hang -

gliding -class -a" },

24 "grouping ": { "id": "http :// example.com/activities/hang -

gliding -school" }

25 }

26 }

27 }

En el ejemplo mostrado en el listado 4.9 , se ha agregado un objeto de context a ladeclaracion. Se declara que Sally tomo el curso. Solo Hang Gliding, bajo la instruccionde Irene, como parte de Hang Gliding Clase A, dentro del contexto de Hang GlidingSchool. Menos mal, ahora es un bocado, pero hemos agregado informacion util aquı.Estas partes del contexto son especialmente utiles en la forma en que se pueden agruparlas declaraciones al informar. La API de consulta nativa en xAPI nos permite regresary solicitar todas las declaraciones hechas bajo las instrucciones de Irene, o ver todas lasdeclaraciones hechas por los participantes de la Clase A de Hang Gliding, o incluso todas


las declaraciones hechas dentro de la Escuela de Hang Gliding. En una herramienta deinformes mas sofisticada, estos elementos podrıan ayudarnos a lograr una agrupacionmuy logica de los datos.Aunque no se muestran aquı, los objetos de contexto tambien tienen un campo de exten-sions, lo que permite adjuntar datos arbitrarios como contexto para la declaracion. Estosdatos se pueden usar en herramientas de informes especializadas cuando se recuperanlas declaraciones. Se hablara mas sobre las extensiones en otro apartado. La tabla ??describe las distintas clave/valor del apartado context.


registration UUID El registro con el que esta asociada la De-claracion.

Opcional

instructor Agent Instructor con el que se relaciona la De-claracion, si no esta incluido como Actorde la Declaracion.

Opcional

team Group Equipo al que se relaciona esta Declara-cion, si no esta incluido como Actor de laDeclaracion.

Opcional

contextActivities contextActivities Object Un mapa de los tipos de contexto de acti-vidad de aprendizaje con los que se rela-ciona esta Declaracion. Los tipos de con-texto validos son: padre, ’grouping’, ’cate-gory’ y ’other’.

Opcional

revision String Revision de la actividad de aprendizajeasociada a esta Declaracion. El formato esgratuito.

Opcional

platform String Plataforma utilizada en la experiencia deesta actividad de aprendizaje.

Opcional

language String Codigo que representa el idioma en el quese produjo la experiencia que se registra enesta Declaracion (principalmente), si co-rresponde y se conoce.

Opcional

statement Statement Reference Otra declaracion que se considerara comocontexto para esta declaracion.

Opcional

extensions Object Un mapa de cualquier otro contexto es-pecıfico de dominio relevante para estaDeclaracion.

Opcional

Tabla 4.7.: Lista de propiedades de contexto [ADL.net, 2018]

Requerimientos:

La propiedad revision debe usarse solo si el Objeto de la Declaracion es unaActividad.


La propiedad platform debe usarse solo si el Objeto de la Declaracion es unaActividad.

La propiedad language no debe usarse si no es aplicable o desconocida.

La propiedad revision debe usarse para rastrear arreglos de problemas menores(como un error de ortografıa).

La propiedad de revision no debe usarse si hay un cambio importante en losobjetivos de aprendizaje, la pedagogıa o los activos de una actividad. (Utilice unnuevo ID de actividad en su lugar).

4.4.6. Resultado

Una declaracion tambien puede terminar en algun resultado medido. Por ejemplo, sies un curso o una evaluacion, podrıamos afirmar que Sally completo Solo Hang Glidingcon una calificacion aprobatoria del 95 % , o Sally completo Solo Hang Gliding con unapuntuacion fallida de 2 de 10, o incluso Sally completo Solo Hang Gliding en 2 horas.Se agrega un resultado a la declaracion de ejemplo:

Listado 4.10: Ejemplo de resultado en JSON

1 {

2 "actor": {



5 },

6 "verb": {

7 "id": "http :// adlnet.gov/expapi/verbs/completed",

8 "display ": {"en -US": "completed "}

9 },

10 "object ": {

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

",

12 "definition ": {


14 }

15 },

16 "result ": {

17 "completion ": true ,

18 "success ": true ,

19 "score": {

20 "scaled ": .95

21 }

22 }

23 }

Como se observa en 4.10 se ha declarado que Sally completo Solo Hang Gliding conun puntaje de aprobacion del 95 %. El campo de completion quiere dice que Sally ha


terminado, y el campo de success nos dice que ella paso. El campo ”puntuacion”nos dala cifra del 95 %. En el caso de scaled, el valor es en realidad un objeto de puntaje, ypodrıa expresarse en terminos de mınimo, maximo y valor bruto. Esto significa que lapuntuacion podrıa ser 2 de 6, utilizando un mınimo de 0, un maximo de 6 y un valorbruto de 2.

Tambien se puede registrar una duracion en el resultado, que nos dice cuanto tiempoduro realmente la actividad que llevo al resultado. Y en el caso de una declaracion queregistra una interaccion entre el actor y el objeto, el resultado puede tener la respuesta delactor. De esa manera podrıamos decir Sally respondio pregunta A con la respuesta opcionB en 8 segundos, y fue correcta. Los detalles sobre las actividades de interaccion y susrespuestas se pueden encontrar en la especificacion completa de xAPI. Aquı nuevamente,xAPI proporciona un campo de extensions, esta vez en el objeto de resultado, parapermitir que las aplicaciones definan sus propios resultados personalizados. Se ven laspropiedades y sus detalles en la tabla 4.8.


registration UUID El registro con el que esta asociada la Declara-cion.

Opcional

score Object La puntuacion del Agente en relacion con el exi-to o la calidad de la experiencia.

Opcional

success Boolean Indica si el intento en la Actividad tuvo exito ono.

Opcional

completion Boolean Indica si la actividad se completo o no. Opcional

response String Una respuesta formateada apropiadamente parala Actividad dada.

Opcional

duration Duration Periodo de tiempo durante el cual ocurrio la De-claracion.

Opcional

extensions Object Un mapa de otras propiedades segun sea nece-sario.

Opcional

Tabla 4.8.: Lista de propiedades de resultado [ADL.net, 2018]

4.4.7. Extensiones

A lo largo de este recorrido por las declaraciones, e han visto varios contextos parael campo extensions. Las extensiones estan disponibles como parte de las definicionesde actividad, como seccion del contexto de la declaracion o como parte del resultadode alguna declaracion. En cada caso, tienen la intencion de proporcionar una maneranatural de extender esos elementos para algun uso especializado. El contenido de estasextensiones puede ser algo valioso para una sola aplicacion, o puede ser una convencionutilizada por toda una comunidad de practica.

Dado que los campos de extensions pueden contener datos arbitrarios, desbloqueanuna gran flexibilidad en lo que puede expresar en una declaracion. Pero, esta libertad de


expresion nos lleva a la responsabilidad de darle un buen uso. Usar extensiones respon-sablemente significa algunas cosas.

Primero, aunque se puede usar extensiones para empaquetar una gran cantidad dedatos especıficos de la aplicacion, aunque no siempre significa que se deba hacer. Unadeclaracion no deberıa estar totalmente definida por sus extensiones y, de lo contrario,no tendrıa sentido. Las declaraciones de xAPI deben capturar experiencias entre acto-res y objetos, y siempre deben esforzarse por asignar la mayor cantidad de informacionposible a los elementos incorporados, a fin de aprovechar la interoperabilidad entre lasherramientas conformes con xAPI.

Segundo, las extensiones deben relacionarse logicamente con la parte de la decla-racion donde estan presentes. Las extensiones en el contexto de la declaracion debenproporcionar un contexto a la experiencia central, mientras que las del resultado debenproporcionar elementos relacionados con algun resultado. Para las actividades, debenproporcionar informacion adicional que ayude a definir una actividad dentro de algunaaplicacion o comunidad personalizada.

Finalmente, la clave en pares clave/valor de extension debe ser un URI, al igual queun verbo o ID de actividad. Un verbo o ID de actividad, se define como unico, es decir,cuando se usa una clave de extension, se afirma que tiene el mismo significado que cuandoalguien mas usa esa clave.

Con todo esto en mente, se anaden algunas extensiones a nuestra declaracion de ejem-plo mostrada en el listado 4.11.

Listado 4.11: Ejemplo con extensiones en JSON

1 {

2 "actor ": {

3 "name": "Sally",


5 },

6 "verb": {


8 "display ": { "en-US": "completed" }

9 },

10 "object ": {


12 "definition ": {

13 "type": "http :// adlnet.gov/expapi/activities/assessment

",

14 "name": { "en -US": "Solo Hang Gliding" },

15 "extensions ": {

16 "http :// example.com/gliderClubId ": "test -435"

17 }

18 }

19 },

20 "result ": {




23 "extensions ": {

24 "http :// example.com/flight/averagePitch ": 0.05

25 }

26 },

27 "context ": {

28 "extensions ": {

29 "http :// example.com/weatherConditions ": "rainy"

30 }

31 }

32 }

En este caso, se ha agregado informacion para definir la evaluacion Solo Hang Glidingen la comunidad del Hang Glider Club usando el campo gliderClubId. Hemos notadouna pieza importante de contexto sobre esta experiencia en la forma del campo weat-herConditions. Y, finalmente, hemos incluido una metrica personalizada en el resultadode la declaracion utilizando el campo averagePitch. Incluso sin estos datos adicionales,la declaracion principal sigue siendo significativa: Sally aprobo Solo Hang Gliding. Lainformacion extra solo permite mas significado en entornos especializados.

Hay una lista de extensiones que se puede encontrar en xAPI. Como en todos los casosse puede solicitar que se agreguen nuevas extensiones para seguir creciendo y llegando amas sitios.

4.4.8. Otros campos

Hasta este punto se han visto los elementos principales de los que se compone unadeclaracion xAPI. Ahora se van a ver algunas otras declaraciones pequenas pero impor-tantes.

Los campos timestamp y stored son elementos crıticos de las declaraciones. Los pri-meros registros cuando se produjo la experiencia, mientras que los segundos registroscuando la experiencia se agrego al LRS de xAPI donde se almaceno esta declaracion.Por lo tanto, el campo stored siempre es establecido por el LRS, mientras que el campotimestamp puede y debe ser establecido por el sistema que origina la declaracion.

El campo authority captura informacion sobre quien o que ha hecho esta declaracion.El valor para este campo es un actor, y podrıa representar a una persona como Sally oIrene, o una cosa como The Glider Field Application. Saber quien hizo la declaracion esinformacion crucial cuando se considera la validez de la declaracion, y tambien es utilcomo forma de pista de auditorıa. Mucho mas se dira con respecto a la autorizacion,autenticacion en otros puntos.

Finalmente, el campo voided en una declaracion dice si esta declaracion ya no es in-formacion valida. Para respaldar la naturaleza distribuida de xAPI, las declaraciones


se consideran logicamente inmutables. Es decir, una vez que una declaracion se ha al-macenado en un LRS, no hay manera de alterar o cambiar esa declaracion. Pero esrestrictivo exigir que todas las declaraciones sean validas durante todo el tiempo unavez realizadas. Por lo tanto, para admitir su invalidacion, como errores u otros, xAPIproporciona un mecanismo para anular algunas declaraciones anteriores utilizando unanueva declaracion. Los detalles sobre las declaraciones de anulacion se pueden encontraren la especificacion xAPI.

Con esto concluye el recorrido por las declaraciones xAPI. Se acaba con informacion dela declaracion de ejemplo, que antes de esto podrıa haber parecido bastante atemorizante,pero ahora deberıa ser discernible:

Listado 4.12: JSON ejemplo completo xAPI

1 {

2 "actor": {



5 },

6 "verb": {


8 "display ": { "en -US": "completed" }

9 },

10 "object ": {

11 "id": "http :// example.com/activities/hang -gliding -test

",

12 "definition ": {

13 "type": "http :// adlnet.gov/expapi/activities/

assessment",

14 "name": { "en-US": "Hang Gliding Test" },

15 "description ": {

16 "en-US": "The Solo Hang Gliding test , consisting

of a timed flight from the peak of Mount

Magazine"

17 },

18 "extensions ": {

19 "http :// example.com/gliderClubId ": "test -435"

20 }

21 }

22 },

23 "result ": {



26 "score": {

27 "scaled ": 0.95

28 },

29 "extensions ": {

30 "http :// example.com/flight/averagePitch ": 0.05


31 }

32 },

33 "context ": {

34 "instructor ": {



37 },

38 "contextActivities ":{

39 "parent ": { "id": "http :// example.com/activities/

hang -gliding -class -a" }

40 "grouping ": { "id": "http :// example.com/activities/

hang -gliding -school" }

41 },

42 "extensions ": {

43 "http :// example.com/weatherConditions ": "rainy"

44 }

45 },

46 "timestamp ": "2012 -07 -05 T18 :30:32.360Z",

47 "stored ": "2012 -07 -05 T18 :30:33.540Z",

48 "authority ": {



51 }

52 }

4.5. Learning Record Store

El LRS [Vazquez et al., 2018], se define en la especificacion xAPI, como un servidor,es decir, un sistema capaz de recibir y procesar solicitudes web, que es responsable derecibir, almacenar y proporcionar acceso a los registros de aprendizaje. Por otro lado,es disenado para permitir a los sistemas almacenar y recuperar sentencias, almacenar elestado y almacenar otros metadatos xAPI de otros sistemas. Hay que tener en cuenta lafuncion mas basica de un LRS es almacenar y poner a disposicion de los administradoreslas declaraciones de los administradores del sistema.

El LRS es el corazon de cualquier ecosistema xAPI, que recibe, almacena y devuelvedeclaraciones xAPI. Se necesita un LRS para hacer cualquier cosa con xAPI. Cualquierotra herramienta que envıe o recupere datos de la actividad de aprendizaje interactuaracon el LRS como el almacen central.

El proposito del LRS es recopilar datos de una variedad de experiencias. Permite elseguimiento de una amplia variedad de experiencias de aprendizaje, que pueden incluirla captura de actividades del mundo real, acciones completadas en aplicaciones movileso incluso el desempeno laboral. Los datos de estas experiencias se almacenan en el LRSy se pueden compartir con otros sistemas que ofrecen informes avanzados o que admiten

36 4.5. Learning Record Store

experiencias de aprendizaje adaptativo.

Se ha expandido mas alla del simple almacenamiento de datos xAPI y ahora incluyenuna funcionalidad que ayuda a los usuarios a utilizar los datos almacenados. Una gamade capacidades que pueden incluir paneles de informes, analisis de aprendizaje, motoresde recomendacion entre otros.

5. Metodologıa

Para abordar un proyecto es necesaria plantear una estrategia de trabajo y para ello sedebe elegir una metodologıa que favorezca la buena y efectiva realizacion de este. Dentrode las metodologıas existentes, la que mas optima para este proyecto es la metodologıaagil ya que algunas de sus ventajas es la flexibilidad y capacidad de adaptacion, debidoal feedback que se va realizando continuamente con el proyecto.

Se hacen reuniones periodicas que fomentan la comunicacion del equipo, tambien lla-madas sprints y sirven para examinar las tareas y los resultados. Estas reuniones generannuevas ideas que al llevarse a la practica conllevan proyectos mas innovadores, creativos yse asumen menos errores, puesto que con los sprints de 1 o 2 semanas, se reduce el riesgo.

Dentro de las metodologıas Agiles podemos ver algunas como Scrum, ProgramacionExtrema, Kanban, ect. Sin embargo, esto es un proyecto individual, no hay equipo detrabajo propiamente dicho. Por lo tanto no se puede emplear ninguna de las nombradasya que estan enfocadas a groups de trabajo de 2 o mas personas,pero si utilizar suscaracterısticas y adaptarlas a nuestras necesidades.

En la metodologıa que se va a realizar, la gran mayorıa de aspectos que se van a usarson de Scrum y para controlar el avance del trabajo se utilizara Kanban. De Scrum seusara sus sprints para delimitar las fases de trabajo, en este caso, cada sprint tendrauna duracion de 2 semanas. Por su puesto cada sprint es planificado antes de empezarloy se marcaran unos objetivos a cumplir con las distintas tareas a realizar. Cada uno delos sprints sera revisado por el tutor. En caso de no poder completarlo, a la hora deelaborar el siguiente se reorganizara el trabajo y se dara prioridad a las necesidades masimportantes que tengamos en ese momento. A medida que las tareas se vayan comple-tando, se revisara y evaluara continuamente por el tutor. Todo esto ayudara al proyectoa irse realizando de forma incremental.

La herramienta que se va a utilizar es Trello, un gestor de proyectos online que per-mite aclarar tus rutinas de trabajo, priorizar, generar avisos y muchas otras opcionesque haran que organizarse no sea una odisea. El tablero se distribuye en columnas olistas independientes, que puedes diferenciar segun dıas, fechas concretas o ambitos querecoge cada una de ellas. Estas listas se subdividen en entradas denominadas tarjetasque recogen el contenido o labores pendientes en tu proyecto dentro de cada una de laslistas. En la figura 5.1 se observa el panel de este proyecto.

37

38

Figura 5.1.: Trello en el proyecto

Iteracion 0 (1/10/2018-24/10/2018): En la primera parte del proyecto se estudialos principales metodos de aprendizaje online que existen en la actualidad y suevolucion a lo largo del tiempo. A raız de este estudio, se realiza un modelo de ne-gocio, los requerimientos necesarios para la creacion de un sistema, la metodologıaa utilizar y las herramientas a emplear para ello.

Iteracion 1 (25/10/2018-21/11/2018): Inicio de construccion del sistema a la vezque estudiamos la nueva tecnologıa para implementarla en ella. Creacion de unsistema cliente-servidor basico para hacer pruebas.

Iteracion 2 (22/11/2018-18/12/2018): Mejora de la Base de datos (BD), mejorade API Rest y de datos a extraer en el frontend. Inicio de realizar el estudio delproblema

Iteracion 3 (2/01/2019-29/01/2019):Diseno del sistema, correccion de errores ypruebas. Se documenta el diseno, la implementacion y los resultados. Se finalizacon la terminacion de la memoria y su revision.

Para la gestion del proyecto se utilizara un control de versiones. El sistema registra loscambios realizados sobre el proyecto a lo largo del tiempo de tal manera que es posiblerecuperar versiones especificas mas adelante. Los usuarios utilizan a diario sistemas decontrol de versiones sin ser conscientes de ello, el ejemplo mas claro es cuando editamoscualquier tipo de fichero en servicios de almacenamiento en la nube como Google Driveo Dropbox.

Dicho control de versiones se usa para acceder al registro de modificaciones sobre unfichero. Esto permite ver los comentarios asociados a cada modificacion y la personaque ha realizado dicha modificacion. Ademas existe la posibilidad de regresar al estado

Metodologıa 39

Figura 5.2.: Ejemplo de panel GitCraken

anterior de un fichero o conjunto de ficheros y se pueden crear ramas para gestionarcambios que finalmente se mezclaran con la rama principal.

La herramienta que se utiliza es GitKraken, una potente y elegante interfaz graficamultiplataforma para git desarrollada con Electron. De forma muy sencilla se puedellevar el completo seguimiento de los repositorios, ver ramas, tags, crear nuevos, todo elhistorial de nuestro trabajo, commits entre otras acciones. Esta se enlaza con GitHubpara evitar el uso de la consola ya que de forma visual y por medio de clicks se realizan deuna manera mucho mas sencilla. Finalmente la visualizacion de las ramas y el historialde commits, que generalmente en la consola se ve muy pobre,con esta herramienta setiene una visualizacion entendible y enriquecida. Podemos ver un ejemplo en la figura5.2.

6. Analisis y especificacion

6.1. Descripcion general

En las siguientes secciones se describiran todos aquellos factores que afectan al pro-ducto y a sus requisitos, sin describir los requerimientos, la descripcion de requerimientosse hace en la seccion siguiente Requisitos especıficos.

6.2. Perspectiva de producto

El sistema sera un producto disenado para trabajar en un entorno online, por loque su utilizacion sera de forma descentralizada y no dependiente de otros sistemas. Elsistema permite al usuario interactuar con el contenido, en este caso vıdeos. Se analizala experiencia que ha experimentado y ası poder sacar conclusiones para futuras mejorasde este.Para ofrecer este servicio el sistema se nutrira de xAPI, donde gracias a nuestrosindicadores podremos estudiar dicho contenido.

6.3. Funciones del producto

La aplicacion dispone de distintas funcionalidades que son accesibles desde los admi-nistradores de las plataformas.

Navegar.

Reproducir vıdeo.

Pausar vıdeo.

Crear evento pausa.

Aumentar contador pausas.

Cambiar volumen.

Crear evento volumen.

Cambiar calidad.

Crear evento calidad.

Mutear.

41

42 6.4. Restricciones

Crear evento muteo.

Detectar vıdeo completado.

Crear evento completado.

Aumentar contador completados.

Generar grafica.

6.4. Restricciones

El sistema necesita de una BD para el almacenamiento.

Los lenguajes de programacion empleados seran: HTML5, CSS3 y JS a partir deframeworks.

Uso de xAPI.

6.5. Requisitos especıficos

6.5.1. Requerimientos funcionales

Requisito RF-1

Nombre navegar

Descripcion Es la posibilidad de acceder y a los distintosvıdeos desde una galerıa.

Prioridad alta

Tabla 6.1.: Requerimiento funcional navegar

Requisito RF-2

Nombre Reproducir vıdeo

Descripcion Capacidad de ver los videos por medio de You-tube.

Prioridad muy alta

Tabla 6.2.: Requerimiento funcional reproducir vıdeo

Requisito RF-3

Nombre Pausar vıdeo

Descripcion Parar e interrumpir la reproduccion de un vıdeoen un punto en concreto.

Prioridad alta

Tabla 6.3.: Requerimiento funcional pausar vıdeo

Requisito RF-4

Nombre Crear evento pausa

Descripcion Capturar el momento en el que el usuario harealizado la pausa.

Prioridad muy alta

Tabla 6.4.: Requerimiento funcional crear evento pausa

Requisito RF-5

Nombre Aumentar contador de pausas

Descripcion Incrementar el numero de pausas que ha realiza-do el usuario durante la reproduccion del vıdeo.

Prioridad baja

Tabla 6.5.: Requerimiento funcional aumentar contador de pausas

Requisito RF-6

Nombre Cambiar volumen

Descripcion Cambiar el grado de volumen del reproductor devıdeo.

Prioridad alta

Tabla 6.6.: Requerimiento funcional cambiar volumen

Requisito RF-7

Nombre Crear evento volumen

Descripcion Capturar el momento en el que el usuario harealizado el cambio de volumen con el valor finalde este.

Prioridad media

Tabla 6.7.: Requerimiento funcional crear evento volumen

44 6.5. Requisitos especıficos

Requisito RF-8

Nombre Cambiar calidad

Descripcion Cambiar la resolucion del reproductor de vıdeo.

Prioridad alta

Tabla 6.8.: Requerimiento funcional cambiar calidad

Requisito RF-9

Nombre Crear evento calidad

Descripcion Capturar el momento en el que el usuario harealizado el cambio de resolucion con el valorfinal de este.

Prioridad media

Tabla 6.9.: Requerimiento funcional crear evento calidad

Requisito RF-10

Nombre mutear

Descripcion Poder silenciar o activar el sonido en el repro-ductor de vıdeo.

Prioridad alta

Tabla 6.10.: Requerimiento funcional mutear

Requisito RF-11

Nombre Crear evento muteo

Descripcion Capturar el momento en el que el usuario ha rea-lizado la accion de mutear con el valor booleanocorrespondiente.

Prioridad media

Tabla 6.11.: Requerimiento funcional crear evento muteo

Requisito RF-12

Nombre Detectar vıdeo completado

Descripcion Saber el momento en el que el usuario ha termi-nado de ver el vıdeo.

Prioridad muy alta

Tabla 6.12.: Requerimiento funcional detectar vıdeo completado

Analisis y especificacion 45

Requisito RF-13

Nombre Crear evento completado

Descripcion Capturar que el usuario ha terminado de ver elvıdeo.

Prioridad muy alta

Tabla 6.13.: Requerimiento funcional crear evento completado

Requisito RF-14

Nombre Aumentar contador completados

Descripcion Incrementar el numero de completados que harealizado el usuario durante la reproduccion delvıdeo.

Prioridad alta

Tabla 6.14.: Requerimiento funcional aumentar contador completados

Requisito RF-15

Nombre Generar grafica

Descripcion Con las interacciones de los usuarios actualizarla informacion y mostrarlos visuales.

Prioridad alta

Tabla 6.15.: Requerimiento funcional generar grafica

46 6.5. Requisitos especıficos

Figura 6.1.: Diagrama de casos de uso

7. Diseno

7.1. Arquitectura seleccionada

En este capıtulo se describe la arquitectura propuesta para el desarrollo de este tra-bajo. Para alcanzar los objetivos planteados en la seccion 3, se ha implementado unaarquitectura orientada a servicios en un modelo multicapa que se describira con detalleen la figura 7.1, en ella se observan las capas que componen la arquitectura planteada.Se ha conseguido una arquitectura debilmente acoplada, flexible y escalable que facilitala interaccion con diferentes sistemas.

Para la integracion de la nueva arquitectura se ha optado, tras un proceso de analisisprevio, por un sistema Rest. Entre las ventajas que proporciona este estilo de aplica-ciones se encuentran una alta flexibilidad, la escalabilidad y la portabilidad, ası comoindependencia, el protocolo facilita que los desarrollos de las diferentes partes de unproyecto se puedan dar de manera independiente.

La capa de presentacion es la interfaz de usuario encargada de la visualizacion delos datos. La siguiente es la capa de servicios que pone a disposicion de los usuarioslas funcionalidades ofrecidas en forma de web services. La capa intermedia o de negociogestiona la logica de la aplicacion estableciendo las reglas y las transformaciones de lainformacion que fluye a traves del sistema. Con ella se comunica tanto la capa de servi-cios como el cliente.

La capa de acceso a datos es la encargada de la comunicacion con la capa de datos for-mada por los diferentes fuentes de datos, en este caso una base de datos relacional. Comoes bien conocido, una de las ventajas de este tipo de arquitectura es la independencia decada una de las capas, lo que facilita la mantenibilidad y reutilizacion de componentessoftware.

7.2. Tecnologıas

En la figura 7.2 se observan las distintas tecnologıas utilizadas en el desarrollo delpresente trabajo. Cabe destacar las siguientes:

Node, un entorno en tiempo de ejecucion multiplataforma, de codigo abierto, para lacapa del servidor (pero no limitandose a ello) basado en el lenguaje de programacion

47

48 7.2. Tecnologıas

Figura 7.1.: Arquitectura orientada a servicios

JavaScript, asıncrono. Su arquitectura esta orientada a eventos y basado en el motorV8 de Google. Fue creado con el enfoque de ser util en la creacion de programas de redaltamente escalable y optimizado.

Express, sin duda el framework mas conocido de node.js, es una extension del pode-roso connect y esta inspirado en sinatra, ademas es robusto, rapido, flexible y simple.

MariaDB, es un sistema de gestion de bases de datos derivado de MySQL con licenciaGeneral Public License (GPL). MariaDB se puede usar en cualquier lugar donde antes seusaba MySQL. Como se trata de un sistema compatible, todo software que antes usaseMySQL es capaz de seguir funcionando igualmente con MariaDB. Este ha implementan-do diversas mejoras y nuevas funcionalidades como nuevos motores de almacenamientoo una nueva gestion de conexiones con la base de datos.

Diseno 49

Figura 7.2.: Tecnologıas

HTML5, es la quinta revision importante del lenguaje basico de la World Wide Web,HyperText Markup Language (HTML). es el lenguaje utilizado para la definicion decontenido de una pagina web, como texto, imagenes, videos, juegos, entre otros. Unlenguaje de marcado que usa la estructura para dar un sentido al contenido web, porejemplo define parrafos, cabeceras, tablas, imagenes y vıdeos en la pagina.

CSS3, es un lenguaje de reglas en cascada de estilo usado para describir la presentacionde las paginas web. Cascading Style Sheets (CSS) permite la separacion del contenidodel documento de la presentacion del documento (disposicion, colores, fuentes, etcetera).

JS, un lenguaje de programacion que te permite crear contenido nuevo y dinamico,controlar archivos de multimedia, crear imagenes animadas y muchas otras cosas mas.

7.3. Diagrama de clases

Para la realizacion del prototipo se ha utilizado una base de datos relacional temporal.Aunque lo deseable para este trabajo serıa almacenar la informacion extraıda de las dife-rentes interacciones del usuario en su aprendizaje, en un sistema final LRS, lo cual se haplanteado como una lınea futura de trabajo para completar este sistema. No obstante,se ha dejado implementado los objetos en formato adecuado para su insercion en un LRS.

Como se puede observar en la figura 7.5 en la parte izquierda esta la clase vıdeo, lacual esta compuesta por cuatro atributos su ID, idvideo, y tres parametros principalesque son el tamano, la calidad y la duracion. En la parte derecha tenemos la clase usuario

50 7.3. Diagrama de clases

la cual simplemente esta compuesta por un ID que sera su token unico. Ambas clasestienen relacion 1..* con la clase visualizacion. Un vıdeo puede tener muchas visualizacio-nes pero cada visualizacion corresponde obligatoriamente a un vıdeo y un usuario puedetener muchas visualizaciones pero cada visualizacion corresponde obligatoriamente a unusuario.

La clase visualizacion tiene como atributos su ID, distintos contadores como el numerode pausas, numero de veces visto y numero de cambios en la configuracion. Finalmenteel tiempo que ha permanecido viendo el vıdeo que no tiene porque ser el mismo que elde la duracion.

Figura 7.3.: Diagrama de clases

Por ultimo esta la clase evento, la cual se utiliza para registrar todas las acciones querealiza el usuario sobre la visualizacion de un vıdeo concreto. Cada evento pertenecea una visualizacion mientras que una visualizacion puede tener muchos eventos. Losatributos para esta clase son un ID, el tipo de evento que se dispara que son el resto deatributos: cambio velocidad, cambio de volumen, si se mutea el vıdeo en algun punto,cambio de calidad, cuando se activa la pausa y el play y finalmente cuando se llega al

Diseno 51

final del vıdeo. Para la mayorıa de estos atributos tambien se guarda el momento en elque sucedio por medio del porcentaje en el que ocurrio.

7.4. Mockups

Figura 7.4.: Mockup galerıa

52 7.4. Mockups

Figura 7.5.: Mockup video

8. Implementacion

Para mejor comprension de esta seccion se ha preferido describir la implementaciondividiendola en dos partes Backend y Frontend. Esto no quiere decir que se haya realizadouna y luego la otra, se ha ido implementado segun la planificacion descrita en la capıtulo5.

8.1. Backend

En la capa de datos inicialmente se ha realizado una Base de datos (BBDD) utilizandoun modelo relacional. Esta esta compuesta por solamente dos tablas Video y Visualiseen la cual solo se almacena la informacion del vıdeo como el ID y su tamano y los even-tos en las visualizaciones que se realizan sobre este. El unico contra es que al modificarsobrescribe cada vez que se realiza una accion. Lo que conlleva a no guardar un registrode los eventos, de todos modos sirve como base inicial.

En la siguiente modificacion ya se introducen usuarios, ya que es necesario tener unsujeto para cumplir con la estructura el estandar de Experience API, se hara por mediode un token para no identificar a los usuarios, siendo el caso mas sencillo. Esto sirveademas para simular la vision de distintos usuarios y hacer pruebas. Por otro lado seanade la tabla de eventos separando la visualizacion del registro de eventos para asıpoder guardar cada uno de ellos de forma individual. Ademas estarıa el servidor LRS,que en este caso no se ha conectado a uno pero se ha quedado el sistema preparado parapoder hacerlo. Para la eleccion de un LRS se consideran distintos tipos: plataformas deaprendizaje Analytics, introduce datos de aprendizaje y rendimiento de una variedadde fuentes para ser analizada y proporcionar informacion procesable. Integrables, estandisenadas para asentarse detras de otra aplicacion, como un LMS, para proporcionarfuncionalidad LRS a ese producto. Y por ultimo, pruebas y desarrollo, que proporcionaninformacion detallada de depuracion para los desarrolladores que trabajan con xAPI. Eneste caso esta pensado para plataformas de aprendizaje Analytics como finalidad, peropreparada para pruebas y desarrollo.

Finalmente encontramos todas las librerıas de JS donde encontramos una dependenciaprincipal que es xapiwrapper.js y luego cuatro dependencias opcionales pero necesariaspara poder realizar de forma correcta el envıo de un objeto xAPI. En este caso son cry-ptojs.v3.1.2.js, verbs.js, xapistatement.js y xapi-launch.js. Todas ellas son librerıas JS yse han instalado con exito [contributors proyect, 2018] .

Para realizar el servidor se ha decidido usar node y Express que han sido instaladosy configurados para su buen funcionamiento. Se han cargado los modulos necesarios y

53

54 8.1. Backend

creado una aplicacion de Express. En la capa de acceso a datos se han creado distintosmodulos donde estan los metodos de acceso a datos que hacen referencia directamentea un conjunto correspondiente de procedimientos almacenados de base de datos.La apli-cacion se inicia escuchando las peticiones por un puerto local.

Cuando se habla de la capa de negocio es toda la logica que tiene el sistema totalmenteabstraıda. En ella se han definido las distintas rutas para enlazar cualquier peticion conla capa de acceso a datos para su correcto funcionamiento. Se ha creado un sistema derutas donde llegan las peticiones y son gestionadas en los modulos creados para user,video, visualise y event.

La capa de servicios esta formada por la logica de aplicacion, que prepara datos para suenvıo a la capa de cliente y procesa solicitudes desde la capa de cliente para su envıo a lalogica de negocios del servidor. Aquı hemos realizado todos los metodos necesarios pararealizar esta comunicacion. Se han creado todas las peticiones necesarias para gestionarel sistema crear, editar, leer y eliminar. Por ejemplo podemos encontrar la creacion deun usuario o de un evento, para modificar los contadores del visualizado y la lecturapara mostrar los vıdeos o los datos a mostrar.

Para la creacion de un objeto xAPI se han instalado varias librerıas externas para subuen funcionamiento. La primera de ellas es tincan.js [Rusticisoftware.github.io, 2017]la base para la creacion de estos objetos y luego base64.js, complementaria para que sufuncionamiento sea el adecuado. Se han construido de la manera mas sencilla posibleutilizando las expresiones mas basicas y sin aglomerar una cantidad elevada de infor-macion. Solo se utilizo un usuario anonimo, el verbo correspondiente a la accion, porejemplo puede ser pausa o completa entre otros. En el objeto hace referencia al vıdeodonde se ha producido la accion. En la figura 8.1 se encuentra un ejemplo.

Conforme se va avanzando en el desarrollo del prototipo, se realizan pruebas conexpresiones mas complejas que anaden informacion como por ejemplo la hora o en ladescripcion poner el porcentaje donde ocurre. Como se observa en la figura 8.1 y 8.2 lascuales reflejan el primer ejemplo mas sencillo y el segundo mas complejo

Para realizar la configuracion se necesita conocer la URL del LRS como mınimo, aun-que la mayorıa de los casos tambien requeriran la informacion de autorizacion. Paraconfigurarlo puedes usar uno propio de una de las librerıas o crearlo de forma perso-nal, se ha decidido aprovechar el de la librerıa y realizar pequenas modificaciones. Laconfiguracion tambien buscara los parametros de consulta de URL y usara esos paresen la configuracion interna de XAPIWrapper.Se analiza para un actor, que se incluyeautomaticamente en la configuracion del contenedor.

Para usarlo hay que saber que todos los objetos son totalmente compatibles conJavaScript Object Notation (JSON), ası que cualquier cosa que espere una declara-cion xAPI puede tomar una declaracion mejorada y viceversa. Cada constructor puedetomar como argumento otra instancia del objeto o el objeto plano equivalente. Por lo

Implementacion 55

Figura 8.1.: Objeto xAPI creado

56 8.1. Backend

Figura 8.2.: Objeto xAPI con descripcion

Implementacion 57

tanto, puede convertir una instruccion xAPI simple en una mejorada llamando a la nuevadeclaracion xAPIS.

Para enviar una sola declaracion al LRS mediante una solicitud PUT. El metodocrea automaticamente la ID del extracto. Proporcionar una funcion para llamar despuesde que la solicitud de la declaracion de envıo hara que la solicitud se realice de formaasıncrona, de lo contrario, la Declaracion de envıo se bloqueara hasta que reciba larespuesta del LRS.

En este caso se ha realizado el envıo de forma ficticia ya que, como se ha comentadoen la seccion 7, la integracion con un LRS en esta aplicacion se ha planteado como unalınea futura de trabajo. No obstante, como se ha comentado en esta seccion se ha dejadoimplementado los objetos en formato adecuado para su insercion en un LRS.

8.2. Frontend

En este apartado se explica la capa de cliente, se comienza viendo como se ha anadidoun reproductor de Youtube que posteriormente permita capturar los datos necesariospara el analisis de la experiencia de aprendizaje del usuario. Para ello se ha utiliza-do YouTube API de IFrame [Google Developers, 2019]. La API del reproductor IFramepermite insertar un reproductor de vıdeo de YouTube en un sitio web y controlar elreproductor con JavaScript. Este enfoque proporciona mas flexibilidad que las API dis-ponibles anteriormente, ya que permiten que YouTube se visualice en un reproductorHTML5 en lugar de un reproductor Flash en los dispositivos moviles que no son com-patibles con Flash.

Utilizando los metodos que proporciona y rellenando los parametros necesarios setendra un reproductor funcional. No obstante hay otras manera de insertar un repro-ductor de Youtube pero esta es la unica que posteriormente servira para poder recogerdatos de los vıdeos ya que esta permite trabajar con Experience API dando acceso auna gran cantidad de informacion sobre los vıdeos.

Para la toma de datos se emplean funciones de YouTube API de IFrame. La decisioninicial fue utilizar Angular y no acogıa la API de Youtube ya que no se podıan cumpliralgunos de los requerimientos como la creacion del player o PlayerState, por lo que seinserto el reproductor de una manera alternativa a esta y se vieron grandes dificultadese impedimentos para la recogida de datos con facilidad, se podrıa decir que habıa hastaincompatibilidades. La decision final es descartar Angular e implementarlo sin el direc-tamente en Javascript.

Para la recogida de los datos se aprovecha la generacion de eventos para notificar a laaplicacion de los cambios en el reproductor insertado. Segun el tipo de evento se obtienenunos datos como se muestra en la tabla 8.1. Por ejemplo pongamos que el sistema detentaun evento de onPlayerPlaybackQualityChange, dentro de este se comprueba cual deellos ha sido, pongamos para este ejemplo el mute por la funcion isMute() y finalmente

58 8.2. Frontend

almacenamos el evento.

Nombre funcion Evento

timeShow getCurrentTime onPlayerStateChange

speed getPlaybackRate onPlayerPlaybackQualityChange

volume getVolume onPlayerPlaybackQualityChange

mute isMuted onPlayerPlaybackQualityChange

quality getPlaybackQuality onPlayerPlaybackQualityChange

play YT.PlayerState.PLAYING onPlayerStateChange

pause YT.PlayerState.PAUSED onPlayerStateChange

complete YT.PlayerState.ENDED onPlayerStateChange

percentage getProgress

Tabla 8.1.: Lista de datos extraıdos

Hay un dato que puede no ser verıdico y no puede capturarse por medio de dichoseventos, por ejemplo el tiempo de visualizado. Solo se podrıa capturar certeramente sisaliera por la navegacion de la aplicacion o si terminara el vıdeo y no se hiciera nada mascon este. En base a los datos recogidos y utilizando una herramienta gratuita para lacreacion de graficos mostramos algunos analisis que nos pueden ayudar a saber posiblesdefectos del vıdeo, problemas de entendimiento o el nivel de interes que se tiene sobredicho contenido.

9. Resultados

Gracias al estudio de los formatos educativos online se ha podido demostrar que losestandares que hasta hoy en dıa han dado grandes ventajas en interoperabilidad se hanquedado obsoletos. No obstante, se ha encontrado una alternativa, xAPI, la cual se haestudiado para poder usar en este proyecto de una manera sencilla y comprobar ası sufuncionalidad y las ventajas que aporta, tal y como se ha podido ver en el capıtulo 4.

Figura 9.1.: Extracto de la galerıa de vıdeos con los que se ha trabajado

En la figura 9.1 se puede observar la interfaz principal del sistema. Es una vista delrepositorio de vıdeos en LSE de la BVMC. Cuando un usuario entra por primera vez alsistema, se crea un usuario anonimo por medio de un token, el cual permite saber todolo que hace dicho usuario sin identificar en la reproduccion de los distintos vıdeos delrepositorio.

Cuando se accede a cada uno de los vıdeos muestra por un lado el vıdeo con el repro-ductor de Youtube y por otro lado, el analisis que se ha obtenido de las reproduccionesde los usuarios como se puede ver en la figura B.1.

Mientras el usuario interacciona con el vıdeo y gracias a la API de Youtube, se hanpodido crear distintos objetos xAPI, como se ha visto anteriormente en la figura 8.1.Por lo que se puede concluir que la creacion de dichos objetos es viable para vıdeos.

59

60

Figura 9.2.: Extracto de visualizacion de vıdeo

Gracias a la obtencion de estos datos se pueden crear analıticas donde visualmente sepuede saber que problemas tiene el vıdeo, poner solucion y ası generar una buena UX,como por ejemplo el de la figura B.1. En esta grafica en concreto se observa donde losusuarios hacen las pausas, esto en una leccion puede significar que lo visionado ante-riormente no se ha comprendido, necesitan mas tiempo para tomar notas o no les estasiendo util.

Durante el desarrollo del prototipo se planteo el uso de Angular. A la hora de po-ner el reproductor de Youtube, la API no era compatible por el uso de typescript. Seimplemento el reproductor de forma alternativa pero no daba la posibilidad de captardatos importantes. La API necesitaba usar javascript y para conseguirlo Angular tenıaque anadir plugins para poder hacerlo. Se tomo la decision de hacerlo sin Angular porla posibilidad de que aun ası no funcionara la API. Se puede concluir que Angular no seadapta a las necesidades para realizar este proyecto y necesita acoplar ciertos accesoriospara poder trabajar sin problemas.

Por ultimo, comentar que este proyecto se ha podido realizar con exito gracias aasignaturas como:

Programacion Hipermedia I y II

Analisis y especificacion de Sistemas Multimedia

Proyectos de Sistemas Multimedia

Usabilidad y Accesibilidad

Resultados 61

Gestion de contenidos Multimedia

Sistemas de Difusion Multimedia

Negocio y Multimedia

10. Conclusiones

10.1. Conclusiones

Se ha conseguido desarrollar una aplicacion para monitorizar y analizar las interac-ciones del usuario ante los recursos multimedia en la plataforma de Youtube aplicada alos vıdeos en LSE de la Biblioteca Virtual Miguel de Cervantes utilizando el estandarExperience API (xAPI). Se han comparado los distintos formatos educativos que permi-ten la interaccion con otros sistemas. Los vıdeos se pueden consultar en esta direccionhttp://www.cervantesvirtual.com/portales/ver_la_poesia/. Creandose un repo-sitorio de objetos xAPI para recoger y monitorizar las interacciones de los usuarios conlos recursos multimedia. Para ello se ha creado una interfaz de visualizacion del conte-nido ası como un cuadro de mandos y analisis del contenido.

Con lo descrito en el parrafo anterior se han cubierto los objetivos planteados para elpresente TFG.

Con la experiencia de este TFG se comprueba la eficacia de xAPI para poder recogerel comportamiento del usuario y poder realizar un analisis exhaustivo del mismo. Unaspecto a resaltar es que no es una tecnologıa facil de manejar la cual ha exigido unacurva de aprendizaje alta, lo cual puede explicar el porque no esta demasiado extendidasu uso dentro de los objetos multimedia pese a que las grandes sistemas como YouTube,Adobe PDF permitan su implementacion.

10.2. Lıneas de trabajo futuras

Para seguir avanzando y sacarle un mayor rendimiento a este estandar se debe seguirapostando por el e investigando, ya que se puede explotar mucho mas. Lo primero que sedebe hacer es crear objetos xAPI mas complejos, donde los usuarios no sean anonimosy tengan un caracter personal.

Otro paso importante serıa aplicarlo no solo a vıdeos individuales si no a un cursocompleto o a un gestor de cursos directamente.

Cargar la informacion en un LRS, lo cual facilita la interoperabilidad entre distintossistemas.

63


64 10.2. Lıneas de trabajo futuras

Finalmente seguir trabajando en obtener mas informacion sobre los recursos multi-media como por ejemplo, detectar cambios de pantalla, ademas de hacer analisis masexhaustivos de la informacion. A este estandar le falta un paso para asentarse y cadavez son mas las empresas que se estan sumando a el.

Bibliografıa

[ADL.net, 2018] ADL.net (2018). adlnet/xAPI-Spec. https://github.com/adlnet/

xAPI-Spec. Online;last accessed 5-december-2018.

[Adlnet.gov, 2018] Adlnet.gov (2018). Experience xAPI - ADL Initiative. https://

www.adlnet.gov/experience-api. Online;last accessed 19-november-2018.

[Ben Clark, 2019] Ben Clark (2019). Preparing xAPI for IEEE standardization. https://xapi.com/blog/xapi-ieee-standardization/. Online;last accessed 19-January-2019.

[Cervantesvirtual.com, 2018] Cervantesvirtual.com (2018). Ver la poesıa. http://

www.cervantesvirtual.com/portales/ver_la_poesia/. Online;last accessed 16-december-2018.

[contributors proyect, 2018] contributors proyect (2018). Wrapper to simplify communi-cation to an LRS. https://github.com/adlnet/xAPIWrapper. Online;last accessed25-January-2019.

[eLearning Learning, 2018] eLearning Learning (2018). What is AICC?http://www.elearninglearning.com/aicc/?open-article-id=5348467&

article-title=what-is-aicc-&blog-domain=growthengineering.co.uk&

blog-title=growth-engineering. Online;last accessed 20-november-2018.

[Elucidat, 2018] Elucidat (2018). Scorm Vs Tin Can (xAPI) Authoring Software —Elucidat. https://www.elucidat.com/blog/scorm-vs-tin-can-xapi/. Online;lastaccessed 22-november-2018.

[Google Developers, 2019] Google Developers (2019). YouTube API de IFrame. https://developers.google.com/youtube/iframe_api_reference?hl=es-419.Online;last accessed 3-January-2019.

[IEEE, 2018] IEEE (2018). Ieee.org. https://www.ieee.org/. Online;last accessed20-november-2018.

[IMS Global Learning Consortium, 2018] IMS Global Learning Consortium (2018). Ims-global.org. https://www.imsglobal.org/activity/accessibility. Online;last ac-cessed 20-november-2018.

[OMS Organizacion Mundial de la Salud, 2018] OMS Organizacion Mundial de la Sa-lud (2018). Sordera y perdida de la audicion. https://www.who.int/es/

65

https://github.com/adlnet/xAPI-Spec

https://github.com/adlnet/xAPI-Spec

https://www.adlnet.gov/experience-api

https://www.adlnet.gov/experience-api

https://xapi.com/blog/xapi-ieee-standardization/

https://xapi.com/blog/xapi-ieee-standardization/



https://github.com/adlnet/xAPIWrapper

http://www.elearninglearning.com/aicc/?open-article-id=5348467&article-title=what-is-aicc-&blog-domain=growthengineering.co.uk&blog-title=growth-engineering



https://www.elucidat.com/blog/scorm-vs-tin-can-xapi/

https://developers.google.com/youtube/iframe_api_reference?hl=es-419

https://www.ieee.org/

https://www.imsglobal.org/activity/accessibility

https://www.who.int/es/news-room/fact-sheets/detail/deafness-and-hearing-loss



66 Bibliografıa

news-room/fact-sheets/detail/deafness-and-hearing-loss. Online;last acces-sed 11-January-2019.

[Rustici Software, 2019] Rustici Software (2019). Rustici Software. https://

rusticisoftware.com/. Online;last accessed 19-January-2019.

[Rusticisoftware.github.io, 2017] Rusticisoftware.github.io (2017). TinCanJS by RusticiSoftware. http://rusticisoftware.github.io/TinCanJS/. Online;last accessed 14-January-2019.

[Software Advice, 2018] Software Advice (2018). SCORM vs AICC vs. Tin Can(xAPI): The Choice is Clear. https://www.softwareadvice.com/resources/

scorm-vs-aicc-vs-tin-can/. Online;last accessed 22-november-2018.

[Trivantis, 2019] Trivantis (2019). 2012 mLearnCon Conferenceand Expo Recap. https://www.trivantis.com/uncategorized/

2012-mlearncon-conference-and-expo-recap/. Online;last accessed 21-January-2019.

[Vazquez et al., 2018] Vazquez, M. M., Rodrıguez, M. C., and Nistal, M. L. (2018). Anxapi application profile to monitor self-regulated learning strategies. IEEE Access,6:42467–42481.

[Wang, 2017] Wang, H. (2017). Construction of xapi-based multimedia interaction tech-nology in architectural design teaching. iJET, 12(7):101–111.

[xAPI, 2019] xAPI (2019). Project Tin Can Evolution: History of Tin Can. https:

//xapi.com/tin-can-evolution/. Online;last accessed 19-november-2018.

[xAPI.com, 2018] xAPI.com (2018). xAPI Statements: The anatomy of an xAPI state-ment. https://xapi.com/statements-101/. Online;last accessed 28-november-2018.

[xAPI.com Homepage, 2019] xAPI.com Homepage (2019). xAPI.com. https://xapi.

com/. Online;last accessed 11-January-2019.




https://rusticisoftware.com/

https://rusticisoftware.com/

http://rusticisoftware.github.io/TinCanJS/

https://www.softwareadvice.com/resources/scorm-vs-aicc-vs-tin-can/

https://www.softwareadvice.com/resources/scorm-vs-aicc-vs-tin-can/

https://www.trivantis.com/uncategorized/2012-mlearncon-conference-and-expo-recap/

https://www.trivantis.com/uncategorized/2012-mlearncon-conference-and-expo-recap/

https://xapi.com/tin-can-evolution/

https://xapi.com/tin-can-evolution/

https://xapi.com/statements-101/

https://xapi.com/

https://xapi.com/

A. Glosario

TIC: Tecnologıas de Informacion y Comunicacion

TFG: Trabajo Fin de Grado

xAPI: Experience API

SEO: Search Engine Optimization

ROI: Return On Investment

LSE: Lengua de Signos Espanola

LSI: Lengua de Signos Inglesa

JS: JavaScrypt

SCORM: Shareable Content Object Reference Model

API: Application Programming Interface

ID: Identificador Unico

URI: uniform resource identifier

IRI: Internationalized Resource Identifier

LMS: Learning Management System

LRS: Learning Record Store

ADL: Advanced Distributed Learning

IEEE: Institute of Electrical and Electronics Engineers

AICC: Aviation Industry Computer-Based Training Committee

67

68

IMS: IP Multimedia Subsystem

DAFO: Debilidades, Amenazas, Fortalezas y Oprtunidades

LETSI: Learning Education Training Systems Interoperability

BAA: Broad Agency Announcement

UX: User Experience

BBDD: Bases de datos

BD: Base de datos

GPL: General Public License

HTML:HyperText Markup Language

CSS:Cascading Style Sheets

JSON:JavaScript Object Notation

SQL:Structured Query Language

BVMC:Biblioteca Virtual Miguel de Cervantes

B. Anexo. Esquema de base de datos

Figura B.1.: Base de datos del proyecto

69

Documents

* U D G R H Q ,Q J H Q LH U ¯D 0 X OWLP H G LD€¦ · 4, un nuevo est andar para las aplicaciones de e-learning que estructura y permite alma- cenar las interacciones de una persona