Fri, 12 Jan 07

Combining distributed small tools as an alternative to Backpack et al

For a while now, I’ve been thinking/dreaming of having a number of very specific, distributed services. These would be no more than additions to the single purpose services we already use (notably, in my case, flickr for photos, this blog for articulating thought and for storing bookmarks). Some additions I’d like to see1 are:

Although I want to be able to record the transactions in some kind of accounting app, I also want each transaction to be a resource on the web that I can link to and bookmark (a RESTful accounts app if you like)

To be fair, a secondary blog could be set-up to do this.

Think - being able to bookmark the same uri multiple times in with different notes against each bookmark. Actually, I wonder why these sort of distributed comment systems are not more prevalent - it seems kinda odd that every blogging engine re-implements something that could be done once, and done well.

I think one immediate benefit of this is the ability to share emails with people in the same organisation/group as you without having to forward them all on.

So, how would having these types of services help us re-create a backpack type page at present?

Well, I’m not sure how good this example is, but let’s think of selling an item on ebay. At the moment, I end up with lots of distributed information about a single sale:

This is fine until you want to interrogate the data. Try finding out how much money you made/lost, when it was sent, who it was sent to, and the problems are obvious.

One solution would be to record all the information for a given item in a page in backpack (or any similar service - a simple wiki would do). But now try to query the data for two items sold, or partially query one item and the problems become evident again.

I think this is where our funky new distributed system can help. Following the same ebay selling process as above:

The important thing is that all of these resources are tagged with a common uri. The uri that represents our item for sale. At the simplest level, this makes auto-generating a backpack type page very simple - we just aggregate2 all of the data tagged with our item uri. Tagging these items with a higher level tag, such as ‘ebay’, will allow us to search across multiple sales/purchase.

Going even further, using opensearch with a simple custom front-end (basically just a parser) gives us even greater querying capabilities. I could imagine searching for something like “ebay finance:expenditure” to get a list of all items (descriptions, notes, pictures etc) we’ve sold on ebay along with our expenditure. Our simple search engine would know to search for all items tagged with ebay, but only those transactions that are tagged with expenditure (i.e. costs to us).

Does this make sense/sound feasible to anyone else? Indeed, has someone else already presented these ideas in a more legible/understandable way? It all seems to make great sense to me but I’ve spent quite a while thinking about it (and what seems like ages just writing this post), meaning there’s every chance I’ve missed something obvious. I’d appreciate any thoughts.

1 I did had every intention of developing these things as a proof of concept, but, on the basis that I'm unlikely to get around to it, and that I do actually think something like this is a good idea, I thought I'd jot my thoughts here.

2 I started out thinking that the tags would be stored against the resource itself - the same way that the tag for a photo in flickr is stored against that photo. I was also assuming that these services would be opensearch enabled to allow searching of the tags. As I've been writing the post I've realised that, providing everything has a uri, we can use as our tagging mechanism and as our search engine.