One concept, many representations

A pattern has emerged over the last year. The same object is described by multiple services.

Checkins

The first time this issue came up was in the description of a venue for the location check-in service at shizzow.com. The same cafe was place #12 at shizzow, and place #44 at foursquare.com and place #321 at gowalla.com.

Food Carts

The next time this pattern emerged is when foodcartpages.com was being built. Here is a wiki page for each food cart in Portland. There are other fine services that exist to catalog food carts in portland. This service is uniquely accessible and supports details of a cart that noone else does.

Beer

Portland loves its beer. While working on the taplister.com mobile app for Android, the notion of the 'authoritative' record to describe a single beer came up. There are national-size beer databases that do very well at capturing a percentage of all beers made.

Approaches

Two approaches that have come up so far are the commons and layering

The Commons

The commons is a centralized document store, with wiki-style access control, and an easy to use RESTful interface. . Other players would have to see the value in such a commons to be motivated to use it. By document store, i mean in the no-sql sense. A record is a json blob that can contain whatever keys and values the last author felt was important. There would be some keys that become a defacto standard.

Layering

With check-in venues as an example, a record for Bob's cafe on foursquare would have some number of links to the same venue in other services. The client that started with the venue description from a particular service, could retrieve the other records and composite them into a fuller description of the venue.