Yesterday’s posts on wikis and the semantic web were probably less constructive than they could have been. I was long on identifying the issues, and short on fixing the problems.

I stressed the importance of user experience, and in many cases the social networking sites already give us that, though I would love to see JP’s ‘graphic equaliser’ brought to life. Unfortunately existing sites give us a good user experience on their terms, inside of their walled garden. GapingVoid hit the nail on the head here, but it’s not just about making money, it’s about freedom to work together on our own terms rather than somebody else’s Ts&Cs.

I’ll (re)use some use cases to illustrate how things might work…

1. Planning the party – how do you get a dozen people in roughly the same place at the same time.. I still see the Wiki as a core to solving this problem. All that’s really needed is a place where everybody can contribute information like flight and mobile numbers so that it can be consolidated. Some kind of federated identity is clearly needed to get people through the door, and maybe OAuth provides a neat way of integrating with what people are using already if they’re not tooled up for OpenID, Information Cards or SAML. Secure syndication is clearly a problem, which is why everybody should have their own queue. Messaging as a Service (MaaS) based on AMQP gives us a way to do this. What happens to those messages? I think they become inputs to the ‘graphic equaliser’, which then throws them out in the user’s preferred modality (e.g. Fred just changed his flight details, I find out by  text to my mobile because I’ve told my system that I’m on the road without full fat net access).
2. ‘Bank 2.0’ – this is very similar to planning the party in that it’s all about creating puddles of knowledge to support decisions. Once again we see content aggregation, syndication, and customised consumption as the core requirements. In this case though there are many things about existing web technology, and in particular HTTP – a synchronous, unreliable protocol, that make things tough. For human decision support there might be some wiggle room on timeliness, but everybody wants accuracy. For automated decisions (e.g. algorithmic trading) things need to be as reliable as possible, and as fast as possible. Moving trades between systems, processing a settlement, sending a confirmation – these are all inherently asynchronous activities that ought to be reliable. Once again AMQP seems perfectly positioned to fit the bill, and once again some kind of MaaS looks like the solution for internal integration and external connectivity.

So, MaaS looks like the foundation here. In some ways I think these services will become like an inside out version of web hosting – a place to consume rather than a place to publish; though clearly we need both.