What’s the difference between profile recipes and xAPI profiles?
Well, they essentially serve the same purpose. The difference primarily lies in the timeline.
Profile Recipes
A “profile recipe” was an early attempt to make it possible for members of the xAPI community to publicly share how they were implementing an information model for a given experience in the hopes that others with a similar experience could use the same model. With shared common models becoming more common, reporting tools targeting those shared models could be created. This provided a range of off the shelf tools for common experiences.
The “profile”, as it relates to the Registry, was intended as an abstract concept that allowed a user to “request” a namespace, under which they could track the items in their information model, and specifically, where they could link one or more recipes. It is associated with a particular label that is applied to the IRI (identifier), which is linked with a recipe that also acts as an Activity to be used in the context of statements. The first phase of implementation (and the only one, likely) of recipes allowed a user to input markdown description of how statements should be constructed. This is the primary difference between the two, with “xapi-authored-profiles” being more technical.
xAPI Profiles
An “xAPI profile” is a newer concept, created by ADL in a more formal way through their BAA process. An xAPI profile is more centered around the technical description of the information model captured via xAPI data.
The concept of a profile is itself codified as a specification for producing a JSON-LD document that can be leveraged by systems. Ultimately a profile is a JSON-LD document and associated references. These enable the building of systems so that any given profile could validate that the requests made to the LRS are in conformance with the profile, and therefore, can be guaranteed to capture the information model codified therein. It lays out specific requirements for both the data elements that must be captured in the various xAPI statements, as well as requirements for the order in which statements can be recorded. Profiles to date have been stored in GitHub (though there is no requirement for this), and will generally be created by a developer as they are more technical in nature requiring knowledge of the JSON-LD format.
Given their support by ADL and the increased technical rigor of an xAPI profile going forward, profiles are likely to be the primary manner in which the community captures shared information models. However, having said that, both concepts have seen slow (or low) adoption rates. In fact, currently, there aren’t any systems that have formally leveraged the profiles to do statement validation/rejection, or have been made generic enough to generate a reporting structure from them.
