Chapter 1

Learning from Specific Mashups

Before we set out to build our own mashups, let's study some specific examples. Mashups combine content from more than source into a new integrated whole. You can get to an understanding of a mashup by asking a number of basic questions:

* What is being combined?

* Why are these elements being combined?

* Where is the remixing or recombination happening?

* How are they being combined, both in the interface, but also behind the scenes in the technical machinery?

* How can the mashup be extended or elaborated?

This chapter will explore three major examples:

* housingmaps.com

* Google Maps in Flickr (GMiF) Greasemonkey script

* Jon Udell's LibraryLookup bookmarklet

I will analyze these three major examples using the questions posed above as a framework. A close study of each of these mashups will be amply rewarded when you come to create your own mashups. At the end of the chapter, I will also point out ways to find out more about other mashups.

Looking for Patterns in Mashups

One pattern we will see repeated among mashups that that link two websites is the combination three actions:

1. Data is extracted from a source website;

2. This data is translated into a form meaningful to the destination website;

3. The repackaged data is sent to the destination site.

Details differ among the different mashups, but the general pattern holds, as we will see in the three mashups presented in detail in this chapter. For instance, where the remixing happens in the three mashups differs among the example mashups, as we will see: a separate application as in housingmaps.com; right inside of flickr for the GMiF script, or within the browser without a change of interface for any website (as in the the LibraryLookup).

Although this pattern of data extraction, translation, and redirection is found in the mashups covered in this chpater, there are other patterns to be found in mashups. Chapter 9 will explore those patterns in detail.

Note: Mashup, remix, reuse, data, and services, Enterprise mashups

Throughout the book, I use a number of related terms (mashup, remix, recombine, data and services) to describe differing aspects of reusing intellectual and creative work to create derivative works. Of course, reuse -- whether in the form of artistic appropriation, scholarly attribution, literary quotation and allusion, parody, satire – has a long history throughout human intellectual, creative, and commercial endeavors. Some terms, such as reuse (as in "software reuse" or "code reuse"), have been in popular usage for a while. Others, such as "remix" and "mashup" have more recently arisen in the context of discussions around Web 2.0 to apply to the combination of data from disparate sources, often via the use of XML and XML web services. In ways, mashups has won out as the term to refer to web interfaces and applications that recombine content into something new, whereas the term "remix" is generally about reusing media, while still having broader usage ("remix culture"). Interestingly enough: Mashup and remix come from a play on musical concepts and contexts.¹

The boundary between mashup and remix is a bit fuzzy, though. "Mashup" and "remix" are terms that have their origins 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. 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.

Broadly speaking, mashups are remixing "data" and "services". By "data", I mean any digital content, whether it is on a computer network, on your computer or any other device. By "services", I roughly mean services as in "service oriented architecture" and "software as a service": web services, and any applications that can be reused.

Whereas mashups are strongly associated with Web 2.0, parallel developments going under such names as "composite applications" are occurring in enterprise computing and service-oriented architectures. Composite applications are also concerned with weaving together data and services, though they usually integrate corporate data and supply chains sitting behind firewalls instead of public APIs from Google and amazon.com. Although mashups and composite applications share common techniques, they are driven by vastly different cultural factors.

This book focuses on personal information instead of information reuse from an enterprise perspective. Personal information is distinct for its heterogeneity, its connection to personal information management, the need for mass customizability, and the many permutations of hardware, software, and data derived from the unique needs of individuals. Nonetheless, ff there are opportunities to draw upon synergies with enterprise Web 2.0 without going far afield, we will do so here.

End Sidebar

Housingmaps.com

When I explain mashups to others, I typically use the example of the website housingmaps.com, a mashup of craigslist.com and Google Maps. Housingmaps.com is useful in ways that are quick and easy to understand. Unlike many other mashups, it is actually useful and invites repeated usage. It also requires no software beyond a modern web browser. Moreover, housingmaps.com takes two already well-known web applications to create something new.

Insert 858Xf0101.tif

Figure 1-1. Housingmaps.com, showing a specific rental listing. Note the pictures and the link to craigslist. All the data is drawn from craigslist and then displayed in a Google Map.

What is being combined?

Housingmaps.com takes the list of houses, apartments, and rooms that are for sale or rent from craigslist and displays them on a Google map. Note that it was invented by neither Google nor craigslist by an individual programmer, Paul Rademacher, who at the time of its invention was not yet a Google employee.

Why are they being combined? What's the problem being solved?

Craiglist provides links to Google and Yahoo! maps for any individual real estate listing but does not map the listings collectively. It is handy to see at a glance where all the listings are, how they are clustered. Housingmaps.com lets you see on a Google map all the craigslist apartments or houses in a specific area, not just an individual item.

Where is the remixing happening?

The remixing occurs on the server-side, on a website (housingmaps.com) that is distinct from both the source website (craigslist) and the destination application (Google Maps). Data is drawn from the source and transformed into a Google Map, which is embedded in web pages at housingmaps.com.

How are they being combined?

The question reduces down to two parts: How does housingmaps.com

* obtain the housing and rental data from craigslist and then

* create a Google map of that data?

Unless Paul Rademacher has struck a special deal with craigslist, he must be "web-scraping/screen-scraping" craigslist (i.e., parsing the web pages, which were meant for human consumption) to get the listing information since craigslist currently has no public API, or RSS data feeds. It will be clear why this must be so once we look at what the role played by RSS and APIs in Chapter 4 and 6. Other people/services have screen-scraped craigslist to get information.³

To display the real estate information on a google map, the current version of housingmaps.com uses the Google Maps API,⁴ which is the official Google-sanctioned way of embedding Google maps in a non-Google owned web page. (We will look in detail at the Google Maps API in various other places, particularly Chapter 13.)

It's interesting to go into a bit of history here to understand the emergence of the mashup phenomenon. When housingmaps.com first showed up in April 2005, Rademacher was using the pre-official API version of Google maps. During the period between the release of Google Maps on February 8, 2005 and the publication of v1 of the Google Maps API (on approximately June 29, 2005⁵), there was a period of intense "hacking" of Google Maps, described in the following way by members of the Google Maps team⁶:

For this and other reasons we were thrilled to see "hackers" have a go at Google Maps almost immediately after we launched the site back in early February. Literally within days, their blogs described the inner workings of our maps more accurately than our own design documents did, and soon the most amazing "hacks" started to appear: Philip Lindsay's Google Maps "standalone" mode, Paul Rademacher's Housing Maps, and Chris Smoak's Busmonster, to mention a few.

Comparable mashups

There are many other mashups that involve extracting "geocoded" data (location information, often latitude and longitude) from one source to then place it on an online map (such as Google Map or Yahoo map). I will name two prominent examples here:

• Adrian Holovaty's Chicago crime map (http://chicagocrime.org), which is a database of crimes reported in Chicago, fronted by a Google Map interface

• Weather Bonk is a mashup of weather data on a Google Map. (http://www.weatherbonk.com/weather/about.jsp)

GMiF (Google maps in Flickr)

In the earlier days of Flickr (before August 2006), there was no built-in feature that allowed a user to show pictures on a map. The Google Maps in Flickr script was meant to fill in that gap by letting you see a Flickr photo on a Google map.

What is being combined?

"Google Maps in Flickr" (http://webdev.yuan.cc/gmif/) brings together Flickr pictures, Google Maps, Google Earth within the Firefox browser via a Greasemonkey script. Let me unpack this statement:

• Flickr (http://flickr.com) is a popular photo-sharing site.

• Google Maps (http://maps.google.com/) is an online mapping system.

• Google Earth (http://earth.google.com/) is a desktop "magic carpet" interface that lets you pan and zoom around the globe.

• Firefox web browser (http://www.mozilla.com/firefox/) is an open source web browser. Notable among its features is its extension/add-on architecture, which allows developers to add functionality to the browser.

• The Greasemonkey extension (http://Greasemonkey.mozdev.org/) is a Firefox extension that "allows users to install scripts that make on-the-fly changes to specific web pages. As the Greasemonkey scripts are persistent, the changes made to the web pages are executed every time the page is opened, making them effectively permanent for the user running the script."⁷ Greasemonkey scripts allows to you -- as the end-user of that website and not as the author of the website -- to make customizations, all within the web-browser.

Why are they being combined? What's the problem being solved?

GMiF is a Greasemonkey script that allows you as a user to display a Flickr picture on a Google map or Google Earth at the geographic location associated with that picture. GMiF was written to support "geotagging" in Flickr. Geotagging, in the context of Flickr, is the process of associating a location with a given photo, typically but not necessarily the location where the photo was taken. Until geotagging was officially integrated into Flickr with the use of Yahoo maps in August 2006,⁸ there was no direct way to associate this geocoding (location information) with any given picture. Rev Dan Catt catalyzed the mass-geotagging phenomenon by suggesting that Flickr users shoehorn the latitude and longitude information into the the tags associated with a photo. Many people took up the practice. The Google Maps in Flickr (GMiF) Greasemonkey script uses that geocoding for a photo.

I should replace this photo with one that will put in http://www.flickr.com/photos/mashupguide/.

Let's take a look at how GMiF works. Consider one of my own photos: http://flickr.com/photos/raymondyee/51350116/⁹ Notice two things (See Figure 1-2.):

1. that this photo has associated geotagging information.

2. the presence of the rightmost Gmap button right after the other pictures tied to a picture. This button is the result of the GMiF script, which inserts the Gmap button. In other words, if you do not have the GMiF Greasemonkey script installed, you would not see this button.

Insert 858Xf0102.tif

Figure 1-2. The flickr photo "Back to work" (http://flickr.com/photos/raymondyee/51350116/) with associated geocoding embedded in the tags: (e.g., geo:lat=37.87425 and the tag 'geotagged')

Pressing the GMap button brings up a Google Map embedded into the Flickr web page, with a "pin" indicating the location of the picture in question. The pin corresponds to the location of the photo.

Insert 858Xf0103.tif

Figure 1-3. Pressing the GMap button brings up Google Map

Clicking on the pin opens a callout with a picture and options of other things to do with the picture. Note how the latitude and longitude listed corresponds to the information in the geo:lat and geo:lon tags respectively.

Insert 858Xf0104.tif

Figure 1-4. Pressing the pin brings up the photo and further options.

Among the GMiF functions is integration with Google Earth. If you hit the "Fly To" button, you will be presented with a file to download. If you have Google Earth installed and it is configured in the default fashion, the downloading of the file causes Google Earth to be launched and you to be flown to the location of the flickr photo. (See Figure 1-5.)

Insert 858Xf0105.tif

Figure 1-5. Pressing the GMiF "Fly To" button launches Google Earth

How are they being combined?

We will work out the technical details about how GMiF is constructed in Chapter 9. The Greasemonkey script rewrites the HTML of the Flickr page to insert the GMap button (this "rewriting of the HTML DOM", as we will see later, is akin to looking in HTML source for where the Flickr buttons are and inserting HTML code for the button) Furthermore, JavaScript code (Javascript is a programming language used to control how elements of a web page behave) is added to embed a Google map in the Flickr page. when you as the user presses the GMap button.

Integration happens in the context of Flickr itself. Note how powerful this is. You don't have to go to another application to see the picture on a Google map. You get to use a slightly modified version of Flickr. These modifications do not require the intervention of Flickr itself. Hence there is room for a lot of customization. (Of course, there are pitfalls: perhaps Flickr really doesn't want you to monkey with its interface. Also, with enough Greasemonkey scripts, we might no longer have a common communal experience of Flickr a rather many fragmented understandings of the interface. I think these risks are worth it though.)

How does the integration with Google Earth happen? The downloaded file is a KML file. KML is a dialect of XML, which we will learn later is becoming the closest thing we have to the lingua franca for exchanging data . The KML file contains the location of the picture and a URL pointing to the picture. (Note that XML, in its various dialects, is used widely to move data from one website to another, one source to another.) KML is one dialect of XML that is used to exchange geographic type data that is also understood by Google Earth. In other words, GMiF takes information from one source (the URL of the picture, the lat/lon of the picture embedded in tags from Flickr) and translate that information into a form that is understood by the destination application, namely, KML for Google Earth. Once you translate that information, you still need to get the information to the destination; in this case, the transport happens through the formation and downloading of the KML file.

Admittedly, GMiF is quite hackerish, requiring the installation of the Firefox web browser (which does not come by default on Windows or Mac OS X), the Greasemonkey extension, and the GMiF script. But I bring this up here to talk about the lengths to which people are willing to go to experiment with their tools to combine things.

Comparable mashups

Mappr (http://www.mappr.com/), "an interactive environment for exploring place,based on the photos people take," is a mashup of Flickr and a Flash-based map.

formal versus informal APIs And integration mechanisms

I mentioned in previous sections how the proliferation of formal integration mechanisms in the form of APIs and XML feeds, for instance, are giving rise to many more mashups and remixed possibilities. It's important to note that we want to depend on not only these formal mechanisms, but also on informal mechanisms. Hence in this chapter, I want to teach you how to look for both formal and informal mechanisms. The example mashups that I describe here use both. I hope to convey to you how to look for those informal hooks.

LibraryLookup Bookmarklet

Parts of this section needs to be rewritten in light of ISBN-13.

Jon Udell's LibraryLookup bookmarklet¹⁰ makes it easy for you to look up in a library catalog a book you find from an online bookstores (such as amazon.com). In this sense, the bookmarklet is a mashup of online bookstores and library catalogs.

This mashup is less flashy than previous examples; it's also not server-side, like housingmaps.com. It is client-side like Google maps in Flickr (GMiF) is – but not exactly in the same way. Jon Udell's bookmarklet shows another way to create browser-based integration. A bookmarklet is "a small JavaScript program that can be stored as a URL within a bookmark in most popular web browsers, or within hyperlinks on a web page."¹¹ In some ways, this method is lighter weight than a Greasemonkey script; for instance, this bookmarklet does not require the Greasemonkey extension in Firefox or even the Firefox browser itself.

Let's look at this problem again, in terms, the framing questions posed before. What is being integrated? How are they being integrated? How are they are being integrated?

What is the problem of being solved?

You find a book at, let's say, Amazon.com, everyone's favorite quasi-library catalog, but instead of buying the book, you want to borrow it instead at your local library. If you want to buy it from Amazon, then no big deal: Amazon naturally makes it very easy to buy books!

The LibraryLookup bookmarklet makes it easy to go from a given Amazon page to the corresponding catalog page in your local library catalog – via the simple press of a button. This method is opposed to the obvious, tedious approach of manually searching for the book again in your local library catalog.

Is there a way to grab the information from your browser page on Amazon.com and send it to your local library catalog? There is a way to do so -- under certain circumstances – which happens to hold true for books being sold on Amazon.com. We can look at the URL of an Amazon page and see the presence of an ISBN. ISBNs are identifiers given to every book that is sold in the United States. They comprise 10 digits (0-9 in the first 9 digits, with the final digit being a check-sum and hence the possibility of an X for the last digit).¹² ISBN is an identifier, associated with the book. (Think of how you can call up a bookstore to inquire about the availability of a certain book. You could give some combination of title, author, publisher, year published etc. But this is a bit of a pain because of human transmission issues (spelling of names, etc.). There's also a lot of ambiguity -- an author by itself, could yield a lot of books. ISBNs are compact and correspond to one and only one manifestation of a book.

With an ISBN, we can concisely identify what we are looking for -- but can we search a library catalog for book by ISBN? Yes, we are in luck -- this is, the LibraryLookup bookmarklet, which 1) extracts an ISBN from the URL of the library catalog and 2) repackages the ISBN in a new URL to look up that book in a library catalog. Let's look in detail at how 1) and 2) work:

extracting an ISBN from the URL

The javascript depends on recognizing the pattern of the ISBN. We know that the ISBN-10 is 10 digits where the last digit can also be an X. If we look at the JavaScript code to send requests to the Berkeley Public Library, please see:

javascript:var%20re=/([\/-]|is[bs]n=)(\d{7,9}[\dX])/i;if(re.test(location.href)==true){var%20isbn=RegExp.$2;void(win=window.open('http://library.berkeley-public.org'+'/search/i='+isbn,'LibraryLookup','scrollbars=1,resizable=1,width=575,height=500'))}

The bookmarklet asks whether there is a part of the URL that looks like an ISBN through the following regular expression:¹³

([\/-]|is[bs]n=)(\d{7,9}[\dX])

The regular expression (regexp) looks for a slash or 'issn' or 'isbn' followed by 7-9 digits, which are in turn, followed by a digit or 'X'.¹⁴

packing up the ISBN to send to a library catalog

If the bookmarklet identifies an ISBN, it now passed that ISBN to the relevant OPAC (online public access catalog). Two steps are involved: 1) figuring out what catalog to send the ISBN and 2) formulating the appropriate query (URL) for the system.

How does the LibraryLookup Project generate a bookmarklet for the relevant library catalog? One can image a system, backed by a comprehensive database of libraries, that presents you a list of libraries from which you can chose one. Some automation might be possible. Look at the OCLC Open WorldCat with its "find a book in the library close to you" functionality.¹⁵ In order to provide such functionality, one would need access to a comprehensive list of libraries and their locations combined with the ability to figure how far a library is far from you. (It might be possible to deduce your location based on your IP address, but such techniques tend to be error prone.) Jon Udell started building a directory of libraries, but found it too difficult to keep it comprehensive and up-to-date. The alternative approach Udell evolved is to take advantage of the fact that most library OPACs are one of about 20 systems.¹⁶ Hence, one is reducing the set of libraries to a parameterization problem. That is, you need to do is to figure out what type of OPAC you are dealing with and enter a URL that corresponds to that library OPAC. Udell's script then generates the appropriate bookmarklet for you.

Let's look at an example, using my own local library, the Berkeley Public Library (BPL) (http://www.berkeley-public.org/screens/opacmenu.html). I survey the examples that Udell shows¹⁷ and figure out, based on similarity of appearance, that the Berkeley Public Library OPAC is an Innovative system. I then type in the Base URL for the BPL OPAC (http://www.berkeley-public.org) and the name of my library, hit submit, I get:

javascript:var%20re=/([\/-]|is[bs]n=)(\d{7,9}[\dX])/i;if(re.test(location.href)==true){var%20isbn=RegExp.$2;void(win=window.open('http://www.berkeley-public.org'+'/search/i='+isbn,'LibraryLookup','scrollbars=1,resizable=1,location=1,width=575,height=500'))}

Insert 858Xf0106.tif

Figure 1-6. The LibraryLookup Bookmarklet Generator with parameters for the Berkeley Public Library.

Let's see this bookmarklet in action. (I suggest you get the bookmarklet for your own local library.) Here I illustrate the bookmarklet for the Berkeley Public Library, using Foundations of Ajax, published by Apress, with ISBN-10 of 1590595823. If you were to go to the corresponding amazon.com page

http://www.amazon.com/Foundations-Ajax-Foundation-Ryan-Asleson/dp/1590595823/

and hit the BPL LibraryLookup bookmarklet, you would see a window pop up showing the book in the Berkeley Public Library. (See Figure 1-7).

Insert 858Xf0107.tif

Figure 1-7. Invoking the LibraryLookup bookmarklet to look up Foundations of Ajax at the Berkeley Public Library

How can this mashup be extended?

There are some limitations with this bookmarklet. If you want to look at a lot of libraries in your area, you might find it tedious to create the bookmarklet for each of these libraries. One approach is to modify the bookmarklet to send ISBNs to the OCLC open worldcat catalog. Here's the corresponding bookmarklet:

javascript:var%20re=/([\/-]|is[bs]n=)(\d{7,9}[\dX])/i;if(re.test(location.href)==true){var%20isbn=RegExp.$2;void(win=window.open(' http://worldcatlibraries.org/wcpa'+'/isbn/'+isbn,'LibraryLookup','scrollbars=1,resizable=1,width=575,height=500'))}

To see another limitation of the LibraryLookup bookmarklet, if you use the Berkeley Public Library bookmarklet to see whether Milosz's New and Collected Poems: 1931-2001 is in or the library by first looking it up at amazon.com and finding a paperback version (http://www.amazon.com/exec/obidos/ASIN/0060514485) and invoking the bookmarklet (to get to http://library.berkeley-public.org/search/i=0060514485), you might be surprised to find that the book there since the Nobel Prize winning poet spent the last 40 years of his life in Berkeley. It turns out that yes, there is a copy of the book in the Berkeley Public Library of that copy is a different edition with a different ISBN. See http://library.berkeley-public.org/search/i=006019667X. Different editions of a work have different ISBNs. Furthermore, it's not obvious how to derive the ISBN of related editions.

This is another reason why you might want to send your lookup queries to the OCLC, which does look for related editions too. See

http://worldcatlibraries.org/wcpa/isbn/0060514485

and type in 94704 to see that even though you feed in the softcover ISBN, you can find the hardcover edition at the Berkeley Public Library.)

Comparable mashups

BookBurro, in the form of either Firefox extension and Greasemonkey script, brings up the price of a corresponding book as a pop-up.

LibraryThing is "an online service to help people catalog their books easily."¹⁸ LibraryThing is much more than a typical mashup, but has elements that are mashup-like – including the thingISBN API¹⁹ described in the following way:

Today I'm releasing "thingISBN," LibraryThing's "answer" to xISBN. Under the hood, xISBN is a test of FRBR, a highly-developed, well thought-out way for librarians to model bibliographic relationships. By contrast, thingISBN is based on LibraryThing's "everyone a librarian" idea of bibliographic modeling. Users "combine" works as they see fit. If they make a mistake, other users can "separate" them. It's a less nuanced and more chaotic way of doing things, but can yield some useful results.

There are, of course, many mashups other than the three that I have highlighted in this chapter. One can always learn more by studying more examples of mashups. You can certainly start with the mashups listed as comparable ones to the three major examples.

In studying mashups, you will find the website programmableweb.com (run by John Musser) to be a highly useful resource. It is a database of mashups, as well as of APIs. From it, you can see which mashups and which APIs are popular. I will come back to tell you more about programmableweb.com

Summary

In this chapter we studied three major examples of mashups: housingmaps.com, Google maps in Flickr, and the LibraryLookup bookmarklet. By posing a number of analytic questions (What is being combined? Why are these elements being combined? Where is the remixing or recombination happening? How are they being combined, both in the interface, but also behind the scenes in the technical machinery? How can the mashup be extended or elaborated?), we saw a repeated pattern:

1. Data is extracted from a source website;

2. This data is translated into a form meaningful to the destination website;

3. The repackaged data is sent to the destination site.

There are important differences among the various mashups, specifically on where the integration happens and what specifically is being integrated. For instance, housingmaps.com is a server-side application, whereas the mashing up of GMiF and LibraryLookup occurs within the browser.

Now that we have a sense of how mashups are constructed and what they are used for, we turn now to a study of the individual services and sources of data that can be recombined.