As recently announced by Doug Kaye, the Conversations Network is embarking on a new phase. The existing channels, including ITConversations and Social Innovation Conversations, will continue. But rather than creating more such channels, the Conversations Network wants to help individuals and organizations capture and publish their own spoken-word audio, mainly in the form of events that are experienced only by attendees but that could be experienced by anyone, anywhere.

This new mission dovetails with PodCorps, a matchmaking service that connects event producers with volunteer stringers who can record those events. When it launched I wrote:

There’s a huge opportunity here to transform communication patterns in a fundamental way. Checking my local events calendar, for example, I see that the following event is scheduled for tonight at the local college:

Mon., Apr. 16
7 to 8:30pm
Pond Side 2 located on Bruder St – Keene State College

Building Smart – Highlighting Local Best Practices

Come and join us in discussing the challenges and successes of implementing innovative building materials, technologies, and design solutions into the built environment.

The information exchanged at that meeting, and at countless meetings like it, has historically been available only to those who attend. There are a million reasons why local folks who might want to attend nevertheless cannot: no babysitter, schedule conflict, etc. And of course remote folks have no opportunity to attend, even though the information exchanged might be highly relevant to them.

Assuming that more of these kinds of events become available, how will we find them? Doug writes:

We will do this using a social-networking model, which allows anyone to post links to recordings he or she finds, to build collections or playlists of their favorite recordings, to share those playlists with others, and to rate and comment on playlists or individual recordings posted by others.

In other words, Webjay for spoken-word audio. It’ll be interesting to see how this unfolds.

In my interview with Webjay’s creator, Lucas Gonze, we talked about some of the reasons why the curatorial model that Webjay promoted hasn’t yet succeeded. One of them, amplified in this comment by Greg Borenstein, is the fear, uncertainty, and doubt that pervades any distribution of — or even just linking to — MP3 files.

That kind of FUD shouldn’t be an issue for spoken-word audio that is explicitly free and legal. So I hope that we can evolve a culture of uninhibited collaborative curation. We’ll see.

I’ll also be curious to see what kinds of new channels and shows may arise from this effort. That isn’t the primary focus. Rather, the idea is to capture, share, and find recordings of events that have already been planned, organized, and held. The Conversations Network mainly seeks to enable the curation of those events. So someone might, for example, assemble the best recorded material in the alternative energy genre, from a variety of sources. I’d like to subscribe to that curator.

But there’s another kind of curation. It’s what I do when I select, from among the many people and ideas that I encounter, those I’ll feature on my two series of interviews: Interviews with Innovators and Perspectives. The world is full of interesting people and ideas, and we may also see the emergence of curators who select and highlight them in original ways. I’d like to subscribe to those curators too.

The Exchange-to-iCalendar script that I mentioned here is now published to CodePlex. It’s intended for organizations that run Exchange and would like to publish selected calendars in iCalendar (aka iCal, or .ICS) format without having to rely on a client machine running Outlook 2007.

I’ve never run a real Exchange server, so I’m wide open to suggestions as to how to actually publish the ICS file created by this little IronPython script. Right now, it just emits that file. For user Jon on Exchange host Zanzibar, you would do something like this:

ipy Zanzibar Jon > jon.ics

There are lots of ways jon.ics could get pushed to a web-accessible location, but I’m not sure what the default should be, or whether to do a filesystem operation, or an FTP transfer, or something else.

My idea is that you’d schedule this command to run on a regular basis, and that it would run under an account that has the necessary privileges to access the specified user’s calendar. But again, I’m not an Exchange admin, so if that sounds like the wrong thing, let me know what the right thing would be.

As for the iCalendar output, this script currently does the Simplest Thing That Could Possibly Work. It doesn’t, for example, try to “fold” long lines in the output (e.g., event summaries and unique IDs), which I gather the spec recommends but does not require.

There’s only been minimal testing. I’ve run it against a couple of different Exchange servers (2003 and 2007), validated the ICS output using this handy validator, and verified that the resulting files — containing both individual and recurring events — can be successfully imported, or subscribed to, in Outlook 2007, Google Calendar, and Apple iCal.

If you have a need for such a thing, try it and let me know how it goes.

Nick Carr’s essay in the current Atlantic Monthly crystallizes a lot of what I’ve been feeling for a couple of years about how our use of the Net is changing us. Not co-incidentally I read the essay in the printed magazine whose non-hypertextuality I experienced as a feature, not a bug. (Nick writes: “Unlike footnotes, to which they’re sometimes likened, hyperlinks don’t merely point to related works; they propel you toward them.”)

Although Nick doesn’t invoke Linda Stone’s touchstone phrase “continuous partial attention,” that’s the effect he’s noticing and reacting to. Whatever you think about the consequences, it’s clear that the Net doesn’t invite sustained attention, deep reading, and quiet contemplation.

Of course neither did cable television which, in the pre-Internet era, taught us to click-slice our attention much more radically than was formerly possible. But TV was just entertainment. You didn’t have to turn it on to do your job. Most of us do have to turn on the computer. As Paul Graham points out in Disconnecting Distraction, that’s a problem. He solves it by disconnecting his main work computer from the Net. But as work increasingly entails the use of software, and as software migrates into the cloud, I wonder how feasible that will be for most so-called knowledge workers.

Although Nick acknowledges that he’ll be branded “a Luddite and a nostalgist” I think his essay is spot on. The Net surely is rewiring our brains. What should we think about that, and what should we do about it? These are important questions.

Since we can’t turn back the clock, and we wouldn’t want to even if we could, I guess we’ll have to learn to live happily and productively in the noosphere we are creating.

Part of the answer is to develop — and teach — strategies that enable us to graze on the information commons in the most effective ways. I work hard at that.

But we also need strategies that enable us to retreat from that commons, and to experience sustained attention, deep reading, and quiet contemplation.

On that front, technology sometimes gives back with one hand what it takes away with the other. I’ll admit that it’s sometimes been a struggle for me, in recent years, to find that retreat in books, particularly fiction, and particularly in printed form. But portable long-form audio has been transformative. This weekend, on several multi-hour bike rides, I listened to the LibriVox version of Jules Verne’s Around the World in Eighty Days, beautifully read by Mark Smith (thanks Mark!).

It’s a great tale! I’d never have found the hours of couch time to re-read it, but I loved listening to it on my rides. (It was also nice to recall that I had written the software that simplifies downloading the book to a podcatcher.)

As I’ve said before, the quality of sustained attention that I find I can bring to long-form audio has been, for me, an unexpected benefit of great value. I’m sure our technologies are rewiring are brains in all sorts of ways, for better and worse. Often, those changes propel us into new and uncharted territory. But they can also help us reactivate ancient traditions, like oral storytelling, and rediscover their powerful neural effects.

On this week’s Interviews with Innovators show I spoke with Harry Lewis and Ken Ledeen, two of the three authors of the forthcoming book Blown To Bits: Your Life, Liberty, and Happiness After the Digital Explosion. The book explores why information technologies continue to produce surprising outcomes, and how society responds to them.

One of the threads running through the conversation is a perennial topic among thoughtful technologists: How much can most people understand about the underlying principles of information technology, and how much should they need to understand?

The authors believe that those principles are more explainable than we think, and as evidence they cite the remarkable tale of Hedy Lamarr, the famous Hollywood actress who — in collaboration with the musician George Antheil — invented and patented the idea of frequency hopping. Their goal was to help American torpedo guidance systems resist jamming by the Nazis. Now, of course, it has become one of the foundations of wireless communication.

Ken Ledeen tells the story at length, and with great animation, in our interview. Coincidentally, today’s NYTimes has a review of “an imaginative, two-character multimedia 80-minute play, ‘Frequency Hopping'”, that brings that same story to life.

We need to be careful about the lessons we draw from this tale. Although Lamarr the actress and Antheil the musician are usually referred to as the “improbable inventors” of frequency hopping, it didn’t happen by accident. They may have been scientific and engineering amateurs, but they were inspired and talented amateurs. And as Ken Ledeen explains, Hedy Lamarr’s social circle included a number of leading professionals from whom she absorbed a great deal of knowledge and understanding.

Still, if a pair of inspired and talented amateurs could invent such a thing, maybe we should have more faith in the ability of most people to understand its basis, and to reason about its implications.

I’m loving YouTube’s new video annotation feature, which Phil Shapiro alerted me to. Lots of people are going to have lots of fun with that. If you remember when MTV first started doing popup video, you’ll have some idea how much fun.

But from Phil’s perspective and mine, this is a seriously useful tool as well. He’s planning to annotate screencasts with it. And I found a great use for it here.

That short video features Bob Coffey, the senior climber at our YMCA. When I made and posted the video, I wasn’t quite sure how senior Bob was so I didn’t say. Yesterday I remembered to ask. Turns out he is 79.

It’s painful to add new information to a video. Opening up the raw file (if you even kept it around), adding a caption, recompressing, reuploading — it’s too much overhead, and unless there’s a compelling need you’re just not going to bother.

Of course you can update the textual wrapper, and alter the title or description. But in this case, I didn’t want to that. The information is much more effective when inserted midstream. After he’s scampered halfway up the wall, the popup annotation saying “Bob Coffey is 79 years old” makes the point more subtly and powerfully.

The point, by the way, is that we can do more, physically, at all ages, than we think. I’ve known a few people over the years who have redefined what’s possible, and it’s always an inspiring thing to see.

To complement my series on client-side calendar publishing, I’ve been looking for a way to push ICS files from Exchange. Why? A couple of local organizations with calendars I’d like to include in my calendar syndication project are running Exchange. It’s true that individuals within those organizations can use Outlook 2007 to publish calendars to the Internet. But companies like to manage these processes centrally. If the city wants its recreation center to publish summer activities, the city’s IT department should be able to do that whether or not the rec center’s desktop machine is alive.

Several folks suggested that the WebDAV interface to Exchange is the way to go, and after noodling on that for a while I’ve come up with a solution that seems to work. (I’ve tested it on a server here in my lab, and against my account on a production server.) I’m planning to release it as a CodePlex project, but as a Microsoft employee I have to cross a few t’s and dot a few i’s to get that done.

Meanwhile, since I’ve never administered Exchange, I have some questions for those who have. What I’ve got is a 100-line IronPython script that can be run on a scheduled basis. You give it a hostname and an account name, it reads events from that account’s calendar, and emits an ICS file.

First question: How does this fit in with your workflow? If you’re a town government, how would you like to manage your public calendar from Exchange? For example, would employees in various departments share one account that corresponds to that calendar? Would you rather divvy things up and then syndicate a set of calendars?

Second question: How will you want to publish the ICS file? My script only creates it. To publish the file to the Net, it could be copied to a directory on a webserver, or it could be uploaded to lots of places in lots of ways. It’s good to have choices, but it’s also good to have a sensible default, and I’m not sure what that should be.

Third question: Would you deploy this thing? I hope the small footprint will help. Being wary myself of solutions that haul in boatloads of requirements, I’ve whittled them down. You only need IronPython, plus of course the .NET Framework which it requires.

Originally, I was also using a few things from standard Python: command-line arguments, regular expressions. But it struck me that requiring all of standard Python for just those things was overkill, so I switched to their IronPython/.NET equivalents.

IronPython itself, resting as it does on the .NET foundation, is a tiny installation. Even so, it’ll be a new and unfamiliar thing to most people. Would an Exchange admin be willing to install IronPython on a production server and allow it to do the things this script does?

My guest for this week’s Interviews with Innovators is John Buckman, a serial entrepeneur with a passion for the world-changing possibilities of online communication. I was a customer of his first company, Lyris, whose email list manager I once deployed for a client. A few years later we met at SXSW, where John showed me his new project, Magnatune, and explained why he created it.

In this interview we discuss Lyris and Magnatune, plus some recent interests: BookMooch, an online book exchange, and Wreck a Movie, a “Web platform that is designed to harness the power of passionate Internet communities for creating short films, documentaries, music videos, Internet flicks, full length features, mobile films and more.”

This platform for crowdsourced film production, which is an outgrowth of the collaboration that led to Star Wreck, is now being used to create a new film called Iron Sky. You gotta love the tagline: “In 1945 the Nazis fled to the moon. In 2018 they are coming back.” As John says, who wouldn’t want to see Nazi invaders from the moon?

His ideas about how to do crowdsourcing closely parallel those of Yochai Benkler, as channeled by Bruce Sterling in his SXSW 2007 keynote, which includes a digression on this theme that begins thusly:

Socially motivated commons-based peer production: How to do it. You don’t just open up a website and invite comments. It actually has to be engineered with some thought and care. And I want to explain how this guy [Yochai Benkler] thinks it’s done. First you have to divvy up the work, because there’s a lot of it, and nobody wants to do it, and you’re not paying them, and you’re not ordering them, because you’re not the market and you’re not the state, so you can’t pay them and you can’t draft them. So you have to divide it up. It has to be granular, modular, and integratable. Granular means that even if I contribute for 5 minutes, I’m going to contribute something of merit.

Software is part of the answer. You need a framework within which to define tasks, parcel them out, and gather back results. Amazon’s Mechanical Turk is the best-known commercial example, but there are noncommercial precedents like distributed proofreaders and LibriVox. It’ll be interesting to see how Wreck a Movie follows and extends those examples.

John affirms Yochai Benkler’s point about granularity, and stresses the importance of precise task definitions.

If you say, nebulously, “Help us get press,” then nobody does anything. If you very specifically say this is the message, post to these press outlets, and name three URLs, that’s a well-defined thing. You get much stronger response. People need direction.

Also, I read recently that membership in volunteer organizations is down, and has been for a decade, but the amount of time people put into volunteer tasks is up. Why? People are less interested in open-ended commitments, instead they’re interested in knocking off specific tasks, and feeling a sense of accomplishment for finishing them.

As Bruce Sterling says, you have to engineer that scenario with thought and care. It’s a kind of engineering that is both social and technical, and some of the leading practitioners are game designers. For more on this theme, listen to Ned Gulley’s reflections on the MATLAB programming contest he’s been running for a number of years.

When David Stutz left Microsoft, he wrote a parting essay that invoked a new kind of Internet-oriented operating system characterized by “software that runs above the level of a single device.” Tim O’Reilly echoed that phrase here, and often used it to help explain what he meant by Web 2.0.

The recently-announced LiveMesh is a nice example of software that runs above the level of a single device. It runs symmetrically on all your computing devices, in the part of the cloud that’s associated with your devices, and in other parts of the cloud where services you transact with are running. This entire constellation is the LiveMesh platform which, as Ray Ozzie recently explained to investors, is an answer to this question:

What would an OS look like in a world of multiple devices, in a world where instead of the computer being at the center, you are at the center?

The platform’s connective tissue, as discussed in my interview with Ray Ozzie, is FeedSync, a synchronization system based on the same simple technology that powers the blogosphere: XML feeds of items, in RSS or Atom formats. Whether they represent big chunks of information like documents and media files, or small scraps of information like calendar events and status messages, LiveMesh objects are made up of feeds. All these objects synchronize across your mesh of devices and services using the same openly-specified FeedSync mechanism.

That openness is another key characteristic of an Internet operating system. So it’s nice to see that FeedSync isn’t only being applied in the context of LiveMesh. This week’s Perspectives interview, with Barbara Willett of Mercy Corps and Nigel Snoad of Microsoft Humanitarian Systems, details Mercy Corps’ use of FeedSync to collect, synthesize, and share information about the management of agricultural development programs in Afghanistan.

In this case, the synchronized data sources are humble Access databases for which Nigel and his team have developed a FeedSync adapter. They’ve also built adapters for spreadsheets and — what should be very interesting to Ken Banks and Joel Selanikio — for SMS messaging systems.

I love stories about pragmatic solutions that find new ways to use existing, simple, and widely-deployed technologies. This is clearly one of those. But it also illuminates an aspect of the LiveMesh platform that hasn’t yet been widely noticed or appreciated. One of its keystones, FeedSync, is an open and general-purpose building block that can be used by anyone, for any purpose.

If the Mercy Corps solution interests you, Nigel says that the toolkit he and his team built for them will be openly released in a few weeks. Watch the FeedSync blog for details.

The word drafting has many meanings but the one I’m interested in here comes from bicycling. When you ride closely behind another rider, you’re drafting. The leader pushes the headwinds out of the way, and the follower doesn’t have to push so hard.

Blogging can work that way too. I thought of this when I reallized that one of the benefits of subscribing to James Fallows is that I’m drafting on his interest in the fledgling air taxi industry. My interest in that topic is more than casual. I’ve interviewed DayJet founder Ed Iacobucci, for example. But James Fallows is way more deeply invested than I am, having written the seminal book on the topic, Free Flight.

I can do a pretty good job of tracking developments on that front by scanning the news, or better yet by subscribing to searches for terms like DayJet and Eclipse 500. But the best way is to draft on a blogger who is authoritative on the topic.

I don’t need to see every news story about DayJet, and pushing them all out of the way in order to focus on the ones that really matter is like pushing a headwind. But James Fallows is already motivated to push that headwind, so I can just draft on him. That way I get just the right air taxi newsfeed, with a dollop of expert analysis on top.

Happily, the analogy breaks down in a couple of ways. A cyclist can only draft on one other cyclist, and it’s a one-way relationship. The follower can’t simultaneously lead. With blogging, I can draft on many peoples’ interests, and many people can draft on mine, and sometimes the leader/follower relationship is reciprocal — I draft on you for topic A, and you draft on me for topic B.

For our purposes here, we can define blogging broadly to include the conventional format, but also microblogging formats like del.icio.us crumbtrails and Twitter tweets. Drafting, in the sense I mean here, can happen in any publish/subscribe medium.

As part of my project in community calendar syndication, I would like to find a way to push an Exchange calendar to a web-accessible ICS file. Although that isn’t a native function of Exchange, I’m sure it can be accomplished by way of the Exchange API, as an add-in or a scheduled server process. For maximum breadth, I guess the relevant API would be Collaboration Data Objects (CDO) rather than the newer Exchange Web Services.

I asked some folks on the Exchange team and none were aware of a component that does this. So I’ve set up an Exchange server in my lab, rolled up my sleeves, and am ready to dive in and see what can be done. But it never hurts to ask. Have I overlooked an existing off-the-shelf solution?

This post is part three of a series in which I’ll summarize what I know about publishing calendars openly on the web, for free, using popular calendar applications including Outlook, Google Calendar, and Apple iCal.

Apple iCal

If you have a .Mac account you can publish your calendar there, but
.Mac isn’t free, and the purpose of this series is to showcase free
calendar publishing options.

The solution here is to find a free service that uses the same
protocol, and the same kind of server, as the .Mac service uses.
The protocol is called WebDAV, and the server is a
special-purpose web server commonly used for calendar publishing.

It’s possible that your ISP already offers a WebDAV server you can
use, for no additional charge. But for many people it would be ideal if there were a free service available for this purpose. One such service is iCal Exchange.

Here’s the signup page:

After completing the form you’ll land here:

For private sharing you can create passwords and use the private URL, but our goal here is public sharing so the public URL — in this case, http://icalx.com/public/judell — is the one you’ll use.

Now switch to iCal, select Calendar, select Publish, and switch the Publish option from the default — .Mac — to Private Server. Paste the public URL you just created into the Base URL, and enter your iCal Exchange credentials in the Login and Password fields.

Now click Publish. Here’s the outcome:

The web address for your calendar is the public web address that iCal Exchange gave you, plus the name you gave your calendar (in this case, Jon), plus the .ics extension. For this example, it adds up to webcal://icalx.com/public/judell/Jon.ics.

This solves half of the problem. Your calendar is now published in a way that enables individuals to subscribe to it. It’s also available for syndication by online services like http://elmcity.info/events.

But the other half of the problem remains unsolved. In parts one and two of this series, we saw that the free calendar hosting options offered by Microsoft and Google provide links to hosted calendar viewers.

There are a variety of other hosted viewers, but as yet I’ve not found one that’s free, and can render any public calendar given a public URL like the one shown here. If such a service does exist, I’m hoping this entry will help me find it.

My guest on Innovators this week is Greg Wilson. We share common interests in collaboration and Python, but neither of those topics was the focus of this conversation. Instead, we discussed Greg’s unique and somewhat curmudgeonly take on high-performance computing. In his view, the HPC industry has focused on achieving bigger and faster computation at the expense of human productivity, verifiable correctness, and reproducibility.

I claim no expertise in that field, but Greg is an expert, so I wondered what he’d think about the approach discussed in one of my recent Perspectives shows, Cluster computing for the classroom. On that show, Kryil Faenov — Microsoft’s general manager for Windows HPC — describes a system that enables professors to define computational models that students can check out, tweak, and then run against large data on a compute cluster.

From a human productivity standpoint Greg likes that approach. But he’d prefer to see more attention paid to verifying the correctness of the models, and to ensuring that code and the data are managed in ways that make experiments reliably reproducible.

---

Disclosure: While working at Los Alamos National Laboratory back in 2000, Greg commissioned me to write a report on Internet Groupware for Scientific Collaboration.

This post is part two of a series in which I’ll summarize what I know about publishing calendars openly on the web, for free, using popular calendar applications including Outlook, Google Calendar, and Apple iCal.

Google Calendar

You’ll need a Google account. If you use Gmail you already have one. Start the calendar program by clicking the Calendar link at the top of the Gmail page.

To publish your calendar in ICS (aka ICAL) format, open the drop-down menu for your calendar’s name under the My Calendars heading, and select Calendar Settings.

The first tab on the ensuing page is called Calendar Details. If you scroll to the bottom you’ll see two sections containing sets of hyperlinked icons. The sections are labeled Calendar Address and Private Address.

You don’t actually have to make your calendar public in order to share both its ICS (ICAL) and HTML formats. You could use the second set of private links to publish (and otherwise communicate) those formats without exposing the contents of your calendar to the Google search engine. But if the goal is to advertise your calendar as widely as possible, you’ll want to do that. So, visit the second tab on this page, labeled Share this Calendar, and check Make This Calendar Public:

Now your ICS feed is active at an URL that looks like this:

http://www.google.com/calendar/ical/yourname%40gmail.com/
public/basic.ics

To capture your version of this link, right-click the ICAL icon in the Calendar Address section, and use your browser’s link-capture method: Copy Shortcut (IE), Copy Link Location (Firefox), Copy Link (Safari). You can paste the link into a web page that you publish, or into a web form or an email that transmits it to another site to which you want to syndicate your calendar.

Similarly, the web view of your calendar is active at an URL that looks like this:

http://www.google.com/calendar/embed?
src=yourname%40gmail.com&ctz=America/New_York

To capture your version of this link, right-click the HTML icon in the Calendar Address section and do as above. This link leads to a Google-hosted page for viewing the calendar.

If your web hosting circumstances allow you to use an HTML feature called IFRAME, you can instead embed the calendar in one of your own pages. The HTML code to do that is provided in the Embed This Calendar section.

This post is part one of a series in which I’ll summarize what I know about publishing calendars openly on the web, for free, using popular calendar applications including Outlook, Google Calendar, and Apple iCal.

Outlook 2007

With Outlook 2007, you can publish for free to calendars.office.microsoft.com. You’ll need a Live ID account. If you don’t already have one, a Live ID is useful for many other services too. To get one, start at login.live.com and click the “Sign up for an account” link.

To start publishing, right-click the name of your Outlook calendar as it appears under My Calendars in Outlook’s navigation pane, select Publish to Internet, and select Publish to Office Online as shown here:

You’ll land on this screen, where — for an open public calendar — you can just click OK and take the defaults.

Now you’ll be prompted for your Live ID credentials.

Enter the email address and password of your Live ID account. And check “Remember my password” so that Outlook can send calendar updates to the server automatically.

Here’s the confirmation:

Even though you likely won’t want to send individual invitations, click Yes anyway. That’s the easiest way to discover what the web address of your published calendar will be. Here’s the email message:

You don’t need to send it anyone, you just need to capture the calendar’s web address. Which, in this case, is:

webcals://calendars.office.microsoft.com/pubcalstorage/
j447ytlz27542/test_Calendar.ics.

If you publish that link on a web page (more realistically, with a label like Subscribe to calendar), visitors who click the link will be invited to launch one or another calendar program (such as Outlook, or Apple iCal) to view the calendar and subscribe to updates. That same address can be used by online services like http://elmcity.info/events which combine calendars from multiple sources.

The .ics in test_Calendar.ics stands for Internet Calendar Standard. The ICS file is useful for exchanging calendar information among calendar programs that run on personal computers, and among calendar services that live online. But it’s not something people can view directly on the web. For that, you’ll want to use a variant of the address that produces a web page people can see and interact with. Here’s the variant:

http://calendars.office.microsoft.com/en-us/pubcal/viewer.aspx?path=
/pubcalstorage/j447ytlz27542/test_Calendar.ics

To form your version of this link, copy the initial part of the above link — the part that isn’t bold — and then replace the part that is bold with the corresponding part from the invitation email shown above.

If you then publish that link on your website, it will lead visitors to a page like this:

Visitors to that page can view the calendar in several ways. And they can subscribe to the calendar by clicking the Subscribe link.

Earlier versions of Outlook

I’m still researching the options. Comments welcome.

My guest for this week’s Perspectives show is Caroline Arms, a digital preservation pioneer at the Library of Congress. She’s a leading student and promoter of digital formats for long-term preservation.

It was fascinating to hear her take on the interplay between the reality of market forces and the interests of cultural preservation. From the Library’s perspective, an important format is one that is both disclosed (i.e., openly specified) and widely adopted. The Library has few illusions about its ability to influence adoption, but it does participate in standardization efforts such as PDF/A and Office Open XML.

Caroline joined the Library of Congress in 1995 to work on the American Memory project, and she well understands that our memories are not only represented by commercially-published content, but also by personally-created content such as photographs and diaries. When that content is paper-based, it tends to survive benign neglect. But digital content doesn’t survive benign neglect, and the Library is thinking hard about the challenge that presents for the photographs and diaries we’re creating from now on.

Yesterday’s proposal for an association of URL-shortening services was motivated by that same challenge. It’s overwhelming to think about tackling the URL persistence problem in a general way, although there’s good progress being made in particular domains, notably scholarly publishing. But it strikes me that URL-shortening is an area where we could bootstrap a scheme that would provide at least some assurance of continuity, in a way that would be evident to a lot of mainstream users. It wouldn’t solve a major problem, but that’s actually the point. We need to pluck some low-hanging fruit, and start to raise expectations about the persistence of the digital resources we’re all creating.

The creator of a new URL-shortening service, urlborg, recently wrote to me to announce some new features. There are, at this point, quite a few of these URL-shortening services. I’m sure each has differentiating features, but before I explore the differences I’d like to see a new and important kind of commonality.

Each of these services invites you to invest in creating a set of short URLs that point to your own longer URLs. None of them provides any guarantees about the future availability of those short URLs. I’d love to see these services form an association that does make such guarantees.

There can never be a simple solution to the problem of linkrot. We don’t own domain names, we only rent them. As content management systems evolve, so often do the URLs they project onto the web. Even if an association of URL-shortening services guaranteed the continuity of short URLs, the long URLs behind them would remain as fragile as they are today.

Still, it would be an inspiring and forward-looking experiment to try. What if TinyURL, snurl, urlborg, and the others were members of an association that would inherit the URL mappings of any member that ceased to honor them? Given such a guarantee, I’d be much more willing to invest in the creation of URL mappings with any of the members, and to explore the features that differentiate them.

In my writeup on MIT’s Project Simile, and again in my talk at the CUSEC conference, I lauded an approach to collective information management that respects our actual linguistic nature. People don’t normally create vocabularies by committee. Rather, we absorb, imitate, innovate, and negotiate the vocabularies we use. Simile embraces that reality. It encourages people to name resources in ways that make sense to them, within the context of their tribes. Then it provides ways to map out equivalences among the terms used by different tribes.

This same idea of pluralistic naming and equivalence mapping came up in last week’s Perspectives interview with Quentin Clark: Where is WinFS now? The connection was implicit but it’s worth making explicit. Here’s what Quentin said:

QC: Going through the litany of technologies that have come from WinFS, one of them is the notion of what I refer to as semi-structured records. The schema is not necessarily all that well defined at the outset of the application. How does the database handle that? We had built WinFS around a feature called UDTs [user-defined types], which is a column type — a CLR type system type.

We finished that up, and we built a whole spatial datatype on it in SQL Server 2008, it’s all good stuff.

But when we stepped back and looked at the semi-structured data problem in a larger context, beyond the WinFS requirements, we saw the need to extend the top-level SQL type system in that way. Not just UDTs, but to have arbitrary extensibility.

So we did this feature in SQL Server 2008 that we internally refer to as sparse columns. It’s a combination of various things. First, a large number of columns. Right now there’s a 1024 limit on the number of columns in a single SQL table. We’re way widening that out.

That comes of course with the ability to store data that’s very sparsely populated across a large number of columns. In SQL Server 2005 we actually allocate space for every column in every row, whether it’s filled or not.

JU: This is what the semantic web folks are interested in, right? Having attributes scattered through a sparse matrix?

QC: That’s right. And that leads to another thing which we call column groups, which allow you to clump a few of them together and say, that’s a thing, I’m going to put a moniker on that and treat it as an equivalence class in some dimension.

Given my enduring fascination with del.icio.us as a prime example of social tagging services that enable real people to evolve metadata vocabularies in a natural way, that really got my spidey sense tingling.

Last November the New York Times ran an interactive visualization of one of the Republican debates that absolutely wowed me. On this week’s Interviews with Innovators show I spoke with two of its creators, Gabriel Dance and Shan Carter, about that project, and about some of their other work including the stunning Faces of the Dead in Iraq. It’s a great overview of how and why the NYTimes has been raising the level of its game — and therefore of everyone’s game — in the realm of interactive data display.

There’s an odd little Web 2.0 backstory about how we arranged this interview. When I cited the credits for the debate visualizer in my blog post, I had a hunch that my use of those names would appear on the creators’ radar screens. And sure enough, I heard back from Gabriel Dance. When I didn’t find any contact info for him on his website, I went hunting around and eventually found him on Facebook.

We then began an on-again, off-again dialogue that lasted for a couple of months, until we eventually settled on a time for the interview. At one point I tried to steer the discussion away from Facebook and into regular email, but for some reason that didn’t happen, so we wound up doing all the communication in Facebook.

When we finally got together for the interview, Gabriel mentioned that he’d never been involved in such a long Facebook email thread. Me neither. Somehow we got stuck in a loop where each of us thought the other preferred to communicate only in Facebook. I was glad to know that this wasn’t some kind of Gen-Y thing, and that we both thought it was a weird glitch.

The other delightful thing about this interview is the audio quality. Gabriel and Shan called me from the Times’ tape synch facility, so their half of the call was professionally recorded, then I merged their track with my locally recorded track. Nice!

In 2004 I interviewed Quentin Clark, who led the WinFS effort, for an InfoWorld cover story on Longhorn. We had dinner recently, and Quentin made a surprising remark. He said that although WinFS never shipped, many of the underlying technologies already have. I wanted to hear more.

So, on this week’s Perspectives show, Quentin expounds at length on the question: Where is WinFS now? Topics include schemas, the entity data model, filestream and hierarchical namespace support in SQL Server, and synchronization.

In general I’m trying to aim Perspectives at a wider audience. But although you have to be fairly technical to enjoy reading or listening to this interview, I coudn’t resist. It’s a fascinating story, and not one the technology press is ever likely to tell. From that perspective, when the WinFS project was shut down, the whole thing evaporated. But as we know, technologies often wind up being used in ways not originally intended. WinFS is a prime example.

Sean McGrath’s report on coping with RSI reminded me of a couple of things. First, I need to find out whether the chair-mounted split keyboard shown here is still available. It’s been hugely helpful to me over the years, but I’m not sure it can be replaced at this point, and that would suck.

(Update: Uh oh. Discontinued 3 years ago.)

Second, I’ve been meaning to note a connection between computational thinking and health. Sean writes:

RSI is about the most complex problem I have ever tried to debug.

His reference to debugging might seem like a geeky affectation, but I don’t think that it is. When you’re searching for the causes of health problems, including mechanical ones like RSI, it can be fiendishly hard to, as Sean says, “establish repeatable causal connections between events.” Our bodies are complex, layered systems. Problems arise at different levels; the levels interact; any assumption may need to be questioned. But ultimately our bodies are systems, and computational thinkers can be pretty good at hacking and debugging them.

You see it when geeks deal with RSI. And you also see it when they deal with obesity. I known seven or eight technical types who have slimmed dramatically in recent years. We’re talking major weight losses of 75 pounds, or 100, or even more. In each case they describe the process in the language of computational thinking. “I hacked my body.” “I debugged my metabolism.”

Sean is right to offer this disclaimer:

I am a computer geek. Not a medical practitioner. If you have symptoms, go see a doctor, ok?

And yet, in my experience with RSI and with other kinds of mechanically-induced soft tissue injuries, doctors can’t help much if at all. What’s required is realtime analysis and debugging of a complex system, on a continuous and perpetual basis. The person best equipped to do that debugging is you, the owner, operator, and inhabitant of the system.

It was a great pleasure to speak with Lucas Gonze for this week’s Innovators interview. Back in 2004, in Blogs + playlists = collaborative listening, I first wrote about webjay.org, the playlist-sharing service that Lucas founded and later sold to Yahoo. Later that year, I made an audio documentary about the people, the services, and ideas that I saw coming together to create a new kind of cultural curation. The factors in play included abundant talent, Creative Commons licensing, and linkable hypermedia.

That vision hasn’t materialized yet. In our conversation, Lucas and I discuss why it hasn’t — and how it might still.

In the realm of music, I think that Lucas’ project to reanimate 19th-century songs provides one of the missing pieces of the puzzle. Copyright restrictions are what sent him to the archives to learn, perform, record, and distribute these old tunes. But as he’s explored them, he’s realized that parlour music of that era was social and participatory in ways that are far less common today.

Lucas once wrote about how he was happy with a recording he’d made of a piece that he played with “only had a few mistakes.” The other day he wrote:

Imagine that we lived in a world where all photography was the kind you see in magazines. In this world all photos are taken by professionals and all the people who got their pictures taken are models at the peak of their career. If you had your picture taken normally, you’d think you were hideously ugly. That is the musical world we grew up in, and it’s bogus. Things don’t have to be that way.

In an era of cognitive surplus, as the pendulum swings back from consumption to production of culture, that’s a good thing to remember.

Something about the title of this week’s Perspectives interview, OpenSearch federation with Search Server 2008, has been nagging me ever since I wrote it. In the interview, Richard Riley and Keller Smith describe how the new Microsoft search server can extend its reach by sending queries to other search services that can return results as OpenSearch-compliant RSS or Atom feeds.

We call this activity federation, but the enabling technology is syndication. So is the group of participating servers a federation, or is it a syndicate?

Some definitions of federation, from 1 dictionary.com and 2 Merriam-Webster:

1 a federated body formed by a number of nations, states, societies, unions, etc., each retaining control of its own internal affairs.

2 an encompassing political or societal entity formed by uniting smaller or more localized entities: as a: a federal government b: a union of organizations

That seems too formal, too heavyweight, for an OpenSearch-mediated search scenario. When you modify a search service to return results in the OpenSearch format, you’re not necessarily joining any kind of union. You’re just making it easier for other entities to latch onto your search results.

OpenSearch was announced on March 16, 2005, at the Web 2.0 conference. That same day I adapted my version of the InfoWorld search service to use it. There was nothing special about what I did, which is why it only took a few minutes. I just added a variant of the query URL that returned results as RSS, with a few minor extensions to comply with OpenSearch.

Then I registered my service with Amazon’s A9, searched A9 for “Jean Paoli”, and saw the combined results shown here.

This arguably was a federation, because you had to join the club in order to have results from your service show up in A9. But nothing about OpenSearch required things to work that way. Other services could consume my search feeds without requiring me to register with them, or permit them.

What’s more, any RSS reader could consume those feeds. Although I’d done the OpenSearch hack to showcase integration with A9, it turned out that I’d solved another problem without even intending to. It was now also possible for individuals to subscribe to InfoWorld queries.

OpenSearch can involve federation, but more fundamentally it’s about syndication. So, do the participating entities form a syndicate?

1 a: a group of persons or concerns who combine to carry out a particular transaction or project b: cartel c: a loose association of racketeers in control of organized crime

2 a group of individuals or organizations combined or making a joint effort to undertake some specific duty or carry out specific transactions or negotiations

That doesn’t seem right either. We can get closer by focusing on the definitions that emphasize simultaneous publication:

1 a business concern that sells materials for publication in a number of newspapers or periodicals simultaneously

2 to publish simultaneously, or supply for simultaneous publication, in a number of newspapers or other periodicals in different places: Her column is syndicated in 120 papers

But these definitions still involve more business coordination than OpenSearch, or feed syndication in general, require. If I use OpenSearch to publish a search service within the enterprise, I don’t need to make a formal agreement with the Search Server administrator in order to enable that server to include my search results. I just need to publish my results as an RSS feed, and tell that person I’ve done so. That same RSS feed is available to users who may wish to subscribe to searches performed directly on my service.

It’s the same on the open web. When you adopt a syndication-oriented architecture, small pieces can be loosely joined, or they can be more tightly coupled. But the underlying publish/subscribe mechanism doesn’t determine that choice.

Chewing on these definitions is more than a pedantic exercise for me. In my local community, I’m trying to show how a particular use of publish/subscribe technology — namely, calendar syndication — can solve an important problem for people, organizations, and the community as a whole.

Federation would clearly be the wrong word for the network of calendars that I’m trying to bring into existence. I’ve been using the word syndication instead. But now I suspect that’s the wrong word too. I want to convey that we can create small pieces, that they can be loosely joined, and that important network effects will emerge. I don’t yet know what word or phrase will make that cluster of concepts light up in people’s heads.

In response to a popular recent item — “We posted weekly.pdf to the website. Isn’t that good enough?” — Sarah Allen echoes my favorite Sergey Brin quote. Sergey said: “I’d rather make progress by having computers understand what humans write, than by forcing humans to write in ways computers can understand.”

Sarah, citing weblog software as an example of software that enables people to write naturally, goes on to say:

Likewise, it is natural to record calendar information overlaid on a timeline with day, week, and month views that mimic traditional paper visualizations of time. This enables the software to generate structured data without people needing to think about it.

I mostly agree with her about blog software. And I would have been inclined to agree with her about calendar software too, until I started looking seriously into how people do — and often don’t — use calendar software.

Let’s look at a fragment of a softball schedule which, significantly, has been written as an Excel file:

Fri. Apr. 25	6:15	Whitney Brothers	Greenwald Realty
	7:45	Servpro	Athen’s Pizza
Sat. Apr. 26	9:00	WR Painting	Peerless Insurance

Notice what’s missing? There’s no AM/PM, because everybody is expected to know that 6:15AM would be too early for a Friday game while 9:00PM would be too late for a Saturday game.

Yes, it’s natural to view calendar information in ways that mimic traditional presentations. But it’s unnatural to write it using calendar software that constantly nags you to specify nitpicky details like AM and PM. People understand what’s a reasonable time for a Friday or Saturday game. Why can’t software figure that out?

I guess that’s why another recent item on parsing human-written date and time information struck a chord with readers. Until we create (and widely deploy) naturalistic interfaces, people are going to avoid the Procrustean bed that is conventional calendar data entry.

On this week’s Interviews with Innovators I spoke with Janis Dickinson, director of citizen science at the Cornell Ornithology Lab. We talked about several of the lab’s projects that involve collection and analysis of volunteer observations about birds and bird habitats.

Courtesy of the eBird project, for example, here is a view of first sightings of common bird species in New Hampshire. At first glance it might be tempting to see the preponderance of dates in the current decade as an effect of global warming. But to support that interpretation, you’d have to answer a bunch of questions about the evolution of record-keeping over the period, and the distribution, reliability, and bias of volunteer observers.

Extracting signal from noise is, of course, one of the classic bread-and-butter activities of information science. What’s fascinating here is the Web 2.0 angle. Birdwatchers are famously passionate data collectors who develop reputations among their peers. When they contribute their data to eBird — and thence to the Avian Knowledge Network — those reputations can begin to be measured, and used to tune the analysis of a large body of contributed data.

For example, the all-time latest reported sighting of the Nelson’s Sharp-tailed Sparrow in New Hampshire was on Nov 24 2007, by Michael Harvey. Is that unusually late? And if so, is it credible? To answer these questions, Cornell’s data crunchers can compare what was and wasn’t reported in the region around that time, by observers whose reputations are one kind of signal that emerges from noisy data.

Lately I’m obsessed with figuring out how to harness the cognitive surplus and put it to work doing better social information management.

The other night I attended a kick-off meeting for a group interested in advancing the cause of local food production in our region. Inevitably the discussion turned to questions that require data to answer. Who are the local producers? Where are they? What do they produce?

In the ensuing discussion, various sources of data emerged. There’s a USDA website, a state government website, a special-interest website, this or that blog. Two things were immediately clear to everyone. First, there would be no effective way to collate these existing sources. Second, most of the needed data wouldn’t be there anyway.

I’d like to be able to recommend the sort of loosely-coupled collaborative list-making method that works so effectively for me. But here’s why I can’t. The method presumes that all the things you’d want to collaboratively curate are already represented by URLs.

In the real world, some are and some aren’t. Consider two examples from this list:

Name: Darby Brook Farm
Day/Time:  8:00 AM – 5:00 PM
Season:  June 1 – October 1
Address:  347 Hill Road
What you’ll find: Vegetables, raspberries, apples.
More Info: 603.835.6624

Name: Stonewall Farm
Day/Time:  Hours vary
Season:  June – October
Address:  242 Chesterfield Road
What you’ll find:  Garden fresh produce through the Community Supported Agriculture (CSA) program, call for options
More Info:  603.357.7278,   bsaunders@stonewallfarm.org,  www.stonewallfarm.org

Because Stonewall Farm has a web presence, we can do all kinds of useful things with its URL. We can tag various bits of metadata onto it (location, products), we can derives views that include that information, we can syndicate those views.

Because Darby Brook Farm doesn’t have an URL, we can’t do those things.

Of course Darby Brook Farm does have an implicit URL-addressable identity at Lighten Up NH. That identity is the record in Lighten Up NH’s database that’s currently being published into a web page by its ColdFusion server.

If that record were directly URL-addressable, the implicit identity would be explicit. Using the record’s URL as a temporary placeholder, we could bootstrap Darby Brook Farm into a collaborative list-making regime based on URLs, tags, and syndication.

Later, when Darby Brook Farm does establish a real web presence, we can unhook its cloud of annotations from the placeholder URL and attach it to the official one.

This scenario highlights a subtle but powerful benefit of data-publishing technologies like Astoria. When you aggressively expose record-level URLs, you can enable the same methods that will work for Stonewall Farm to also work for Darby Brook Farm.

This week’s Interviews with Innovators show is a conversation with Raymond Yee, author of the recently-published Pro Web 2.0 Mashups.

The book is chock full of good examples. Even if you’re an experienced developer of mashups that involve Flickr, del.icio.us, Eventful, and the various mapping services, you’ll learn helpful strategies for using these services individually and in combination.

What we wound up mostly talking about, though, is the vast space of information that’s not currently available to be mashed up. That might be because the information isn’t online at all, or because it isn’t online in a form that’s tractable.

As a kind of social experiment I’ve been tackling this problem in my local community, with particular emphasis on calendar information. In this week’s interview, Raymond talks about tackling the same kind of problem with emphasis on geographic information. Both cases can exemplify a pattern that I’m calling shared responsibility.

Consider, for example, the public library. It hosts a variety of events, some of which are its own (children’s story hour) and some of which aren’t (an AA meeting). Who’s responsible for putting these events onto the library’s public calendar?

Clearly the library should publish its own events. But it needn’t necessarily feel obliged to publish other organizations’ events. In the case of AA meetings, for example, the library is only one of about a dozen venues around town. Shouldn’t AA publish its events to those venues?

We have the tools and services now to enable this kind of small-pieces-loosely-joined approach. In this case, acting as a proxy for AA, I published its regular meetings to Eventful. One of those meetings happens at the public library. So now when you visit the combined calendar, events at the library show up from multiple sources. One is clearly identified with the library itself, others are identified with the various groups using the library.

Of course nothing prevents the library from choosing to authoritatively publish all of the events that it hosts. But it’s useful to show how that can be a choice, not an obligation. If we take a decentralized, small-pieces-loosely-joined approach, information management chores that look insurmountable can turn out not to be.

Ray Ozzie joined me for this week’s Perspectives show. It’s available there as audio plus a text transcript, and you can also watch the video on Channel 9.

Ray opens the conversation by reflecting on his transition to Microsoft three years ago, and on the roles he and Craig Mundie will play as they jointly inherit Bill Gates’ responsibilities.

Next the conversation turns to a meme that Tim O’Reilly once evangelized: the Internet operating system. That phrase never resonated as powerfully as Web 2.0 did, but the ideas behind it are becoming realities. Ray applauds the work that Amazon and Google have done in this area. And he talks about how Microsoft’s legacy as a platform company, dedicated to helping developers succeed, will influence its approach.

In that context, Ray explores one piece of Microsoft’s emerging Internet operating system: the newly-announced Live Mesh. Sharing common DNA with earlier projects, notably Groove and before that Notes, Live Mesh is a data synchronizer born to the Web. The objects that it synchronizes are represented as RSS and Atom feeds, and are manipulated with a RESTful API that works symmetrically on local and cloud-based nodes.

Although the most visible Live Mesh application is a file-and-folder synchronizer, Ray notes that this is just one example of an application pattern that can apply equally to the synchronization of custom objects, like calendar events, across all the devices in a mesh. It also applies across the spectrum of application types, ranging from the browser to conventional rich clients to Web-based rich clients like Flash and Silverlight.

There’s another pattern for Live Mesh applications, one that’s less familiar. In this pattern, a website uses Live Mesh as a pipeline to communicate with Live Mesh users. If you’re running a travel site, or a bank, you can use that pipeline to transmit structured data to your users — for example, itineraries or transaction reports. It’s easy to create those XML feeds, you can leverage the Live Mesh infrastructure to deliver them securely and reliably at scale, they synchronize across all devices in each user’s Live Mesh, and they’re accessible to local applications using same RESTful feed APIs that were used to create them.

It’s almost 10 years since I began producing and consuming data feeds, initially in RSS format. Although I regard the syndication of data feeds, in general, as a transformative technology, the concept still makes no sense to civilians and has little or no effect on their lives.

In order to understand why not, and as a way of figuring out how to motivate a practical understanding of syndication, I’m tackling a problem whose solution doesn’t involve RSS, or Atom, or microformats, or XML. The problem is calendar syndication, and part of the solution is iCalendar, a non-XML format that all widely-used calendar programs support well enough for my purposes.

It’s only part of the solution because the real problem is that most people, most of the time, for most of their calendar-related activities, don’t use calendar programs. They use spreadsheets and wordprocessors, and they produce unstructured web pages and PDF files.

There was a time when, behind their backs, I would mock them for doing so. No longer. As I meet with intelligent and well-educated professionals in my community, and talk with them about how to synchronize calendar information from a variety of sources, I realize that they simply have no intuition about the difference between a PDF file and an ICS file that contain the same calendar information. Both are computer files, right? Both can be posted to the web, right? Both can be searched, right? Problem solved.

There are really two aspects to this missing intuition. First, the concept that some kinds of computer files are more structured than other kinds. Second, the concept that the structured kind can flow easily around the Net without loss of fidelity, and can deliver use value in a variety of contexts, whereas the unstructured kind is inert.

These are ways of computational thinking unknown to most people. As a school administrator, librarian, city planner, social worker, or retail store owner, nobody expects you to understand and apply these principles.

And yet almost everybody needs to harmonize personal and organizational calendars. And many individuals and organizations need to flow their calendar data into other contexts to promote and coordinate their activities.

So here’s my approach. I’m scooping up all the calendar information I can find for my community, in whatever form I can find it, and flowing it into a coommon view. Then I’m syndicating that view elsewhere to show that there’s nothing special about my aggregation.

The idea is to establish a critical mass by brute force, and allow people to see how, over time, sources that are structured and can syndicate will remain in the game, and sources that aren’t will have to sit out on the sidelines.

It’s turning into a nice case study of how organizations and individuals can negotiate shared responsibility for calendar information that’s of common interest. But that’s a story for another day. First things first. I need to give people a reason to care about using a calendar program — any calendar program, could be Outlook or Apple iCal or Google Calendar, so long as it exports iCalendar — in preference to a spreadsheet or word processor. Although the geek tribe can scarcely imagine why, that first step is a doozy.

For this week’s Interviews with Innovators show I spoke with Deepak Singh. This interview extends what has become an ongoing series of discussions with folks who are applying the principles of web 2.0 to the practice of science. This was, of course, the original purpose of web 1.0.

Other Innovators shows on this topic include conversations with Joel Selanikio about epidemiological data collection, Barbara Aronson about giving poor countries free subscriptions to biomedical journals, and Timo Hannay about the impressive stream of online innovations that’s flowing from the Nature Publishing Group.

My new Perspectives series has also explored this theme of Net-enabled science. There, I’ve talked with Catharine van Ingen and Dennis Baldocchi about collaborative analysis of atmospheric C02 data, and with Pablo Fernicola about using Word to produce scientific articles in the National Library of Medicine’s XML format.

For some reason I’ve never gotten around to doing stitched-together panoramic photos until recently. Today, with spring fever raging, I hopped on my bicycle, did one of my favorite circuits, and made this 360 view of Park Hill in Westmoreland:

It turned out to be an interesting study in perception. If you check the enlarged view, you’ll see a tiny, insignificant-looking church in the center of the spread, dwarfed by mailboxes in the foreground. In my memory of the scene, that church was the dominant feature. But what my eyes actually saw is what the camera saw: a tiny, insignificant-looking church.

Next time I’ll need to stand closer to it. And I’ll need to bear in mind that what we think we see is a heavily interpreted version of what hits the retinas.

Still, it was fun. I love that you can see the handlebars of my bicycle on the left, and the seat on the right.

I’m sure there lots of ways to do this, I’ve never really looked into it, but Windows Live Photo Gallery makes the whole thing a snap. From camera import, to photo stitching, to Flickr upload, was under 10 minutes. And most of that was CPU time.