From the Bing announcement:

This notion of creating and presenting computational knowledge in search results is one of the more exciting things going on in search (and beyond) today, and the team at Bing is incredibly fired up to bring some of this amazing work to our customers.

When the Wolfram Alpha API was released in October, we saw the promise of connecting to its data and algorithms. The connection with Bing is appropriate, given how the search engine has framed itself as a “decision engine.”

Epicenter notes the integration is part of a larger trend:

Microsoft’s decision to try out some of Wolfram|Alpha’s answers is yet another step in an industry-wide march towards returning more than just links as the answer to most search query. Search engines now routinely blend in maps, music, videos and reviews, in order to give better results to user queries.

In addition to being a coup for the young Wolfram service, this is healthy news for anyone charging for an API. Microsoft has validated not just Wolfram, but the idea of an API as a revenue stream.

The company wants to fill out its 80apps store, which is launching later this fall. As an incentive they’re offering some pretty geeky prizes: Herman Miller chair, gadgets and an Atari 2600, for example. To qualify you’ll need to submit your app by December 11th.

Of course, there’s not a whole lot of code to write, since the crawling is done for you. Using Java, you’ll need to implement processDocument() and parseLinks() functions. Then you’ll need to export a JAR file and upload it to 80legs. More technical details can be found on the 80Apps Wiki.

As you can see from the table above, the platform is not free. However, it’s never been cheaper or easier to crawl the web. Any apps you create, whether or not they win the contest, will be available for sale on the 80apps store. You keep 100% of the revenue and just pay 80legs for the page crawling and CPU-hours.

Unlike most APIs, which provide data, 80legs is providing a service, one that usually takes much more cost and effort to set up. Also, it is enabling developers a means to make money directly, something missing from many paid APIs. Expect tools like 80legs to gain in numbers, as developers start expecting platforms that give them a boost.

 Alexa Site Thumbnail used in Learn10

 Amazon eCommerce used in www.q-compare.com

 Amazon Mechanical Turk used in JoomFlix JF Crowd

 Basecamp used in PPMLite

 Daylife used in Show Me Spin

 eBay used in www.q-compare.com

 Facebook used in Learn10, Your Zodiac Sign, Health and Yoga

 Flickr used in Picked Jobs, Twitter Times

 Freebase used in Picked Jobs

 FriendFeed used in ffOldAvatars, ffScheduler, FFSummary

 Google AJAX Language used in Learn10

 Google AJAX Libraries used in Learn10

 Google App Engine used in Your Zodiac Sign, Health and Yoga

 Google Homepage used in Learn10

 Google Maps used in Google Maps and Last.FM Mashup, National LID Atlas, Picked Jobs, Specialgourmets: Gluten free, Allergy Free Food

 Google Maps Flash used in AIRCN Flight Simulate Map

 indeed used in Picked Jobs

 Last.fm used in Comprendo, Google Maps and Last.FM Mashup

 Lyricsfly used in Comprendo

 Moneybookers used in Give 1 Get 2: Moneybookers Exchange

 MyVox used in Learn10

 PayPal used in JoomFlix JF Crowd, Learn10

 Seesmic used in Learn10

 Twilio used in Mobile Commons

 Twitter used in Beshertweet, iTrends iPhone app, Realtime Related Tweets Bar, Twitter Times

 uClassify used in Show Me Spin

 Web API for Biology used in Academic Site Navigaiton

 What The Trend? used in iTrends iPhone app, Twitter Times

 Yahoo Search used in Twitter Times

 Yahoo Site Explorer used in Yahoo Site Explorer in 3D

 Yahoo Term Extraction used in TagCloud, Yahoo News Tag Soup

Mashups of the day:
And each day there is one mashup selected to be Mashup of the Day. Here are last week’s winners:

 ffScheduler

 iTrends iPhone app

 Picked Jobs

 Realtime Related Tweets Bar

 Show Me Spin

 Twitter Times

 www.q-compare.com

 Yahoo Site Explorer in 3D

My previous posts focused on COPE (Create Once, Publish Everywhere) and content modularity, the fundamentals for ensuring that content can be managed and distributed to virtually any platform. But ensuring that your content can be delivered to those other platforms does not mean that it can display appropriately on them.

Content often contains very important semantic markup, used to emphasize the content, relate it to other content, describe it, etc. By markup, I mean HTML, character encodings and microformats, among others. Although this markup is important to the content, it also makes it “dirty”, potentially compromising its ability to live and flourish in the myriad places to which it will get distributed. No matter how modular the content is in the database, if it is sullied by this markup, it is not truly portable. As a result, just building an API is not enough. The API needs to be able to distribute the content to any platform in a way that each platform can handle.

To demonstrate this problem around portability, I often use the pre-iPhone iPod as an example. This device did not parse HTML. Rather, tags would simply be printed as strings. When podcasting took off, some NPR titles had HTML tags in them, including < em > and < strong >. Because iPods were not able to render the HTML, titles would like something like, “This is a < em >great< /em > title!” Similar, another fail scenario that is relevant to NPR is an HD Radio display. These devices are also not able to render markup printing these tags to the screen.

There are two primary ways of handling this problem. The more common way is to store the dirty content in the database and to maintain a series of scripts that handle it on the way out. Although this is potentially effective for specific goals, there are some significant problems with it. For starters, stripping out the markup as it gets distributed means that the markup still lives with the content in the database. As a result, as new platforms arise and as markup standards evolve, the markup in the content will remain static. So, each distribution script that handles the markup will need to be carefully maintained and updated accordingly. Moreover, since each distribution platform could have its own compliance with the various forms of markup, each of these outputs may require their own script to handle the content (that is, the more distribution channels there are, the more scripts there are to maintain). Finally, the majority of systems that allow markup in this way do very little to limit the type of markup that is used. Because of the tremendous variance in how the markup is used in the content, these scripts will need to be increasingly complex, causing the accuracy to be tougher to guarantee.

Rather than handling the cleansing process on the way out, NPR has created a system that cleans the content on the way in. The goal here is to save the content in the database in a modular AND portable way. That means that each discrete object type is stored separately while ensuring that text content in each object is devoid of markup. I call this system “Markup Addressing” and here is how it works:

• A range of fields in the system are markup-enabled, allowing Editors and scripts to include HTML and other markup values in the content directly.
• For each field that allows markup, very specific values are allowed. Some fields allow more, some less, but all fields are limited to nothing more than the 25 tags and character encodings that the system as a whole allows.
• We apply client-side handling to ensure that no markup beyond those allowed by the field are used for that field. We also enforce proper nesting and syntax for the markup.
• Before saving the clean and acceptable markup to the database, we identify all markup for each field and begin our “addressing”, which is essentially identifying the character numbers of the markup in the text. For each tag or character identified, we find the character position for where it starts. If applicable, we also find the character position for the close tag. We then strip out the markup from the text and store in a relational table the address in the text that the markup was found. This relational table does not include the markup itself. Rather, that is stored in a separate table that is the authority for which tags are allowable. The image below represents roughly how we store this kind of information.

The diagram above represents how NPR strips out markup from content fields prior to saving to the database. The markup is then “addressed” and stored in a series of relational tables, enabling any presentation layer to present the content with or without markup. It even allows the markup to be easily transformed as needed before pushing to different platforms. (Click here for an enlargement of this diagram)

There are several very tangible benefits to this approach, all of which improve overall portability of the content. These benefits include:

• Distributing the content without any markup is as simple as pushing out the content from the database directly, without any further processing. This is helpful for platforms that are unable to render markup, including those mentioned in my examples above.
• Distributing the content with the original markup is just as easy by reassembling the markup based on the addresses.
• It is easy to only distribute only some of the markup based on what the markup is. An example of this is if the destination product wants to emphasize content but does not want to allow for links to other content.
• As markup, such as HTML tags, get deprecated, this approach only requires a change to one field in the entire database, instead of having to cycle through the database to find all instances of the old tag to replace it with the new one. For example, < b > has been replaced with < strong >, so we simply need to modify the one record in the authority table for tags to make this change apply across the entire set of content.
• As new platforms arise, if they require specialized markup, it is easy to transform the existing markup to anything else required for these new platforms.
• Adding new allowable tags is easy by simply extending the client-side handling and the authority table. These tags can include microformats and other business-critical tags that help describe the content. For example, NPR could very easily create a tag for our internal purposes for < station >, such that for every station that gets tagged, rather than rendering this tag, the system will look up the station in our database and replace that < station > tag with a hyperlink to the station’s home page.

NPR’s system applies these methods to specific fields throughout our CMS. When distributing the content through the API, however, we only currently apply the power of Markup Addressing to the story full text. The API has a field for < text > which removes all markup for the syndication as well as < textWithHtml > which reassembles the content with all markup. Extending this to all other markup-enabled fields would be quite easy under this system, although there has not yet been a need to do so.

Regardless of which approach is taken, there is one other significant issue that prevents true portability of content… the content itself!

I create a distinction between “content” and “calls-to-action” to help clarify this problem. Content is the information that the users actually want to consume. It could also include metadata, which helps to accurately describe the content that the user is actually consuming. Within this content, applying markup that emphasizes it or relates it to other content should be done in such a way that the meaning of the content is unaltered by the abstraction of the markup from the content. Here is an example of an appropriate way to apply markup to the content:

This image is part of an NPR story that demonstrates appropriate use of HTML within the body of the text. The artists’ names are linking to artist pages, but the meaning of the story is completely unaltered by the removal of the markup.

In this scenario, removing the links to the artists’ names in the text, for example, does not alter the meaning of the content. Of course, it does diminish some of its power as the user cannot easily learn more about these artists within the context of this story. That said, distribution of this content without those links will not adversely affect the meaning of the story. The artist names are valid and appropriate within the body of the text.

Applying markup within the content that is calling the users to perform an action, on the other hand, poses a different problem. Here is an example of a call-to-action within the content:

This image is part of the same NPR story demonstrating the use of calls-to-action, which make the content unable to provide meaning without the context of the markup. These calls-to-action make the content less portable, specifically to platforms that are not markup enabled.

Notice that within this content there is a link to related content where the link text is “Listen to The Entire Album”. Abstracting away the link itself actually alters the meaning of the text as the text provides no information about the audio asset. There is no indication as to what album or who the artist is. So, as this content gets distributed to platforms (both known and unknown), pulling out the markup actually adversely affects the content.

This is a problem for every content producer, including NPR. Although we have gone through great measures to put the content in the best position to live and thrive in all platforms, there is still work to be done to ensure the success of our distribution strategies. Some of these efforts are technical in nature. Others could impact editorial processes and style guides. But in all cases, our goals are the same… to be a media organization that produces great content for our users, wherever they wish to consume it.

The one feature request that we’ve heard over and over, however, is
“what’s going on where I am?”. To answer that, we wanted to give you
all a heads up regarding the new “Trends API” that we’re launching.
This API will open up trending information that is specific to a
number of locations around the world.

At a high level, there will be two new endpoints:

• an endpoint to give a listing of all locations that trends are
  available for, and
• an endpoint to actually allow you to query by a specific location.

As with Twitter’s other APIs, the Trends API is a RESTful API that returns results in both XML and JSON. Twitter has decided to utilize Yahoo’s Where on Earth IDs (WOEIDs) to identify locations for which it has trending data. WOEIDs are unique identifiers for place names around the world (see our additional coverage of WOEIDs and Yahoo’s Placemaker API for more information).

Using the trends available method will retrieve an array that includes WOEIDs (and related place name information such as name and place type) for trending locations. The top 10 trends for a location can be retrieved using the trends location method with a particular WOEID.

This information is cached for five minutes, and therefore users are discouraged from querying these endpoints faster than once every five minutes. Developers can also use a WOEID of “1″ to get global trending results. Also note that location-based trends will not be rolled up into daily and weekly trends (for the time being).

Twitter’s move to support location-based trends is sure to give developers an opportunity to further enhance existing mashups and applications that utilize Twitter’s API. The move also highlights the value that geographic context provides for real-time information, especially on a platform that has gained as much momentum as Twitter.

[Hat tip TechCrunch].

If the first dictionary was invented after the Internet was created, it might look something like Wordnik, which bills itself as “a place for all the words, and everything known about them.” Wordnik allows users to look up definitions, add new words to their online database, and provides example sentences culled from the Internet. Unlike many online dictionaries, Wordnik’s content can also be accessed through an API (see our Wordnik API profile for details).

The Wordnik blog describes why an API makes sense for an online word directory:

Wordnik has amassed an incredible amount of data… one of our core principles is that you shouldn’t have to come to any particular web site to learn about words: the word data should come to you wherever you are.

Wordnik’s RESTful API allows developers to look up definitions, display the use of words in example sentences, and return data about how frequently the word appears in Wordnik’s corpus. The Wordnik API also gives developers access to an autocomplete function, and both a “random word” and a “word of the day” listing. Data for each function is accessed by GET request, and data can be returned in either XML or JSON format. The API is still in alpha development, and access is currently limited. Requests for access to the API can be made using this online form.

After the Deadline is an English language spelling and grammar checking API (our After the Deadline API profile). Already available as a plugin for Wordpress and TinyMCE, this open source project attempts to provide web based access to the same type of language support found in desktop word processors such as Microsoft Word. The system goes beyond simple spellchecking - After the Deadline checks style, grammar, and common misuses of words, and it can even provide explanations for its suggestions.

Raphael Mudge, developer of After the Deadline, wrote about the advantages of using a web based API for word processing on the 2009 WordCamp NYC blog:

The web is not ready to replace the word processor yet. The word processor still has something that we don’t. One of the great powers of the word processor is its magical ability to check my writing and tell me it’s OK… After the Deadline is a software service. Since it’s open source you’re not tied to any vendor and you have access to the code to run your own server.

The After the Deadline API accepts input through both POST and GET requests. Currently the After the Deadline API allows developers to spell and grammar check a collection of text, or simply return the amount of errors that the text contains. The API accepts either POST or GET requests, but data is only returned in XML format. Developers must sign up for an API key by creating a new user account.

As the examples above indicate, more and more software features traditionally found in desktop offerings are being implemented as web service models. For other web services that deal with knowledge and data, check out our huge list of reference APIs.

The MyChances API accepts a number of variables, from test scores and AP classes to ethnicity and parents’ education. Using the values, along with its internal data on a college’s admissions practices, MyChances reports back on the probability the student will be accepted (more details at our MyChances API profile).

This service is bound to be controversial. For one, many colleges and universities weigh more heavily qualitative information, such as essays and recommendations. However, MyChances gives a guide based on real applicants. And students searching for a school are looking for any sort of feedback they can get. In addition to probability, MyChances also returns their sample size and corresponding statistical accuracy.

Though the API references free and enterprise versions, the site does not list any charges. The terms of service reference potential fees for usage “over a certain rate, or for certain types of commercial applications.” And the company appears to be reviewing developer projects, through an application that requests details, though this practice is somewhat common.

FairLuck API: The FairLuck API is a random number generator intended to help casino software developers test and verify the lucksets created by their server code. By using this API, online games can offer their players total confidence because no cheating is possible.

ForeclosureListings.com API: ForeclosureListings.com combines one of the largest databases of foreclosure listings direct from major banks, mortgage companies, Government, HUD, Fannie Mae, Freddie Mac and others. Their nationwide network of courthouse scouts obtain information as it is filed regarding owners that have just been served with a foreclosure notice (pre-foreclosure). The ForeclosureListings.com APIs let you get the latest 10 Foreclosure Homes in any zipcode, city, county or state and also know if a property in a given address is a foreclosure.

Lemonfree API: Lemonfree is an automobile search engine. There are 2 million cars offered for sale. It does not charge dealers or private sellers to list their vehicles for sale. The service offers quality vehicle listings that you can into your own website or project. The Lemonfree API allows you to obtain Lemonfree.com vehicle results for a variety of search queries.

Location-API.com API: Location-API.com helps developers and mobile service providers to locate mobile phones and other mobile devices connected to the GSM and WCDMA networks.

Geographic coordinates for latitude and longitude are provided from a database that includes cells from 200+ countries and 3.9M cells.

oDesk API: oDesk is a marketplace for online workteams, with a unique business model for both buyers and providers that looks to guarantee to buyers that an hour billed is an hour worked, while guaranteeing to providers that an hour worked is an hour paid.

The oDesk public API allows developers to access the oDesk platform from outside oDesk.com, search jobs and providers and view detailed work histories of others on your team. Also check your messages and reply to important messages via the API.

Touchnote API: The Touchnote API lets any website that hosts images use to integrate a print-on-demand facility for postcards into their offering. It also lets developers make money by getting paid a share of every card that uses one of their images: 10% of revenue (revenue is all the money that they get paid by the customer for the postcards minus tax). And an introductory offer gives 30% of revenue until March 32, 2010.

Unfortunately, neither the data nor the imagery is available in the API version of Google Maps. While Google provides programmatic access to driving directions, as well as walking directions — the third type, transit, has never been a part of the Maps API. The reason could be that there are extra factors, like fares and zones, that don’t quite fit the same structure as other directions.

Indeed, though Google receives hundreds of transit feeds from hundreds of agencies, only a handful have data accessible to other developers. This may not be Google’s fault, as I wrote in Why Aren’t There More Transit APIs? It’s easy to see the benefit of providing data to Google, but a harder sell to open up to any developers. Of course, some are better than others.

Developers don’t necessarily need Google or agencies to provide them with all the data. London Tube Journey Planner, for example, shows routes and plans trips. We currently list 91 transit mashups, several dating back to 2005.

Founder Gil Elbaz announced Factual’s launch:

“Today, we are announcing the beta launch of Factual, a platform where anyone can share and mash open data on any subject. Factual provides smart tools to help the community build and maintain a trusted source of structured data so everyone can make better decisions. Users can contribute data and get deeper data on a particular subject, publishers can add free content to their site with embeddable tables to enhance the end user experience, and developers can customize tables and create new applications using the Factual API.”

There are a handful of fun datasets already, such as American Idol finalists (embedded below) and a little peak into Factual’s employees.

Some have noted a similarity between Factual and Wolfram Alpha, which also has a new API. SearchEngineLand explains the difference:

“Unlike Wolfram Alpha, which is a closed system with data “curated” by employees, Factual has adopted a Wikipedia-like model which allows anyone to create, structure or even edit data in Factual tables. Elbaz hopes this open model will encourage community participation, enabling Factual to grow rapidly and enjoy widespread adoption.”

As part of the open model, Factual allows both reading and writing to its API. Also, unlike Wolfram Alpha, Factual’s API is free for developers.

Factual joins our list of 20+ database APIs. Among the most similar services are community-generated Freebase and Comprehensive Knowledge Archive Network.