Scoping Out An Open Location Platform


I noted earlier today that it would be nice to have a kind of Open Location Platform in order to get the most out of the Social Location apps that have gained such interest and popularity as of late. The problem with all the existing applications and platforms is that they do not speak each other’s language, and thus cannot benefit from all the information that is being crowdsourced into their respective location repositories. All these applications have a different take on Social Location, attracting a specific, unique crowd. The challenge of an Open Location Platform would be not to lose the uniqueness of each of the existing platforms in the process of unifying the way in which places are searched for and posted. Ideally, the applications would not even have to do very much at all to benefit from an Open Location Platform.

The way I see an Open Location Platform is as a kind of API interfacing between the existing Social Location apps, a central repository of Places – in fact, I prefer the name Open Places Platform over Open Location Platform, for a Place is More Than A Location™ – and the proprietary Places Repositories that the apps maintain now.

A unique Place Identifier must be used to link the Places in the Central Repository – which I believe should be OpenStreetMap, because it has the infrastructure set up and would benefit from the crowdsourcing from all these unique Social Location platforms – to the Places in the proprietary, existing repositories.

The initial assignment of unique Place Identifiers is not really straightforward: there’s bound to be a lot of duplicates, even within the existing repositories, and removing duplicates inserted by humans is always a challenge. All unique Places should be collected in the OpenStreetMap database, and the Identifiers should be assigned there. Currently, every new node inserted is assigned an ID automatically, so that ID could easily be used.

Assuming this model is in place, we can start scoping out the basic operations: Searching for Places, Request Details for a Place, and Post a New Place.

Searching for Places

In a Social Location environment, it is safe to assume that search operations for known Places will be geographical, i.e. within a certain distance from the user’s current location, or within a certain area defined by a bounding box. A response to such a Places search would have to contain a minimal amount of information about each place found: geographical location, name, and something like a genre. That last bit might be troublesome, because it should be platform-agnostic. Either the Social Location platforms need to arrive at a shared taxonomy of ‘Place Genres’, or it should be left open, in the spirit of OpenStreetMap. I would opt for the former.

An actual search operation would thus not involve the proprietary Places Repos at all, because everything is stored in the Central Places Repo, OpenStreetMap – with those elementary nuggets of metadata on each Place to avoid unnecessary client-server round trips. Oh, as an added bonus, the location + name + Place Genre gives OpenStreetMap enough info to render it on their map. A Social Location application that uses OpenStreetMap as a base map layer would have the added benefit of up-to-date maps crowdsourced by their own users.

Request Details for a Place

The next step for a typical Social Location app would be to request more detailed information about one particular Place. Applications could still do this the way they are used to: requesting details directly from their own Places Repo using the their own interface or API. This way, however, the application would not be able to reap the real benefits of the Open Places Platform: firing one Place Details request at the Open Places Platform and getting results from all registered Places Repos, instead of just their own. This might not make much sense for the current Social Location apps, but a newer generation of apps could be crafted to make use of the Place information coming from different communities. In order to be able to process all this heterogenous Place information, some harmonization of Place metadata might be desirable.

To make a Place Details request more efficient, and maybe also to provide some indication of the expected information richness, an intermediate request might be implemented, in which the Application requests a list of Repos that have a record for the Place it intends to query. This could be a really fast request.

In a less-than-ideal-but-still-entirely-feasible scenario, one Social Location platform might not want the client of another platform benefiting from the information crowdsourced intro their Repo. This could be dealt with in a security and access provision layer.

Post A New Place

The posting of a new Place would by design be a two-step process, because the Place would have to be registered in the Central Repository, OpenStreetMap, first, and subsequently inserted into the proprietary Places Repo using the new unique Place Identifier returned by the Central Repo in step 1.

Conclusion

I think this could work. Really, it could.

Update – It’s About Business.

I spoke about this concept at WhereCampEU, which was in London on March 12-13, 2010. Slides are here (though most all of that is contained in this post). Wiki here.

The discussion that arose after the talk was very interesting and explored the business aspects of a consolidated check-in more thoroughly. I had thought about the incentive needed for the current social location platforms to want to engage in an effort to consolidate the check-in. The concept I laid out is meant to leave the existing platforms and their databases alone as much as possible. It is not meant to replace current apps either. It is designed to act as a thin intermediary layer, enabling users to gain optimal access to Places, while allowing the individual application platforms to retain the added value they accumulated. The only information about Places that is physically consolidated is the basic factual information: location, name, and Place type. That is not where the value is – the value is in the user generated content, which they retain and can choose to share but are, in the Open Places Platform scheme, in no way obliged to do.

The discussion raised the interesting point of conservatism inspired by venture capital. Steven Feldman, in another session at WhereCampEU, calculated the venture capital backing the social location business added up to around US$ 200 million already. As I am typing it, I wonder if I got that right. It’s a lot of money and the suppliers of that money will want to see some return on their investment – which they are not going to get if they’re going to start ‘opening up’ and ‘jeopardizing’ their assets: Places and Users. Because that is how short-sighted I think most venture capitalists are. So my new conclusion is: We Need A Different Name For This.

Update 5/20: And the story continues…without a happy ending!

8 thoughts on “Scoping Out An Open Location Platform

  1. Pingback: Scoping Out An Open Location Platform « oegeo Help

  2. Pingback: uberVU - social comments

  3. I definitely believe that this will work. Not only will it be beneficial for social location apps, they can also be used for any social app like Facebook, twitter, etc.

  4. Pingback: Tweets that mention Scoping Out An Open Location Platform « oegeo -- Topsy.com

  5. Would your idea result in different approach on building the API for location based applications. And would the company’s like FS, Gowalla etc be prepared to change their API ?

    • Yes, but not to a great extent. They would have to take into account that the UID for each Place would be assigned by an external entity, which also maintains the core metadata. Plus they would need to implement some really simple calls in their API to satisfy the requirements of the (thin) Open Places Platform. All in all the effort is not really in the API changes, but in the initial harmonization – assigning the initial UIDs and therewith weeding out duplicates across the existing platforms. And more than anything else, Foursquare and ‘friends’ would have to decide that there is more to gain in a consolidated check-in platform than there is to lose. Remember they are building their proprietary Places repositories on venture capital and their investors won’t like to see that valuable asset jeopardized. My answer to that would be that the most valuable asset is not the Places database, but happy users – targets for smart location based advertising. And happy users are users that don’t have to register with four different apps for their social location experience.

  6. Great article! I believe that is exactly the kind of system we need to prevent numerous ‘walled gardens’ of locations appearing with too much redundant data being entered by the communities. As you point out in your update it’s going against what the backers of the current geo-apps will want to happen, but it’s badly needed in the long term IMO.

    Perhaps the system should be created regardless. I think if the data has decent tags lots of apps would spring up around ‘pubs near you’, ‘nearby parks’ etc. Plus new geo-games could be kick-started more easily of course.

    What would you say the next steps are to making this happen though? Do you know of people willing to start off on this?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s