Matt demanded accent-aware spell checking for the WordPress spell checking plugin his company acquired earlier this year. And just a little more than a month later, After the Deadline delivered. Now Beyoncé, café, coöperate, and even my resumé look prettier.

Separately, Wordnik offers a new take on online dictionaries, and they just launched an API.

Will Norris has discovered that iTunes 9’s interactions with the Store are more web-happy. I’ve been asking where the iTunes Store API was for some time, now I think I’ve got what I need to build one.

This plugin is the next step after my proposal for a common invite API. Here’s how I described it when requesting hosting at the plugin directory:

A common framework for registering tickets that will be acted upon later. Use it to manage challenge/response interactions to confirm email addresses, phone numbers, IM screen names, Twitter accounts, etc. Build an invite system around it, or use it as the foundation of a short URL system. It’s an extensible framework that takes cues from WordPress’ cron and admin Ajax functions.

Tickets are unique 1-32 character strings associated with actions and some stored data. Upon receiving a ticket, the matching action is executed with the stored data as an argument. After receiving the action, a plugin can destroy the ticket (as for challenge/response actions), or or leave the ticket in place for repeated use (like redirecting to longer post permalinks for a short URL resolver).

Here’s how it works:

Registering a ticket requires three things:

• The unique string that identifies the ticket
• A string representing the action that will be executed when the ticket is called
• Some data that will be passed to that action when the ticket is called

And here it is in action:

$ticket = $wptix->register_ticket( 'action_name_string', $wptix->generate_md5(), array( 'data' => 'val', 'more_data' => 'another_val' ));

To actually do anything with that ticket you’ll have to also register a function associated with the action name you gave when you registered it:

add_action( 'action_name_string', 'my_function_name' );

WP Ticket Framework registers a URL base in the form of http://site.net/do/any_ticket_string, so you can call a ticket simply by visiting that URL, or you can call tickets within your code. The following demonstrates one method of handling ticket inputs as part of a larger form submission.

if( ( $ticket = $wptix->is_ticket( $_POST['phone_confirmation'] )) && $ticket->arg['user_id'] == $current_user->ID ){
 $wptix->do_ticket( $_POST['phone_confirmation'] );
}else{
 $errors->add( 'user_phone', __( "<strong>ERROR</strong>: The confirmation code is invalid." ), array( 'form-field' => 'phone_confirmation' ) );
 return;
}

Caveats:

• Tickets don’t have any built in expiration mechanism. You can, however, include an expiration time in data saved in the ticket and act on that accordingly.
• Tickets don’t have any built in security mechanism. If only a certain user should be allowed to call a ticket, your code needs to be aware of that and enforce it.
• Tickets are deleted after being called, though you can suppress that by calling $wptix->clean_up_after( FALSE );.
• Tickets can only be queried by ticket string. If your application needs to keep track of open tickets for each user (as an example) it should also make a user meta entry about it.

The BuddyPress forums have a number of threads about handling invitations (two worth looking at: one, two), but no real solution has emerged. At the same time, there’s also a need for some means of confirming other actions such as password resets, email changes (both of those are already handled by WPMU, I know), cell phone numbers to receive SMS messages, and other actions that need to be confirmed later.

So I’m proposing a generic API to handle things like this. The built-in WordPress cron and ajax functions seem to offer a clear pattern for creating such an API: Simply, plugins and core code could register an action and a function to be called when that action is executed. The API could also store data to be sent to that function when it is executed.

Among the things I’d do with this?

• Confirm email addresses
• Confirm cell phone numbers via text message
• Confirm IM accounts
• Confirm Twitter accounts
• Confirm password reset requests
• Confirm invitations in BuddyPress

Anybody else interested?

I’ve wanted a Wikipedia API for a while. Now I might’ve stumbled into one: commons.wikimedia.org/w/api.php. It doesn’t do exactly what I want, but it might yet be useful.

hmm-citation-extractor, ParsCit and FreeCite (not to be confused with FreeCite, the F/OSS EndNote-like app). FreeCite is available as a service and a download.

Still, wouldn’t a simple URL be easier than all these unstructured citation formats?

Answers.com is throwing a bone to WordPress users with their new AnswerLinks plugin written by Alex King.

But wait, there’s an Answers.com API? A few pokes at the Google machine reveal nothing relevant, and Asnwers.com’s site is mum too. Taking apart the code, I get the following (modded enough to make it run-able if you drop it in the base of your WordPress install):

require_once('wp-config.php');
require_once(ABSPATH.WPINC.'/class-snoopy.php');
$snoop = new Snoopy;
$snoop->read_timeout = 5;
$snoop->submit(
	'http://alink.answers.com/link/xml'
	, array(
		'text' => “Put a long-ish string of meaningful text here, then look for interesting stuff in the print_r'd output.”
	)
);
print_r($snoop->results);

If the input string isn’t sufficiently long, the output will be empty (eliminating one of my potential uses for it), but it’s interesting to twiddle.

Answers.com, API, AnswerLinks, hacking, remixable, mashable

I’ve been talking a lot about remixability lately, but Nat Torkington just pointed out that the web services and APIs from commercial organizations aren’t as infrastructural as we might think.

Offering the example of Amazon suing Alexaholic (for remixing Alexa’s data), he tells us that APIs are not “a commons of goodies to be built on top of for fun and profit, like open source software.” Here are his “six basic truths of free APIs:”

1. Free APIs are not a god-given right. Businesses offer them for their own self-interested reasons. If you build on top of the API but aren’t delivering the value for the business that provides the API, your use of the API will probably go away.
2. If you build your own business on top of an API, you need a contractual relationship to ensure the service doesn’t get taken away from you. These generally cost money.
3. If you find a way to get something from a site that isn’t explicitly offered as something for you to build on, your use of it will probably be fought unless you’re delivering value as in (1).
4. The provider of your API will find it easier to implement services on top of their API than you will. Therefore you have to add something of your own that’s difficult to replicate, something beyond a simple UI tweak or a feature like “search”, so that the business that provides the API doesn’t simply compete with you when you look like you’re succeeding.
5. For these reasons, free APIs are a very poor substitute for having the source and the data and thus owning and controlling every piece of your application.
6. For these reasons, there’s no such thing as a free API if you’re looking to build a business.

Surely Torkington means free as in free beer APIs, as many of the problems he cites arise because the data and services are not free as in free speech. And this leads to two things I want us to be aware of in libraries: giving over our data to companies that lock it up behind licenses that restrict how it can be reused and remixed is dangerous; and we have an opportunity — some would say responsibility — to build out some of that information infrastructure and deliver free as in free speech APIs and data for all to use.

remixability, mashups, self interest, public good, api, apis, free, free beer, free speech,

It’s been more than a year since I first demonstrated Scriblio (was WPopac) at ALA Midwinter in San Antonio. More than a year since NCSU debuted their Endeca-based OPAC. And by now most every major library vendor has announced a product that promises to finally deliver some real improvements to our systems.

My over-simplified list said that our systems failed us in the categories of usability, findability, and remixability, and now people are asking me what I think about what I’ve seen from the vendors so far.

In general, they all include improved search results, and everybody seems ready to address comments and user-tagging, though the system vendors seem to be leaving findability to OCLC’s WorldCat efforts.

What’s missing, I fear, is remixability.

Remixability is the quality of a system or data set to be used for purposes the original designers or owners didn’t predict or intend. If I can define one buzzword with another, remixability is what allows mashups.

In 1971, in the earliest days of ARPAnet, Ray Tomlinson showed his friend a project he’d been toiling on on the sly: email. “Don’t tell anyone! This isn’t what we’re supposed to be working on,” he’s reported to have said.

In a different world, with a slightly different set of circumstances, the at sign on our keyboards might be lost. If he had had to ask his bosses for permission, or if the simple structure of that nascent internet was less open, Tomlinson would have been finished before he’d even gotten started. But as it turned out, Tomlinon was able to remix computers from mathematical machines to communication devices.

Fellow remixer Tim Berners-Lee explains it well:

Twenty-seven years ago, the inventors of the Internet designed an architecture which was simple and general. Any computer could send a packet to any other computer. The network did not look inside packets. It is the cleanness of that design, and the strict independence of the layers, which allowed the Internet to grow and be useful. It allowed the hardware and transmission technology supporting the Internet to evolve through a thousandfold increase in speed, yet still run the same applications. It allowed new Internet applications to be introduced and to evolve independently.

When, seventeen years ago, I designed the Web, I did not have to ask anyone’s permission. The new application rolled out over the existing Internet without modifying it. tried then, and many people still work very hard still, to make the Web technology, in turn, a universal, neutral, platform. It must not discriminate against particular hardware, software, underlying network, language, culture, disability, or against particular types of data.

These innovations resulted not from management directive, but inspired moments urged along by a supportive network architecture. The value of the internet was built on it’s remixability.

There are two ways to look at mashups of today, like Flickr Colr Pickr. Some see them as amusements and question who would build such things, others wonder how they can build systems that are as open to reimagining as Flickr.

And while some remixes might be simple amusements, others can be much larger. Flickr user Dan Cat, who imagined putting Flickr photos on the map (and built a mashup that let Flickr users do just that), ended up being hired by the company to build those features into their official site. Amazon, meanwhile, says remixers — including the 180,000 registered Amazon Web Services developers — account for almost a third of their sales.

The lesson is that when you open up the tools of remixing, people will use them, and the innovations that result will offer value even for non-remixers.

Today, we’re likely to invest in the software architecture of our libraries on a scale that matches the expansion during the Carnegie era. We might do well to think about one of the remarkable features of that period:

The Carnegie libraries were important because they had open stacks which encouraged people to browse. The open stacks were more democratic. People could choose for themselves what books they wanted to read. The libraries were meant to be for people of all walks of life.

The crisis in library systems arose because the people who build them and those who pay for them couldn’t imagine them in any other way. Open, remixable systems will allow patrons of tomorrow the opportunity to build the information solutions we can’t now imagine.

Is remixability in your next RFP?

remixability, mashups, library, library systems. l2, lib20, library 2.0, libraries, api, soa

ProgrammableWeb pointed out an InformationWeek story that claimed 28% of Amazon’s sales in early 2005 were attributable to Amazon affiliates. And C|net claims Amazon now has 180,000 AWS developers (up from the 140,000 Amazon was claiming about a year ago).

(Note: not every Amazon affiliate/associate is an Amazon Web Services (AWS) developer, but Amazon hasn’t shared more specific numbers.)

These slides, from Amazon’s AWS developer relations team explain a lot about what AWS is.

API, amazon web services, AWS, Amazon API, developers, earnings, Amazon.com, mashups

A couple questions about my API to convert 10 digit ISBNs to 13 digits pointed out somethings I failed to mention earlier.

First, the API actually works both ways. That is, it identifies and validates both 10 and 13 digit ISBNs on input, and returns both versions in the output. Example: 0811822842 and 978081182284-8.

And, as yet, I have no user agreement or usage policy. Except for the disclaimer — don’t blame me if it’s broke — I’m leaving this open (though I’ll probably have to figure something out for future APIs).

Finally, if all you want is a one-time conversion of a list of ISBN’s, you might find Dave Pattern’s solution a bit easier.

update: EdJohnston’s notes about why the ISBN1013 API can’t be linked from the Wikipedia ISBN page.

api, conversion, converter, international standard book numbers, isbn, isbn-13, isbn1013, libraries, library, web service

OpenSearch is a standard way of querying a database for content and returning the results.

The official docs note simply: “Any website that has a search feature can make their results available in OpenSearch format,” then adds: “Publishing your search results in OpenSearch™ format will draw more people to your content, by exposing it to a much wider audience through aggregators such as A9.com.”

It’s a lot easier to understand OpenSearch once you’ve used it, so take a look at A9.com and do a search. A9 isn’t the only OpenSearch aggregator out there, but it’s a great example. You can query a number of OpenSearch targets by clicking the buttons to add columns (also try resizing the columns), or you can add any of the 422 public search targets listed at A9.

Now, if you’ve got the beta of IE 7, you can see how it’s extending beyond server-side aggregators and into client software. Even better, you can see how this is becoming automigical via autodiscovery.

One of the most exciting features of OpenSearch is its support for complex queries as well as simple keyword searches, and the ability to return intelligent responses to a search, such as alternate search suggestions (think spelling corrections) and facets (hey, any librarians attending this?)

Now, the question for libraries is when are we going to demand OpenSearch interfaces from our information providers? The inclusion of OpenSearch in IE7 more than gives it critical mass, but so far it seems to be just something a few progressive library-types are experimenting with. In the short term, imagine how improved our metasearch tools would be if based on fully-implemented OpenSearch feeds (with the facets and suggestions). In the long term, I can’t imagine any aspect of a library’s online services not touched by this technology.

a9, API, lib20, libraries, library, library 2.0, OpenSearch, search, search aggregator, search api

I’m honored to join Katie Bauer, of Yale University Library, in a program coordinated by Mary Jane Kelsey, of Yale Law’s Lillian Goldman Library.

The full title of our program is Technology Scouts: how to keep your library and ILS current in the IT world (H-4, 4PM Tuesday, room 274). My portion of the presentation will focus on how we’re fixing up our catalogs, with a big emphasis on how APIs can be used to continuously reinvent the way we look at — and thus understand and use — the information we have. The big idea here is that as we separate the systems that store and manage our data from the applications that display and manipulate it, we open the door to faster, cheaper development — and make room for a bunch of new ideas along the way.

Because it’s a short program, I’ll only be able to gloss over some of the discussion of what’s wrong with our catalogs and how we’re fixing them, and while there’s a lot to say about WPopac, I’ll have to leave it to Jenny Levine to explain most of it.

My slides are online. As usual, all the underlined text is hotlinked along with all the screenshots, so click them for more information and detail.

AALL, AALL2006, American Association of Law Libraries, api, conference, law libraries, lib20, libraries, library, library 2.0, opensearch, presentation, rss, web 2.0, web20, xml

No, I’m not talking about the interface our users see in the web browser — there’s enough argument about that — I’m talking about web services, the technologies that form much of the infrastructure for Web 2.0.

Once upon a time, the technology that displayed a set of data, let’s say catalog records, was inextricably linked to the technology that stored that set of data. As we started to fill our data repositories, we found it usefull to import (and export) the data so that we could benefit from the work others had done and share our contributions with others. These processes were manual, or at least actively managed, and they depended on the notion that we had to have that information in our servers to be used by and displayed for our users.

Then technology evolved. Many applications now separate the components that store and manage the information from the components that display and manipulate it, and a few applications open up their data stores to the public via web services-based APIs. This is the concept that makes HousingMaps, ChicagoCrime, and Flickr Colr Pickr, among so many others, work.

Think about this for a moment: Our ILSs are inventory management systems, but our OPACs are (supposed to be) search and retrieval systems. The difference is obvious from here, but our vendors continue to operate as though you can’t have one without the other.

It might be easier to illustrate this point with an example or two.

Amazon Light is one of hundreds of applications based on Amazon’s web services. It connects Amazon’s inventory system with a custom built search and retrieval system, and it works. The Amazon Lite developers at Kokogiak didn’t need to build the inventory system, they only needed to think about ways to make the Amazon inventory more useful to you. Try it out, you might like the ability to search your local library (via some real hacks) or bookmark things via del.icio.us.

Or, you might not. Because Amazon allows anybody to access their catalog data, everybody has the opportunity to build a better, more usable catalog — or any other application that can benefit from the bibliographic details in it.

Take LibraryThing for example. It’s hard to explain what it is about people who read books that makes them want to list the books they own or have read or are interested in reading, but LibraryThing doesn’t worry about the why. It just answers the need. And because listing books, at least making a detailed list of books, can be time consuming, LibraryThing makes it easier by fetching the full details and book jacket from Amazon’s catalog. LibraryThing doesn’t need to “own” that info, it just needs access to it.

And what’s interesting is that LibraryThing is only one of a number of similar applications. Take a look at AllConsuming, Technorati’s popular books, and listal. These services connect Amazon’s catalog data with other data gathered from users or from web crawls, then they share the results. Here’s Ryan Eby’s lists of owned and wanted books, and here they are in RSS. Why RSS? Take a look at how he’s using the listal feed for his current reading list in his blog (lower-right column).

These are not technology demos. These are real applications. They are examples of how the world changes when you open up access to your catalog data. It’s what happens when we realize that the tools that store and manage our information are separate from the tools that display and manipulate that information.

Obviously, I’m about to make the (now-old) argument that we need to open our OPACs like this, but we also need take the lesson that easy and loose is winning over detailed and difficult — even in XML representations of our catalog data. And after looking at all that’s been done so far, I want to ask: why not adopt Amazon’s web services XML schema?

Is it so bad that it was invented elsewhere? Is it a bad thing that there are perhaps hundreds of applications that are already using data in that format?

Maybe the answer to those questions is yes, but here’s where technology can serve us again: we don’t have to choose. We don’t need to bet on one technology while we watch others progress faster. Our systems can output the same catalog data in any number of different ways. RSS, OpenSearch, MARC-XML, ATOM, EAD, or DC are all possible, easy in fact — if the inventory server architecture is open enough to allow it.

What do I really mean when I say library web services should be like Amazon web services? I mean they should be that accessible, that usable, that hackable. I mean libraries will benefit when people we’ve never met are spending their evenings building new applications to use our data. People are wondering how to get more programmers in libraries (example one, two), but I’m wondering how to make library systems more programmer friendly.

Fired up? Read more with my library catalogs should be like WordPress post, John Blyberg’s ILS customer bill of rights, and Ryan Eby’s open vs. turnkey discussion.

tags: amazon, amazon api, amazon web services, api, dublin core, ead, libraries, library, library catalog, marc, marc-xml, opac data, opensearch, web 2.0, web service, web services, web20, webservice, webservices, xml, xml server

I want Wikipedia to have an API, but it doesn’t. Some web searching turned up Gina Trapani’s WikipedizeText, but that still wasn’t exactly what I wanted. A note in the source code, however, put me back on the trail to the Wikipedia database downloads, and while that’s not what I want, I did learn that they’ve got a table of just the article titles (over 1.2 million of them) in their downloads.

Some of this is related to my interest in making Wikipedia work better in an academic library context, but I’ve got other plans too. With luck, we’ll see a beta release this week.

tags: api, application programming interface, article titles, database download, free encyclopedia, hacking, rss, web services, webservices, wikipedia, xml

We don’t need to hack Google Maps anymore. Now that Google has released a public maps API, we can make more reliable map-dependent apps (which will now have better browser compatibility, thank you). Within a few minutes of signing up for a maps API key I had put together the following of the Nevada Test Site Tour.

Yeah, click the satellite button, scroll, zoom… It’s real.

The API is all JavaScript, but I use a bit of PHP to iterate through an array of points and generate the code that puts the lines and pins on the map.

The most frustrating development with the Google Maps API is that each developer key is limited to a certain hostname and directory. It’s sensitive to things like “www.maisonbisson.com” instead of “maisonbisson.com” or “maisonbisson.com/blog/post/10594” instead of “maisonbisson.com/blog/” . That’s why this is loading in an iframe.

Thanks to The Unofficial Google Weblog for the tip that the API was released yesterday. As a minor coincidence, Yahoo! also released their maps API this week. Damn.

tags: api, google maps, google maps api, map api, mapping, maps api, nevada test site, yahoo, yahoo maps, yahoo!, yahoo! maps

Last week I got excited about the as-yet unreleased geolocation API for BBC Backstage. Now Larry D. Larsen of the Poynter Institute is excited too. In a post titled The Future of News (… Hint: GPS) he talks about putting news in geographic context with geolocation tags.

Eventually, clicking an article in a news/Google Map hybrid might zoom in to a 3D model of the area where an automatic pop-up starts playing a slideshow with pictures of the scene or streaming video along with the text news content. Imagine integrating Google Maps into your classifieds so readers could search for jobs based on what is close to their house. The possibilities are endless.

It’s aparently an old saw of his, but I hope his message starts to get through.

Credit goes to Ernie Miller for the blinking this at The Importance Of….

Technorati Tags: api, bbc, future of news, geolocation, gps, news, poynter institute, reported

The APIs aren’t yet out, but the BBC has already won me over with their Backstage BBC concept. Of course, I’m a fan of anything with an API, but the real deal here is that it appears they’re planning on releasing a “query by geo-location data” API — and I’m all a gaga about about geolocation. I’ll definitely be looking to see what takes shape across the pond.

Technorati Tags: api, backstage, backstage.bbc, backstage.bbc.co.uk, bbc, bbc backstage, geolocation, news

I had just sat down to post a note about an interview with J.D. Lasica in On The Media (listen to MP3) this week when I found David Rothman beat me to it. The interview was one of the better treatments of copyright issues that’s I’ve heard/seen in the (relatively-) popular media.

Here’s the summary from the OTM site:

For every move that media industries have taken to protect their copyrights, there has been an equal and opposite countermove by consumers. In Darknet: Hollywood’s War Against the Digital Generation, J.D. Lasica explores the realm in which so-called pirates operate – slicing, dicing, and sharing media to their hearts’ content. Lasica talks to Bob about how Hollywood is driving consumers further into the shadows and under the radar.

One of the best features of OTM interview, is the way they ran it along side a story about Backstage BBC, the new developer interface/API for the worlds most popular news website. How’d it work? It worked because — just like Google, Amazon, Yahoo, and others — they saw value in opening up their copyrighted material to see how others might “remix” it.

But because Rothman reported on the Darknet/Lasica interview first and better, I’m taking the easy way out by throwing down a few links and calling it good:

Lasica’s book: Darknet.

Lasica on Darknets –“private, encrypted spaces where social groups can communicate with each other and exchange files.” His concept, ten examples, and Wikipedia’s take.

Lasica on digital libraries: top 10 assaults on digital liberties.

Technorati Tags: api, bbc, bbc backstage, copyright, copyright issues, copyrights, darknet, david rothman, developer interface, on the media

WordPress’s XML-RPC support looks pretty good. Heck, it supports a half dozen APIs and works well with ecto … except for tag support, which is my only complaint with it so far.

The Movable Type API supports a “keywords” field that I’m thinking can be hijacked as a “tags” field instead, but while ecto sends the goods — I can see them in the XML-RPC data that gets sent out, WordPress seems to ignore them upon receipt. So I’m looking around the Wordpress plugin API docs for a solution, but all I can find is an undocumented mention of xmlrpc_methods in Skippy’s list of plugin hooks.

Technorati Tags: api, codex, ecto, plugin, tag, tags, xml, xml-rpc