Mashup Guide

The online Barnes and Noble store (barnesandnoble.com) uses ISBN-13 in the links to books. (e.g., RESTful Web Services) Amazon.com uses ISBN-10. Something to keep in mind to et LibraryLookup to work for Barnes and Noble.

Jon Udell was kind enough to make some comments on what I've written on his LibraryLookup bookmarklet in Chapter 1 (which I post here with his permission):

Under "How can it be extended": OCLC xISBN! That service solves a key problem with the bookmarklet version: that an ISBN does not uniquely identify a work. But it creates a new problem: a bookmarklet alone cannot perform client-side remixing (i.e., calling xISBN and then using its output to splice Amazon and the library). I've incorporated xISBN into several solutions:
• http://weblog.infoworld.com/udell/2006/01/30.html

  Being a Greasemonkey hack, this has limited reach. I've been meaning to try to produce a universal version that'd work with IE, probably using Turnabout (http://www.reifysoft.com/turnabout.php), and you've reminded me to prioritize that.

• http://weblog.infoworld.com/udell/2006/01/26.html

  This is actually a different kind of mashup, involving Amazon wishlists. It's very cool. But again, it has limited reach in the sense that RSS notification is geeky.

• http://elmcity.info/services

  This version eliminates RSS in favor of email, the idea being to appeal more broadly. Except it hasn't, because the conceptual barrier -- multipurpose your Amazon wishlist in order to receive notifications about availability in your local library -- is formidable.

  All three of these solutions could, and perhaps should, be generalized for multiple OPACs and multiple libraries, in the way that the bookmarklet generator has generalized the bookmark hack.

  That's it! Hopefully somebody will read this and take on one or more of these challenges, in case I don't get to them.

Today, I start posting early drafts of the Introduction and Chapter 1 of my book. I'm keen on hearing feedback from those of you who would like to read early drafts of my book. The latest versions of chapters will be linked from the table of contents.

Although my book will be fully released under a Creative Commons license once my publisher Apress and I finish off the first edition ("v 1.0") , I won't apply the license to the pre-v1.0. I don't want too much reuse of the materials until we've hit the level of quality of the first edition.

I will to being a bit nervous about posting early drafts publicly since the drafts are still rough around the edges (if not more deeply flawed!) but I will put some faith in the open source philosophy embodied in the mantra of Release Early, Release Often. One of my goals in writing this book is to create a community resource. The more input I can get from the community, the better. Moreover, I'd like to get as many improvements and fix as many mistakes ("bugs") as I can before the book gets committed to paper. As with software, it's easier and less expensive to make changes earlier in the process.

A note about the publishing process I'm using here:

• I'm using the standard Apress process of writing books in Microsoft Word. (I'm sure with the heavy representation of open source topics that there are many Apress authors who use another tool but I've decided to go with Word. I wrote my dissertation with LaTeX and I figure that it would be instructive to learn the ins and outs of Microsoft Office in the process of writing a book. I'm crossing my fingers that I won't have major Office corruption problems.)
• I will start with the easiest way for me to post my manuscript, that is, as a series of PDFs. I will move towards posting the manuscript in more flexible formats, such as transforming the book into a wiki that we can keep up to date.
• Although I don't have a good structure for aggregating discussion around chapters yet, I decided to experiment a bit with Google Docs and Zoho Writer. To that end, in addition to the PDFs, I'm uploading my draft chapters to the two systems.
  • Google Docs
    • Introduction
    • Chapter 1: Learning from Specific Mashups
  • Zoho
    • Introduction
    • Chapter 1: Learning from Specific Mashups

I admire the commenting system available at the Django Book site and hope to have a system in place that allows for inline annotation of my book. For now, I provide at least three places to provide comments:

• For the GoogleDoc version, I can add collaborators who would like to edit or comment directly on the manuscript. (Send me email.)
• For Zoho, people can tack on comments to the document.
• We can use the commenting system in Wordpress.

I look forward to using the Zoho APIs and the Google Docs API (which I'm sure will eventually be there.)

You will note the figures are currently missing from Chapter 1. Though I have a strong argument for posting these pictures under fair use, I'm in the process of securing all the copyright clearances just to ease everyone's minds about including screenshots in the book.

By the end of this week, I plan to post a draft of Chapter 1 ("Learning from a Study of Specific Mashups") for public comment. I'm a bit scared to do so since I see so many flaws in what I've written so far -- and am wary of having even more pointed out by others! I also know, however, that the more intelligent and constructive feedback I get on my manuscript before the words get committed to print, the better it will be for me, the book, and ultimately my readers.

I currently have a sidebar that discusses nomenclature: specifically, what is the relationship among the word mashup and remixing in the context of my book -- which is about "web mashups", the reuse and recombination of digital content. I'm tempted to just use the terms loosely and interchangeably and not to make a tight distinction between the terms. I'm not ready to go in that direction without taking another close look at the issue.

At this point, I am making some tentative conclusions, based largely on what I've read on the Wikipedia.

• mashup and remix are terms that have their origin in popular music.
• roughly speaking, a remix is a alternate version of a song while a mashup brings together elements of two or more songs.
• there seems to be a tussle on the article on web mashups (technically, "Mashup (web application hybrid)") as to whether an application which is a mashup has to be "web application" or any type of "application".

At this point, I will say that if I wanted to make the parallels from popular music hold up for digital applications, I would use remix to talk about scenarios that are about reusing or repackaging data without combining it with other content (e.g., using the Flickr API to make a web page that has only Flickr images) while reserving mashups to refer to combinations of data from a variety of sources (e.g., combining Flickr photos with photos from Yahoo! photos). But the lines are fuzzy and, imho, not worth the effort to draw too carefully.