Contact Us Get Email Updates
 
 

Thanks! Someone will be in touch with you shortly.

Rather just email us? Email us here.
Rather speak with someone in person?
Call any time with Tin Can questions:

866.497.2676

A Step Forward: The Registry

Posted by

Categories: Announcements, Best Practices, News, Standards, Statements, Tin Can

Posted 1 August 2013

 

Collectively, we could make a big mess of Tin Can data. Let’s try to avoid that.

At this point you likely know that Tin Can communicates activity data in the form of statements. Each statement is required to have some pieces like actor, verb and object. They also can include context, results, and authority. Within those pieces, highly specific, custom data can be added to communicate the circumstances and to clarify the importance of the activity. The types of custom data that need to be identified in a statement are activities, activity types, attachments, extensions, and verbs. To add those, each must be defined and given an identifier. The identifier needs to link to a place with information about it, like a definition. This means that anyone can define almost anything with one of the five types and include that in a statement.

What’s the mess?

Here’s an example. If a dozen people create their own identifiers with their own definitions of what the Tin Can verb “completed” means, then it quickly becomes difficult to know what the verb “completed” really means, in a Tin Can sense. Which one, out of the dozen, is the right one to use? If a reporting tool is built to treat data about “completed” activities in a certain way, it will rely on the identifier to know that a statement includes the “completed” verb. When there are a dozen identifiers for the same thing, a person will have to scrutinously monitor the data received in statements to manually add the new identifiers that mean the same thing, so the tool knows to look for them. This makes the data harder to work with and less interoperable. You can read more about this idea here.

The Tin Can API Registry

So, we built the Tin Can API Registry for the community to use. It’s a place where every piece of custom data that’s been used in a Tin Can statement can be stored, curated, and referenced.

If you want to use the “completed” verb, look it up in the Registry and see what its meaning is. If it’s the right verb for you, great! Use the Registry’s identifier for “completed” in your statement. If you see, from the definition, that “completed” isn’t the right verb for you, then search for another. Maybe “finished.” If you can’t find what you’re looking for, just add it. We’re curating the entries in the Registry for uniqueness and quality, when you add something we will review it and get you a permanently resolvable identifier to use.

Another feature of the Registry that is coming soon is profiles. We’re in the process of building profiles. Today, they are used to group activities. Soon, profiles will include all of the data types in the Registry to create collections of activities, activity types, attachments, extensions, and verbs that are used together in a specific way by a community of practice. The Registry will allow you to name your profile and pick the identifiers that are relevant. Soon you will get a home for your profile that displays these data types on one page to make it easy for others to craft statements that use these known identifiers. You can read more about profiles here.

Check out the Tin Can API Registry here, and let me know if you have any questions about it.

 
  • Ivan Ramos Pagnossin

    Hi, Megan. I was wandering how all these stuff about statements and Registry are related to schema.org and json-ld. Could you, please, give me some guidance?

  • Meganbowe

    Hi Ivan, good question! Tin Can statements use a particular format for describing actions and the registry catalogs identifiers that are used to describe those actions. Schema.org and json-ld have a similar purpose in that they are formats for describing ‘things’ on the internet, many of those things could be the objects of Tin Can statements. Borrowing from those formats to describe objects in Tin Can statements is entirely possible. We haven’t throughly explored further connections between statements & the registry to schema.org & json-ld but I have no doubt there are a lot of possibilities and I would love to hear your ideas on this.

Tin Can API Email Updates

* indicates required

Tin Can API Email Updates

Thanks for signing up for the Tin Can API newsletter!

Make sure to follow us on Twitter @ProjectTinCan,
and tweet this page to let others know about the Tin Can API.

Close