Richard, by the way, would like to add the privacy/surveillance issues arising from smart meter deployment to his list of causes, and is looking for someone who wants to lead that charge. If you’re interested and qualified you are welcome to contact him. Here, as I have now learned firsthand, is the protocol. You’ll write to him at rms@gnu.org. You’ll receive an autoreply that begins:

I am not on vacation, but I am at the end of a long time delay. I am located somewhere on Earth, but as far as responding to email is concerned, I appear to be well outside the solar system.

After your message arrives at gnu.org, I will collect it in my next batch of incoming mail, some time within the following 24 hours. I will spend much of the following day reading that batch of mail and will come across your message at some point. If I write a response immediately, it will go out in the next outgoing batch–typically around 24 hours after I collected your message, but occasionally sooner or later than that. Please expect a minimum delay of between 24 and 48 hours in receiving a response to your mail to me.

If a conversation ensues, it will happen on that cycle. This strikes most people as odd. As Jeremy Zawodny once noted, though, Richard Stallman is Getting Things Done. Old School.

Then, last week, something else went wrong. The widgets in the right column were getting bumped down by a post that didn’t belong in that column. I tried a few debugging strategies and then wrote to WordPress.com support again. Here was the prompt response from macmanx:

You’re all fixed up now. You had an extra div tag in “Meta-tools for exploring explanations,” but I removed it.

Oops. I know how to validate HTML and should have caught that myself. It’s not something I’d have wanted to bother the support team with. But they didn’t make me feel like a jerk. Again the problem was handled promptly and cheerfully.

You know, we tip for all sorts of services in the physical world, including ones delivered far less capably. Why not tip for excellent online customer service? If there were a tip jar for WordPress.com I’d have used it both times.

I was talking about Bret Victor’s notion of explorable explanations, which he illustrates on a page called Ten Brighter Ideas. I’d looked at it before, but when I revisited it yesterday I had trouble believing that the following claim could be true:

If every US household replaced 1 incandescent bulb with a compact fluorescent bulb, we’d save 11.6 TWh (terawatt hours), which is the energy equivalent of 1.5 nuclear reactors or 9.5 coal plants.

Some people intuit what these units and quantities mean. But most of us — me included — don’t. And even experts are prone to error. A few months ago I spotted one such error. A Ph.D. economist wrote an editorial that consistently used billions of barrels of oil rather than, as intended, millions. The column was syndicated to hundreds of newspapers, and so far as I know nobody noticed until I happened to check.

What prompted me to check? My friend Mike Caulfield, who’s been teaching and writing about quantitative literacy, says it’s because in this case I did have some touchstone facts parked in my head, including the number 10 million (roughly) for barrels of oil imported daily to the US.

The reason I’ve been working through a bunch of WolframAlpha exercises lately is that I know I don’t have those touchstones in other areas, and want to develop them. Having worked a few examples about global energy, I thought I’d built up some intuition in that realm. But in this case the intuition that prompted me to check Ten Brigher Ideas was wrong.

When I did check, things went completely off the rails:

If 111 million households each swap out one 75W bulb for a 25W bulb, saving 50W each for 180 hours (i.e. half of each day for a year), we’re looking at 100,000,000 * 50W * 180hr = 999GWh. We’re off by a factor of about 1000.

As Pasi points out in a comment:

Hmm, “half of each day for a year” is not 180 hours, but 365*24/2=4380 hours?

My brain thought days, my fingers wrote hours. I think I’m slightly dsylexic when it comes to units, and so I’m prone to that sort of error. It’s another reason why I use WolframAlpha to check myself. When I do that, I try to take advantage of WolframAlpha’s marvelous ability to automate conversions. For example, during an earlier exercise I needed to visualize the gallon equivalent of the energy released by combustion of one kilogram of gasoline. Normally this would entail looking up the density of gasoline, 0.726 g/cm³, applying that constant, and then converting to gallons. But in WolframAlpha the phrase density of gasoline is meaningful and can be used directly, like so:

http://www.wolframalpha.com/input/?i = ( 1 kilogram / density of gasoline ) in gallons

Similarly, here’s what I could have done to check the Ten Brighter Ideas claim:

http://www.wolframalpha.com/input/?i = (1/2 year) * 111,000,000 * 50W as TWh

That comes to 24 TWh, which is in the ballpark of the claimed 11.6. Maybe Bret assumed lights are cumulatively on 1/4 of the time, I haven’t checked, but if so that would nail it.

Why didn’t I write the WolframAlpha query that way in the first place? Because, I think, we still expect to do a lot of basic computation ourselves. You want the answer in hours? Put hours in. How many? You can figure that out. But should you?

I think it depends. It’s good to exercise your inboard computer — not only to calculate results but also to store and retrieve certain touchstone values. But it’s also good to delegate calculation, storage, and retrieval to outboard computers that can do these things better than we can — if that delegation can be smooth. WolframAlpha points to one way that can happen, Bret Victor’s simulations point to another.

Others imagined what the educational value of such a system might, or might not, be. Noting that Bret’s demo “looks like a powerful visualization system,” Mark Guzdial wrote:

The problem is that visualization is about making information immediate and accessible, but learning is about changes in the mind — invisible associations and structures.

Ned Gulley echoed Mark’s concerns. Citing Bret’s 2009 essay Simulation as a Practical Tool — which contains live demos that use simulation to solve a physics word problem — Ned writes:

It’s beautiful! And it works well as long as you don’t want to modify the essential parameters of the problem. But Victor isn’t helping us learn the metatools that he uses to create this environment. To be fair, that wasn’t his goal, but as a user, I feel like I’m locked in a pretty small task box. More to the point, it’s expensive to create these interactive gems, and there’s only one Bret Victor.

Victor’s real power is his ability to rapidly create and deploy these tools. In a twinkling he can size up a task that is worth studying, put a box around it and spin a tool. He does this so effortlessly, with such mesmerizing legerdemain, that we lose sight of this meta-skill. What Victor was really doing in his talk was illustrating the power of tool spinning, the rapid creation of customized, context-sensitive, insight-generating tools. Direct manipulation is good, but the nature of direct manipulation changes with the context, and the context can’t always be anticipated.

My preferred goal is to make tool spinning (and tool sharing) as easy as possible. If tool spinning is easy, if that is the expressive skill that we give our users, then small task boxes aren’t a problem. You can always make more tools.

Don’t use the thing Bret made. Do the thing that Bret does.

Ned’s right about tool-spinning and I’ll come back to that. But first I want to consider Mark Guzdial’s critique, cited by Ned, that interactive simulations don’t help us build the mental muscles we need to reason analytically and symbolically. Indeed not. But Bret doesn’t claim that they do! In Simulation as a Practical Tool he says flatly:

Regardless of how it’s taught, most people will never be comfortable entering this level of abstraction in order to explore the problems of their lives.

That’s true for the physics problem Bret solves in that essay, it’s true for the programming challenges he tackles in his CUSEC demo, and it’s also true in all scientific and technological realms. Some people can reason effectively using abstract symbol systems. Most think more concretely and reason best about what they can see, touch, explore, control. What matters in the end is that people can reason effectively, about all sorts of things, especially about the scientific knowledge and technological machinery on which our civilization depends.

In his 2011 essay Explorable Explanations, and the companion demo Ten Brighter Ideas, Bret imagines a world in which public discourse about energy (or health or climate or economics) is facilitated by an explorable explanation that:

• States assumptions, and ties them to supporting data.

• Makes connections among interacting variables.

• Enables the viewer/user to vary assumptions and observe consequences.

An example from Ten Brighter Ideas:

Suppose 100% of US households replaced 1 bulb at random with a compact fluorescent.

This, we learn, would save 11.6TWh per year, which is equivalent to 1.5 nuclear reactors or 9.5 coal plants. The underlined elements — 100% of households, 1 bulb — become sliders you can use to vary these inputs. What if only 20% of households get with the program? If each replaces 5 bulbs, we can get the same 11.6TWh savings.

Wait a sec. 11.6TWh? Terawatt hours? Let’s check. If 111 million households each swap out one 75W bulb for a 25W bulb, saving 50W each for 180 hours (i.e. half of each day for a year), we’re looking at 100,000,000 * 50W * 180hr = 999GWh. We’re off by a factor of about 1000. Let’s find out why.

The constants Bret is using are right there in the HTML. Here’s the relevant one:
Likewise the data that Bret is using is right there in the HTML. Here’s the relevant citation:

US Nuclear Generation of Electricity :
December 2009

The spreadsheet gives total US nuclear power production for 2009 as 798,854,585 MWh. That’s roughly 800 million MWh. I guess the constant should have been 796.488e9, not 796.488e12. (Or the units should have been GW not TW.) Checking that: http://www.wolframalpha.com/input/?i=800 million MWh = 1/4 yearly energy production of all nuclear power plants. OK, that makes sense. I can believe US nuclear energy production is in the ballpark of 1/4 of worldwide production.

Now, here’s the claim that Bret’s active document explores:

If every U.S. household installed just one compact fluorescent light bulb, it would displace the electricity provided by one nuclear reactor. 1 = 1!

It comes from a brochure at BeyondNuclear.org entitled Ten Reasons to Say No to Nuclear and Ten Brighter Ideas. As we can see, that’s wrong. We’d need 1000 bulbs per household, not 1 bulb, to displace one nuclear reactor. 1000 = 1!

This kind of thing is embarrassing, but it happens all the time. And while Bret will surely wince if he happens to read this (unless I’ve got it wrong somehow, in which case I’ll wince),

Wince. (See comments.)

We need robust explorable explanations that state assumptions, link to supporting data, and assemble context that enables us to cross-check assumptions and evaluate consequences.

And we need them everywhere, for everything. Consider, for example, the current debate about fracking. We’re having this conversation because, as Daniel Yergin explains in The Quest, a natural gas revolution has gotten underway pretty recently. There’s a lot of more of it available than was thought, particularly in North America, and we can recover it and burn it a lot more cleanly than the coal that generates so much of our electric power. Are there tradeoffs? Of course, There are always tradeoffs. What cripples us is our inability to evaluate them. We isolate every issue, and then polarize it. Economist Ed Dolan writes

These anti-frackers have a simple solution: ban it.

The pro-frackers, too, have a simple solution: get the government out of the way and drill baby, drill.

The environmental impacts of fracking are a real problem, but one to which neither prohibition nor laissez faire seems a sensible solution. Instead, we should look toward mitigation of impacts using economic tools that have been applied successfully in the case of other environmental harms.

In order to do that, we’ve got to be able to put people in both camps in front of an explorable explanation with a slider that varies how much natural gas we choose to produce, linked to other sliders that vary what we pay, in dollars, lives, and environmental impact, not only for fracking but also for coal production and use, for Middle East wars, and so on.

Where will these tools come from? As Ned Gulley says, they’re expensive to build, and you need a scarce talent Bret Victor to build them. And even then, as we’ve seen here, it’s tricky to get right. Where will the tool-spinning meta-tools come from?

I actually think Bret knows, or at least intuits very well, how we can get there, and I think he has shown the way in his book-length 2006 essay MagicInk. That’s what I meant to write about today, but after an unexpected detour through Ten Brighter Ideas I think I’ll do that another time. Meanwhile if you haven’t read MagicInk I commend it to you.

• What is the Ob of Nebraska? (The Platte. Hence the name for these: Ob-Platte puzzles)

• What is the Newark of Delaware?

• What is the Gettysburg of Hawaii?

The authors write:

If one were to ask, “What is the Atlantic City of France?”, a large number of people would undoubtedly answer “Monaco”, even knowing full well that Monaco is not a city inside France, but rather an independent, albeit small, country that is not in France, but borders it (the gambling city within Monaco is Monte Carlo). However, Monaco is world-famous for its casinos, is small enough to be thought of as a city, and like Atlantic City, is located on the sea.

I’m working on an Ob-Platte puzzle that you may be able to me with. It goes like this:

Who is the Andy Morikawa of Ann Arbor?

I’m working on the same puzzle for Berkeley, Boston, Providence, Portland, Seattle, Toronto, and a few other places where I’d like to convene a seminar on community information management. The first of these was held in Blacksburg, Virgina, during my recent visit there, and was successful because Andy Morikawa knew and invited all the right people. The Andy Morikawa of Blacksburg is a fellow at Virginia Tech’s Institute for Policy and Governance, and was until recently the executive director of the Community Foundation of the New River Valley.

Just as Monaco is not actually a city in France, the Andy Morikawa of Ann Arbor, Berkeley, and Providence might or might not be affiliated with the universities in those towns. Another Andy might be an independent community organizer, or a city councilor, or an economic development specialist, or the director of a nonprofit chartered to consolidate and promote cultural arts. He or she will certainly, though, be a well-known connector who has the ability to convene the kinds of folks I want to reach. They’ll come from the public schools, the colleges, the city government, the newspapers and online media, the music and dance scenes, the public library, the hospital, the chamber of commerce, the downtown merchants association, arts and culture nonprofits, social services organizations, sports leagues, environmental groups, and other centers of public life.

Crucially I am not looking for webmasters and IT staffers, but rather for leaders responsible for public engagement. The principles I’ll explain and demonstrate are ones that everyone can understand and apply. Once leaders understand what’s possible they can delegate to staff, but what they’ll delegate is nothing they couldn’t pretty easily do for themselves.

What makes this a tricky problem in social networking is that my best contacts are in the technical world, but I’m trying to reach outside it. That’s why I need an Andy to help me bridge the gap. If you are an Andy, or if you know an Andy, I’d really like to hear from you.

For the sorts of calendars you see at elmcity.cloudapp.net, which represent schools, libraries, museums, music venues, sports clubs, and other organizations offering schedules of activities to which the public is invited, the application of the principle is as follows. Publish your calendar from a single canonical source as two streams of information. One is an HTML page for people to read and interact with on your own website. The other is an iCalendar (ICS) feed that can syndicate to other sites.

One popular way to publicize events, Facebook, doesn’t fit neatly into this model. For some organizations, a calendar on a Facebook page is the canonical source. I respect the choice to use Facebook in that way, and support it by enabling such calendars to syndicate from Facebook into other contexts. But I don’t recommend the choice.

Consider this link that appears on the Peterborough NH timeline for April 28:

Sat 09:00 AM Childhood Pop-Up Museum Peterborough Historical Society Museum and Archives

It’s nice that this event is able to show up in a public timeline for the Monadnock region, along with events from many other sources. But if you click the link … well, it depends. If you’re logged into Facebook you’ll see the details. Otherwise not.

The Peterborough Historical Society does publish the event on its own site, here it is, but there’s no iCalendar feed on the site. The only machine-readable calendar for the Peterborough Historical Society available on the web is the Society’s Facebook page. And while that page is on the web, it’s only fully available to the subset of the web formed by logged-in Facebook users.

What I want, and what I think everyone who promotes public events should want, is the inverse of that arrangement. I think we should put our public calendars on our own sites. And then, since Facebook is a wonderful tool for socializing our calendars — that is, discussing upcoming events, keeping track of who’s planning to attend — we ought to be able to syndicate from our own calendars into Facebook.

It’s doable, and I’ve prototyped a solution, but in light of an upcoming change in the way Facebook handles API access tokens I’m going to wait for the dust to settle before rolling it out. I’m told there may soon be a new mechanism that will simplify the authentication dance the elmcity service will need to perform in order to make this happen.

Meanwhile, though, I’ve implemented a variant of the idea. On Saturday a favorite local band, Jatoba, will be playing here in Keene at Waxy O’Connor’s. I found the event on the MonadnockNH music calendar, to which it had syndicated from two sources: Eventful.com and Waxy’s own calendar. I’m hoping some friends will want to join me there, and Facebook is a great way to alert them that I’m going. So I posted the event to my Facebook page.

Then I realized it was silly for me, or anyone, to have to retype data that’s available in machine-readable form. So I’ve expanded the elmcity service’s Add to calendar mechanism. Options were formerly Add to Google Calendar, Add to Hotmail Calendar, and Add to iCal (for generic iCalendar clients). Now there’s also Add to Facebook. When you see an event on an elmcity timeline that you’d like to socialize, it’s now just two clicks to pluck it from the timeline and announce it to your Facebook friends. It’s kinda cool, and it’s a nice warmup for the wholesale syndication I’m planning to do later.

Ownership of data and services based on data are separable concerns, and it’s crucial that we begin learning how to separate them. In this case the owner of the data about Jatoba’s appearance at Waxy O’Connor’s is Waxy O’Connor’s.

(An aside: You might argue that the owner of that data is really Jatoba, and that Waxy O’Connor’s could be syndicating from Jatoba’s site. That’s true. You might also argue that Waxy O’Connor’s doesn’t really own its calendar, Google does. That’s true too. Waxy O’Connor’s has no more of a contractual relationship with Google than it might with Facebook. But Waxy O’Connor’s does have a contractual relationship with its site provider, and that contract could include provision of a calendar service that puts Waxy O’Connor’s in charge of its own data. Likewise for Jatoba.)

(Another aside: Eventful and Waxy’s do not agree on the start time for Jatoba’s appearance. This is not uncommon. Eventful says 8PM, Waxy’s says 9PM. I’m going at 9PM because I regard Waxy’s as the more authoritative source in this case. I’m not sure where Eventful got its information, but if it were syndicating from Waxy’s or from Jatoba then we wouldn’t see this temporal drift.)

What Facebook can bring to the table, if we look at it the right way, is a service based on data owned by Waxy O’Connor’s — or by Jatoba. It’s the service, again, of socialization: announcing an event to a group, discussing the event with the group. Music promotion is interesting in that there are three ways that socialization might happen. A band might want to do it, and/or a venue, and/or a fan.

So, for example, an event that was syndicated from Waxy O’Connor’s site (or from Jatoba’s site, or from both), might want to be injected into a Waxy O’Connor’s Facebook Page, and/or a Jatoba Facebook Page, and/or the personal Facebook page of a fan like me. The latter option is available now. The former ones are coming soon.

I’ve mocked up a simple mechanism that you’d use to identify an iCalendar feed and a Facebook Page that you control, and then tell the elmcity service it’s allowed to inject events from the iCalendar feed into your Facebook Page. My notion was that you’d only need to use this mechanism once, to hook things up. Thereafter the elmcity service would sync the iCalendar feed to the Facebook Page on some regular schedule.

In order to do that, though, the elmcity service would need to hold onto the access token that it got from Facebook. The needed permissions are: manage_pages (so the elmcity service can update the Facebook Page), create_event (so it can create events on the Facebook Page), and offline_access (so the elmcity service can keep updating the Facebook Page without asking you). The last of these, offline_access, is a very powerful privilege, arguably too powerful, and sure enough it’s going away in a few weeks.

What I think this means is that it will still be possible to sync from an iCalendar feed to a Facebook Page, but that the owner of the Facebook Page will need to be notified periodically (every 60 days, it seems) to reauthorize the service that does the synchronization. Have I got that right? If so it’ll be awkward, but I won’t really be able to complain. I agree that users should periodically review the powers they’ve granted to third-party apps and services.

At least one student, lisskane, tried the experiment. She wrote:

I’m going to completely admit that before this class I knew absolutely nothing about the WWW and Internet infrastructure. And honestly, it still confuses me. Who knew that the web and the Internet were different things? I thought they were simply interchangeable words, synonyms that could be looked up on Microsoft word. But they are different and when to my surprise when I click on Internet, there are no synonyms for it. It is it’s own thing. Which brings us to what Jon Udell was saying in class. When it comes to the World Wide Web, our imagination is our only limit. We decide what we want to make. Who we want to share it with and what we want it to mean. Take words for example.  Dackolupatoni: when you Google that, nothing comes up. But here is our experiment. Let’s search it in a few hours and probably this will come up. Which is recursion. And then that person can be linked to this. And it goes on and on. Now isn’t that cool?

It sure is! Unfortunately for lisskane her grain of sand, dackolupatoni, has not yet fully awakened. Bing finds a tweet I posted yesterday. But neither Bing nor Google, as of Saturday morning, has yet made lisskane’s experiment in discovery and recursion come alive. This pains me. I want her to see it happen. But I realize I forgot to mention something. This power to cast grains of sand into the virtual world and than awaken them is a power that grows as you exercise it. Mine, after many years, is strong. Hers is nascent. But thanks to another wonderful property of the web I can share some of my power with her. So, Google and Bing, please awaken lisskane’s grain of sand.

The university knows about this activity, it’s been written up on the website. What the university doesn’t know, it seems, is that this instructor has been unable to land any funding to support these trips. For five years she and a collaborator from another school have paid for travel and lodging — their own and the students’ — out of their own pockets. Which, in her case, is more than a bit of a stretch.

What do you do when you hear a story like this?

• Rail against a system that does not recognize or support some of its truest heroes.
• Point her to Kickstarter.
• Celebrate the human spirit.
• Give her a hug.

I’m going to skip a) because life’s too short and it’s boring. b) Done. c) Done. d) Flubbed my chance but I hope to fix that.

In A tale of two dams I proposed using a tag, WestStDamKeene, to coordinate public discourse about a decision we need to make here in Keene, NH. Should we repair the Ashuelot River Dam on West Street, or remove it?

On the day I wrote that post, it was the only document on the web containing the 14-character string WestStDamKeene. A few months later I mentioned it again in Awakened grains of sand¹, which considers what we can do when we invent names that are unique to the web — and that can be found by searching for them.
So now a Google or Bing search would find two documents on the web containing the tag WestStDamKeene.

Yesterday I tried that again and was delighted to find a number of results, notably from two local organizations deeply involved in the decision about the dam: the City of Keene [Google, Bing] and the Keene Sentinel [Google, Bing].

Among the links that turn up in a general search for WestStDamKeene is this pointer to minute 40 of the two-hour city council meeting on Oct 6, 2011, when discussion of agenda item F begins. That happens because the title of item F is Ashuelot River (West Street) Dam (onlinetag: weststdamkeene) – Department of Public Works.

This makes me very happy! The City explains:

The City of Keene has embarked on a new online initiative to streamline information sharing with the citizens of Keene. The City will be “tagging” certain projects or initiatives that have generated a significant amount of community interest. This initiative will be a collaborative effort with the Keene Sentinel, which will be applying the same tag to their articles. The tag assigned by the City can be used to search all online content associated with the item through the search engine of your choice.

And it adds:

As you collaborate with others online to discuss City projects, you are welcome to tag your posts, emails, articles, etc. with the same tags. For example, if you belong to a Keene neighborhood group, and you have information to share regarding the West Street Dam project on the group’s Facebook page, make sure to include “weststdamkeene” in your post. Your post will then appear in a Web search alongside City and Sentinel tagged content.

If others follow that advice and join in, my happiness will increase.

¹ Cliff Gerrish’s poetic response to Awakened Grains of Sand also made me very happy.

Finally I learned that the condition has a name: Raynaud’s syndrome. The Mayo Clinic says it’s more a nuisance than a liability, and I guess that’s true, but lately it’s gotten to be a real nuisance. Even indoors, during winter, I’ll realize that my hands are ice cold, and have to run hot water on them in order to resume typing on the keyboard or playing guitar.

I read that some folks have had success with biofeedback so I decided to give it a try. Raynaud’s is just an autonomic nervous response. The shutdown of circulation to hands and feet may be necessary in a survival situation, but with Raynaud’s it happens unnecessarily and inappropriately. The idea of biofeedback is that you can train yourself not to do that.

So I got one of these. It’s nothing special, just a thermometer with a sensor you tape to your finger. You look at the number and try to make it go up.

The first few times I tried nothing happened. The baseline, for me, seems to be room temperature, which in winter might only be mid-60s. I couldn’t budge from that. Then, one day, after about 15 minutes, I gained a tenth of a degree. Then another. Then a degree. Then another. And suddenly the temp was shooting up. In about five minutes it went from 67 to 94.

This wasn’t replicable. Sometimes I’d get that dramatic response, sometimes nothing at all. And it didn’t seem very practical because you can’t do anything else, you have to watch the readout — this is biofeedback, after all.

Eventually I noticed that if I placed my opposite hand — that is, the one without the thermometer — someplace warm, like on my neck, then I could sometimes trigger the warming response in the other hand. So that’s my current best strategy. When I notice my hands feeling cold indoors, I’ll take a “measurement” by placing one hand lightly on the side of my neck. Often I can get both hands to warm up by doing that.

I think the thermometer was useful mainly to prove to myself that the relaxation response is controllable. And that it’s binary, or so it seems to me, by which I mean that for the most part it either happens or it doesn’t. And that some kind of feedback is needed to produce the warming effect I want. Direct self-measurement (i.e. touching my neck) seems to work well enough, and that’s nice because it’s something I can easily do while working.

I’m getting OK results indoors, but still not having much luck outdoors. Now that I know the syndrome isn’t just something that happens to me, though, but rather something I’m doing to myself, I think I might eventually be able to back off from the arctic mittens on days other people are wearing light gloves or nothing.

¹ Feeds not easily discoverable, and not valid, but can be made to work.
² Ann Arbor’s public schools are exemplary.
³ Only the Dorchester facility.
⁴ Missing most activities.

The URL for the series is http://www.wired.com/cloudline/tag/the-personal-cloud, and the corresponding RSS feed is http://www.wired.com/cloudline/tag/the-personal-cloud/feed.

Principle: Top-down and bottom-up

In the elmcity context, the most important taggable object is the calendar feed. That’s because when you can characterize a whole feed with a tag, all the events in that feed inherit the tag. The primary sources of taggable feeds are Eventful, Upcoming, Facebook, Meetup, and EventBrite. I call them taggable because, while some of these services tag individual events, none tag feeds based on venues (Eventful, Upcoming) or Pages (Facebook) or groups (Meetup) or organizers (EventBrite). Assigning feed-level tags is an editorial exercise for the curator.

To these sources I add as many standalone iCalendar feeds as I can find. For Boston and Seattle, the results add up to lists of over 600 tagged iCalendar feeds. Here’s a table of the current list of tags for Boston, the current list for Seattle, and the intersection of the two lists.

Among the dynamics in play here, we can see the general and specific principle at work. For a general tag like university there are city-specific instantiations: bu and northeastern for Boston, uw and seattleu and nscc for Seattle. Likewise for the general tag highschool there are specific tags like boston-latin-hs and cathedral-hs for Boston, garfield-high and ingraham-high for Seattle.

These city-specific tags are top-down in the sense that I, as curator of the hub, have assigned them and made them part of the hub’s core tag vocabulary. But they are also bottom-up in the sense that they represent discoverable sources that are providing enough event flow to warrant such treatment.

These core hub vocabularies are fluid. As I move from hub to hub I’ve been keeping an eye on the common core and refactoring all the hub vocabularies as I go along. I also use these evolving hub vocabularies as templates against which to match vocabularies from other sources.

Mechanism: Tag matching

Some of the source services, notably Eventful and EventBrite, include per-event tags. When one of these tags matches a tag in the (evolving) core vocabulary for that hub, the elmcity service adds that tag to the event’s list of tags which it inherited from its feed.

There are also tables for each foreign service that map tags used there to tags in the hub’s core vocabulary. So, for example, the Eventful tag movies_film and the EventBrite tag movies both map to the core tag film.

As we saw in Portable tags, some iCalendar feeds use the CATEGORIES property of the iCalendar format to express per-event tags. Managing these tags is trickier because, well, they’re unmanaged. Until recently I was suppressing them. Now I’m experimentally allowing them to appear, but segregating them from the core vocabulary. If you check the tags for Boston or Seattle or another city you’ll see that the list divides into two sections. The first presents managed tags: the core vocabulary. The second presents unmanaged tags from iCalendar feeds, enclosed in squiggly brackets to differentiate them from the core vocabulary.

Here’s the current set of unmanaged tags for Boston and Seattle:

When one of these tags matches a tag in a hub’s core vocabulary I promote it — that is, I treat it as part of the managed core and it no longer shows up in squigglies. That’s a top-down approach. But there’s a complementary bottom-up approach. As I scan the unmanaged tags, both within and across hubs, it can become clear that an unmanaged tag belongs in the managed core. To accomplish that I simply use the unmanaged tag somewhere in the managed core. From then on, occurrences of the unmanaged tag are promoted into the core.

A logical next step is to enable curators to edit per-hub maps so that, for example, Seattle’s {central library} and Boston’s {libraries} will be promoted to simply library. I haven’t built this mapping feature yet but it’s on the todo list.

I’m still exploring the interplay between the top-down and bottom-up approaches. But it definitely feels like the right way to handle common vocabularies augmented by different (and regionally-varying) vocabularies.

(This series: elmcity tagging principles.)

Jonah’s strategy tags each .ODF file with two items of information: a customer name, and a date. His convention is to keep the date current, so that current projects float to the top in date-ordered folder views. For many people the names of files in a folder are just one unorganized namespace. For Jonah they represent two parallel namespaces — or, as I encourage people to think of it, two sets of tags.

One of the benefits of this approach is portability. He could, if needed, transfer those files to another computer, perhaps even one running another operating system, without losing his ability to organize and retrieve records by customer name and date.

Principle: Create and use portable tags

For calendars, the CATEGORIES property of the iCalendar format is the most obvious way to tag events. Unfortunately it isn’t portable. Some content management systems enable users to tag events using the CATEGORIES property. And some calendar applications, like Outlook, also do. But other calendar apps, like Google Calendar and Hotmail Calendar, don’t. If you’re using one of these to publish a calendar, you can’t tag an event as a concert. And if you’re viewing a calendar that has events tagged that way, you won’t see or be able to make use of the concert tag.

There’s a simple and portable solution. iCalendar’s SUMMARY property, which is the title of an event, is universally readable and writable. So if your event stream naturally divides into concerts and lectures, it’s really helpful to identify events accordingly in their titles:

Concert: Joey Pratt Album Release Party with Noah Lefebvre

Lecture: Technology Future Shock: Society, Policy and Innovation in the Digital World

An even better strategy is to provide two separate feeds, one for concerts and the other for lectures. But that’s for a future installment. The key point here is that you can add value to any namespace — a set of files in a folder, a set of events on a calendar — by using tags to qualify filenames or titles.

Mechanism: Use iCalendar filters to extract tag-based feeds

The elmcity service provides a growing set of filters that can extract subsets of iCalendar feeds based on tags found in the SUMMARY (title) or DESCRIPTION (or URL) properties of events.

In the ideal scenario, providers of feeds would use tags as prefixes to the SUMMARY property. In the real world that doesn’t happen, at least not yet. But the elmcity filter is still useful because it’s natural to include keywords in titles and descriptions. Consider, for example, the calendar for Vinology, a wine bar and restaurant in Ann Arbor. Its calendar mixes two different kinds of events. Some are about food and drink (“small plate special”, “happy hour”). Others are about the jazz acts often appearing at Vinology. By filtering on jazz in the SUMMARY and/or DESCRIPTION of Vinology’s Google calendar, the elmcity service is able to extract just the jazz events and add them to Ann Arbor’s music and jazz calendars.

Currently there’s no incentive for Vinology (or anyone else) to adopt this strategy in a more intentional way. That’s because Ann Arbor’s elmcity syndication hub isn’t aligned with attention hubs like AnnArbor.com and ArborWeb.com. If Vinology knew that events tagged with music and/or jazz would show up on those sites in those categories, there would be a strong reason to do it.

(This series: elmcity tagging principles.)

PS: The next Vinology event in the music view of Ann Arbor’s elmcity hub, by the way, is the Doug Horn Trio, this Thursday at 9PM. That event isn’t on the AnnArbor.com calendar or the ArborWeb calendar. To put it there, Vinology would have to take data that it has already entered here and reenter it here and here. I think those other calendars should syndicate the data straight from Vinology (and everyone else).

PPS: See also Harry Tuttle’s busy month and The art of organizing search results.