The Registry has been up for a few weeks. A number of people have created profiles and started using it to catalog their data types. It’s great!
There are a couple things here, and it really comes down to the fact that we’re looking to collect everything that’s being used. Looking at a collection of everything makes deciding what to use (and how to use it) a little more complicated, but in a good way.
Activity Streams IDs have been added
We just finished adding verbs and activity types from Activity Streams’ registry. You will notice a few duplicate terms between the ADL URIs and the Activity Streams URIs, this is not something to worry about. It’s part of the reason for why we built the registry, the terms that are duplicated have different identifiers and both already exist in statements out there. Meaning, we can’t pick one to show exclusively or change them. The best thing to do is to put them all into a place where you can easily find the identifiers and what they mean. This helps in making sense of the data, and it also helps people see all of their options when they are picking an identifier to use.
Using Activity Streams IDs
This leads into the second important thing. There are a number of entries with which we included a note about not using them in new xAPI statements, literally a “do not use” label. You’ll see those notes at the ends of the descriptions. It’s important to be complete for the purpose of data conversion, but because there are a number of differences between the xAPI and Activity Streams specifications, some of the identifiers from Activity Streams won’t make sense in a xAPI statement as they have been defined.
There are other entries that we didn’t go so far as to say “do not use,” but be cautious about how they will affect the structure of your statements if you do decide to use them. Take the activity type ‘comment.’ We wouldn’t expect comment to frequently be used as a xAPI activity type, but it could be. More often the text of a comment is going to go in results than be an activity itself. If the comment is the activity, each comment will have an ID (which is cumbersome and has to be created on the fly). This would be statements like “I posted <comment>.” The better route with comments is to make a statement like “I commented <comment> on <something>.” This really more about granularity. The question to ask yourself is: When using activity types from Activity Streams, first consider if they provide the desired level of granularity for the statement you’re making. Do you want a different identified activity for each instance of this object?
We’ve spent a lot of time figuring out how to encourage a working data ecosystem around these specs, enough time to make you laugh… or cringe. Getting statement structure right can be tricky, and we’re happy to help you. Just get in touch.
