If you want consistent xAPI data, then having processes and rules is critical. They provide a baseline so everyone in your organization knows what’s right and what’s wrong when it comes to data structures, formats, and vocabulary. In this xAPI Governance blog post, we explore the importance of rules and processes and how you can implement them.
Rules help control the fun.
Monica Geller phrased it best in Friends when she said, “Guys, rules are good! Rules help control the fun!” And that sentiment applies to rules around your xAPI data.
In a moment we’ll look at these rules and processes, including examples. But, before we do that, let me emphasize that the exact rules aren’t as important as simply having rules in the first place.
For example, one organization might have a rule that all activity IDs always use lowercase letters, while another organization might have a rule to only use uppercase letters. You could argue the pros and cons of using uppercase versus lowercase letters—but either option is fine because both organizations have more consistent data compared to an organization with no clear rules (e.g. uses upper and lowercase letters).
In other words, simply having a rule that you stick to—whatever the rule states—is a benefit in itself.
How do I create xAPI rules?
Create a set of rules for every type of identifier you define, including:
- activity IDs,
- activity types,
- verbs, and
You also can define rules around using xAPI statement properties. For instance, you might specify the timestamp property should always be populated by whatever is generating the xAPI statement, rather than leaving the LRS to fill in that information. Otherwise, the LRS will populate the property with the time when the data is stored, which may not be when the event or experience actually happened.
As a worked example, let’s explore three rules you might apply to Activity IDs.
1) Always use lowercase letters.
In xAPI, versions of an identifier that use different forms of capitalization are considered totally separate. For example, these identifiers represent separate courses:
To avoid confusion around capitalization, define easy-to-remember rules that apply to capitalization—such as, “Always use lowercase letters when defining identifiers.”
Note: Don’t change the identifiers that already use previously defined URIs, even if they break your new capitalization rules. Otherwise, you risk causing the very inconsistency problem you’re trying to avoid.
2) Always use https:// for identifiers.
In a similar way, identifiers starting with http:// are considered totally separate from those starting with https://. For example, these identifiers represent separate courses:
To avoid confusion, create a rule around only using one of the following for starting identifiers:
NOTE: Some authoring tools don’t give you a choice between using http and https for your course ID, so you may need to define those courses as an exception to the rule.
3) Follow a specific pattern.
To help avoid duplicate identifiers, define a set structure for IDs, such as:
https://<org domain>/<department>/<course id>
This practice is helpful when multiple departments across an organization define activity IDs. For example, it might make sense to include a department ID as part of the activity ID. That way, each department can maintain their own lists of activity IDs without the risk of conflicting with another department's IDs.
TIP: Try creating an application or spreadsheet that automatically generates good activity IDs for your content authors.
What about xAPI processes?
In addition to rules, having processes is just as helpful for maintaining consistency. Processes are actions or steps you take when designing your xAPI data or integrating a new data source into your learning ecosystem.
Two examples of processes are:
- Each department maintains a list of their activity IDs currently in use to avoid reusing the same ID for multiple things (i.e. anything that can be part of an xAPI statement, including any type of learning or non-learning experience or artifact). Assigning unique department IDs means that other departments won't ever have an ID that conflicts with another department’s identifier—which further supports maintaining consistent xAPI data.
- Before defining new verbs, activity types, and extensions, check The xAPI Registry and the xAPI Vocabulary & Profile Index for existing identifiers. This helps you build identifiers from what’s already been defined, rather than creating something from scratch. This also helps avoid duplicating verbs, activity types, and extensions so you have consistent data across multiple data sources.
Roads? Where we’re going, we do need roads.
You might be thinking, “I can see how rules and processes are important in large organizations. For a one-person L&D team, though—where I’m the only one doing xAPI—that’s just overkill.”
However, whether you’re a team of one or many, you will benefit from having clear rules and processes. First, they help ensure consistency over time (e.g. not using a completed verb one month, and then using a different verb the following month). And second, rules and processes help when training new team members or successors.
Up Next: xAPI Documentation (Part 3)
Do you know why it’s important to have good documentation when it comes to your xAPI statements? Find out in our next post, as we explain what you should document and how to get started.
NOTE: Friends and Back to the Future are used here only to illustrate the examples in this blog post. Watershed is not associated with, sponsored by, or affiliated with Warner Bros. Television or Universal Pictures.
About the author
As one of the authors of xAPI, Andrew Downes has years of expertise in data-driven learning design. With a background in instructional design and development, he’s well versed in creating learning experiences and platforms in corporate and academic environments.
Subscribe to our blog