API of the Week : DBpedia API

If you were to ask me, I would say the twenty year old software engineer has a distinct advantage over the older telephone guys (such as me) in the realm of innovation.  Since the barriers to entry to deploying a service provider have fallen through the floor, the larger challenge is not in complex engineering, but is instead in innovation.   The younger engineers are free of the legacy of the PSTN, and many things would occur to an experienced engineer won't to them, and it's not a bad thing. 

For the benefit of everyone who actually remembers when Carter was president, I bring you the API of the week : DBPedia.  It's not in any way a telephony API, and that's my point.  A large number of innovative applications that use telephony will include APIs that have NOTHING to do with telephony.  The DBPedia API is an effort to put a Web Services API on top of the Internet's encylopedia.  With it, you can query Wikipedia from your application for structured answers such as "Tell me all of the authors born in Canada during 1954".  Essentially, it allows you to access all of Wikipedia's 1.6 million articles from your application, whatever that application might be.  You can learn more about it on the their site.

What does this have to do with telephony? Nothing. What does this have to do with next generation applications? Everything.  Applications that use the Internet as the platform use APIs from a large number of sources, and by and large, these APIs are not telephony. However, nearly every time a telephony API is used, an API such as GoogleMaps, Amazon SQS or DBPedia will be used right alongside it.  As a developer in this market, it makes a lot of sense for you to get to know your neighbors for two reasons. First, the more you can make your API play well with others, the faster the adoption of it will be. Secondly, the more you can understand your customers, their problems and how they need your part for their solution, the better you can make your API for them.   I'm supposing this means that you need to get familiar with APIs like this.

Which leads me back to my original statement.  The twenty-something-don't-know-or-care-about-SS7 engineer will sit down and design their version of the hot-or-not site one day, and use a whole bunch of crazy APIs to put together the application.  Then, they will go have a beer, come back, and say "You know, it would be really cool if you could just call the person you want to hook up with.  Is there an API for that?"  They won't even consider for a minute the words "termination", "LATA" or "CALEA".  They're just writing an application.  They need an API for some function, and it will take a few minutes to integrate it into their application.  And, there are many, many more of these guys than all the telecom engineers that have ever, and will ever, exist.   

So, I bring you the DBPedia API, as an example of the hundreds of APIs that will live in the same neighborhood as the Telecom APIs.   Go check it out; let your imagination run.  And one day, when a web guy surfs for a telecom API, I hope it's your API they choose.