What's Up with Verbs in .95?

The 0.95 spec is complete; you can grab a copy here if you would like to read it. I recommend it with a cup of hot chocolate by the fire, kinda… If you’re into warm stuff and cold hard specifications.
The 0.9 version of the spec had a closed list of verbs that mimicked SCORM functions. Mostly things that courses typically do in LMSs. The verbs available to describe what a person did were experienced, attended, attempted, completed, passed, failed, answered, interacted, imported, created, shared, and voided. The great part about having so many early adopters from so many types of applications: there was loud and clear feedback about some changes needed in how we could use verbs. “Searched” isn’t there, “posted” isn’t there, “watched, read…” The list was hard to work with.

This feedback was vital to the evolution of the spec. The point of xAPI is not just to generate a pile of similar data, but to get meaningful data that can be widely understood and is valuable to those creating learning experiences and supporting performance.
Open verbs are a big deal
The big, big change in the 0.95 spec is that verbs are now open. You can use any verb, and in using a new verb you’re taking on some responsibility. For each new verb you must define what it means. Each time it’s used in a statement you have to point to that definition (with a URI – Uniform Resource Identifier). This way, when another system receives statements from your application, that system can make sense of your statements.
The good is news is that there has been some groundwork laid for you. The verbs that were in the 0.9 spec have become ‘reserved verbs’ and live in the spec’s Companion Document. These are the only ways that these verbs can be defined. Since xAPI was born of the Activity Streams specification, you can also use their verb registry for your statements without having to define that verb and host the definition yourself. Though, the Activity Streams page does not include URIs for the verbs, a work around is discussed in this message.
Use verbs smartly!
Now, this is definitely not part of the spec, but in the interest of everyone building tools that make data which creates greater value to bigger ecosystem, imagine if everyone decided to use the verb “enter” and defined it differently:
Interaction 1. Enter is to type text in a field
Interaction 2. Enter is to physically walk into a learning space
Interaction 3. Enter is to log in to an online learning space (webinar, course, meeting, etc)
Interaction 4. Enter is to transcend time and space arriving in a new dimension

Each of these could be valid meanings for enter in a specific context. The goal is not to find one ultimate definition for what the word itself means. The goal is to explain what enter means in the application’s context. Pointing to that explanation helps others understand what is valuable about the actor having entered the object.
Now imagine each of these applications are sharing these statements among different LRSs. Every time an ‘enter’ statement comes in with a new URI, the LRS’s reporting interface needs to go check that definition to see if it knows of it. If it doesn’t know what that is, likely, a person needs to tell the machine what to do with it. If we all are using different URIs for the same definitions, this creates much more work than it saves. Imagine this on a large scale 30,000 statements coming in with 5,000 unknown meanings. This is a quick way to data that is absolutely unusable and adds a lot of “transactional weight” to the system.
Verbs need to be an open conversation.
I have more good news!! We’re already a tight community and we scale well. Look at how we’ve grown in the last 6 months.
If the companion document and activity streams registry don’t have the right verb for you, put a call out to the community and ask if someone has used that verb yet or if they have suggestion for a similar existing definition that you can point to. If someone has, point to their definition. If no one has used the verb, then when you define it, let everyone know where it is so they can use it. The more we can share and point to common definitions of meaning, the stronger all of our work will be.
ADL also has planned to build an open source verb registry, once that is ready it will take care of a lot of this. Until that’s ready, let’s keep the conversation going.
Results and extensions need to be defined, too. 
Everything I’m writing about verbs also applies to results and extensions: one needs to define what the result or extension is and point to where the definition is.
I have some more thoughts on how we should use context libraries to help communities of practice use common sets of verbs, results, and extensions for the exact same reason discussed above. There is an in-depth post to be had there, but for now? Define things well so that your data will be useful to everyone.