We had a nice chat with Rich Seeley from SearchSOA a little while ago, all about the new 1.1 release of the WSO2 Registry. Rich wrote up the conversation in this article, but he seems to have focused a bit too narrowly on the "triples" aspect. :)
It looks like Rich conflated our discussion of the extension points in the Registry with the talk about associations. Not a truly egregious error, to be sure, but one that does mask some of what we're doing.
The extension points in the Registry are designed to enable serious customization in two ways - first, Filters/Handlers let you install interceptors that control the existing Registry behavior. For example, you can set it up so that whenever a put() matching certain conditions (let's say where the target URL matches "/pictures/*") occurs, a Handler can check that the size of the new resource is under a certain threshold before the put() is allowed to complete. Handlers are great for inserting custom governance rules, or for performing automated tasks triggered by normal Registry actions. We use these for our WSDL validation and auto-importing XSD Schemas that are imported from WSDLs or Schemas.
The second extension point is called Aspects, and using Aspects allows you to add new behavior beyond the standard put/get/delete and our various built-in community features. The out-of-the-box example we have for this is Lifecycles, where we let you configure a chain of states and, optionally, conditions which control the transition from state to state. The Lifecyle aspect adds the "promote" and "demote" actions to any resource which has a Lifecycle associated with it. But Aspects can be used to make any arbitrary behavior occur, so for instance spell-checking, triggering an external build process, sending email to someone, etc...
So, we also do of course now support arbitrarily typed associations, so you can say stuff like "document D1 references service S1" (this might be documentation for a Web service) or "picture foo.jpg is-a-photo-of http://glendaniels.blogspot.com". These are the actual triples, and they do represent what are essentially subject-verb-object relationships. The subjects are always Registry resources in our world, the relationship types are arbitrary strings (which may, and probably should, be URLs), and the objects (or "targets") are either relative URLs from the Registry root, in which case they are other resources in the Registry, or absolute URLs in which case they point to Web resources.
The important takeaway here is that our extension model isn't entirely built on the triple system. Triples are just one way you can use the Registry to build out a network of behaviors and relationships that best reflects your particular set of data.