Xapi Conceptos Basicos

XAPI: Conceptos básicos
J. Pablo Caballero
Aclaración de términos
La especificación xAPI no siempre se llamó así. En los inicios

cuando ADL1 le encargó a Rustici Software el proyecto de
investigación, esta empresa bautizó al proyecto con el nombre
"proyecto TinCan2", y el resultado del proyecto que le entregaron a
ADL fue el "TinCan API". Más tarde ADL le asignó el nombre oficial
de Experience API (Experience Application Programming
Interface), o xAPI para mayor brevedad.
1 ADL significa Advanced Distributed Learning, y es un programa del gobierno de

Estados Unidos relacionado con el Departamento de Defensa. Este programa se ocupa
de impulsar diversas iniciativas relacionadas con aprendizaje y formación, entre las que
se encuentran SCORM y xAPI.
2 Utilizaron el nombre TinCan (bote de hojalata) como metáfora de la comunicación
punto a punto que se realiza con este API.
2 XAPI: Conceptos básicos
Todavía es muy frecuente encontrar referencias a TinCan API, y

hay quien sigue llamándolo así, aunque sea de manera esporádica.
No debe haber ninguna confusión: es exactamente lo mismo, no

hay dos especificaciones diferentes. Así que si alguna vez está
leyendo algo sobre xAPI o escuchando a alguien hablar sobre ello y
de repente se refieren a TinCan, no se preocupe, están hablando
de xAPI.
Lo más apropiado para evitar confusiones es usar el nombre

oficial: Experience API o xAPI.
¿Qué es xAPI?
Como su nombre indica, xAPI es el API de las experiencias. Como

eso seguramente no le dice nada, vayamos por partes.
Primero, definamos lo que es un API. API significa Application

Programming Interface, o interfaz de programación de
aplicaciones, y se refiere a una especificación detallada de un
conjunto de funciones u operaciones que un sistema software
expone, es decir, pone a disposición de otros sistemas software
para que éstos puedan utilizar dichas funciones. Esta definición
detallada también comprende los datos (y su estructura) que se
pueden utilizar al llamar a dichas funciones, así como los datos (y
su estructura) que dichas funciones devolverán al ser llamadas.
En otras palabras, un API es un conjunto de normas que rige

cómo pueden comunicarse y qué datos intercambian dos sistemas
software diferentes. Cuando un sistema software sigue las normas
XAPI: Conceptos básicos 3
de un API concreto, se dice que implementa esa API. Es importante

poner de relieve este contraste: una cosa es un API -unas normas,
al fin y al cabo- y otra cosa distinta es el software, algo específico y
real, que sigue esas normas.
Ahora bien, de la definición anterior se desprende que hay, en

cierto modo, dos partes diferentes en referencia a un API: una
parte que expone funciones, y otra parte que llama a o utiliza
dichas funciones. Efectivamente, esto es así, y en consonancia con
este hecho también se pueden distinguir dos tipos de software
respecto a un API:
● el que implementa las funciones y las expone, normalmente

llamado servidor de API, o el sistema que implementa el API
● los sistemas software que implementan las llamadas a las

funciones expuestas por un servidor de API. En este caso, se
les llama clientes (o también consumidores) del API.
Normalmente el servidor es mucho más complejo, ya que es el

que proporciona la funcionalidad, que puede ser algo sencillo o
algo muy complicado. Los clientes, en cuanto al uso del API, suelen
ser más sencillos, ya que aprovechan toda esa funcionalidad y
hacen uso de ella simplemente mediante las llamadas al servidor
de API.
Sabiendo ya lo que es un API en general, podemos decir que

xAPI se refiere a un API concreto:
xAPI es un conjunto de normas que establece cómo los

sistemas software deben comportarse para expresar,
transportar, almacenar y recuperar, datos referentes a

experiencias.
La idea clave con la que hay que quedarse es que xAPI es un

conjunto de normas, una especificación para sistemas software.
Un conjunto de métodos de comunicación, claramente definidos,
entre varios componentes software.
Aunque ciertamente xAPI permite referirse a experiencias de

cualquier tipo, a partir de ahora nos referiremos principalmente a
experiencias de aprendizaje, ya que ese es el entorno en el que
xAPI fue concebido.
Premisas, objetivos y alcance
Las premisas de las que se partió al crear la especificación xAPI

son sencillas3:
● se percibe la creciente necesidad de poder analizar

información sobre experiencias de aprendizaje y sus
resultados;
● esta información puede provenir de una amplia variedad de

fuentes, plataformas y tecnologías;
● la mejor manera de solucionar esta necesidad es desarrollar

un marco de trabajo común de amplia aceptación que defina
cómo recoger, almacenar e intercambiar esta información.
3 Estas premisas se han tomado casi literalmente de la introducción de la especificación.

Algunos de los objetivos de este marco de trabajo -la

especificación xAPI- son:
● maximizar la interoperabilidad de los servicios que crean,

recogen, almacenan y procesan información sobre
experiencias de aprendizaje;
● proporcionar una guía a quienes quieren crear aplicaciones

que se ajusten a esta especificación o la implementen;
● proporcionar criterios que permitan evaluar la conformidad

con esta especificación.
El punto de la interoperabilidad es muy importante, como

veremos más adelante, y el sistema que implementa el API (el
servidor) juega un papel central y clave en un entorno xAPI; es
vital asegurarse de que se ajusta a la especificación xAPI
totalmente.
Con el alcance de la especificación me refiero a qué es lo que

esta abarca. Es importante puntualizar esto, porque a veces se
malinterpreta la especificación y se le atribuyen a xAPI funciones o
características que realmente no tiene. Considero esto tan
relevante que un poco más adelante dedico una sección a describir
en detalle algunos de estos errores o interpretaciones erróneas
que no hacen más que crear confusión.
De manera muy general puede decirse que xAPI abarca:
● el modelo de datos (sobre experiencias), y

● los métodos de transferencia (y su formato).
xAPI define el modelo de datos para los documentos (objetos)

que maneja, siendo el más relevante y conocido el statement
(declaración o sentencia) que veremos enseguida. En líneas
generales, un modelo de datos define qué atributos puede tener un
objeto (por ejemplo, un objeto puede tener un atributo que sea
"fecha de creación", o "calificación"), y también de qué tipos
pueden ser esos atributos (por ejemplo, se puede decir que el
atributo "calificación" debe ser un número, y el atributo "nombre"
debe ser una cadena de caracteres).
El xAPI también prescribe los métodos de transferencia que se

deben usar entre servicios que se ajustan a la especificación xAPI.
Más concretamente, esto se refiere a las peticiones que pueden
hacerse y el formato que han de tener estas peticiones (entre otras
cosas, los parámetros que se pueden incluir al hacer cada petición)
y qué datos (y con qué formato) se enviarán como respuesta a las
diversas peticiones.
Adicionalmente xAPI especifica que se ha de usar JSON 4 para

representar estructuras y objetos de datos. Técnicamente xAPI se
refiere al uso de JSON para la serialización de datos. Sin entrar en
detalle, diremos que serialización se refiere a una representación
de datos en algún formato que se pueda transmitir de un sitio a
otro (y/o almacenar) fácilmente. Uno de estos formatos es JSON.
4 JSON significa JavaScript Object Notation, y es un formato ligero de intercambio de

datos de amplísima utilización.
Aunque parezca poco, el detalle técnico de esas dos áreas

principales llega a ser bastante profundo. Por eso insisto en
resaltar que aunque los detalles técnicos sean muchos, lo que
abarca la especificación es un par de cosas. No lo digo con sentido
peyorativo, ya que son un par de cosas que están teniendo una
influencia extraordinaria en el mundo de las tecnologías
educativas.
Es importante tener presente la idea del alcance de xAPI, porque

cuando alguien se pregunta si tal o cual cosa "la hace xAPI" o
"xAPI no la permite", o "se puede hacer en xAPI" etc. lo que hay
que preguntarse es ¿se trata de algo relacionado con el modelo de
datos o con los métodos de transferencia? Si la respuesta es sí, se
podrá encontrar información relevante en la especificación. Si la
respuestas es no, entonces es algo que -aunque pueda ser
relevante en el contexto técnico del que se trate- no está
controlado por xAPI.
Veamos unos ejemplos concretos para ilustrar la idea:
● ¿Una pieza de eLearning que funcione con xAPI es responsiva

(se adapta a distintos tamaños de pantalla)? Esto no tiene
nada que ver con modelos de datos ni métodos de
transferencia. Será responsiva si el desarrollador la ha hecho
así, si no, no. No tiene nada que ver con xAPI.
● ¿Cómo se sabe, en un entorno xAPI, si cierto alumno tiene

acceso a cierto contenido? xAPI no trata en absoluto sobre
contenidos ni sobre acceso de alumnos a contenidos; así que
xAPI no a resolver ese tipo de cuestión. Es un asunto
ciertamente relevante, pero separado de xAPI.
● ¿Puedo solicitar, al sitio que almacena los datos, que me

devuelva declaraciones (statements) relacionados con cierto
alumno? Esto sí que tiene que ver con los métodos de
transferencia y sus parámetros. La respuesta está en la
subsección 2.1 de la sección 3 de la especificación (y sí, sí que
puede hacerse ese tipo de solicitud).
Declaraciones (statements)
El concepto más conocido y que suele verse como el centro de

xAPI es el statement, que podríamos traducir como declaración,
aunque a veces se puntualiza utilizando los términos declaración
de actividad o declaración de estado. También a veces se le llama
sentencia. A partir de ahora utilizaré simplemente declaración o
declaraciones.
La especificación las define así:
"declaraciones son la evidencia de cualquier tipo de

experiencia o evento que se va a monitorizar con xAPI."
Esto es bastante genérico. Para concretar más podemos decir

que una declaración es un objeto de datos (o documento) que
puede contener varias propiedades o atributos, de las cuales tres
son obligatorias para poder enviar una declaración al sistema que
las almacena. Estas tres propiedades son Actor (sujeto), Verbo, y
Objeto.
Naturalmente, esta estructura Sujeto + Verbo + Objeto nos

permite expresar declaraciones de manera informal en lenguaje
natural, lo cual resulta útil y conveniente:
"Antonio accedió al curso 'contablidad101'”

"Belén vio el video 'Introducción a técnicas de venta'"
"Cristina respondió la pregunta '¿cómo buscar trabajo?' en el
foro de discusión"
Ese tipo de afirmaciones pueden considerarse evidencias de que

algo ocurrió, y en muchos casos esta evidencia la generará algún
sistema software (contenidos, juegos, simuladores) como resultado
de la interacción de un usuario (el "actor"). Nótese también que el
verbo se utiliza en tiempo pasado5.
De forma intuitiva se entiende perfectamente lo que es una

declaración y por qué proporciona tanta flexibilidad: ¡puede
expresar cualquier evento o experiencia!
A pesar de su aparente sencillez, a nivel técnico las definiciones

y los requerimientos para el objeto de datos que representa una
declaración son muchos y muy estrictos. En la siguiente tabla se
muestran todos los atributos que puede tener una declaración (los
dejamos en inglés, ya que son elementos definidos por la
especificación y nunca se traducen).
5 No es obligatorio utilizar el verbo en tiempo pasado, pero es muy habitual. Es lo que

suena mejor, ya que las declaraciones se refieren siempre a algo que ya ha ocurrido.
Propiedad ¿Obligatorio?
id Recomendado
actor Obligatorio
verb Obligatorio
object Obligatorio
result Opcional
context Opcional
timestamp Opcional
stored Fijado por el LRS
authority Opcional
Version No Recomendado
attachments Opcional
A su vez algunas de estas propiedades almacenan otros objetos

con otros atributos que se definen en detalle en la especificación.
Resultan de especial interés las propiedades context (contexto) y
result (resultado), ya que, aunque son opcionales, son las que
pueden proporcionar una riqueza y un detalle extraordinarios a
cada declaración. En efecto, una declaración que solo tenga actor,
verbo y objeto puede resultar tan poco específica que apenas tenga
utilidad.
El contexto que rodea a un evento o actividad suele ser

significativo. Siempre que se pueda debe incluirse información en
el contexto. La propiedad context puede tener a su vez varios
atributos (todos opcionales, ya que el contexto es opcional), como
instructor (útil si se trata de una actividad en la que intervenga un

profesor), language (el idioma de la actividad), etc. Pero hay una
propiedad en la que merece la pena detenerse un poco más, y es la
llamada contextActivities (actividades de contexto), que puede
incluir referencias a una o más actividades de varios tipos
predefinidos: parent (padre), grouping (agrupación), category
(categoría), y other (otros). De este modo, una declaración puede
expresar el tipo de relación que existe entre el Objeto principal (la
actividad) y otras actividades. Veamos un ejemplo para aclararlo:
Una simple declaración, como "Antonio respondió la pregunta 5"

nos da algo de información, pero esta declaración sería mucho más
rica y útil si le añadimos actividades de contexto:
Antonio respondió a la pregunta 5

del test 1 (parent)
del tema 4 (grouping)
del curso "iniciación a biología" (grouping)
tipo "biología" (category)
tipo "roedores" (category)
perteneciente a "programa piloto del currículo BioEdu"
(other)
Es evidente que esta última declaración es mucho más

informativa.
Otra de las propiedades que también merece la pena mencionar

es result (resultado), que nos permite añadir detalles referentes al
resultado de la actividad, como por ejemplo score (calificación),
success (éxito), completion (terminación), response (respuesta), y
duration (duración). Habrá muchas declaraciones en las que no sea

necesario añadir un resultado, pero hay algunos tipos de
actividades (por ejemplo, responder a una pregunta, o completar
un examen/test) que sí que deberían añadir toda la información
que sea posible sobre el resultado de la interacción.
Como seguramente podrá intuir, la cantidad de detalle que xAPI

permite almacenar es enorme. Pero por si esto no fuera suficiente,
o se necesitara almacenar algún tipo de información que no encaja
con las propiedades predefinidas, el context y el result pueden
incluir una propiedad llamada extensions que permite almacenar
objetos arbitrarios, es decir, con las propiedades que queramos. De
esta manera xAPI es extensible, y permite que cualquiera pueda
añadir los datos que necesite, aunque no estén definidos en xAPI.
Lo que no se permite es alterar las propiedades predefinidas. Por
ejemplo, a una declaración no se le puede añadir directamente una
propiedad arbitraria, porque el sistema la rechazará. Sí que se
podría añadir información arbitraria, como se ha mencionado, en
una extensión.
Los detalles técnicos de cómo se representa toda esta

información, y de cómo se identifican los actores, verbos, objetos
(actividades o experiencias), etc. quedan fuera del alcance de este
texto (eso es lo que explica la especificación xAPI), pero baste
decir que las reglas son muy estrictas, y si se intenta enviar una
declaración que no cumple las reglas, el sistema encargado de
almacenar declaraciones la rechazará.
Como se ve, el xAPI combina una extraordinaria flexibilidad con

una notable precisión en cuanto al registro de experiencias,
actividades o eventos (como quiera llamarlos). El xAPI permite

expresar y guardar detallada información de una manera
consistente aunque se trate de muy diversas experiencias.
Insistimos en que la especificación lo permite, pero eso no significa
que todos los sistemas que utilizan xAPI para registrar eventos
guarden el mismo nivel de detalle. En otras palabras, y esto es
fundamental, si queremos guardar muchos detalles sobre la
experiencia de usuario, por ejemplo con una experiencia digital
(módulo eLearning, simulador, etc.) dicha experiencia debe estar
programada para registrar todos esos detalles. Eso parece
obvio, pero a veces se confunde la capacidad que proporciona la
especificación xAPI con la funcionalidad real implementada en un
sistema. Hay quienes piensan, o esperan, que si tienen un módulo
eLearning normal y corriente hecho con una herramienta de autor
rápida, y lo "guardan como xAPI", entonces mágicamente generará
y guardará todos los detalles que tengamos en mente. Y no. No es
así en absoluto. Ciertamente las herramientas de autor van
evolucionando, y actualmente algunas sí que guardan ciertos
detalles, particularmente los resultados de preguntas, pero todavía
les queda mucho por evolucionar para guardar más detalles sin
que haya que programarlo "a mano".
Por tanto, aunque xAPI permite guardar muchas cosas, conviene

recordar esta máxima:
Todo lo que quiera guardarse...¡antes debe generarse!
Alguien puede pensar, y con razón, que guardar tanto detalle

implica más planificación y más trabajo (sobre todo si se necesita
programación a medida para poder generar todos los detalles que

se desean guardar), además de requerir más espacio de
almacenamiento (más coste). Eso es cierto. Entonces, ¿para qué
tanto detalle? pues sencillamente, porque más detalle significa más
información, y a la hora de hacer análisis de datos podremos
aplicar más filtros, agrupar declaraciones basándonos en los
detalles, etc. Es decir, cuanta más información tengamos, más
variados y profundos podrán ser los análisis que hagamos (siempre
que la información sea significativa). Tomando como referencia el
ejemplo de antes, en el que nuestro amigo Antonio respondía a la
pregunta 5, podemos ver que si hay muchas declaraciones con ese
nivel de detalle, podríamos por ejemplo agrupar muy fácilmente
todas las declaraciones relacionadas con "biología", o
pertenecientes a un tema concreto, etc., y así hacer análisis
cruzados con diversos criterios.
Muchas veces no estaremos seguros de cuánto detalle debemos

guardar. En general sería recomendable guardar más detalle en
lugar de menos, aunque eso dependerá de muchos factores. ¿Por
qué? ¿No podríamos guardarlas ahora con menos detalle y luego
añadir más detalle? Pues no, no se puede, y hay dos razones para
esta negativa. La primera, porque las declaraciones suelen
generarse en el momento que se produce el evento (normalmente
también se envían inmediatamente, aunque esto no es obligatorio,
pueden enviarse más tarde), y es en este momento cuando se tiene
toda la información pertinente a la declaración. Sería imposible (o
muy difícil) reproducir más tarde las condiciones en las que se
generó ese evento, para añadir detalle. Y la segunda razón,
totalmente inapelable, es que xAPI dicta que las declaraciones
son inmutables una vez almacenadas. Es decir, una vez que una
declaración ha sido admitida en el almacén central, se puede ver,
se puede copiar a otro almacén, etc. pero no se puede modificar.
Por lo tanto, es imposible añadir detalles más tarde. Se deberían
incluir todos los detalles que queramos en el momento de generar
la declaración. Por eso es recomendable, ante la duda, guardar
más detalle.
En muchos casos no se trata tanto de añadir muchos detalles

sino de añadir alguna información específica que nos resultará útil
para los posteriores análisis. Por ejemplo, si nos interesa saber qué
segmentos (y en qué orden) de un video suelen ver los usuarios, el
sistema que presenta el video tendrá que analizar las interacciones
del usuario para generar información de cuándo pulsa play, o
pause, cuándo salta a otro sitio, etc. y a partir de este análisis,
codificar de alguna manera información sobre los segmentos
vistos. Cuando el sistema genere una declaración (por ejemplo
cuando el usuario cierre el video), el sistema tendrá que incluir
esta información sobre segmentos vistos en la declaración. El xAPI
no define este tipo de información específicamente, pero como nos
permite usar extensiones, el sistema podrá introducir esta
información específica y detallada que necesitamos en una
extensión de contexto.
El xAPI nos permite de por sí guardar información muy

detallada, y debido a su extensibilidad, podemos añadir detalles sin
límites. Pero una cosa es que xAPI lo permita, y otra que podamos
o queramos hacerlo. ¿Cómo sabemos qué información (y con qué
nivel de detalle) debemos almacenar en las declaraciones? ¿cómo
sabemos qué y cuántas declaraciones enviar en cada sesión de

usuario? Este tipo de preguntas son muy importantes, y
perfectamente legítimas. Lo malo es que no hay respuesta única. Y
esto nos lleva a uno de los puntos clave que tocaremos
repetidamente a lo largo del libro, porque es fundamental.
Recuerde lo que se expuso en el primer párrafo de la introducción:
Normalmente queremos analizar datos para obtener respuestas
que nos permitan obtener algún beneficio (mejorar algo). Por
tanto, cualquier implantación xAPI, sea grande o pequeña, debe
estar dirigida o fundamentada en las respuestas que queramos
obtener de los datos. Esto es lo que nos guiará para saber qué
datos, cuántos, y con qué detalles o características necesitaremos.
Este proceder, quizá se haya dado cuenta, lo he introducido

veladamente en el ejemplo anterior del video: "Si nos interesa
saber qué segmentos (y en qué orden)... tendremos que (hacer una
serie de cosas)". En el ejemplo puede interesarnos el análisis de
esa información para inferir si los usuarios se saltan trozos del
video o no, e intentar entender por qué. Lo esencial es empezar
definiendo claramente lo que nos interesa saber. Eso determina
todo lo que viene después.
Como puede ver, este importante punto ha surgido solamente

tras explicar las declaraciones en xAPI. Todavía queda mucho por
exponer, pero verá que insistiremos en esta idea. Los distintos
factores presentes en la implantación que se quiera hacer, así
como los retos que surjan, habrá que abordarlos teniendo siempre
en cuenta los objetivos que se persigan con dicha implantación,
atendiendo a las preguntas que se quieran responder. Por eso
antes de plantearse nada técnico respecto a xAPI, lo primero que

hay que tener claro son los objetivos y las respuestas que se
buscan.
En el Apéndice A se muestran varios ejemplos de declaraciones

reales, con detalladas explicaciones sobre los distintos atributos.
Otros documentos
Además de declaraciones, cuya importancia es primordial como

hemos visto, los sistemas que almacenan datos xAPI también
proporcionan la capacidad de almacenar lo que llama
genéricamente documentos. Se trata de documentos de estructura
libre, es decir, xAPI no dicta qué propiedades deben tener, por
tanto podemos guardar la información que queramos. En
terminología de la especificación, se les llama document resouces
(recursos de documento). Esta funcionalidad está pensada para
que las actividades puedan almacenar información que vayan a
necesitar más tarde (en otra sesión) o que quieran compartir con
otros usuarios. Veremos brevemente el recurso de State (estado),
Activity profile (perfil de actividad) y Agent profile (perfil de
agente).
Nota: en xAPI, el actor en una declaración puede ser un agente o

un grupo. El término agente, por tanto, se refiere a un individuo.
Estado (state)
Los documentos de estado están asociados a un agente y a una
actividad6. Este tipo de documentos son útiles para que las
distintas actividades puedan guardar datos de un usuario a medida
que interactúa con ellas. Ejemplos de información que suele
guardarse en los documentos de estado podrían ser datos sobre
qué partes de un módulo eLearning ha visto ya el usuario, en qué
pantalla se llega, o cualquier otro detalle. Lógicamente este estado
puede recuperarse y modificarse en distintas sesiones. De esta
manera una actividad puede recuperar información sobre lo que el
usuario hizo en la última sesión y actuar en consecuencia: por
ejemplo podría marcar ciertas secciones como vistas, o podría
mostrar al usuario la última pantalla que vio.
Perfil de actividad (activity profile)

Una actividad puede utilizar el recurso de perfil de actividad
para guardar documentos con información que no es específica
para un usuario (agente) concreto. De este modo las actividades
pueden guardar información que será compartida por los usuarios
de esa actividad. Por ejemplo, si se trata de un juego, se podría
guardar un documento con una tabla de los usuarios y
puntuaciones más altas.
6 Adicionalmente, pueden estar asociados a lo que la especificación llama registration,

que es un identificador único que se puede utilizar para agrupar declaraciones.
Normalmente se relaciona con la matriculación de un alumno en un curso.
Perfil de agente (agent profile)

Los documentos del tipo perfil de agente se utilizan para guardar
información sobre usuarios a la que se desea que puedan acceder
distintas actividades. Por ejemplo, sería apropiado guardar en el
perfil de agente un documento con preferencias de usuario, de
manera que distintas actividades puedan acceder a esas
preferencias. Otro uso, quizá más interesante, sea para compartir
o comunicar datos entre actividades cuando las está usando un
usuario. Por ejemplo, una actividad podría pedir al usuario que
respondiera alguna pregunta, o escribiera una reflexión
relacionada con el tema, y podría guardarla en un documento del
tipo perfil de agente. Otra actividad diferente (por ejemplo, otro
tema del mismo curso) podría recuperar esta información para
mostrársela al usuario y utilizarla de alguna manera (quizá
recordare al usuario lo que respondió entonces, y planteare qué
respondería tras ver este nuevo tema y tener más información).
Otros estándares de eLearning (SCORM) no permitían ninguna
comunicación entre unidades separadas. Con xAPI y el perfil de
agente sí que se puede, lo cual puede proporcionar oportunidades
interesantes desde el punto de vista del diseño instruccional.
Tipos de sistemas
Cuando se explicó lo que es un API se mencionó que los sistemas

que implementan la API se dividen en dos tipos desde el punto de
vista funcional: el servidor, que es el software que implementa la
API (proporcionando funciones y recursos que otros sistemas

pueden aprovechar), y los clientes, que son esos sistemas que
hacen uso de la API, llamando a las funciones que expone el
servidor.
Por supuesto en xAPI también es así, y conviene ahora introducir

brevemente los tipos de sistemas que hay en xAPI. Más adelante
me extenderé sobre cada uno de ellos con bastante más detalle,
pero llegado este punto es necesario al menos familiarizarse con la
terminología. Hablaremos de LRS, LRP, y LRC.
LRS
LRS significa Learning Record Store o almacén de registros de
aprendizaje. Se trata del sistema que implementa xAPI, y
funcionalmente es el servidor de API. Su rol es vital y central en
cualquier despliegue que utilice xAPI. Como su nombre indica, es
donde se almacenan los registros de aprendizaje, que es otra
manera de llamar a las declaraciones. Siempre que hemos hablado
del sistema central o almacén central donde se guardan todas las
declaraciones, nos estábamos refiriendo al LRS.
Como acabamos de ver, además de declaraciones el LRS puede

almacenar otros tipos de documentos. Y, algo que no habíamos
mencionado antes, xAPI permite que las declaraciones lleven
archivos adjuntos (attachments, en inglés), y el LRS también los
almacenará. Gracias a los archivos adjuntos las actividades pueden
guardar en el LRS documentos de texto, audios, videos etc. Esto
puede resultar útil en diversos escenarios, por ejemplo en
actividades de aprendizaje de idiomas donde el usuario puede
grabar su voz.
Como puede imaginar los LRSs son sistemas complejos, que

además deben estar diseñados para poder crecer (escalabilidad) y
tener un rendimiento adecuado. Efectivamente, un LRS puede
estar recibiendo muchos datos (declaraciones, otros documentos,
adjuntos) de muchas actividades a la vez. Antes de guardarlos
tiene que realizar estrictas comprobaciones sobre todos los datos
que reciba, para verificar que se ajustan a las normas de xAPI, lo
cual requiere una capacidad de procesamiento adecuada. Una vez
verificada la corrección de los datos, el LRS debe almacenarlos.
Para esto normalmente utiliza un sistema de base de datos potente,
rápido y también que permita el crecimiento.
No es fácil, ni mucho menos, desarrollar un LRS. Debe ajustarse

estrictamente a absolutamente todas las normas que se especifican
en xAPI. Si no lo hace, si no pasa todos los tests de conformidad,
no se le puede llamar LRS, porque no lo es.
Así pues, la característica esencial que hace que un sistema sea

un LRS es que implementa completamente el API de experiencia.
Sin embargo, más adelante veremos que los LRS normalmente
implementan además otras funciones.
LRP
Si los LRS almacenan datos, principalmente declaraciones, algún
otro sistema debe generar todas esas declaraciones (y también
documentos y archivos adjuntos). Efectivamente, hasta ahora nos
hemos referido a estos sistemas como actividades, y en la mayoría
de los casos se tratará de actividades de aprendizaje. Desde el
punto de vista funcional a este tipo de sistemas se les llama

Learning Record Providers o LRP (proveedores de registros de
aprendizaje). Antes se les llamaba Activity Providers (AP), y todavía
es frecuente encontrar este término.
Los LRP son clientes de xAPI, y por tanto utilizan las funciones
que exponen los LRS para poder enviares declaraciones (con o sin
adjuntos) y documentos para que se guarden en el LRS.
Resulta útil pensar en LRP no como sistemas separados y a

medida (aunque podrían serlo), sino como funcionalidad que se le
añade a algo. Por ejemplo, un contenido eLearning que genere
declaraciones xAPI y las envíe a un LRS, sigue siendo eso, un
contenido eLearning, pero funcionalmente se lo puede considerar
un LRP. Lo mismo ocurre con un juego, un simulador, etc. Una vez
que se los modifique para que generen y envíen declaraciones,
funcionalmente son LRPs.
Podríamos decir que añadir a algo la funcionalidad de enviar

declaraciones xAPI es hacer a ese algo compatible con xAPI.
Implementar esta funcionalidad es relativamente fácil. Además,
existen librerías para distintos lenguajes que ya implementan todos
los mecanismos básicos para crear declaraciones, enviarlas, etc. lo
cual facilita mucho el desarrollo.
LRC
Hasta ahora hemos visto sistemas cuyo rol principal es generar y
enviar datos, y sistemas cuyo rol principal es almacenar esos datos.
Funcionalmente existe otra categoría de sistemas a la que
llamamos Learning Record Consumer, y se trataría de sistemas
que solicitan datos al LRS (declaraciones, principalmente) con el

fin de procesarlos, analizarlos, crear informes, visualizaciones, etc.
Los LRC también son clientes xAPI, pero en lugar de enviar datos,
lo que van a hacer principalmente es consumir datos de un LRS.
Funcionalidad mixta
Conviene insistir en que esta clasificación es funcional, se refiere
a la función principal que lleva a cabo un sistema. Esto no significa
que el sistema solamente haga esa función (por ejemplo, proveer
datos y nunca consumirlos). Por ejemplo, un modulo de eLearning,
lo que más hará será enviar declaraciones al LRS, pero en algunos
momentos también solicitará y recibirá datos del LRS, por ejemplo
un documento de estado para el agente/actor que está
interactuando con el módulo en cuestión, o cualquiera de los otros
tipos de documentos que hemos visto. Incluso también puede hacer
peticiones para recibir declaraciones.
Asimismo, un sistema que sea principalmente LRC (consumidor)

también podrá enviar declaraciones u otros documentos al LRS.
Por ejemplo, imagine un sistema que cada noche procesa todas las
declaraciones que se han registrado ese día, y genera certificados
o diplomas para los alumnos que hayan completado cursos. Este
sistema podría también generar declaraciones del tipo "el sistema
X generó un certificado de aprovechamiento del curso para el
alumno Y" y enviarlas al LRS.
Perfiles xAPI
Como puede imaginar después de todo lo que se ha expuesto
hasta ahora, el xAPI proporciona muchísima flexibilidad. A veces
puede resultar difícil decidir cómo aplicarlo: ¿qué verbos usar?
¿cuáles son los tipos de actividad apropiados en cada caso? ¿existe
alguna secuencia recomendada en la que se deben enviar
declaraciones? Y todo esto quizá aplicado a muy diferentes
situaciones: contenidos lanzados por un LMS, contenidos de video,
etc.
Parece que resultaría conveniente tener algún tipo de guía o

directriz que pudiera ayudarnos a tomar estas decisiones. Como
esta problemática se vislumbraba desde los primeros tiempos de
xAPI, ya entonces se hablaba de comunidades de práctica
(Communities of Practice, CoP), grupos que quieren utilizar xAPI
en un contexto concreto, por ejemplo "contenidos lanzados desde
un LMS", "juegos", "video", etc. Y también se hablaba de recetas
(recipes) que venían a ser indicaciones sobre qué declaraciones
utilizar (con qué verbos, y en qué secuencia) en tipos específicos
de experiencias.
En la versión actual se habla de perfiles (profiles), definiéndolo

como: "Conjunto de reglas y vocabularios para ser implementados
además de xAPI para el caso de uso particular del que se trate". Se
sigue hablando de comunidades de práctica, que son las que deben
definir sus perfiles, dar indicaciones sobre las mejores prácticas a
seguir, etc.
Es claro que este es un tema importante. Por eso se ha ido más

allá y se ha creado una especificación separada y específica
para perfiles de xAPI. Esta especificación formaliza la definición de
perfiles y la manera de crearlos, y define una manera de expresar
información sobre perfiles de tal manera que los ordenadores
pueden entender y utilizar automáticamente esa información. Es
decir, se definen reglas muy precisas sobre cómo definir y
compartir perfiles.
Esta especificación de perfiles es muy avanzada y seguramente

solamente tengan que adentrarse en ella las personas más técnicas
que necesiten hacer algún desarrollo relacionado con ella. No
obstante, he considerado conveniente dar a conocer su existencia
llegados a este punto, porque su potencial para facilitar el uso de
xAPI es grande. Cuando las herramientas de autor (y otras) sean
capaces de manejar perfiles automáticamente, quedará
notablemente facilitado el uso correcto (y útil) de xAPI para
aquellos que lo necesitan pero que no tienen necesariamente un
perfil técnico, por ejemplo para los diseñadores instruccionales.
En resumen, el enorme potencial de xAPI y su gran flexibilidad

pueden llegar a constituir una dificultad para su correcto uso, pero
recuerde que se están tomando medidas para encauzar toda esa
flexibilidad y que sea más fácil aplicar patrones útiles, conocidos, y
perfectamente documentados.
Lo que xAPI NO es ni hace
Puede parecer extraño -después de explicar en cierto detalle qué

es xAPI- dedicar una sección a lo que xAPI no es. El problema es
que, aunque la fuente autoritativa de lo que es xAPI es la propia
especificación, no todo el mundo tiene la inclinación, el perfil
técnico necesario, o simplemente el tiempo, de estudiarla. En
realidad xAPI tiene tanto potencial que a veces es fácil atribuirle
poderes mágicos que en realidad no tiene. Hay ciertos
malentendidos sobre xAPI que son bastante comunes, por eso he
creído conveniente proporcionar información sobre ellos
directamente, para contribuir a que dejen de causar confusión, y
así pueda detectarlos y rebatirlos fácilmente.
No es un sistema/software
Recordemos que xAPI es una especificación, una serie de
normas. Solamente define cómo deben comportarse distintos
sistemas software, pero no es en sí misma un software. En
ocasiones se oye decir "xAPI hace esto", o "xAPI captura cualquier
tipo de aprendizaje", etc. Intuitivamente lo entendemos, pero es
que esas frases, dichas así sin puntualizar, pueden confundir a
algunas personas. Y debemos evitar crear confusión. Quien no
conoce xAPI y oye o lee ese tipo de afirmaciones por primera vez
puede pensar que si xAPI hace... o xAPI captura..., entonces xAPI
será un sistema o algo así que se instala en un entorno eLearning,
y que hace diversas cosas. No. Conviene puntualizar y ser más
estrictos. El xAPI lo único que hace es decir cómo hay que
implementar ciertas funcionalidades.
No define empaquetamiento
Al contrario que otros estándares de eLearning (en concreto
SCORM), xAPI no se pronuncia en absoluto sobre cómo deben
empaquetarse los contenidos, ni siquiera si deben empaquetarse o
no, dónde se deben colocar, etc.
No define control de acceso a contenidos

En la mayoría de los casos el acceso contenidos no es público.
Muchas veces solo debe permitirse el acceso a los usuarios
autorizados. Todo lo que esté relacionado con comprobación de
credenciales, autorización para acceder ciertos contenidos etc. es
totalmente ajeno a xAPI.
No define el lanzamiento (launch) de

contenidos
Lanzar un contenido, en el ámbito de la Web, significa abrirlo,
ponerlo en marcha. Por ejemplo, cuando se pulsa un enlace o un
botón para abrir un contenido eLearning se desencadenará el
proceso de lanzamiento (launch), cuyo resultado es que el
contenido aparezca en el navegador.
xAPI realmente no dice nada sobre contenidos. Solo dice que,

cuando un contenido envía una declaración, ésta debe tener,
obligatoriamente, un actor. Esto plantea el dilema de que el
contenido debe saber qué actor utilizar cuando envíe
declaraciones. Adicionalmente, debe saber la dirección y los datos
de acceso (usuario y clave) del LRS, para poder enviarle las

declaraciones.
Esta información que el contenido necesita para funcionar con

xAPI, se le proporciona al contenido al lanzarlo. Esto puede
hacerse de muy diversas maneras, y xAPI no define ninguna. Es
decir, el proceso de lanzamiento está fuera de la especificación,
xAPI no lo dicta.
Esto plantea no poca confusión, sobre todo si uno no sabe o no se

imagina los detalles técnicos de cómo puede producirse el
lanzamiento. Existen varios procesos de lanzamiento (y cualquier
desarrollador puede programar cualquier lanzamiento que se
invente, si eso resulta útil para su situación concreta). El problema
es que el lanzamiento más conocido y popular tiene un defecto
bastante notable de seguridad. Este método, por decirlo de una
manera sencilla, pone el actor, la dirección del LRS y las
credenciales de acceso al LRS en el URL, con lo cual son datos que
quedan a la vista en el navegador. Se pueden aplicar medidas para
paliar estos problemas (y debería hacerse, por supuesto), pero -si
se puede- es mejor utilizar algún otro método más seguro.
Pero el gran malentendido que surge con esto es que hay gente
que al acercarse por primera vez a xAPI, sobre todo si tienen cierto
conocimiento técnico, enseguida dicen que "xAPI es inseguro".
Esto es un ejemplo claro de lo que ocurre a veces, que se atribuye
a xAPI cosas que la especificación no dice. Ciertamente, el
método de lanzamiento descrito antes tiene ese problema de
seguridad, pero es que la especificación xAPI jamás dice que
haya que utilizar ese método.
Lo resalto con tanto ahínco porque es importante siempre

recordar esto:
el proceso de lanzamiento NO es parte de xAPI
Existen muchas maneras de abordar el lanzamiento y de

proteger la información que no debería quedar a la vista.
El cualquier planteamiento con xAPI que involucre contenidos

Web hay que plantear (y resolver) el problema del lanzamiento
como resulte más conveniente para la situación concreta.
No gestiona contenidos
Ni xAPI define, ni por tanto los LRS incorporan, ninguna
funcionalidad relacionada con la gestión de contenidos.
Los LRS (como tales) nunca alojan ni lanzan contenidos.
No hace a los contenidos adaptables

(responsive)
De nuevo, xAPI no dice nada acerca de los contenidos. Por tanto,
que unos contenidos Web se adapten a distintos tamaños de
pantallas no tiene relación con xAPI en absoluto. Los contenidos
serán adaptables si el desarrollador así los programó, y si no, no,
independientemente de que envíen declaraciones a un LRS o no.
Usando xAPI se pueden enviar declaraciones desde

prácticamente cualquier dispositivo y contenido, pero eso no
significa que por usar xAPI los contenidos van a funcionar y a tener
una aspecto óptimo en cualquier dispositivo donde los queramos
poner.
No determina seguridad o inseguridad

En términos de seguridad, la especificación xAPI solo se
pronuncia en cuanto a dos métodos de autenticación.
Explícitamente dice que cualquier otra cosa relacionada con
seguridad queda fuera del alcance de la especificación.
Esto es importante, ya que cualquier afirmación sobre seguridad

o inseguridad de xAPI tiene en realidad poco sentido. Cuando se
plantea un despliegue con xAPI habrá que aplicar las medidas de
seguridad que se aplican normalmente en cualquier tipo de
despliegue tecnológico o informático: seguridad de redes,
cortafuegos, encriptación, etc. El hecho de que se use xAPI no hace
al despliegue ser seguro o inseguro de por sí.
Los LRS no reemplazan a los LMS

Es cierto que para utilizar xAPI el LRS es estrictamente
necesario, y el LMS no, pero eso no significa -en absoluto- que
aquél vaya a sustituir a éste. Se puede poner en marcha un
despliegue en el que haya un LRS y contenidos formativos que le
envían declaraciones, y que no haya LMS. Pero si en su entorno ya
utilizan un LMS, seguramente lo seguirán utilizando aunque
empiecen a adoptar xAPI.
Los LMS y los LRS son sistemas totalmente distintos, llevan a

cabo distintas tareas y, sencillamente, no tiene sentido decir que
los LMS quedan obsoletos porque ahora existen los LRS.
Hay LMSs que están incorporando funcionalidades de LRS, es

decir, están convirtiéndose en un sistema híbrido. Hay quien
recomienda que se mantengan separados, y esta recomendación
tiene sentido, ya que tanto un sistema como el otro ya son
complejos de por sí, así que intentar mantener las funcionalidades
de los dos a la vez es un reto. Además, la carga a la que se puede
llegar a someter a un LRS normalmente será mayor que la de un
LMS, lo cual es otro argumento a favor de mantenerlos separados
para poder escalar el LRS independientemente.
Nótese que si a un LMS se le añaden funcionalidades de cliente

xAPI, será -funcionalmente- un LRP (learning record provider) y
podrá enviar declaraciones al LRS. Esto no es raro en absoluto, ya
que el LMS puede ser una fuente muy rica de datos sobre cómo los
estudiantes o empleados hacen uso de las distintas funcionalidades
relacionadas con el aprendizaje proporcionadas por el LMS.
Ni reemplaza a SCORM ni es su nueva versión

Es relativamente frecuente encontrar artículos que dicen que
xAPI es la nueva versión de SCORM. Esto, simplemente, no es
verdad.
Cuando se creó xAPI desde luego que se tuvieron en cuenta las

limitaciones de SCORM, pero no se quería conseguir un estándar
que hiciera lo mismo pero de otra manera. Lo que se quería era
algo que permitiera hacer cosas que no se pueden hacer con
SCORM, pero no necesariamente reemplazar lo que ya hacía
SCORM. Estos dos estándares tienen diferente alcance. No definen
los mismos tipos de cosas. Como hemos visto, xAPI no define nada
relacionado con el empaquetamiento de los contenidos. SCORM sí,

era una de sus características fundamentales. Y lo mismo ocurre
con otros aspectos de los estándares.
No hay por qué intentar reemplazar con xAPI los escenarios de

formación que se pueden resolver con SCORM, o que han sido
resueltos con SCORM en un entorno donde se utiliza un LMS (si se
utiliza SCORM, el LMS es necesario).
Piense en xAPI como algo que nos permite hacer cosas que antes
no podíamos hacer. Algo que nos permite mirar hacia adelante y
concebir nuevos escenarios, no intentar repetir los mismos
escenarios de antes con las nuevas herramientas.
En este punto resulta conveniente mencionar CMI5. Quizá haya

oído hablar de ello. CMI5 es un perfil (en el sentido que ya hemos
explicado) de xAPI centrado en el caso de uso de contenidos
eLearning que se lanzan desde un LMS y utilizan xAPI para hacer
el seguimiento. Es, por tanto, un perfil que cubre el mismo caso de
uso que cubría SCORM, y lo que se intenta es que funcione de
forma parecida. CMI5 es xAPI con reglas adicionales para este
caso de uso. En cierto modo CMI5 sí que podría considerarse como
una versión avanzada de SCORM. CMI5 define empaquetamiento
de contenidos, define el método de lanzamiento, las declaraciones
que se deben enviar y en qué secuencia, etc. No obstante permite
la flexibilidad de poder enviar otras declaraciones, además de las
obligatorias. Otra diferencia con SCORM es que, la definición de
un paquete de CMI5 permite que los contenidos se mantengan
separados del LMS, es decir, no hace falta ponerlos en el LMS.
Para poder usar CMI5 el LMS tiene que implementar
necesariamente las funcionalidades CMI5 que le corresponden

(por ejemplo, el método de lanzamiento prescrito por CMI5, ser
capaz de importar estructuras de cursos CMI5, etc.)
No hace que todos los contenidos funcionen

sin conexión
Otra de las áreas que en ocasiones se interpreta erróneamente
es la capacidad de xAPI de funcionar sin conexión (offline). De
nuevo, se trata de una mala interpretación de algo que la
especificación posibilita, y se cree que es algo que cualquier
sistema compatible con xAPI implementa necesariamente.
La especificación define que una declaración tendrá dos sellos de

tiempo: timestamp (el momento en el que la acción ocurrió), y
stored (momento en que la declaración se almacenó). El hecho de
que sea la propia declaración la que registra el momento en que se
generó hace posible que las declaraciones se puedan almacenar en
cualquier otro momento posterior sin pérdida de información. Por
tanto cualquier LRP puede almacenar declaraciones localmente y
más tarde enviarlas todas al LRS. Por ejemplo, podría almacenarlas
localmente si detecta que no hay conexión a internet, y cuando
detecte que la conexión se ha recuperado, podría enviar todas las
declaraciones que ha ido almacenando. En este caso sí que
podríamos decir que funciona sin conexión. Pero ¡ojo! debe quedar
claro que es el LRP el que funciona sin conexión si se ha
programado para ello. Es decir, no por el simple hecho de usar
xAPI va a tener esa funcionalidad. Se trata más bien de que, si se
desea programar dicha funcionalidad en el LRP, xAPI no pone
ningún impedimento. Al LRS le da igual que las declaraciones

lleguen justo después de generarse o dos horas después, o cinco
días después: cada declaración seguirá teniendo su sello de
tiempo.
Otra vertiente del malentendido sobre funcionar sin conexión se

refiere a las actividades que -por su naturaleza- son sin conexión,
simplemente porque no son digitales. Un simple ejemplo podría ser
un juego de rol que se lleva a cabo en una clase presencial. ¿Podría
reflejarse mediante declaraciones xAPI lo que ocurre en el juego,
cómo actúa cada alumno? Sí, claro. Pero se necesitaría algún
sistema con su interfaz (y seguramente con una persona
manejándolo), que permitiera expresar eso que está pasando en el
mundo real mediante declaraciones xAPI. Ciertamente cualquier
cosa que pueda expresarse mediante una estructura Sujeto +
Verbo + Objeto, podrá expresarse como declaraciones xAPI. Por
tanto, efectivamente, xAPI permite que hagamos seguimiento de
cualquier actividad, incluso las que no son digitales ni tienen
conexión por naturaleza. Pero evidentemente esto no va a pasar
solo por el hecho de que xAPI exista, sino que tiene que haber
alguna implementación, algún sistema, que efectivamente permita
traducir lo que está pasando en una actividad no-digital concreta, a
declaraciones xAPI.

Xapi Conceptos Basicos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Xapi Conceptos Basicos

Cargado por

Copyright:

Formatos disponibles

XAPI: Conceptos básicos

La especificación xAPI no siempre se llamó así. En los inicios

1 ADL significa Advanced Distributed Learning, y es un programa del gobierno de

Todavía es muy frecuente encontrar referencias a TinCan API, y

No debe haber ninguna confusión: es exactamente lo mismo, no

Lo más apropiado para evitar confusiones es usar el nombre

Como su nombre indica, xAPI es el API de las experiencias. Como

Primero, definamos lo que es un API. API significa Application

En otras palabras, un API es un conjunto de normas que rige

de un API concreto, se dice que implementa esa API. Es importante

Ahora bien, de la definición anterior se desprende que hay, en

● el que implementa las funciones y las expone, normalmente

● los sistemas software que implementan las llamadas a las

Normalmente el servidor es mucho más complejo, ya que es el

Sabiendo ya lo que es un API en general, podemos decir que

xAPI es un conjunto de normas que establece cómo los

transportar, almacenar y recuperar, datos referentes a

La idea clave con la que hay que quedarse es que xAPI es un

Aunque ciertamente xAPI permite referirse a experiencias de

Premisas, objetivos y alcance

Las premisas de las que se partió al crear la especificación xAPI

● se percibe la creciente necesidad de poder analizar

● esta información puede provenir de una amplia variedad de

● la mejor manera de solucionar esta necesidad es desarrollar

3 Estas premisas se han tomado casi literalmente de la introducción de la especificación.

Algunos de los objetivos de este marco de trabajo -la

● maximizar la interoperabilidad de los servicios que crean,

● proporcionar una guía a quienes quieren crear aplicaciones

● proporcionar criterios que permitan evaluar la conformidad

El punto de la interoperabilidad es muy importante, como

Con el alcance de la especificación me refiero a qué es lo que

De manera muy general puede decirse que xAPI abarca:

● el modelo de datos (sobre experiencias), y

● los métodos de transferencia (y su formato).

xAPI define el modelo de datos para los documentos (objetos)

El xAPI también prescribe los métodos de transferencia que se

Adicionalmente xAPI especifica que se ha de usar JSON 4 para

4 JSON significa JavaScript Object Notation, y es un formato ligero de intercambio de

Aunque parezca poco, el detalle técnico de esas dos áreas

Es importante tener presente la idea del alcance de xAPI, porque

Veamos unos ejemplos concretos para ilustrar la idea:

● ¿Una pieza de eLearning que funcione con xAPI es responsiva

● ¿Cómo se sabe, en un entorno xAPI, si cierto alumno tiene

ciertamente relevante, pero separado de xAPI.

● ¿Puedo solicitar, al sitio que almacena los datos, que me

El concepto más conocido y que suele verse como el centro de

La especificación las define así:

"declaraciones son la evidencia de cualquier tipo de

Esto es bastante genérico. Para concretar más podemos decir

Naturalmente, esta estructura Sujeto + Verbo + Objeto nos

"Antonio accedió al curso 'contablidad101'”

Ese tipo de afirmaciones pueden considerarse evidencias de que

De forma intuitiva se entiende perfectamente lo que es una

A pesar de su aparente sencillez, a nivel técnico las definiciones

5 No es obligatorio utilizar el verbo en tiempo pasado, pero es muy habitual. Es lo que

stored Fijado por el LRS

A su vez algunas de estas propiedades almacenan otros objetos

El contexto que rodea a un evento o actividad suele ser

instructor (útil si se trata de una actividad en la que intervenga un

Una simple declaración, como "Antonio respondió la pregunta 5"

Antonio respondió a la pregunta 5

Es evidente que esta última declaración es mucho más