Location data is used quite a lot these days, developers use for example Google's geocoding webservice to validate if a keyed in address is valid or not. Business address locations are used in marketing and product definition exercises, true this is not new, business directories exist already for a long time, however it is the way how this data is used today. Instead of buying a directory book or CD, copying the data into an Excel to start "working" with it, new usage patterns emerge today from data exposed through an API.
API
A data API (or Application Programmers Interface) is the key to get access to these data sets. A developer writes software that calls the API from the supplier and pulls in the data. Note that some of the API's are more functional and others are more data oriented.- Functional API: Check if a given VAT number is valid within the EU: http://isvat.appspot.com/
- Data API: Get information from more than 1.2 million restaurants in the US via http://www.factual.com/data-apis/places/restaurants
Some API's are in between these two flavours.
Data + Context
Data on its own is rather dull however, when it is put to use within a specific context it becomes much more valuable. Consider a spell checker; the dictionary is just a series of words with the proper linguistic rules. However, when a dictionary is used in an editor, the text you write is corrected by the spell checker using the dictionaries. The editor is the software where your text provides the context.
Google uses wikipedia data to show you extra information when doing a search. In this example your search phrase is the context and the data is from wikipedia.
Business models
There seems to be two trends here; traditional companies that expose data API's or companies whose business is exposing data API's. The NY times has a data API (http://data.nytimes.com/) that exposes data about people, locations, organisations, etc. In fact, it's their data they used internally for a long time but shared with the world now. Factual.com is a company whose actual business is to acquire, curate and provide data.
Technology behind the API's
Technology wise, most of the data is only accessible via the API requiring an active internet connection. However, some data sets are also available as a download so you can use this on premise offline. The most common forms of API are REST and SOAP based although the latter is decreasing rapidly because it's much more bloat than the REST API's. Additionally REST API's are much more supported in the upcomming programming languages. The most used formats of the data API's are JSON and XML.
Monetization
Companies whose business is not to acquire, curate and sell data sets like factual.com, struggle with their business models. Should they provide their data for free or should they charge for it? Or perhaps they can sell it through data market places like Windows Azure Marketplace. Most companies brought their offers in some form on the internet as an attempt to gain market share in the digital world. Content oriented companies are considering to put their content online via a data API but they are scared about the cannibalisation effect it has on their current online or offline offering.
So at first it seems like a bad idea... or not? Exposing your content through API's results into a whole range of new customers that weren't interested in your product offerings before and it increases brand awareness. Let me explain these.
So at first it seems like a bad idea... or not? Exposing your content through API's results into a whole range of new customers that weren't interested in your product offerings before and it increases brand awareness. Let me explain these.
Let's take the example of a publisher. In the past they published books which is a form of product packaging where the author and publisher decided what goes in the book. Some customer of that book read it from cover to back, however, most only read parts of it (especially for reference material). When the company brings their content online, they pre-package it for customer segments and throw in a search experience as replacement (or addition) for the old table of content or index. Established customers that need lot's of the content are served, however in the long tail business model, there are lot's of other potential customers that need very little of the content and are willing to pay (smaller) amounts.
This is where API's come into place. First the customer can decide for themselves how they consume the content, i.e. they choose their own product packaging. Secondly they consume just enough and they don't pay for the excess. As content provider you can decide to open up parts of your content through the API's. As the new customers get more and more into your content they might even consider to buy a more premium product. And yes, some of the customers previously in the head (of the long tail) will go for the cheaper API product instead, however, this won't happen over night as they usually have your pre packaged products build into their business processes which they won't change immediately.
If you build your gateway through the API from your corporate site you will see a huge increase in traffic which will have a positive effect on your brand. You'll be considered innovative, a company that is evolving in today's internet economy.
Here's another good slideshow to accompany this article: http://www.slideshare.net/jmusser/open-api-ecosystem-overview-december-2010