Four ways to make the world a better place through the astute use of computer software.
A voting advice system can change the game--not by removing money from the campaign equation, but by making it irrelevant. That single effort can enable a wide variety of progressive reforms that have found themselves mired in the mud of political inertia.
To see how it works, why it's practical, and the benefits it will provide, see: Taking the Money Out of Politics
In the open source community, it is a truism that people can collaborate on an implementation, but it is virtually impossible to collaborate on a design. Design and other forms of decision-making in complex situations are representative of what has come to be known as Wicked Problems.
I'm grateful that, through my participation in Doug Engelbart's Unfinished Revolution colloquium at Stanford, I became acquainted with Jeff Conklin, who alerted me to the nature of Wicked Problems, and to the use of Horst Rittel's Issue-Based Information System (IBIS) methodology (aka Dialogue Mapping) for taming them.
The idea is to structure a conversation in a way that records the views (and catalogs the objections) of all interested parties, so they can be methodically examined. The system should also make it possible to reach into the graph of connected thoughts and raise particular nodes to a higher level (proposals and objections, for example) so that all previous discussion becomes backrground that underlies the proposal, rather than a mass of foregoing detail that buries it--something that is perhaps the single most problematic feature of email discussions. (See What's Wrong with Email?)
To that end, I started the RuDI project (Ruby Utilities for DITA processing), because:
In Ireland, I discovered that we teach music in precisely the wrong way. There (in school), everyone learns to play tunes by ear. Those that go on to specialize in music learn how to read and write musical notation. It's kind of like learning your native language--first, you learn to hear it and speak it. Then you learn to read it and write it.
As a result of that education, people in Ireland develop a common vocabulary of music they can play and dance to. (Everyone in Ireland has "party piece"--a poem they can recite, a tune they can play, or a dance step they can do to entertain each other at a social gathering.)
That process is made easier by the fact that Irish tunes are melodies--some simple, some intricate--but because they lack harmonies, a hundred people can join in and play a single tune, all at the same time. Even when the tunes have variations, the resulting ensemble sounds rather good--so Irish "sessions" are commonplace, with players of multiple instruments getting together to play common tunes and share new ones, all in an impromptu setting. (Since there are multiple ways to do harmonies, there is no way to duplicate that kind of thing. It takes a lot of pre-arrangement to make harmonies work.)
That kind of thing creates a community of muscians. And since the tunes are the basis for dances, they form the backbone of community gatherings. At those gatherings, people dance together in a combination of partner line dances and square dances, where a caller helps to keep things organized, but where the caller isn't really needed, once you know the steps.
That entire culture results from the teaching people to play music by ear. It also enables musicall creativity. To play by ear, you first have to hear the tune, then you play it. So you learn to play what you hear in your head, which is the very essence of musical improvisation. So teaching people to play by ear fosters creativity at the same time that it fosters creativity.
But learning by ear is hard, at first. It becomes easier and easier over time. Skilled muscians get to the point that they can hear a tune once and then play the whole thing. But at first it might take quite a bit of hunting to find even one note! So teaching someone to play by ear can require an extradordinary amount of patience.
That's where the computer comes in. The computer is nothing if not patient, so it's made for this kind of task. I developed a program called TuneTutor. You select how much of a tune to play, and how fast to play it. The program then plays that part tune (showing you the fingering on several possible instruments, if you want), and waits for you to play it back. You can repeat that cycle as many times as you want before you move on to the nesxt segment.
At this point, that program only has a couple of pre-programmed tunes. The next step is to add a parser that reads tunes in "abc" notation, for example, so that new tunes can be easily added. (That step has been pending for a very long time! But that's pretty much the only really important feature left to implement.)
For more, see: Learning to Play By Ear
The idea is to capture "nutritional system" information in the form of production rules (this in, that out). Those rules can be used as the basis for inference and analysis. The next step is make it possible for someone to run a series of queries against those rules, and make the interface available on the web.
One of the interesting issues is that such rules operate at multiple levels:
After some recent job experience, it made sense to begin capturing the beginnings of a nutritional systems model (an OpenOffice spreadsheet). That information is stored in XML form, which makes it possible to both edit the information and access it with relative ease. It is a project that will require much more thought and evaluation, though--not the least of which is the construction of an ontology to represent all of the many possible interactions of inputs and outputs at the various levels (so the Protege ontology-management tool is another interesting possibility).
§ Home · Books · Health · Music · Dance · Golf · Yoga · Essays · Store §
Copyright © 2009
by Eric Armstrong. All rights reserved.
Subscribe for announcments.
Contact me to send feedback, make a donation, or find ways to help others.
And by all means, be sure to visit The TreeLight Store.