Vegan Pancakes!

In response to Alecia's post (*ahem*: my new best friend's post) on our conversation about her project, I'll just jot down some of my mental notes.

First off, the problem: to make the maps of pollutant release data from NPRI (or any other maps, really) accessible. More specifically, to make the NPRI data as useful for non-sighted users as for sighted users -- and this means making some of the implicit information a sighted person gets from a map accessible to a non-sighted user. As I understand it, since the maps are displayed as images, then the (only?) accessibility mechanism that Alecia can use is the longdesc attribute of the image. So, the problem is partly one of coming up with a meaningful textual description of a map. A few other constraints: the web interface ought to be unified: the same for both sighted and non-sighted users; to be meaningful the text description can't be overly long (i.e. it ought to only contain relevant information, whatever that means. see below:).

• "...implicit information...": we talked a bit about what this means, and it seems like it means just about anything you care to say is in the map. So, the clustering of smoke stacks around a major waterway is implicit because just by looking at the map you can pick out the cluster -- even though the cluster isn't represented as a cluster in the NPRI data. Um, even things like 'major waterway' is implicit, in a way, because it's not part of the NPRI data but it does appear on one of the other layers of the map. The amount of implicit information is practically, well, infinity+1, so trying to include all of it in a longdesc is not an option. So what to include then? Hrm.. accessible cartography's own frame problem.
  
  The scenario I think we're both assuming here is one of a Google maps type map which shows all sorts of terrain details, street details, etc..., and then overlayed on that is the NPRI data. A sighted person can ask and answer all sorts of queries on her own, just by looking at the map and visually sifting through the implicit data.
  
  One way to constrain the amount of information to put in the longdesc we discussed is to have a UI where users can express what they want to find explicitly. Once they state that the system gives 'em an appropriate map. In this way, whether they're sighted or not, we know enough about what not to put into the description and what to include, so as to only include relevant features.
  
• Subproblem 1: So, if we run with the "task-oriented" UI that elicits the user's goal, then we have to design it well. There are probably another infinity+1 user questions, but knowing maybe they fall roughly into a few classes that the UI could be specially designed for (e.g. questions about locality: "what waterways are closest (5,10,25,.. Km) to a particular smoke stack"). User study, or mining the NPRI advanced query tool, maybe?
• Subproblem 2: "...a meaningful textual description of a map...": Okay, once you have the relevant aspects of the map in hand, then you have the problem of turning into a sensible text description. I'd think there was work done on this already....
• "...the web interface ought to be unified...": I really appreciate this point. I didn't at first, since it seemed intuitive to just split things up. One question I have for Alecia is whether she thinks it's okay to sneak in some features that are particularly useful for non-sighted users? For instance, maybe the default map displays all sorts of layers that aren't included in the longdesc. It's only when the user selects these layers to be, say, highlighted in someway, that they're actually included in the textual description. Is that fair game?
  
• Exploration: one thing I thought about after our meeting was about making the accessible version of the map open to exploration. As we were talking I immediately zoomed in on the task-oriented UI as a way to narrow down the map detail, but maybe a user isn't coming to the site with a specific task in mind, maybe they just want to explore the data in a less structured way... I don't know what this means exactly, but I guess I'm thinking of how sometimes patterns just pop out of a picture (e.g. clusters) when you're not looking for them. Thinking about how to include exploration into accessible maps might be out of scope for Alecia's project, but it sure sounds interesting.
  

Food Force, and communicating science

Check out the United Nation World Food Programme's educational video game, Food Force. You're the forth member of a crack WFP team put together to deliver food aid to a fictional country that is having a hunger crises. I've only taken a quick look at the game myself, but it has lots of interesting cinematics, music, and game play. The idea is that by playing you learn about a hunger crises, and how the UN tackles it. And having fun. And spending an afternoon not making progress on your thesis. Not.

Making a video game that teaches about climate change came up in our brainstorming sessions last year, and this is an interesting case to study.

But more importantly for me, I found the link to this game in the comments of this RealClimate.org post on communicating science (both comments and post are worth reading), which itself was linked to by today's post on the same topic. This is the space I'm playing in: communicating science. I started with the ill-defined idea of visually querying climate data/models as a way to communicate the science of climate change and, lo', here's a whole area of work to distract me from narrowing down ground and motivate a specific thesis idea.

Why we can't buy our way out

When I posted a summary of our brainstorming sessions a while back, I noted my concerns with approaches to raising awareness of climate change and of the impacts of our decisions that go about it by providing us simply with more information. It sounds like a good idea: the more we know, the better the decisions we'll make. It's got to be true to some extent, but my concern is that emphasizing the focus of optimising purchasing choices isn't good for your mental health. For one thing, it can so easily lead to a feeling of being burned out ("green fatigue" I've heard it called).

But there's something else this shift of focus does. It helps us to ignore the fact that we're so much more than just consumers. Raj Patel says it plainly in Stuffed and Starved, pg. 312:

The honey trap of ethical consumerism is to think that the only means of communication we have with producers is through the market, and that the only way we can take collective action is to persuade everyone else to shop like us. It alters our relationship to the possibility of social change. It makes us think we are consumers in the great halls of democracy, which we can pluck off the shevles in the shops. But we are not consumers of democracy. We are its proprietors. And democracy happens not merely when we shop, but thorughout our lives. The connection between those who eat and those who grow food cannot be measured in terms of brand loyalty points or dollars spent. To short-cut the food system, and to know the people who grow our food, is more than to broker a relationship between buyer and seller. It is to build a human contact that goes beyond a simple transaction and that recognizes certain kinds of commonality, certain kinds of subjugation, and struggles, fights, for an end to the systemic inequalities in power which shape the way rich and poor live today.

A collaborator, a story, something delicious

I met with Greg and Alecia this morning. Alecia, as you can see from her blog, is working to make web mapping accessible. That means providing all the information a sighted person can infer from a map to users regardless of their ability to see or use a mouse. Since there is an enormous amount of implicit information in a map (e.g. quick, what's the closest major centre to Winnipeg?), this problem is tough. I'm sure this isn't a complete description of the problem, but that's the idea.

There's overlap with my interests in that we're both looking at representing spatio-temporal data in interesting ways. Well, it'll sure be nice to have another person to bounce ideas off of.

But what, exactly, am I working on these days? This morning I bumbled my way through an explanation to Alecia. Greg pulled it together into a coherent and sexy story. I'm going to give you my own retelling of it:

Climate change -- the science is out there. There are plenty of datasets and models to show us how the climate behaves and how it's likely to behave in various future scenarios. And if you aren't truly scared shitless, then you're not reading the same books and websites I am. Or maybe it's because you don't have a compelling way to make sense of the science, to understand it and its implications on your life and future.

My hope is that I can do something about this. I'd like to make, or find and refine, something to that ("even") a high school student could, and would want to, interact with to help make sense of our predicament.

That's where the interest in spatio-temporal visualisation comes in. Maybe what's needed is a nifty environment for exploring existing data, or a simplified climate model, or .... well, I dunno yet.

For the next few days I'm going to continue my exploration of visualisations, but I'm going to widen my search beyond academic papers necessarily. I'll probably be turning up more than I can blog about, so I've created a del.icio.us account which you can follow, or check out some of the existing relevant del.icio.us bookmarks.

2 1/2 papers on engineering climate models

Here are two papers (plus another that goes into more depth) on the software engineering of the Community Climate System Model, and the Earth Systems Modelling Framework. I'm just starting to get into these projects, and these papers have been very helpful so far:

1. Overview of the Software Design of the Community Climate System Model by J. Drake et. al.
   This paper describes the dreamy world of the CCSM project, a seemingly well-oiled software engineering enterprise. This paper covers the design of the CCSM, plus an overview of the software development process.


2. The Architecture of the Earth System Modeling Framework by C. Hill et al.
   This is a larger project that incorporates the CCSM. This paper just outlines the design (no process). For more details see: Design and Implementation of Components in the Earth System Modeling Framework by N. Collins et al.

Extensible programming

A couple of years ago I did some extra-curricular work with Greg Wilson and Miles Thibault related to the idea of extensible programming. As a warm up, I built a scheme interpreter and implemented hygenic macros from scratch. Learned heaps. Two of Greg's students (golly, can't remember their names) appear to be taking up the extensible programming idea in earnest as their master's projects. For what it's worth, I'll summarise two of the ideas that came out of the project:

• You can't have an extensible language without an extensible parser. Stating it this way makes it seem pretty obvious, but when we moved from scheme to Java this was a bit of a revelation. In Scheme you can extend the language anyway you want simply with a macro, but that's only because the language has an extremely constrained syntax. For Java you'd either have to have predefined grammatical constructs that extensions would fit into (like the JSE macro syntax), or have your language extensions also extend the parser to support themselves.
  
  
• Fully qualified language keywords. One option I came up with to support grammer extensions was the notion of a fully qualified language keyword. In the same way that Java lets you fully qualify classes (e.g. org.w3c.Document) why not fully qualify keywords to allow the parser to handle ambiguous bits of syntax. For example:
  

  import syntax com.pipitone.try;
  
  ...
  
  java.lang.syntax.try {// standard try-catch
  ...
  }
  catch (FooException e) {...}
  catch (BarException e2) {...}
  
  com.pipitone.try {// custom, multi-exception try-catch
  ...
  }
  catch (FooException e1, BarException e2) { ... }

Interesting stuff, this. It's still exciting. If I wasn't trying to save the world I'd probably being working on this project. ;-)

Exploratory spatio-temporal visualisation

The last paper I reviewed discussed and evaluated different visual querying techniques for general relational databases. Today's paper, Exploratory spatio-temporal visualisation: an analytical review by N. Andrienko et al., narrows the discussion to just spatio-temporal data and focuses less on querying specifically than on evaluating a variety of exploratory techniques specific to spatio-temporal data.

The paper begins with a long discussion intent on classifying the kinds of questions one can ask of spatio-temporal data. The authors point to spatio-temporal data having three major dimensions: what, where, and when, and that a classification system natural falls out from this observation. Questions about the data are usually posed about one dimension given the other two (e.g. when did x happen at y?) with answers needed at various levels of aggregation (e.g. at specific points, over a range of points, or overall; they refer to this as the "search level") and with various types of comparisons/relations done on the results (they're rather vague about this bit). At the end of their discussion the authors decide to explore only those questions that focus on the time dimension: given a time (or range) what happened where?; or when did what happen where. Here's their handy graphical representation of all of this:



The paper then turns to briefly surveying existing exploratory techniques: querying (they focus on dynamic querying and filtering), map animation, and other visualisations to explore changes in locations, events, or attributes.

With these techniques in hand the authors get to the real meat of the paper and evaluate how each technique serves to answer the two general kinds of questions. In the process of doing so they to break down the two question types into more specific questions types, detailing various search levels and cognitive operations. For instance, an elementary when -> what + where question might involve comparing behaviours over the same time interval (e.g. "compare the movements of stork X and Y") or at distinct intervals (e.g. "compare the migration behaviours of the stork X in the years 2001 and 2002"). Each of these question subtypes are explained and matched to appropriate exploratory techniques, often with references to existing implementations.

This paper is another (seemingly b/c what do I know?) decent survey of existing software and techniques. It presents a slightly more principled classification (the question types) and evaluation criteria but is fairly light-weight on the analysis (it all seems rather ad-hoc), and provides no empirical backup for many claims.

There is one thing I can take away from this paper: that visual querying is more than just a visual represention of the query question. It's also exploration. This paper implicitly assumes this with its highlighting of techniques which blur the visualisation of the query and the results, à la dynamic queries.

The other take away is dead obvious but I'll state it anyway: the type of questions you're asking tell you (or contstrain, or inform) what exploratory/query techniques to use. Creating a novel SQL query visualiser might not be what climate scientists or grade 10 students need to answer their types of questions. It's worth mentioning all of this only because it highlights an important point for me: I need to get a handle on what questions folks can't answer easily (or aren't asking, but ought to).