The concept is fairly simple: guess which of ten words fits into a blank space in a sentence. As you guess correctly, your choices narrow, but you only have one minute to get them all.

The quiz runs on Google App Engine (our Google App Engine API profile) and was created with the Google Web Toolkit.

The part we see is fairly simple. It just needs to grab ten potential answers from the database. The more complex part is how Blackler went about finding the the articles to use, which he explains in a post about how he made it. For example, he used links within Wikipedia to determine whether an article would be too obscure.

It’s fun to see these sorts of mashups. They build upon data that’s already out there for other purposes. If something this interesting can be made from Wikipedia’s unstructured data, imagine what is possible with something like Factual’s open data platform or similar public datastores.

Hat tip: Andy Baio

The Science Museum is currently running an exhibit called “Cosmos & Culture: how astronomy has shaped our world“. In order to help promote the exhibit, the museum has created an online mashup contest. Developers are invited to use the new Cosmic Collections API to access information about objects on display, with a chance to win one of two £1000 prizes.

The Cosmos and Culture competition wiki explains what the Science Museum hopes to accomplish by providing a public API to access information about exhibits:

The data relating to the remarkable objects on display has been made open to the public so that competition entrants can ‘mash it up’, combining it with external resources and software to create new interfaces. This is a bold experiment for the Science Museum - we’re releasing our data and what happens next is completely up to you. Your challenge is to create brand new web interfaces for the objects - to shine a new light onto them and bring the stories behind them to life.

Mia Ridge, Lead Web Developer at the Science Museum, discussed how the Cosmos and Culture competition could help muster up feedback from developers:

I also wanted to use the competition as an open beta test for our API - would our data make sense to non-museum people? Is it re-usable in its current structure? What kinds of functions would API users find useful?… I’m also really excited about the chance to let people loose and see what they come up with. The Cosmic Collections competition seemed like the perfect opportunity - there are so many different objects from cultures across the world and throughout time.

The Science Museum’s Cosmic Collections API features a RESTful interface, and returns data as XML. The API, which can be accessed using GET requests, is able to either return a list of all items in the Cosmic Collection, or provide specific information about a particular item in the collection.

The Cosmos and Culture project may prove to be an informative example for other museums to follow when exploring ways to interact with online visitors. We asked Ridge about her choice of data formats in designing the Cosmic Collections API:

I’ve also been considering Linked Data, microformats, RDFa - there are lots of different ways to get our data out there, and our experiences with this project will influence what we do next. I’m slowly working to improve the way our collections are presented online, and integrating machine-readable data with the public-facing pages is part of that.

The Cosmos and Culture competition is open to entries until midnight (London time) on November 28, 2009. More information about the contest can be found here, and there is a Science Museum Developer Google group as well. For some inspiration in creating your own mashups for the contest, take a look at our collection of dozens of science mashups and science-related APIs.

If you’re not familiar with the OWF, it is a non-profit organization that helps developer communities collaborate and share technical innovation on the web, by applying the approaches of the open source community to standards and protocols. In essence, the foundation aims to facilitate the creation and implementation of specifications through legal agreements that are simple and effective.

The Yodel Anecdotal blog provides a good summary of what the OWFa signifies for developers and companies alike:

Today, the Open Web Foundation is announcing the availability of the Open Web Foundation Agreement (OWFa), a reusable and straight-forward legal document, designed to be easily adopted by a wide range of specification communities and organizations. Specifications made available under the Open Web Foundation Agreement may include everything from small ad-hoc formats sketched out among friends to large multi-corporation collaborations that ultimately grow into internationally recognized standards with the help of formal standards- setting organizations.

And Marshall Kirpatrick at ReadWriteWeb provides some additional food for thought with regard to the OWFa:

What does this mean? It means that other companies will be able to use technologies like Media RSS, OAuth, Salmon, Web Slices and more without fear that unclear licensing agreements will lead to legal problems later. It also means that developers creating innovative new tech specifications to push and pull user data from one site to another can launch them using a turn-key license developed by some of the top legal teams in the business.

As part of the release of the OWFa, Yahoo! and other companies moved forward with open sourcing several specifications and standards. The projects released under the new OWFa include:

• MashSSL Open 1.2.0 (SafeMashUps)
• Media RSS 1.5.0 (Yahoo!)
• OAuth Core 1.0 Revision A (Facebook, Google, Yahoo!)
• OAuth WRAP 0.9 (Facebook, Google, Microsoft, Yahoo)
• OpenService Format Specification version 0.8 (Microsoft)
• PubSubHubbub (Google)
• Salmon Protocol (Google)
• Simple Web Tokens 0.9 (Facebook, Google, Microsoft, Yahoo!)
• WebSlice Format Specification version 0.9 (Microsoft)
• XML Search Suggestions Format Specification version as of 11/11/2009 (Microsoft)

And over on the Open Web Foundation blog, DeWitt Clinton notes that there will be more to come:

The Open Web Foundation Agreement is just the first step among many toward a comprehensive, straightforward approach to an open specification development process. In upcoming months, the Open Web Foundation will be developing reusable Contributor License Agreements, which can be adopted by specification communities during the development phase itself, even before a usable specification is completed, and will offer Best Practices guidelines for open development processes.

This is fundamentally a good move that represents the first step in fostering innovation that is not subject to limitations and restrictions posed by other types of licenses. And it opens up the possibilities for developers to aiming to improve and iterate on emerging standards that can have wide or narrow spectrums of implementation. You can find additional coverage on the OWFa and more information about the work of the OWF and its members at the foundation’s web site.

The Chargify API is the core of their service, which handles billing and subscription services (details at our Chargify API profile). Lead developer Michael Klett explained how it works in an interview with ZDNet:

Customers start out on a merchant’s website that’s integrated with Chargify. They’ll enter their credit card data there to purchase an item. The merchant passes that data to us over SSL. We’d verify that and run that information against the merchant’s own payment gateway.

Chargify’s API accepts method calls using HTTP, and returns responses as JSON or XML. It helps merchants keep the purchase flow on their own sites and let Chargify do the processing.

Though Chargify doesn’t itself charge anything until you reach 50 customers, you’ll need a merchant account. These involve monthly and sometimes setup fees. Currently Chargify only supports Authorize.net.

The need for a merchant account may keep hobbyist developers using the Paypal API, where fees are only incurred when a purchase is made.

For more on Chargify’s services, watch their video (embedded below).

Your application can search NextStop using location coordinates, an address, or just a city name. Results can also be filtered by keyword or any combination of four categories. You can get an idea of the search options by using the recommendations on a map example application. The data provided by NextStop is extensive, with everything you’d need to recreate the site.

The site launched earlier this year and has already collected a lot of content, all available via the API. For now, the API is read only, though the team (made up of former Googlers responsible for Picasa and Calendar) is leaving the options open based on developer feedback.

For an idea of what you could build, check out the NextStop API examples or join the API list on Google Groups.

The library makes it easy to find the most popular books on the website with a special best-sellers section. From the list you can click to search by ISBN, one of several values returned by the Times API.

The implementation is, perhaps, a little simplistic. However, the user experience of the list isn’t the part we should be admiring. It’s that libraries are embracing open APIs and creating useful information access applications on top of them. It’s a big enough trend that there’s a good new book on exactly that topic from Nicole C. Engard entitled Library Mashups.

Library funding is dwindling. Perhaps getting back to the basics of what a library provides–information–is the key. Like newspapers, libraries cut through the clutter and find the knowledge we need. Connecting to APIs with data that gets us there is one new way to do just that.

In truth, the API has been out there since at least May, in use by a select few developers. That means that there are already a number of great examples in the app gallery.

FourSquare’s service lets users within its cities “check in” to let their friends know where they are. There are a number of other services, such as BrightKite (our BrightKite API profile) and Shizzow (our Shizzow API profile), that have similar features. However, FourSquare made sharing locations a game. The service awards points, mayorship and badges to its users. With this, and unveiling its iPhone app at the popular SXSW conference, FourSquare took off.

TechCrunch thinks the API could make it even bigger:

The opening of the data is likely to be important for Foursquare in the long run. Foursquare is getting traction with users putting information into its system, but a real explosion could come if third-party developers start making some great apps on top of the service. Obviously, we’ve seen that type of community swarm around and feed services like Twitter.

The API provides access to the same functions that make the FourSquare mobile apps run. In addition, you can access a user’s checkin history. Developer Andrew Mager details how to write a FourSquare app using OAuth and PHP.

TechFlash reports how founder Steve Murch expects the platform to be used:

Murch anticipates developers taking advantage of the content to create new cooking applications for Android, iPhone, Blackberry and Windows Mobile devices as well as new food-related mashups with Twitter and Facebook. Murch also sees the content possibly being used to develop applications for kitchen-related touchscreen computer systems.

For an example of what could be built, check out BigOven’s free iPhone app, or the demo video embedded below.

There’s a lot in this API. You can search by title, or any keyword. That means it’s easier than ever to find cookie recipes that call for persimmons. In addition to search, you can access reviews and photos, plus a host of user-specific methods (using HTTP Basic Access Authentication).

One of the more exciting features might be the grocery list, which allows developers to view and add items to grab at the store. It’s easy to see how this could be mashed up with the world’s first grocery API from Tesco.

As you may have read in our previous coverage, the TownMe GeoAPI enables developers to access a variety of data based on spatial queries (e.g., find a bar near San Francisco) and it also allows developers to create private ‘layers’ to store data for a specific location or locations. Although this capability is not new (see for example the Shizzow and Google Maps Data APIs), it is good to see that the write capabilities are included with an API targeted at developers working with location-based services.

The new GeoAPI.com API includes a net new web site and several additional features that are highlighted on the GeoAPI.com blog:

• GeoAPI.com domain. We are re-launching and re-branding as GeoAPI.com to make it easy for developers to find and access information about the Mixer Labs GeoAPI.
• Media Layers. We have added the ability to search additional media layers such as Twitter and Flickr by geo-location.
• Attribute search on entities. We make it even easier to search our API for businesses or POI across multiple categories or attributes.
• Tiny URLs and Link Open Data for places. We have added the tiny URL domain geo.am to provide a short hand by which you can canonically refer to locations based on our GUIDs. This means a single entity will always be findable within the framework we provide.
• iPhone SDK. We have added a library to make it easy for developers to use our API in your iPhone app.
• Higher Queries Per Day limits. We have raised our QPD from 5,000 to 20,000.
• Intersection Data. We have added data for over 10 million intersections in the USA. You can see a sample view of an intersection here inluding nearby Tweets and Flickr photos.

Documentation for the new API is available, as well as several demos that showcase how to use some of the new features, including a “Media Layers” map mashup and a “What’s Near Me” JavaScript app for the iPhone. Note that a developer key is required to access the RESTful API.

Geo/mapping APIs continue to be popular in our mashup directory, and we’re looking forward to seeing some new mashups and apps that use GeoAPI.com. Mapping continues to be the most popular category, with over 96 APIs listed in our API Directory.

 Amazon S3 used in CloudBerry Explorer for Amazon S3

 Calais used in Transmission News

 Cicero used in Redistricting The Nation

 COLOURlovers used in Top 99 Palettes at Once

 Facebook used in Facebook Friends Map

 Google AdSense used in Turkish Earthquakes

 Google AJAX Libraries used in Turkish Earthquakes

 Google Ajax Search used in Transmission News

 Google Analytics used in Lobbyist Activity Tracker

 Google Custom Search used in Turkish Earthquakes

 Google Maps used in BillMaps, Facebook Friends Map, Place Your Point on Map, Transmission News, Turisbook, Turkish Earthquakes

 Google Maps Flash used in Lobbyist Activity Tracker

 GovTrack.us used in BillMaps, Lobbyist Activity Tracker

 Open Government Data Initiative used in BillMaps

 OpenStreetMap used in Lobbyist Activity Tracker

 Touchnote used in photofunia

 Twitter used in CouponFollow, Transmission News, Tweetply

 Wikipedia used in Transmission News

 Yahoo Geocoding used in Transmission News

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

 BillMaps

 CloudBerry Explorer for Amazon S3

 CouponFollow

 Lobbyist Activity Tracker

 Top 99 Palettes at Once

 Tweetply