-
Website
http://avc.com/ -
Original page
http://www.avc.com/a_vc/2008/10/the-content-api.html -
Subscribe
All Comments -
Community
-
Top Commenters
-
ShanaC
1239 comments · 73 points
-
daryn
216 comments · 15 points
-
kidmercury
835 comments · 104 points
-
howardlindzon
207 comments · 71 points
-
Charlie Crystle
205 comments · 36 points
-
-
Popular Threads
-
Top Tracks of 2009
14 hours ago · 49 comments
-
Top 10 Records Of 2009
1 day ago · 73 comments
-
Getting Computer Science Into Middle School
6 days ago · 281 comments
-
Open APIs and Open Standards
1 week ago · 207 comments
-
Thoughts on Blackberry Fail
4 days ago · 77 comments
-
Top Tracks of 2009
Soon Google is going to support RSS for the search engine. You'll be able to do a search that returns RSS, for anything you could search on using the user interface and plug the result into anything that understands RSS.
In other words we already have a fine API for content -- RSS. It's not clear what's to be gained by creating another. Maybe someone from NYT could illuminate.
While it may not be the 'semantic web' that we've all been dreaming out, semantically classifying news, whether its topics or connections, is really going to enable a whole new generation of value added services to built on top of these platforms.
A similar thing is going on in online brokerages -- the battle is moving away from end-user websites and towards integrating trading and data platforms via APIs with third parties.
But RSS as a current standard doesn’t have this level of flexibility or associated meta-data to allow this to be effective over different data sources or different content “domains” (maybe your want to pull information on the empire state building from NYT, Wikipedia, Tour Schedules, nearby restaurants etc and represent it as a day planning service (ok lame example)). API’s can allow this level of detail but you don’t want to have to be building a custom integration module for every content source site you want to access.
Anyway isn’t this what Web 3.0 is about, building a standardized API format that will allow this all to happen? I thought we were done with Web 2.0 already :)
RSS could do that... but doesn't do it very well.
Facebook, Twitter etc allow users to build apps inside their platforms or running off their platforms.
Boorah, Snooth etc allow users to leverage the data in any way they want.
If the NYT API allowed you to pull a list of stories that mentioned the Empire State Bldg then its no different than the way ours works. For them full text matching, or some basic semantic matching and then returning relevant results. Thats a data/content driven API.
If you visit the Times building on 8th ave, there is an installation in the lobby which cross cuts across the content is a variety of ways: photo captions, ingredients, questions asked, headlines.
Worth checking out.
(and Dave, RSS is an envelope not an API but for straightforward use cases they're interchangeable)
But honestly, my only choices are build it myself, use the whole platform, or go 2 tier with MySql from scratch. Am I missing something? Why can't there be a service where I can instantiate and store profile data and preference variables without having my clients with existing sites migrate their entire user population to XYZ social platform?
I am stooopid?
He's the one who tipped me off to it
Websites can sign-up and use our "widget-like" web service to display the content on their site. Then use their CSS to make it look like their site and put their own ads around it.
Eventually, I hope to see all newspapers giving out their content (with their own ads inside) and let other folks build sites around it.
How cool would it be to build a newspaper with editorials from all the big newspapers, or articles on a specific subject?
Unfortunately, there's not much revenue to be had on "old news" and there are not many publishers who want to let go of the control.
Your comment in the post - "But if instead of being limited to wikipedia, they could use dozens of highly trusted, accurate content sources (emphasis mine), they could probably do much more." is interesting so far as the issue of trust and accuracy.
The level of "trust" in major news source organizations has dropped dramatically over recent years, especially as these organizations have tilted to one end of the political spectrum or another.
Developing a system that highlights bias, such as the recent work to identify left-leaning/right-leaning article citations, is an interesting and challenging field. How to monetize that type of system is perhaps even more difficult.
Maybe AVC topic pages are next?
-bill
Here's an API for all NYTimes stories for a query:
http://www.dapper.net/dapps/NYTimesArticles
And the Mark Bloomberg stories result in RSS: http://tinyurl.com/MarkBloombergNYTRSS
People have been using content APIs for quite sometime now to build innovative stuff. It gets interesting now when businesses start to understand that distributing their content is actually a very effective (and probably the most effective) marketing strategy. In fact, that's exactly where online marketing/advertising and APIs/the semantic web meet.
the content API for http://www.idiomag.com will be live very shortly. for eg, you can call the latest music news, reviews, bios and media, from an artist name or genre.
Andrew
Mike Bloomberg http://topics.nytimes.com/top/reference/timesto...
Empire State Building
http://topics.nytimes.com/top/reference/timesto...
In fact we have 13k of those. Every Topic Page comes w/ an RSS feed http://topics.nytimes.com/top/reference/timesto...
I love what you and your colleagues are doing
Fred
MTVN Content API - Nirvana Video Method
http://api.mtvnservices.com/1/artist/nirvana/vi...
The MTVN Content API is also mentioned in the NYT blog.
http://developer.mtvnservices.com
My request: Please lose the quotes around the term "Content," as it labels the terms as if it's newer and more novel than I think this use of APIs deserves. I feel like a PETA activist for APIs.
Reuters is well ahead of the Times, whose "Campaign Finance API" (that deserves quotes) is toe-in-water at best relative to Reuters' OpenCalais (also Mashery-hosted), which is basically a way-closer-to-realized example of what Fred's post is all about. My strong hope is that the Times goes way beyond "Campaign Finance" data (quotes mine again), which I'll bet isn't even putting the Times' data at-risk.
http://madstore.sourceforge.net/
Any suggestion would be appreciated, thanks!
We (MCN) build mobile search services by federating to local content sources. All the transaction-based sources readily make their APIs available to us. The revenue stream is clearly definable: more traffic leads to more sales.
Monetization is not as clear for information sources, and they have lagged behind technologically. What NYTimes is doing, in exposing that layer for externals to build their own applications, is making their own content act as advertising for themselves. As first movers, they are most likely to be included in the new apps being developed for the PS and Mobile internet, increasing their value as a trusted source. This increases their potential reach far beyond that available from print distribution and causes their advertising rate to increase (based on circulation).
If they can continue to push ads with their content, then opening their content to developers is an advertising goldmine. NYTimes might want to add an affiliate program to share ad revenue with the application vendors if the vendor leaves in the ads.
Even if the new applications strip out the original ads, they still manage to increase NYTimes reach. Increasing the distribution increases brand awareness for NYTimes. A win for all parties.