Summary
As APIs proliferate, the opportunities for reuse don't multiply nearly as fast because their semantics don't neatly align. Standards could solve this problem, but they're too hard to be practical. We need another way. XDI is aiming to solve this problem in the long term. Rules are a practical answer to this problem today.
Yesterday Matt Asay had an article in ReadWriteWeb entitled Why The Quantified Self Needs A Monopoly. At least three different people brought it to my attention. Their reactions can be characterized as confusion and disbelief.
Matt identifies a problem: we have lots of ways of tracking our health and fitness data, but "no one is yet doing a great job of synthesizing them." Of course, this isn't just true of health and fitness data, it's true of nearly every connected device on the planet. They all feed data into their silo.
Matt's solution is what has people scratching their heads:
The first company to effectively bring together all this disparate data into one app is going to win. Yet it's an open question whether such a victory actually means defeat, given privacy concerns and the potential for abuse of such invasive intelligence about our health (or lack thereof).
It's a valid concern, but not one that I suspect many of us would heed as we throw our data willy-nilly into apps. We want health more than we want privacy. Some even make their health data public in order to goad themselves into hitting their goals:...
While most people don't tweet their weight, I suspect many, if not most of us will happily trade privacy in return for more powerful tools to improve our health. And if it works, ironically, we'll likely become even less inhibited about publicly sharing our health data, as we show off the weight we're losing, the times we're hitting on our rides, etc.
But first we need someone to win the race to aggregating the data behind our quantified selves. And we need it now.
From Why The Quantified Self Needs A Monopoly—ReadWrite
Referenced Tue Aug 06 2013 10:13:25 GMT-0600 (MDT)
Matt's taking a short cut to a solution, but he's spot on with respect to the way humans traditionally solve these problems. The right answer is a decentralized solution based on standards. The easy answer is a centralized solution based on a single powerful player—hence Matt's call for a monopoly.
The decentralized approach is fraught with effort and prone to missteps that can lead to failure. Solving a problem like the one Matt brings up in a distributed way is hard because it requires cooperation and non-market forces (in many cases). APIs alone can't do the job because no one is making them consistent. Each company is deciding on it's own. There are typically two solutions to this problem:
- De jure standards—go to OASIS, start a standard body, work like hell for years with no recognition and lots of slings and arrows, hope that someone adopts them.
- De facto standards—be so big that everyone must adhere to your standard or be first and so clever that everyone who comes along later adheres because doing anything else would be stupid.
Matt's ultimately arguing for the second of these options (assuming some benevolence on the part of the monopoly). And practically speaking, given these two choices, that's probably the only thing that will solve this problem. De jure standards are really hard.
This is the problem Tim Berners-Lee (TBL) was trying to solve when he proposed the semantic web. TBL was proposing a third way that didn't require de facto or de jure standards. Rather there would be a way to connect the APIs together after the fact—at run time rather than at compile time, as it were.
I'm on the Oasis XDI TC, which is working on the XDI standard. In a way XDI is a meta-standard since it's got semantic interchange at its heart. The goal, eventually, is to dynamically link disparate APIs together merely (ha!) by providing a semantic map between the concepts in the API and some common semantics.
In a world of semantic data interchange, you could bring the Endomondo, Fitbit, and Strava APIs together by mapping the concepts behind their syntax to a common health data dictionary. Do the mapping and then applications can take interact with any of them, at run time, through the mapping. This isn't a simple solution, but as far as I can tell, it's the only solution that doesn't require that we negotiate for years on every subject or give ourselves to monopoly players.
In the meantime, I'm working on using maps in the form of rulesets to translate semantic concepts. For example, I wrote earlier about my experiment to link together my Philips Hue lights and my Insteon-controlled lights. This provides a real, practical way of solving the problem of semantic data interchange now. Rules embody semantic translations that create opportunities for more dynamic, emergent, and loosely-coupled interactions.
