Tim O’Reilly has often asked a good question: seeing as my phone and email
know who I communicate with, my company directory knows who I work with,
and Amazon knows who has written books for my company, why can’t these
various things somehow combine to automatically deal with friend requests
coming from social networks?
This specific problem is just one example of a wider issue. Given that so
much diverse and overlapping information about each of us is spread between
many applications, why are seemingly simple things based on combinations of
information — like automatically reacting to known friend requests — still
not possible?
Tim summarizes this by asking “Where is the web 2.0 address book?“
The traditional reaction to Tim’s need would be to begin work on the design
of a new application to provide the suggested features. This might give
rise to an online social address book incorporating his specific
suggestions, along with anything else the application designers might dream
up to provide additional functionality.
While such an application might be cool and work well in the short term, I
believe that approach is doomed to failure. The main reason is that we
can’t anticipate the future. Baking decisions about what to support or not
into applications is almost certain to leave us wanting
and needing more. At that point we’re beholden to application designers’
willingness, priorities, and ability to further adapt.
What happens when Tim comes up with another idea, or when you or I do? While an application might be designed to be open — for example, by providing an API or a plugin
system — at the end of the day it’s just another application sitting in
front of its collection of data. This problem is particularly severe in our
specific case: Tim would ideally like the incorporation not just of his
phone’s data and his email, but specific information from the O’Reilly org
chart and from Amazon. That level of specificity — or personalization, if
you prefer — is well beyond the interests of anyone writing a general phone book application.
For these reasons, among others, I believe the traditional “let’s build a
cool new app” reaction to Tim’s dilemma is the wrong approach.
The other answer
An alternate answer begins with a sharp departure from this thinking. I
suggest that the Web 2.0 address book need not take the familiar shape of
an application. Instead, like a physical address book, it might be mainly
about the data. That is, centered in a common data store through which a
variety of loosely coupled applications interact with users and with one
another.
In such a world, a friend request to Tim would be added to a shared online
data store. There it would be noticed by an application running on a mobile
phone, a periodic script that scans Tim’s inbox, or an internal O’Reilly
script with access to the company’s staff list. Any application recognizing
the requesting user’s details could add information to the request object
to indicate recognition. The initiating application could detect this and
act on it.
Several aspects of this idealized scenario are worth close consideration:
- Such a system would require an underlying storage — a “data fabric”
as Tim has called it — that was shared not just for reading, but also for writing. The shared writable data fabric would be open to future applications. They could contribute or consume information as they saw fit, without requiring the permission of existing applications, possibly without knowing or caring about each other’s existence. Future applications would interact seamlessly with existing ones by simply following established data conventions. - While any application should able to join the fun and contribute, a permissions system would be needed to protect existing information and to selectively share it among authorized applications. For example, Tim might authorize an application on his phone to add information about numbers he has dialed or email addresses he has been in contact
with. He could authorize another application — in our case an automatic friend request resolver — to read that information and to create more information on his behalf to indicate existing friendships. - This data-centric answer to the “Where is the web 2.0 address book?” question points to a wide class of future applications which cooperate and interact not through synchronous pre-ordained API calls, but via asynchronous data protocols which follow open-ended conventions. This is in strong contrast to applications which hold information in databases with relatively inflexible structure behind APIs that strictly delimit possible interactions. Applications using a shared writable data storage can adopt conventions and data protocols by which they cooperate to achieve joint actions. Applications that operate in this way leave the door open for new conventions, for additional unanticipated data, and for future applications that adopt the existing conventions, or introduce new ones.
At Fluidinfo we’re building a shared online “cloud” data system, called FluidDB, with the characteristics outlined above. FluidDB aims to usher in a new class of applications, as described above, in which data can be
thought of as being social. The data allows diverse
applications to interoperate and communicate asynchronously using shared
conventions. [Disclosure: Tim O’Reilly is an investor in FluidInfo.]
In FluidDB, all objects may have information added to them by anyone or any application at any time — with no questions asked. Whereas a more traditional approach locks down entire database objects, FluidDB has a simple and flexible permissions system that operates at the level of the tags that comprise objects. Objects are always writable, including by future applications and by idiosyncratic applications that know, for
example, how to access the O’Reilly staff list.
To put things in a more general light, Tim’s “How ridiculous is this?” complaint (see image, below) is symptomatic of a wider problem. It highlights the awkwardness of a computational world in which applications keep their data behind UIs and APIs that are designed for specific purposes. These prevent augmentation, sharing and search, and they ultimately prove inflexible. It is ridiculous that even simple operations combining information in obvious ways are still beyond our reach.
Slide from Tim O’Reilly’s “What is Web 2.0?” presentation at Web 2.0 Expo Berlin 2007.
Relief does not lie in the direction of more applications holding more data behind more APIs. It lies instead in allowing related data to coexist in the same place. Both Google and Wikipedia have demonstrated, in very different ways, the massive value that accrues from co-locating related data. There’s a real need for a Wikipedia for data. Writable and with an
object for everything, like a wiki, but also with permissions, typed data, and a query language to make it more suitable for applications. Such a store can hold the data, the metadata, support search across these, and provide a locus for applications to communicate.
The Web 2.0 address book then becomes a ball of data, not an application. Something we access as we please, using a collection of tools that individually suit us, and without any application having the final word on what’s possible.
Related: