One of the fuzziest concepts in xAPI is statement registrations. Statement Registrations are designed to meet the needs of existing registration concepts. When they’re used in other situations, it’s not always clear when to set registration to different values or what its meaning is. Most applications of Statement Registrations are for loose statement grouping in ways that feel natural to implementers, and for the most part, that’s worked out well. In the xAPI Profile Specification’s very first draft, we intended to use registration more strictly, as a way to determine what statements are part of the same machine-readable patterns for tools to analyze and verify.

Once we got into the details, we realized registration alone wasn’t enough to accomplish our goals.

What are things people use statement registrations for now?

Currently, registrations usually identify something like a session — a group of statements that go together, but in a way that doesn’t have a natural identifier, so a random or ad hoc identifier makes sense instead. Registration can be used as part of storing and retrieving xAPI document resources, so it makes sense to use the same registration in contexts where the same document resources should be used.

What happens if the same statement is used in multiple profiles?

This is good! The xAPI Profile specification is written to encourage this, making it easier to create profiles that refine and remix with other profiles. So long as a statement follows the rules for all applicable profiles, just put all the profiles in the category context activities and everything will work together.

What happens if the same profile pattern is implemented multiple times for different activities (or the same activity)?

Here’s a wrinkle. Let’s say a person takes an eLearning course, and the course contains two videos. Current practice and one we want to encourage is put the same registration on all statements.

First question you might have is, “How do we distinguish the two video segments — their patterns — when they have the same registration?” You might also ask, “Do we require different registrations?” These are open questions, and without a good answer, it will be difficult to ensure tools match profile patterns to actual statements consistently. In some circumstances there will be ambiguities for which there won’t be easily defined, consistent rules.

This gets even more complicated with how the an authoring tool like gomo (and maybe others) allows you to embed an entire eLearning course onto a slide of yet another eLearning course. You could therefore potentially have multiple versions of the same pattern, running at the same time, with the same registration.

What are our options?

Do we limit or constrain a registration to one pattern per profile at a time?

One option is to give up the property we were hoping for above and require the registration be changed for statements within one session/launch-like grouping when a new pattern needs to be presented… but this makes it harder to layer profiles together, breaks existing paradigms already being used to understand xAPI data, and is generally dissatisfying.

Do we use arrays for multiple statement registrations?

Basically, do we change how statement registrations work entirely? Unless there’s no alternative, we don’t want to propose this, especially as in numerous cases how registrations already work is perfect for profiles.

Do we rely on “punctuating statements?”

In this scenario, we restrict what patterns can look like so the statement templates we see at the ‘start’ and ‘end’ are exclusive with each other and with the statement templates in the ‘middle’ (for multi statement patterns), guaranteeing processing systems can consistently tell when a new pattern starts in a single registration. This meets most of the requirements most of the time, but in the case where someone could be going through the same profile’s pattern interleaved (such as moving back and forth between two videos in a module), it won’t work.

Do we come up with a new extension?

We could use registration to differentiate groupings of statements in simple cases where there are no instances of things within things (videos in eLearning courses), with a context extension describing statement registrations within the main registration that could be used to differentiate between patterns involving things that are within other things. This workaround wouldn’t break the current spec.

Do we invent the concept of “sub-registrations?”

So, let’s propose how we’d use a new context extension to give us the ability to distinguish which statements are part of the same profile patterns. Let’s assert…

1. Statement registrations must still be used.
2. When only one profile or only one pattern occurrence of each profile will be used, only statement registrations SHOULD be used.
3. The context extension to be used (MUST for multiple pattern occurrences, MAY for single pattern occurrences) to clarify “sub-registrations” (probably not the term we want to use but works for now) looks like:

[
  {
    "profile": "http://example.org/profile/1",
    "subregistration": "insert uuid here"
   },
   {
    "profile": "http://example.org/profile/2",
    "subregistration": "another uuid here"
   }
]

This enables a single statement to adhere to multiple profiles.

This even enables (potentially) a statement to be in multiple patterns for the same profile at once, which means it is possible to

• unambiguously distinguish how statements align with patterns,
• identify statements that are constructed incorrectly according to those patterns,
• identify partial sent patterns with missing statements,
• et cetera.

Additionally, if an authoring tool is profile-enabled, it should be able to add this extension automatically — not just to already included statements, but even to author-specified statements — all without the author needing to manage it directly, which keeps complications to a minimum. Similarly, it should be possible for programmers creating custom profile-related code to use programming libraries that manage the extension directly.
The only dissatisfying aspects of this approach will be

1. In some cases it requires an extension, and
2. This is not a general mechanism for extending statement registrations, as it is specific to profiles. It may be possible to make it more general, though.

Your thoughts?