Add a Moodle core event on each recived xAPI statement (coming from the browser)

[nadavkav]

Since Moodle's logstore_xapi plugin is monitoring a set of specific core events, similar to the ones that are sent into the mdl_logstore_standard_log, and send them to an external LRS, H5P module should also be able to send each xAPI statements that is "coming" form the client (browser) via ajax into h5p custom xapi events table, also as a core Moodle event.

[nadavkav]

Suggested fix https://github.com/iucc/h5p-moodle-plugin/commit/4d4fed11509c8be3fb678ffd8f9a15ae98cfb9b9 Which includes a module system setting for enabling this feature

[nadavkav]

Important update https://github.com/iucc/h5p-moodle-plugin/commit/10714e8a983f46f49d151f1867cadc54a6fb75b3

[nadavkav]

If this concept is approved, I will also add a link to an external logstore_xapi github repository with a special PR that include support for this new hvp/classes/events/xapi_statement (which is already working for us, and sending xapi events into an external LRS)

[thomasmars]

This seems reasonable. Could you tell me a bit more about some things:

• How are events dispatched through the Moodle Core system usually used ? Is it necessary to dispatch them to an LRS, or can you view them natively in Moodle ? How would a typical Moodle site make use of these events and is it easy to get started with ?
• This can lead to a lot of data being stored. Are they aggregated at some point ?
• xapi-collector.js is only collecting and sending 'completed' or 'answered' events, since these are used for generating the reports. If we go with this approach we should probably catch all events and dispatch them through the Moodle Event API ?

[nadavkav]

Great! good to read that it make sense :+1:

• Moodle, by default send all core and 3rd-party plugins events to mdl_logstore_standard_log (https://docs.moodle.org/33/en/Logging), and any other logstore plugin that is turned on (enabled), either core logstores or also 3rd-party logstores, like the logstore_xapi (https://moodle.org/plugins/logstore_xapi). So, by default, Moodle does not send any events outside to any LRS. only if we install logstore_xapi and configure it properly.
• Logstore_xapi send out a specific set of Moodle core events to an external LRS. I extended it to be able to also send the H5P xapi statement events coming into Moodle from the browser (as described above on this patch), here is the relevant commit: https://github.com/iucc/moodle-logstore_xapi/commit/db03333e62974538d135fc7f861101a718772d34 (not yet pull requested upstream, it's our own repo)
• You can view the Moodle core events natively in each activity's log view report, and also on the System Admin log report, and also with other 3rd-party plugins.
• A Moodle system can "listen" to events happening all over the system, and trigger other action based on them. (i.e A user just triggered an H5P quiz xAPI statement with a verb property = "completed"... then, another plugin can "listen" to the event and mark another Moodle core activity as "visible" to that user ( a video resource, a higher level quiz, another h5p module, ...), just about anything.
• Indeed, Moodle core logs get huge very quickly, depending on the size of the institute using it (user, user behaviors, number and size of courses, teaching methodologies, ...) and we have various system administration techniques to handle it.
• We should have some hvp admin level system setting to control the type of verbs getting logged into Moodle and the level of details. I am already starting to implement it. as it is very very important to some institutes (for academic research, i.e "Who clicked seek, play pause and when in the H5P IV") and for daily progress reports for the teachers and students, as simple as activity completion and its grade.

Hope it's more clear.

[thomasmars]

Thank you, that's some good info. One more thing:

• Shouldn't different verbs for xAPI statements be split into different events ? It seems like other core plugins have more specific event names. Instead of having one event called hvp_xapi_statement, we would have hvp_interaction_attempted, hvp_interaction_interacted, hvp_interaction_answered, etc. ? (I guess this is more of an implementation detail though)

Either way, I think this would be a nice step towards a better integration with Moodle. We would love a pull request for this.

[nadavkav]

Well, I am not entirely sure what should be the right way to go forward implementing this, maybe we should ask it on the Moodle forums (https://moodle.org/mod/forum/view.php?f=33) or the Moodle telegram dev chat (https://telegram.me/moodledev)

Anyways, what I did is change the the Moodle core event's "action" property after the event was fired and already populated with the relevant xAPI statement data, to hold the xAPI verb: https://github.com/iucc/h5p-moodle-plugin/commit/10714e8a983f46f49d151f1867cadc54a6fb75b3#diff-a82923ea8a8f20ccb1d23bc05be41637R46 Which is very useful at the moment, to workaround the dilemma you are face with.

I recommend adding the following xAPI experts: @ryansmith94 and @garemoko and @davidpesce to the discussion (if they can spare some time reviewing this, that would be highly appreciated)

[ryasmi]

I don't have a lot of expertise with h5p or this plugin, but as @thomasmars suggests, I would think it best to have separate events in the Logstore for each of the h5p events and avoid tying the events to the xAPI in the Logstore.

In the xAPI Logstore Plugin it can pick up the separate events and create statements specific to those events there.

This encapsulates the xAPI logic in the xAPI Logstore Plugin and ensures that this plugin's events can be used by other plugins that may or may not be related to the xAPI.

[nadavkav]

Thank you @ryansmith94 for your input! Did you have a look at my implementation of a single H5P xAPI "multi verb" event? https://github.com/iucc/h5p-moodle-plugin/blob/mod_hvp_rtl_support/classes/event/hvp_xapi_statement.php I am already sending all those events into: https://github.com/iucc/moodle-logstore_xapi/commits/h5p_xapi_event_support (Which I haven't PR yet, as it is still under prototype/testing)

Considering the current 35 sub H5P modules and their potential verbs, there are a lot of verb combinations, and it does not seem generic enough solution to add events for each one of them.

[garemoko]

I can see the argument for separating out the events.

A counter argument is that since H5P is already generating xapi statements it's extra complexity to split them out into separate events and then have the logstore plugin catch all the different events.

I wonder if there's a way for the events to go directly to the logstore's xapi emitter. Or maybe it shouldn't be connected to the logstore plugin at all.

I've not really looked into this properly; just throwing out ideas.

[ryasmi]

Did you have a look at my implementation of a single H5P xAPI "multi verb" event?

No I hadn't looked at it when I replied @nadavkav, I've had a quick look through it now, it doesn't seem to be doing much since like @garemoko says this plugin is already generating xAPI statements (which I didn't realise until I read your code and Andrew's comment).

Considering the current 35 sub H5P modules and their potential verbs, there are a lot of verb combinations, and it does not seem generic enough solution to add events for each one of them.

I can see how that might be a pain, however, in that case, you could extend a single class to reduce the work which would maintain flexibility in the xAPI Logstore Plugin and allow the events to be represented independently in the Logstore table.

Or maybe it shouldn't be connected to the logstore plugin at all.

Yeah I'm wondering that too Andrew, whilst there are some benefits to integrating this plugin with the Logstore, that is probably a separate concern. I guess the real benefit is that xAPI Logstore Plugin can use a cron job to emit the statements, but I'm not sure if that would be a benefit here.

[garemoko]

xAPI Logstore Plugin can use a cron job to emit the statements, but I'm not sure if that would be a benefit here

I see that as a real benefit. The question is whether it's better to have the complexity of integrating with the logstore plugin, or duplicate the statement queuing and sending functionality in both plugins. Without having dug into it, I'm not advocating either way.

[nadavkav]

Thank you @garemoko and @ryansmith94 for your feedback! still, not sure how to go forward with this. safely.

We are already using the logstore_xapi (for almost two years now) to send Moodle core event + custom H5P xAPI to an external LRS, and it is also important for us to have those h5p xapi statements send first into Moodle, either mdl_logsotre_standard_log or h5p's internal custom xapi-statements table. so we can not send them directly from the client's browser to an external LRS (if that's what you are thinking about), as we need them for server-side grade and progress calculation (to prevent client side malicious grade manipulation) and also triggering other course learning paths related to xapi statement specific verbs and such.

Indeed, the challenge is that we are already getting xapi statements off the h5p sub plugins, in the first place, and I do not want to lose that data structure and its detailed content when "translating" it into a Moodle standard event. so I just keep everything and later the logstore_xapi expander and translator do not have much to do, but passing almost everything as is to the emitter.

[ryasmi]

You're welcome @nadavkav 👍 I'm not sure either.

Assuming that this plugin generates the statements client-side, I think the client can still manipulate their grade in your current solution.

Okay, so I don't think the mdl_logstore_standard_log is the right place for the events to go since the events are already xAPI statements and it wouldn't really be right to store all those events with under the same eventname in that table. I think integrating this plugin with the mdl_logstore_standard_log is a separate problem (despite being somewhat related).

To improve my understanding, why does this plugin generate xAPI statements? What does it do with them if it doesn't send them to an LRS already?

[nadavkav]

H5P use xAPI as it is a great standard, and since it is a framework not just for Moodle but also for other applications like Wordpress, Drupal, Their own h5p.org cloud service, Canvas, other systems... it sends those xAPI event into the hosting environment. In Moodle's case, into a custom xapi statement ready table, and later display it to the users using a specific reporting UI that is based on that xapi data that was received from the JS client. More info: https://h5p.org/blog/december-2016-xapi-improvements

Since logstore_xapi listen to core Moodle events and since we wish to send those event out into a remote LRS from a single funnel, we extended the H5P plugin to be able to convert the JS xAPI events coming into the Moodle system into a core events, and the logstore_xapi to be able to understand those events. and send them all out to an external LRS. Follow the de-facto route. You might think, that H5P module should send the incoming xAPI events directly into a remote LRS, but as it might seem quicker and shorter route, it could open a potential for data integrity anomalies, and also misconfigurations.

[ryasmi]

Hmmmm okay. It sounds to me like there should be a plugin to load statements from the "xAPI statement ready table" into an LRS. However, that plugin may want to share some code with the xAPI Logstore Plugin. That solution would reduce code duplication (still shares code with the xAPI Logstore Plugin) and reduce data duplication (between the ready table and Logstore table).