Mashup Guide

Ever since Pro Web 2.0 Mashups came out, I've wanted to get the book on the web.  Publishing PDFs was a start -- but I have envisioned developing a full-blown web application, a book that would could interact with my readers, be self-correcting and self-updating.  It's only appropriate that a book about APIs and mashups should itself embody the techniques that are describe in it!

Well, it's going to be a while until I get there -- but I'm happy that I haven't taken the next step:  publishing a (X)HTML version of the book.   The canonical version of the book ended up being a series of QuarkXPress files.  I had written some Python appscript programs to convert the book to a simple homebrew XML representation but didn't have sufficient time to take it all the way to DocBook.  I hired Liza Daly's Threepress Consulting to do the bulk of the conversion to DocBook, leaving me some labor intensive details to fit my budget.  (BTW, Liza is a great person to work with, very  smart and responsive to my queries. )

With the book in DocBook, I have been using oXygen 11 to edit the files and transform them into XHTML. I was hunting around for CSS files for DocBook-derived XHTML, but found surprisingly few options.  The one I'm currently settling on to get me started is the stylesheet  for FreeBSD documentation (see the style in action on the FreeBSD site).   I'll definitely want to customize the stylesheet for the book to reflect the look and feel I desire -- but I'm happy with the starting point.

I'm pleased to announce that I've posted an  XHTML version of Pro Web 2.0 Mashups:  Remixing Data and Web Services. This should make it much easier for folks to use my book.  It also opens up some good opportunities for me to update the book, which I plan to do as I teach my Mixing and Remixing Information course this semester.

A warning: the XHTML translation has some technical flaws that I'm working to fix.  However, I figured that it was better to put a working version up and then fix it along the way.

Enjoy and let me know what you think!

My publisher and I have agreed to release my book under the By-NC-SA 2.5 Creative Commons license. Should we go even further in openness and license under a By-SA license and remove the commercial reuse restrictions? David Wiley's post Why Universities Choose NC, and What You Can Do at iterating toward openness prompted my own comment:

I’m very interested in this issue. I’m currently working on a book to be published by Apress on mashups (http://blog.mashupguide.net/about). The deal I have with my publisher is to publish the book under a By-NC-SA-2.5 license. As David knows, I was debating with myself on what license to choose from among By-NC-SA, By-SA, and the GNU FDL. I finally decided not to go all the way to By-SA because I was afraid that if we didn’t go with the NC restriction, a commercial player could undercut Apress (and me) by taking all the materials and selling it in a more commercially advantageous position. That is, I’m afraid of the prospect of someone printing and selling paper copies at cheaper cost or putting up my book on a commercial site and realizing advertising revenue for cheap (since they did not put in the money to produce the book in the first place.) I will admit that my fears may not be well-founded — so I’m interested in figuring out whether I should revisit the issue of licensing with my publisher. (It’s not that Apress is adverse to publishing books under the GFDL — see http://www.djangobook.com/license/, for instance.) I will say that the incident with Seth Godin’s book did not help with my fears though. (http://sethgodin.typepad.com/seths_blog/2007/02/please_dont_buy.html)

Bottom line: how do I make my work as open as possible while not opening my publisher and me up to being unfairly taken advantage of commercially? I’m not predicting that I’ll be making tons of royalties off my book, but I don’t want to have what little might be coming my way to be taken away either! Since I recently left the long-term employ of the University of California, I’m a bit more dependent on income from writing than I used to be.

This week, I'm working a version 1.5 (a cleaned up first draft) of Chapter 3 "Tagging and Folksonomies". The important task for me is to work with I already have in my manuscript. Still I like to step back for a moment and write out what ideally I'd like be able to convey to my readers about tagging and folksonomies and/or functionality that I would like to have in hand for my computer systems.

• I'd like to be to integrate the various implementations of tagging, wherever they are. For example, I use tags in Flickr, del.icio.us, and technorati. They all have somewhat different ways of expressing similar functionality -- but I'd like to use these systems in as seamless way possible.
• I like to apply tags to digital content, whether it is on my desktop computer, on one of the Web 2.0 sites, or it is on custom online collaborative spaces.
• I like to be to apply tags at a very fine grained level. For example, not to a video clip as whole, but to a specific time segment.
• I'd like to have better tools to visualize and query my tags, to have tools that assist me in tagging new materials based on what and how I've already tagged materials. I like to offerred suggested tags based on some mix of what has already been typed in,what my social networks uses, global usage patterns, and other things that I've tag already.
• Tools for name reconciliation and reduction of tags. I might have had inconsistent use of singular and plural tags and want to have tools that will help me clean up those inconsistencies
• Right now I have a mess of tags in delicious. I'd like some tool to help me clean them up. (Does del.icio.us direc.tor fit the bill?)
• I'd like to have better reconciliation between controlled vocabulary systems (e.g., LCSH) and folksonomies.

The observations I've written are abstract. I should think in terms of concrete systems. Systems I tag a lot in:

• Flickr
• delicious
• Amazon.com
• Librarything.com
• I do make categories on my WordPress blogs which seem to turn into technorati tags.

It would be useful to have a big list of systems that support tagging. I believe such a list exists already on the Wikipedia. Probably on the list are a lot of the social book marking sites, photo sharing sites other than Flickr, video sites like YouTube.

Starting today, I will be writing much more often on this weblog to narrate the progress of my mashup book. The writing has been going well, but needless to say, there's so much more to do. This week, I am working on two fronts: cleaning up Chapter 1, an overview of mashups, and drafting, Chapter 8 on the programmable Web browser, Javascript, and AJAX. Although I am writing many, many words in a word processor -- many of which I hope will make it into the final draft of my book, I long to write shorter pieces, which will facilitate the development of the book. That's why am I'm taking time out of the book to weblog a bit.

Let me tell you a bit about Chapter 8, whose working title is "Learning Ajax/JavaScript widgets and their APIs." In thinking about the chapter today, I realize that the big idea I want to get at is that the modern web browser is programmable and hence, is a rich platform for mashing up data and services. As a connoisseur of mashups, I would want to figure out all the different ways in which I could extend, change, subvert, and customize the web browser, which is the dominant client-side platform for exchanging information on the Internet. The possibilities are astounding for customization both in how a web server host communicates with others and how you as an end-user could process communications coming at you.

A specific example, and certainly not a surprising one, to cover in Chapter 8 is Google Maps, which I call (without great precision of wording) an Ajax widget. Ajax, because it involves the constant and fluid interchange of data between the browser and the server executed through JavaScript -- and a widget because one can use Google maps without knowing all the inner workings of Ajax. That is, you can use it at a high level of abstraction. (I do use Google maps as a specific instance of Ajax widgets but I cover Google maps again in greater detail in other chapters to emphasize the mapping (functional) aspect of it -- instead of the technical implementation part of it.)

Ajax is a rich subject, as can be seen in by the myriad books that have been published recently on the subject. I would like to put Ajax in the larger context of the programmable Web browser. Here I will admit to struggling with how to piece together a chapter that I believe should at least mention, if not plumb the depths of the following:

• both how an "ideal" W3C DOM-standards compliant browser works and how various browsers actually work in various areas: how javascript is implemented, object models behavior, CSS, events, etc.
• Javascript-based APIs, widgets such as Google maps -- what are they, how to use any all.
• non-browser environments for Javascript, such as Google Gadgets, Yahoo Widgets, Adobe Acrobat
• extension mechanisms in browsers (Firefox addons, Safari , IE , Opera)
• Javascript and browser debugging tools like Firebug
• Javascript libraries: how they relate and what can be intermixed -- and which ones are tied to which web programming frameworks.
• what people have done already on all these fronts using Javascript and remixing the browser
• how to write Javascript and Javascript widgets that can be reused by other people, including cross-platform Javascript
• ideas of what you can do in terms of mashups

I obviously would not be to cover all these topics, nor should I even try! What I plan to actually cover as a way into this big list of topics is the following:

• the lastest versions of Firefox, instead of looking in depth at all browers -- old and new
• the Yahoo UI Library, as a specific example of a packaged javascript library
• a walk-through of how to use Firefox + Firebug / Javascript Shell + YUI Connection Manager
• to build a Google Map example, as a way to get into Ajax widgets in general
• how to build a basic AJAX call to Flickr
• how to write a simple Greasemonkey script to lay the foundation of understanding Google Maps in Flickr , a major example in the book).

Because next week is spring break at UC Berkeley, I have a bit more breathing room to work on my book. While I need to turn in the first draft of Chapter 8 (on AJAX and Javascript) next week, my current priority is to recalibrate the schedule for the book as a whole. I'm please to see that my book already shows up on the Apress site as well as on Amazon.com. It's pleasing and a bit scary at the same time as I deal with the myriad details of finishing up the writing!

On this weblog, I will be writing about all aspects related to the writing of the mashup book, including many materials that won't ultimately get into the book itself. What's on my list of things to write about?

• things I learn about mashups, including questions I have
• the process of writing this book
• mushy, early thoughts that I'm working through
• updates on noteworthy matters on the web that merit (or don't merit) immediate comment
• supplementary materials
• answers to questions or responses to comments I get from readers

Over time, I expect to start posting early drafts of my book, ready for commenting. Ultimately, the completed texts, codes, illustrations from the entire book will end up on mashupguide.net.

On this new weblog, I will write about my book in progress, currently entitled, Pro (Web 2.0) Mashup Development: Remixing data and services to make the web your own. My publisher, which has been wonderful to work with, is Apress.

Although I'm busily and intensely writing my first chapters to make my deadlines, I have been looking forward for a while to write even more stuff--though, in an alternative, supplementary writing space. I need a place to work out some thoughts and, more importantly, to reach out to prospective readers -- such as you!

I have great plans for this blog and the rest of mashupguide.net, but like all great plans in my life, they may not turn out the way you expect.