xAPI Data Governance: Processes & Rules

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
• extensions.

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:

• https://example.com/mycourse
• https://example.com/MyCourse

To avoid confusion around capitalization, define easy-to-remember rules that apply to capitalization—such as, “Always use lowercase letters when defining identifiers.”

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:

• https://example.com/mycourse
• http://example.com/mycourse

To avoid confusion, create a rule around only using one of the following for starting identifiers:

• http://
• https://

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.

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:

1. 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.
2. 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.