Namespaces


Background

In June, 2010 a thread on the mailing list started by Martin Atkin proposed that we abandon the previous approach of URI-based verbs and object-types and migrated instead to a keyword registry. This thinking was further supported by Joe Gregorio's post on Distributed Extensibility (in sum, it doesn't work).

The outcome

As a result of the discussion, it was determined that ActivityStreams would not use URIs for extensibility, and would instead rely on a centralized registry, maintained at activitystrea.ms.

What this means

For the most part, this will mean that the core ActivityStreams schema will be simpler and easier to read, reducing friction and potential confusion for implementors and people who arrive at this work out of context.

Instead of seeing lengthy URIs like http://activitystrea.ms/schema/1.0/post in activity feeds, you'll now just see "post". 

We also decided against setting a base URI at the root of the feed, again, choosing to rely on a registry of pre-defined and meaningful keywords (though the keywords themselves need not be semantically significant).

How ActivityStreams verbs and objects can be extended

Using this keyword approach means that URI-like strings are still valid verb and object-types, they're just not the form that "official" types will come in.

So, if Company X wants to create its own set of verbs and objects without following the ActivityStreams Process (thus without worrying about interoperability) they can still use the fundamental format and serialization of ActivityStreams, but with their own verbs and object-types, ideally in a form like this: 

 

To ActivityStream parsers, these URLs will just be treated as foreign or unrecognized strings — correctly. For Company X's partners, they can build in support for these strings in order to increase interoperability. 

Other Registries

Since the ActivityStreams registry is not currently set up, it's worth taking a look at existing registries to explore their approach: