Twine,, and event-driven service integration

Last week on Interviews with Innovators I spoke with Nova Spivack about Twine, a service that’s been variously described as the first mainstream semantic web application and “just 2.0”. You’ll find support for both points of view in my conversation with Nova. It’s true that, unlike and other comparable services, Twine is built squarely on top of what Nova calls a “semantic web stack.” But it’s hard to discern, in Twine’s current incarnation, just what that entails.

One of the bookmarks I imported into Twine, for example, is It’s the home page for an organization called the Higher Education Bridge Certification Authority (HEBCA). In Twine, the item shows up tagged as an Organization. That’s the kind of thing that you’d expect a semantically-aware service to do. But what does it mean for Twine to classify HEBCA as an Organization? It’s unclear. Here’s the offered link. It points to a small collection of items that mention HEBCA, but Twine does not “know” anything at all about HEBCA.

What our conversation revealed, though, is that my method of testing Twine — which involved importing all my bookmarks — was flawed. I had assumed, incorrectly, that Twine would absorb the bookmarked pages themselves. It will, but it doesn’t yet, currently it only aborbs the metadata such as title and link. If you want to find out what Twine’s linguistic and semantic analysis can do, you need to pump content into the system.

That’s easier said than done. The only API available for content injection is email. Twine materializes a private email address to which you can send items you want to post as private notes.

I spent a few minutes thinking about writing a script to automate the injection of items I bookmark on It’s doable, of course, but only by dint of hackery that I would undertake grudgingly and normal folks would never imagine or attempt.

This kind of integration will get a whole lot easier for everyone when the various services export events representing our actions within them. For example, a couple of weeks ago I reorganized my tagspace, adding the tag socialinformationmanagement to a group of otherwise-tagged items in order to emphasize that particular facet. And I tweeted:

Imagining new kind of FriendFeed event: “Jon Udell updated 9 bookmarks, adding the tag socialinformationmanagement”

In other words, when I perform a public action in some service — like bookmarking an item in, or even just retagging an existing item — the service posts an event on a topic to which other interested services subscribe. In this case, FriendFeed is the interested service. When I configure FriendFeed to monitor my account, it asks for the list of event types that it exports, and I choose which of those to display in FriendFeed.

Of course FriendFeed needn’t be only an event subscriber. It can and should be a publisher too. Another service should be able to ask FriendFeed for the list of event types it aggregates for me — bookmarking an item on, posting a photo on Flickr, adding a book to my LibraryThing library — and then subscribe to all or just some of those events.

(While we’re at it, I want a service that can not only subscribe to my aggregated event feed, but also take actions. One of the actions I’d configure would be: When Jon bookmarks a new item on, fetch the item and inject it into Twine using the specified secret email address.)

Of course there’s nothing new here with respect to basic change notification. has been doing that in the blog realm for many years. Now it’s time to generalize the mechanism across the range of services that manage various aspects of our online lives.

Posted in Uncategorized

10 thoughts on “Twine,, and event-driven service integration

  1. This is topical; yesterday I saw OpenCongress’s “My Political Notebook” and was thinking along similar lines–the last thing I want is another bookmarklet and another place to store stuff.

    I like the “event topic” model, but wonder if it wouldn’t get stalled on trying to articulate an event model? I’ve kind of thought you could drive a lot of things just from bookmarks with smart tagging strategies.

  2. The event monitoring does not need necessarily to happen at the data provider’s side (, but can easily take place on the consumer’s platform (FriendFeed), by filtering for specific events recorded on the incoming RSS feed.

  3. > The event monitoring does not need
    > necessarily to happen at the data
    > provider’s side

    Agreed. On this point, I love this Roy Fielding article:

    Pushing back against the prevalent notion that REST-style polling fails for large-scale event notification, he shows how appropriate resource design — e.g. a bitmap representation of the global state of all Flickr accounts — would enable producers and consumers to share the work in a smart way.

  4. > I’ve kind of thought you could drive a lot
    > of things just from bookmarks
    > with smart tagging strategies.

    Indeed you can, way more than is commonly appreciated. But there’s no practical way to subscribe to near-realtime notification of events in or other services.

    I actually like Roy’s idea a lot. No new protocols, just highly efficient representations of events that anybody can fetch and analyze.

  5. There is a service (in beta) that aims to do what you describe – it’s at

    Unfortunately it needs your credentials for the services you want to orchestrate – most of them do not support Oauth (yet).

    (BTW John I commented this yesterday as well but my comment never got out of the spam/moderation queue – I hope it will now)

  6. gnip provides something close to what you describe.

    They will push bookmark events to subscribers in near real-time based on user (actor) or tag filters. Subscribers can also poll for events up to 60 minutes ago. I don’t think they have tagging events yet.

    They also offer public actions from other providers, such as flickr, digg, twitter and others.

Leave a Reply to Joe GermuskaCancel reply