In game theory, a Nash equilibrium is a state in a two or more persons game in which no player has anything to gain by changing only his or her own strategy unilaterally.

Basically, when two players can’t or won’t coordinate (for lack of ability to communicate, luck of trust, whatever) and rely only on maximizing their immediate personal benefit, Nash has shown that there is always a state in such a game that is at equilibrium, meaning that none of the players, acting selfishly would want to change it (as it would reduce their payoff).

The very interesting thing about Nash equilibrium is that such state it’s not necessarily the one that maximizes the payoff that the players would obtain if they had coordinated.

One classic example of this is the so-called “prisoner’s dilemma“, a situation in which two prisoners can decide to be silent or betray the other and obtain different payoffs depending on their choice and the other persons’ choice, but without the ability to coordinate.

If both prisoners stay silent, they get 6 months, but if one stays silent while the other betrays, the betraying one goes free while the silent one goes to jail for 10 years. If both betray, they get 5 years each.

The best outcome is for both people to remain silent, but the selfish drive (and therefore what makes the ‘both silent’ state optimal but imbalanced) is to betray since even if the other betrays as well, 5 years is less than 10 (the situation where you trusted the other person to remain silent but he betrayed you).

It is worth nothing a few things here:

1. if the prisoners get 10 years in jail both if they both betray and if one gets betrayed while remaining silent, the ‘both silent’ state becomes both optimal and at Nash equilibrium.
2. we can therefore infer that the optimality and nash equilibria of a particular game are not only a function of its rules, but of its paybacks as well.

This means, at the very least, that Nash stability and optimality of non-coordinated strategies can be influenced by tuning the paybacks without altering the rules of the game.

Now, think of distributed and decentralized data modeling efforts as a non-cooperative game: the players involved that require to model their data for their own use will try to do so in a way that minimizes their effort and maximizes their benefit. If both modeled their data in the same way, they could reduce their data integration costs, if not their integration costs will be substantial. The problem is that it’s hard for the players to predict the cost of each integration and, most importantly, their need for a particular one, especially as the number of players grows large.

With absolutely no coordination, the only Nash equilibrium of such a system is the ‘babel’ state: everybody does their own thing.

On the other side of the spectrum, the state that would globally minimize integration costs for everybody (which is, everybody using precisely the same way to model data) is not at Nash equilibrium, as individuals would perceive that improving their immediate modeling needs would increase their (easy to predict) immediate payoff more than it would increase their (hard to predict) future integration costs.

Note how the above is basically saying that no matter how descriptive, complete, well-thought-out and encompassing your data model is, it’s usage won’t be at Nash equilibrium, which will naturally bring diversity, dialects and changes into its uncoordinated usage.

It is critically important to realize that this is *not* a function of the quality of the data model, but it’s a function of the difference in difficulty in predicting the immediate present benefit against the future integration ones. Thus, spending more time polishing the data model won’t make any difference in the outcome as it diverges to reach Nash equilibrium.

One of the things that irritates me the most about the semantic web and its advocates is the naive presumption that optimal states in non-coordinated data modeling systems are necessarily stable and therefore will happen naturally.

While this was the case for the web (where selfish decentralized activity brought both local improvements and global ones at the same time and it was therefore relatively easy to bootstrap), this is not the case for the semantic one; this fact is often called the “chicken and egg problem”.

Many (including myself) have tried over the last decade to solve this bootstrapping problem by forcing existing data to surface, hoping to catalyze activity and applications that would further push for more data to surface and for more applications to exist.

But one thing that I’ve come to realize recently is how surfacing data might not be enough to bootstrap an autonomous system if we don’t find a way to align the Nash equilibria and the optimal states of the distributed data modeling and integration game.

What this means in practice is that we must find a way to tweak the paybacks of the data integration game (which is clearly a non-zero-sum game) so that its Pareto optimal states are also at Nash equilibrium (a thing that the Prisoner’s Dilemma shows it’s far from granted).

I personally think that Exhibit and Potluck are the best examples out there of solutions that don’t specifically change the nature of the game but shift the paybacks, thus attempting to reduce the gap between Pareto optimal states and Nash balanced ones.

A lot more has to happen on the Potluck front, of course, being practically just paperware and a lot more has to happen about harvesting the collective intelligence of people using these tools, to further improve on their use and emerge data that could be useful to increase coordination and make it easier to predict integration costs.

We are still far from solving the bootsrapping problem, but one thing is clear in my mind: exposing a bunch of data as RDF (no matter how well inter-linked and how many URIs can be dereferenced as URLs) is not going to be enough without a deeper and more serious analysis of the socio-economical dynamics around data modeling and data integration.

“Build it and they will come”, this time, might not be enough.

A catalyst is an agent that affects the outcome of a process by providing a (normally alternative) mechanism involving a different execution path and lower activation energy.

This diagram (courtesy of Wikipedia), shows the concept visually.

Normally, you hear about catalysis in chemical or biochemical processes (also known as enzymes in the former realm) and they have a vital role there, but here I would like to draw the attention to the general notion of it: anything that “enables” things to happen, not because they are part of the result, but because they allow it to happen more easily (thus increasing its likelihood of success).

One type of catalyst that I talked about previously is a standard: here the catalytic action is created by separating the concerns and allowing independent evolution (while focusing coordination management costs).

But there is another type of catalyst that is often overlooked: the human one.

There is a general tendency to believe that things either happen or don’t depending on how good the starting idea is and how good its execution is. My experience tells me that the presence of one (or more) human catalysts is always a huge factor in the success (or failure) of any activity.

Then why is it that so very few organizations make such positions explicit in their management hierarchy?

Interesting debate between Joel Spolsky and web standard advocates (read, for example, Sam’s reply). This reminded me of a question that Mitch Baker asked on her blog about “standards and interoperability” that I had in my to-do list to answer.

Joel’s main point is that the “idealist road” on standards is a myth and that people will just see it as a bug, complain and downgrade (or switch to something else). He’s referring to the decision of the IE team to default IE8 rendering mode to “standard”, which will break many IE-specific functions that people did in the past to make web sites work with IE6 and IE7.

He explains the problem of interoperability in a “many to many” situation (many independent producers and many independent consumers) and concludes (my words) that decentralized environments plus entropy result in a mess and there is nothing you can do about it. You have to learn to deal with it.

And that is something I agree with.

Call it like you want (”browser wars”, “ontology harmonization”, “schema alignment”, etc) they are all various facets of the same problem: contract maintenance in a decentralized interoperability scenario.

To allow independent parties to work in parallel and without central control, you have to “separate their concerns” and you can’t do that if you don’t create/specify a “contract” between them that defines the way in which they need to interact.

Joel rightly explains that such “contracts” (a.k.a. “standards”) are inherently poor or incomplete in describing the bridge between two different concern islands.

The situation is bad enough when concerns and contracts are fixed in time, but it gets insanely complicated when such concerns and contracts need to be adjusted over time. “separation of concerns in motion”, we could call it.

The problem is a nasty one: because the “many to many” environment is completely decentralized, nobody has enough power to replace all three parts of the equation at the same time (consumer, producer and standard). This is, most of the time, a feature, allowing nobody to have enough control to tilt the power more on one side than the other.

But when the standard needs to evolve, even just slightly, you can’t do it without work on both sides.

This always reminds me of something that Ben told me years ago: you can’t craft lenses (thus polish glass) with a single abrasive powder, you need at least two different ones. Why? because no matter how fine and well operating, a single abrasive has specific properties and will create specific patterns on the surface. You won’t see the patterns but the result will be not perfectly smooth. Two different ones will likely remove each other patterns. The more different abrasives you use, the smoother the surface will become.

Which is why both email and the web are such an incredibly messy yet magnificently interoperable systems: their standards are constantly under the action of many different abrasive agents (on both sides of the production/consumption barrier), each one using the surface of interaction with the rest and therefore polishing it by usage/friction.

The result is incredibly polished (where for “polish” I mean “able to allow a huge variety of players on both the producer and consumer side of the interoperability equation”), but also incredibly inertial.

But here is where I think Joel’s analysis gets poor: he doesn’t consider the effect of feedback in the system.

Everybody that tried to build automatic controls knows very well that you can’t design a stable system without some sort of feedback. For interoperability systems, friction is the feedback (where for friction I mean “some interoperability breakdown that has overall negative impact on the system”).

Usage of the contact area between producers and consumers creates patterns, some good some bad. The bad ones cause friction to develop on that surface, both parties natural tendency is to change things to reduce such friction.

Note that this does not mean that the surface will ever be polished, but that there is a natural tendency to follow the “gradient of friction”. Also note how there is no coordination between the various players, so both sides will independently try to reduce friction, not necessarily resulting in a overall positive action.

Joel’s main point is that it’s better to look for a local minimum of that friction gradient, while his detractors are saying that it’s tolerable to “climb up” the friction gradient if getting out of this valley will result in a finding a lower minimum later.

Both sides are are just expressing their subjective views about the world and about their natural search algorithm in a complicated solution space: the first one could be called pragmatic and the second idealist; the first is always guarantee to find a local minimum, but it’s not guaranteed to obtain the best possible one, the second could achieve much better results but might take a long time to find it and sustain a higher level of friction in the meanwhile.

In a search space that is so complicated and has so many players, it is almost guaranteed that using a local optimization process for friction will not yield any long-term dramatic improvements. Joel justifies this saying that even in another (lower) friction minimum, there will still be friction anyway, so why bother.

The other camp doesn’t say that friction will go away, but that braver explorations of the solution space (ones that might actually *increase* friction in the short term) might lead to lower minima later.

Who is right? Which search algorithm do you subscribe to? Which one is optimal? And for whom? For the producers or for the consumers?

There are no objective answers for these questions (each individual had very specific ways they use to ‘explore’ solution spaces in search for an optimal one, it’s probably part of how they perceive the world), but there are things that one can extract from such a debate that are generally useful:

1. immovable standards fail to adapt to the friction feedback loop and therefore die and get replaced. In order for a standard to survive in a stable the system, it needs to continue to change. This is *very* counterintuitive, especially for the kind of people that enjoy working on standards. This disconnect between the mentality of the people that work on standards and its need to be easily evolved in order to survive is a constant source of trouble (see XHTML vs. HTML5, XSLT vs. CSS, WS-* vs. REST, just to name a few);
2. standards, themselves, don’t reduce any interoperability friction whatsoever: it’s the usage ecosystem they catalyze that ultimately polishes the contact surfaces and thus reduces the friction. Again, people that enjoy working on standards have a really hard time understanding this, mostly because they focus on improving the surface polish other than improve its catalytic factor (of which, normally, they know nothing and just stumble upon).
3. standards (and their maintenance efforts) should be judged for their ability to catalyze stable polishing activities around the contact surface rather than for the qualities of the surface they were meant to describe. A good polishing process with a rough surface will always end up more polished that a well polished surface with a poor polishing process around it. This is where claiming that Postel’s principle often leads to deployment problems feels like the fool that when pointed to the stars looks at the finger.
4. successful standards have a ‘good enough’ description of the interaction surface that first enables the catalysis between the separated concern areas and a ‘good enough’ evolution process that enables developed friction to polish the surface, even when scratches are created by its use from one side or the other. Improving the polish of the interaction surface won’t do any good to the standard if its evolution process is suboptimal.

In short, a standard is a process, not a specification.

Failing to express that makes most of Joel’s points moot, like judging a dancer by looking at a few pictures of her performance.