Learning Repositories, Badges, Standards and Mahara

NZMootPostImageI’ve been lucky enough to get across to the NZ Moodlemoot this week and catch up with a bunch of clever people working with Moodle, as well as the odd Mahara guru (ping Kristina Hoeppner). The first post-keynote session I saw was about the Mozilla Openbadges integration with Moodle, quickly followed by a session on the Moodle Mahara integration. During both of these I was also ruminating on the Tin Can API.

This got some cogs turning for me in relation to how these things all relate to each other, given that they are all trying to achieve something similar – giving learners a place to store their achievements.

Before the flames start, yes, I get that this is a gross simplification (even if I’m still getting my head around the nuances of both Open Badges and Tin Can), so I’ll do my best to give a definition of all three – please feel free to correct me in the comments if I’ve messed anything up.

  • Mahara – is an ePortfolio (and social networking and group collaboration and blogging) tool that allows learners to keep almost any kind of artefact, and re-use it in Pages that can be shared with the world (or a subset thereof), and that supports the LEAP2A standard for importing and exporting data.
  • Mozilla Open Badges – is a project which includes a place (called a Backpack) where users can collect online badges from other badge provider systems, and then share these badges with other systems as evidence of achievement. The badges are images which contain metadata that define a bunch of information about the badge and its issuer.
  • The Tin Can API – is a set of standards that define learning events that a learner can have sent to a Learning Record Store (LRS) which can record their achievements or activities. Anyone could set up an LRS provided it meets the Experience API standard. Learning activities are simple statements such as ‘Mark authored a blog post in his Moodle course’ or ‘Mark completed Assignment 1 in his Moodle course’.

See the overlap? And the differences? Good – then you can explain them to me…

But seriously, my head scratchers around this current scenario are:

  1. When people talk about the Mozilla Open Badges project, they seem to talk about it in the sense that it will be there forever. I’ve not heard one person yet talk about portability in the event that the Mozilla Backpack site was to disappear, and that worries me. Are badges stored in a way which will allow portability to another alternative LRS? Or is the backpack really just a simple engine to harvest Badge metadata and show it off in a nice way which could be easily replicated in something far simpler than an LRS?
  2. Why wouldn’t Mozilla and the folks at Rustici (the Tin Can people) work together to get Open Badges feeding a generic LRS? I searched, but all I could find was one vague comment in a Tin Can blog post. Or is my mental model that the Mozilla backpack is nothing more than an alternative implementation of a stripped back LRS (but without the Experience API standards to back it up) completely wrong? And in that case then my mental model of a badge completion is just one learning experience record, even if stored in a different way (metadata inside an image) wrong too?
  3. Where does Mahara fit in all this? Should Mahara be setting itself up to be an LRS that supports the Experience API standards? Or are the Open Badges standards open, and could Mahara support the storage and display of badges?

Thanks to Dr Chuck for sharing this post on the structure of badges – it helps, but I’m still not clear on just how ‘open’ the Open Badges concept is in terms of being underpinned by an open standard.

I don’t have any answers to these yet, in fact I’m still working through how these three projects interconnect – or don’t, as it would appear right now.

Would love to hear thoughts from anyone in any of these three areas who can add more light to the darkness.

7 thoughts on “Learning Repositories, Badges, Standards and Mahara

  1. My take on it is this.

    Badges can be useful in themselves and the existence of the Open Badges framework is just an extra. Note the metadata resides in the images themselves so that you can actually just put them anywhere you like (eg Twitter or in your blog).

    Mahara could certainly have a little extra code to be more aware of the metadata and act as a ‘backpack” destination for badges, which a user could embed in their portfolio. The Open Badges implementation in Moodle is already designed to make it easy for Moodle to push to other systems besides Backpack.

    Tin Can API, well I have trouble seeing the usefulness of it outside limited internal SCORM-type scenarios. It’s like a Moodle log, except without verification or a standard grammar.

    • Hi Martin,

      Not sure how much you’ve looked at the xAPI spec, it’s a little more than a Moodle log and the spec does offer standard data structures and a fairly narrow vocabulary. Usefulness is limited to implementation but I’ll mention a few use-cases that could be handy in the context of Moodle.

      1) Sometimes connected content reporting. VLE and LMS are not unlike a fortress. Log in, click, click again to find content, finish content, content reports finish. But this requires a connection at the beginning of the experience and a persistent connection throughout. The xAPI establishes a consistent protocol for communicating statements from devices and content that don’t originate (aren’t launched) from within the VLE or LMS. That doesn’t seem like limited usefulness to me.

      2) Version 1.0 of the spec will handle attached artifacts. In the context of Moodle and Mahara, a statement can be accompanied by a picture, a document, or other file that is directly associated with the Noun > Verb > Object structure of the statement. Sure, you can use a form to upload files to Moodle but Moodle’s process and workflow is different than every other system that also has its own workflow and process. Driving a standard for submission and association with an experience record doesn’t seem that useless to me.

      3) Moving beyond content to observed performance capture, live, where the work is being done. Think about an instructor in a classroom observing students performing tasks and providing feedback on those tasks. This feedback can manifest as video, audio, or text. As the instructor provides this feedback, a statement is generated through a device in the instructor’s possession – this statement is received and consumed by an LRS and becomes a part of the record for that student. The student can retrieve that feedback and review at a later date. It’s a digital footprint of something that happened in physical space. This doesn’t seem that useless to me:)

      These are all off-the-cuff examples of things that would enhance and expand the models we currently use to deliver and track learning experiences.

      • From my admittedly brief reading it feels more like a meta-standard to me … for example things like https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md#verb “The xAPI does not specify any particular Verbs”. It remains to be seen how this will work out among many manufacturers, and how a LRS can accurately make sense of disparate data “John finished watching a video, John completed a PhD”, while dealing with privacy, security etc, in a way that is really useful to those trying to understand what someone else actually knows.

        I totally understand the computer science zeal behind it but I’ve just seen too many standards evaporate to get excited about this one yet.

        However, it’s relatively simple for Moodle to produce activity streams in this format from its logs (for an external LRS) so we will most likely do that at some point soon and see how it gets used.

        • Hi Martin,

          An LRS doesn’t make sense of the data. The function of an LRS is to catch the data and supply that to other systems. Privacy is a concern and the spec does provide some framing for execution. It is a spec and the intent of the spec is to modularize interoperability in a way that (hopefully) will be flexible without being so floppy that it’s useless.

          Many of us are stuck in mindsets that tend towards:

          1) I own this system that provides activities that I specify
          2) I use mechanisms to assess completion of these activities that I specify
          3) I, and I alone, can judge whether or not someone is worthy of a grade based on the mechanisms I specify within the system I own.

          If that’s the thinking, I can see how xAPI would be seen as useless because it breaks that paradigm. We don’t need to understand what someone knows — we need to understand so much more than that. xAPI isn’t that answer, but I’m hopeful that it’s going to be a part of changing course to a greater awareness and adaptability.

  2. The integration of Open Badges into Moodle was the first step, and Mahara will be second according to the competition for which TotaraLMS received a grant to implement the functionality. Thus, Moodle would be the issuer of a badge and Mahara the displayer. See also http://docs.moodle.org/dev/openbadges for some initial user stories.

    Mahara is suited well to be a displayer of badges because learners can build up a repository of badges and then use them in various contexts. But it could also be an issuer, esp. if you don’t use another system for working with learners and the portfolio is your primary platform.

  3. Originally we wanted to have Moodle the issuer of badges and Mahara as the displayer. Now we’re planning to do both with both and also make Mahara a backpack provider as that seems a good fit. We’re waiting for Mozilla to make some more progress on federating backpacks before doing that work.

    I think the xAPI could be an interesting one to tie together with the OBI – we’re exploring it though I share some of Martin’s concerns, while there is a lot of noise around Tin Can, it’s still early days.

Comments are closed.