http://marchofman.org:8080/marchofman/imagefeed/This was surprisingly easy to develop, thanks to the ROME library for Java. (I had a few problems deploying it, but that was my fault.)
16 December 2007
March of Man: Image Feed
There is now an RSS feed that will show all the latest updates to the March of Man gallery. Point your blog-reading software to:
This was surprisingly easy to develop, thanks to the ROME library for Java. (I had a few problems deploying it, but that was my fault.)
This was surprisingly easy to develop, thanks to the ROME library for Java. (I had a few problems deploying it, but that was my fault.)
12 December 2007
Exobotics!
We at Exopolis just launched this today:
This is a hybrid Flash/Flex app that allows you to select robot parts (including a heart, which represents a musical track) and assemble them into a dancing robot which you control with the mouse and keystrokes. I have to say—I spent hours making this and it's still fun to me.
I'd actually started something similar back in Flash 4, if you can believe that. Yes, before true ActionScript. I had to manually create a sine lookup table. It was fun.
After a couple of false starts in intervening versions of Flash, I finally had my greatest success with a Flex version. Dynamic binding makes this sort of thing so much easier.
Basically, the way the robots work is that each joint is associated with a type of object called a Locator. Minimally, a Locator stores a point, dispatches updates whenever that point moves, and allows that point to be constrained. A Locator can be created as simply as:
<Locator id="myLocator" x="100" y="100"/>
Of course, that's not a very interesting Locator, since it doesn't move. Moving a Locator can be done in one of two ways. One way is to extend the basic Locator class, creating a specialized type of Locator. As an example, one of these is StageMouseLocator:
<StageMouseLocator id="mouseLocator"/>
The x and y properties of this Locator always correspond to the position of the mouse. If I wanted to bind another Locator to this, I could do it like so:
<StageMouseLocator id="mouseLocator"/>
<Locator id="myLocator" x="{mouseLocator.x}" y="{mouseLocator.y}"/>
Voila, now myLocator follows the mouse. Why would I want to do this when mouseLocator already does that? Good question. I wouldn't. But now I can do stuff like this:
<StageMouseLocator id="mouseLocator"/>
<Locator id="myLocator" x="{mouseLocator.x + 100}" y="{mouseLocator.y}">
<constraint>
<constrain:VerticalConstraint minY="100" maxY="500"/>
</constraint>
</Locator>
Now it will always be 100 pixels to the right of the mouse, but it will constrain the vertical position to between 100 and 500 pixels in the display's coordinate system. You can see how this sort of binding with modification can lead to more complex behavior.
Another way to control a Locator object is by using an (aptly-named) Controller object. One such object is a SineController object:
<control:SineController id="beatController" speed="0.25" context="{this}"/>
This keeps an angle value, updates it on every frame (incrementing by 0.25 radians) and makes the sine value available through a property called sine. So if I wanted a controller that followed the mouse but oscillated up and down, I could do this:
<StageMouseLocator id="mouseLocator"/>
<control:SineController id="beatController" speed="0.25" context="{this}"/>
<Locator id="myLocator" x="{mouseLocator.x}" y="{mouseLocator.y + beatController.sine * 50}"/>
Of course, I have other types of Controller (StepController, which extends SineController; RandomController; ClickController; etc.), other types of Locator (JumpLocator, JointLocator, InterpolatedLocator, ModeLocator, etc.), and other types of constraints (DistanceContraint, RectangularConstraint, etc.). All of these I blend to create a basic skeleton of points.
Once I have the skeleton, I can attach various visible objects call Connector objects, each of which connect to a number of points and have rules for "squash & stretch". The robots all use MovieClipConnector objects, which each link a Flash movie clip to one or two connectors. I also have DrawnConnector, ImageConnector, etc., and hopefully I can use those on future projects.
I had actually started to make this as an application where you would sketch your own character and it would animate according to a skeleton, but this turned out to be much too processor-intensive, at least for now. Fortunately, one of our senior designers, Chuck Chugumlung, had this idea for a dancing robot factory and he and some other designers (Dan Duran, Jancy Liu), went to town.
Anyway, enough geekery. Go make some robots dance!
This is a hybrid Flash/Flex app that allows you to select robot parts (including a heart, which represents a musical track) and assemble them into a dancing robot which you control with the mouse and keystrokes. I have to say—I spent hours making this and it's still fun to me.
I'd actually started something similar back in Flash 4, if you can believe that. Yes, before true ActionScript. I had to manually create a sine lookup table. It was fun.
After a couple of false starts in intervening versions of Flash, I finally had my greatest success with a Flex version. Dynamic binding makes this sort of thing so much easier.
Basically, the way the robots work is that each joint is associated with a type of object called a Locator. Minimally, a Locator stores a point, dispatches updates whenever that point moves, and allows that point to be constrained. A Locator can be created as simply as:
<Locator id="myLocator" x="100" y="100"/>
Of course, that's not a very interesting Locator, since it doesn't move. Moving a Locator can be done in one of two ways. One way is to extend the basic Locator class, creating a specialized type of Locator. As an example, one of these is StageMouseLocator:
<StageMouseLocator id="mouseLocator"/>
The x and y properties of this Locator always correspond to the position of the mouse. If I wanted to bind another Locator to this, I could do it like so:
<StageMouseLocator id="mouseLocator"/>
<Locator id="myLocator" x="{mouseLocator.x}" y="{mouseLocator.y}"/>
Voila, now myLocator follows the mouse. Why would I want to do this when mouseLocator already does that? Good question. I wouldn't. But now I can do stuff like this:
<StageMouseLocator id="mouseLocator"/>
<Locator id="myLocator" x="{mouseLocator.x + 100}" y="{mouseLocator.y}">
<constraint>
<constrain:VerticalConstraint minY="100" maxY="500"/>
</constraint>
</Locator>
Now it will always be 100 pixels to the right of the mouse, but it will constrain the vertical position to between 100 and 500 pixels in the display's coordinate system. You can see how this sort of binding with modification can lead to more complex behavior.
Another way to control a Locator object is by using an (aptly-named) Controller object. One such object is a SineController object:
<control:SineController id="beatController" speed="0.25" context="{this}"/>
This keeps an angle value, updates it on every frame (incrementing by 0.25 radians) and makes the sine value available through a property called sine. So if I wanted a controller that followed the mouse but oscillated up and down, I could do this:
<StageMouseLocator id="mouseLocator"/>
<control:SineController id="beatController" speed="0.25" context="{this}"/>
<Locator id="myLocator" x="{mouseLocator.x}" y="{mouseLocator.y + beatController.sine * 50}"/>
Of course, I have other types of Controller (StepController, which extends SineController; RandomController; ClickController; etc.), other types of Locator (JumpLocator, JointLocator, InterpolatedLocator, ModeLocator, etc.), and other types of constraints (DistanceContraint, RectangularConstraint, etc.). All of these I blend to create a basic skeleton of points.
Once I have the skeleton, I can attach various visible objects call Connector objects, each of which connect to a number of points and have rules for "squash & stretch". The robots all use MovieClipConnector objects, which each link a Flash movie clip to one or two connectors. I also have DrawnConnector, ImageConnector, etc., and hopefully I can use those on future projects.
I had actually started to make this as an application where you would sketch your own character and it would animate according to a skeleton, but this turned out to be much too processor-intensive, at least for now. Fortunately, one of our senior designers, Chuck Chugumlung, had this idea for a dancing robot factory and he and some other designers (Dan Duran, Jancy Liu), went to town.
Anyway, enough geekery. Go make some robots dance!
11 December 2007
Holiday Fun: Affirmative
Coming soon (probably tomorrow) ... possibly the most fun thing I have ever had a part in making.
Clang clang,
—Keesey
Clang clang,
—Keesey
09 December 2007
Human Origins: Wrong Answers to the Question
Anyone who's spent enough time discussing human origins is bound to have heard this old chestnut at some point:
If we're descended from apes, how come apes are still around?
A variant uses "monkeys" instead of apes.
In an attempt to defend the scientific explanation, people will often use one of two stock answers:
Number 2 is flat-out wrong. We are descended from apes. You could modify that sentence a bit, though, and get a true statement: "We're not descended from any living apes, but we share a common ancestors with them."
The real answer is that "ape", as commonly used, is an unnatural term, and it obscures communication about the subject. Generally "ape" is used to refer to all hominoids except for humans. What's a hominoid? Let's spell that out in some detail:
(Yes the scientific name of western gorillas really is Gorilla gorilla. And the western subspecies thereof is Gorilla gorilla gorilla!)
As you can see, hominoids form a big, bushy branch of the primate tree, and most of the extant twigs (i.e., species) are among the gibbons (although most living individual hominoids are human—nearly all of the other species shown here are threatened or endangered).
Among living hominoids, we humans are most closely related to chimpanzees (including bonobos). The second runner-up is gorillas, then orangutans, and then finally that big bushy mass of gibbons. These relationships reflect events in our ancestry: the human-chimp split (about 5–7 million years ago), the split from gorillas (about 8–10 million years ago), the split of African hominids and orangutans (about 12–15 million years ago), and the split of great apes and gibbons (about 16–21 million years ago). Each split stems from a population, a group of common ancestors which we share with some other living hominoid group. Those ancestors were hominoids and were not humans; therefore, they were apes.
But, looking at this tree, you can see how unnatural the designation "ape" is. What sense does it make to lump our closest living relatives (chimpanzees) in a group with much more distant relatives (e.g., gibbons)? It would make as much sense as if we invented a group that included all hominoids except for siamang giboons, or all hominoids except for gorillas, or all hominoids except for any randomly-selected group in that cladogram.
(This also points out some problems with the Planet of the Apes movies—chimpanzees would probably just see humans, gorillas, and orangutans as belonging to some group of non-chimp hominoids. And gorillas and orangutans would respectively exclude themselves from such a group, but include chimps. Come to think of it, only the orangutans would be thinking of a natural group.)
Really, the only way to make the term "ape" natural would be to include ourselves. Then we would not only be descended from apes—we would be apes.
The term "monkey" has a similar problem, since some monkeys are more closely related to us than they are to some other monkeys.
A "monkey" is basically any simian that is not an ape (or human). To make it a natural term, we would have to include apes (including humans).
Should we use those terms differently, and consider ourselves apes and monkeys? It would be more honest, phylogenetically speaking. In the end, though, those are vernacular terms and people are free to use them however they want.
If we're descended from apes, how come apes are still around?
A variant uses "monkeys" instead of apes.
In an attempt to defend the scientific explanation, people will often use one of two stock answers:
- If you're descended from your parents, how come they're still around?
- We're not descended from apes, but we share a common ancestor with them.
Number 2 is flat-out wrong. We are descended from apes. You could modify that sentence a bit, though, and get a true statement: "We're not descended from any living apes, but we share
So what's the real answer?
The real answer is that "ape", as commonly used, is an unnatural term, and it obscures communication about the subject. Generally "ape" is used to refer to all hominoids except for humans. What's a hominoid? Let's spell that out in some detail:
Hominoidea
|--Hominidae
| |--Pongo
| | |--P. abelii (Sumatran orangutans)
| | `--P. pygmaeus (Bornean orangutans)
| `--Homininae (African hominids)
| |--Gorilla
| | |--G. beringei (eastern gorillas)
| | `--G. gorilla (western gorillas)
| `--Hominini
| |--Homo sapiens (humans)
| `--Pan
| |--P. paniscus (bonobos)
| `--P. troglodytes (common chimpanzees)
`--Hylobatidae (gibbons)
|--Symphalangus syndactylus (siamangs)
|--Hoolock
| |--H. hoolock (western hoolocks)
| `--H. leuconedys (eastern hoolocks)
|--Nomascus
| |--N. concolor (western black crested gibbons)
| |--N. gabriellae (yellow-cheeked gibbons)
| |--N. leucogenys (white-cheeked crested gibbons)
| `--N. nasutus (western black crested gibbons)
`--Hylobates
|--H. agilis (agile gibbons)
|--H. klossii (Kloss's gibbons)
|--H. lar (lar gibbons)
|--H. moloch (silvery gibbons)
|--H. muelleri (Müller's gibbons)
`--H. pileatus (pileated gibbons)
Cladogram of extant hominoids, to species level.
(Yes the scientific name of western gorillas really is Gorilla gorilla. And the western subspecies thereof is Gorilla gorilla gorilla!)
As you can see, hominoids form a big, bushy branch of the primate tree, and most of the extant twigs (i.e., species) are among the gibbons (although most living individual hominoids are human—nearly all of the other species shown here are threatened or endangered).
Among living hominoids, we humans are most closely related to chimpanzees (including bonobos). The second runner-up is gorillas, then orangutans, and then finally that big bushy mass of gibbons. These relationships reflect events in our ancestry: the human-chimp split (about 5–7 million years ago), the split from gorillas (about 8–10 million years ago), the split of African hominids and orangutans (about 12–15 million years ago), and the split of great apes and gibbons (about 16–21 million years ago). Each split stems from a population, a group of common ancestors which we share with some other living hominoid group. Those ancestors were hominoids and were not humans; therefore, they were apes.
But, looking at this tree, you can see how unnatural the designation "ape" is. What sense does it make to lump our closest living relatives (chimpanzees) in a group with much more distant relatives (e.g., gibbons)? It would make as much sense as if we invented a group that included all hominoids except for siamang giboons, or all hominoids except for gorillas, or all hominoids except for any randomly-selected group in that cladogram.
(This also points out some problems with the Planet of the Apes movies—chimpanzees would probably just see humans, gorillas, and orangutans as belonging to some group of non-chimp hominoids. And gorillas and orangutans would respectively exclude themselves from such a group, but include chimps. Come to think of it, only the orangutans would be thinking of a natural group.)
Really, the only way to make the term "ape" natural would be to include ourselves. Then we would not only be descended from apes—we would be apes.
The term "monkey" has a similar problem, since some monkeys are more closely related to us than they are to some other monkeys.
Haplorhini
|--Tarsius (tarsiers)
`--Simii (a.k.a. Anthropoidea)
|--Catarrhini
| |--Hominoidea (apes, including humans)
| `--Cercopithecidae (Old World monkeys)
| |--Cercopithecinae (macaques, baboons, etc.)
| `--Colobinae (colobus monkeys, langurs, etc.)
`--Platyrrhini (New World monkeys)
|--Aotidae (owl monkeys)
|--Atelidae (howler moneys, spider monkeys, etc.)
|--Cebidae (marmosets, capuchins, etc.)
`--Pithecidae (titis, uakaris, etc.)
Cladogram of dry-nosed primates (haplorrhines), to an arbitrary level of resolution.
A "monkey" is basically any simian that is not an ape (or human). To make it a natural term, we would have to include apes (including humans).
Should we use those terms differently, and consider ourselves apes and monkeys? It would be more honest, phylogenetically speaking. In the end, though, those are vernacular terms and people are free to use them however they want.
27 November 2007
Flex Builder 3 Deep Linking: Awesome!
O.K, so, a little history.
Everyone reading this is aware of what a website is. Generally, it's a collection of hypertext pages that cross-link to each other.
At least, that's what they used to be. Increasingly over the past decade, more and more Flash websites have appeared. A Flash website is generally one interactive "movie" file that dynamically loads content according to user actions. In other words, a Flash website is not a collection of "pages"—it's a (potentially) complex application that can take on many different states.
With a traditional hypertext website, linking to any particular "page" is simple. Even linking to particular sections of particular pages is simple. Each page has its own address (a URL—Uniform Resource Locator), so you can just grab that in your browser and pass it off to someone else.
With Flash websites, it becomes a lot more complicated. The state of the Flash movie is not automatically reflected in the URL. Generally, you have to implement some kind of complex system, using JavaScript, to tack on information to the URL. The information flow has to go both ways. Flash has to be able to read the URL, determine the proper state, and move into it. At the same time, whenever the user induces Flash into entering a different state, that must be reported to the browser so it can be reflected in the URL. It's a major pain.
Enter Flex Builder 3.
Flex Builder is a development tool (also available as a plugin for the Eclipse development platform, which is what I use) that generates Flash content. Not long ago, Adobe released an alpha version of version 3.
I had heard that they had added a deep-linking feature, and had been meaning to read up on it Doubtless they would it some kind of customized implementation with my components.
Wrong.
Last night I was troubleshooting a bug with March of Man, and happened to upload some files generated by Flex Builder 3, which had not previously been uploaded. All of a sudden, there it was: deep-linking to every major section of the site.
I barely had to lift a finger.
Regard:
O.K., so it's not perfect. The URLs are a bit ugly, and I'm not sure if they're going to work with future versions of the website. Also, it'd be nice if the browser title changed. But I'm sure with a little delving into the documentation and a few tweaks, it should be possible.
On another note, I am no longer the only artist on March of Man! (Well, already some of my works are heavily based on photographs taken by others, which is why I need to implement multiple attributions, but anyway....) With the addition of Stephen O'Connor's Homo erectus, this is finally what it was meant to be: a collaborative paleo-art project.
Everyone reading this is aware of what a website is. Generally, it's a collection of hypertext pages that cross-link to each other.
At least, that's what they used to be. Increasingly over the past decade, more and more Flash websites have appeared. A Flash website is generally one interactive "movie" file that dynamically loads content according to user actions. In other words, a Flash website is not a collection of "pages"—it's a (potentially) complex application that can take on many different states.
With a traditional hypertext website, linking to any particular "page" is simple. Even linking to particular sections of particular pages is simple. Each page has its own address (a URL—Uniform Resource Locator), so you can just grab that in your browser and pass it off to someone else.
With Flash websites, it becomes a lot more complicated. The state of the Flash movie is not automatically reflected in the URL. Generally, you have to implement some kind of complex system, using JavaScript, to tack on information to the URL. The information flow has to go both ways. Flash has to be able to read the URL, determine the proper state, and move into it. At the same time, whenever the user induces Flash into entering a different state, that must be reported to the browser so it can be reflected in the URL. It's a major pain.
Enter Flex Builder 3.
Flex Builder is a development tool (also available as a plugin for the Eclipse development platform, which is what I use) that generates Flash content. Not long ago, Adobe released an alpha version of version 3.
I had heard that they had added a deep-linking feature, and had been meaning to read up on it Doubtless they would it some kind of customized implementation with my components.
Wrong.
Last night I was troubleshooting a bug with March of Man, and happened to upload some files generated by Flex Builder 3, which had not previously been uploaded. All of a sudden, there it was: deep-linking to every major section of the site.
I barely had to lift a finger.
Regard:
O.K., so it's not perfect. The URLs are a bit ugly, and I'm not sure if they're going to work with future versions of the website. Also, it'd be nice if the browser title changed. But I'm sure with a little delving into the documentation and a few tweaks, it should be possible.
On another note, I am no longer the only artist on March of Man! (Well, already some of my works are heavily based on photographs taken by others, which is why I need to implement multiple attributions, but anyway....) With the addition of Stephen O'Connor's Homo erectus, this is finally what it was meant to be: a collaborative paleo-art project.
26 November 2007
March of Man Skewed
Posted a very minor March of Man update last night. Now the collages can be horizontally skewed. Examples (click to enlarge):
(Vertical distribution primarily based on phylogeny.)
(Vertical distribution based on geography.)
(You'll note I also finished some more Homo sapiens sapiens depictions.)
(Vertical distribution primarily based on phylogeny.)
(Vertical distribution based on geography.)(You'll note I also finished some more Homo sapiens sapiens depictions.)
23 November 2007
New: March of Man Collages
I've just uploaded a new version of March of Man. The primary new feature is a tab called "Collage", which contains a first attempt at the doing what the project is all about: creating an image that uses multiple figures to show to story of hominin phylogeny and geographic dispersal.
An auto-generated March of Man collage.
Okay, so there's still a lot to be done. There are only 13 images in the database so far (all mine, although some are heavily based on others' photos), so there are plenty of gaps to fill in.
Collage features planned for the future:
As I further refine this tool, and as the database of images continues to grow, the collages will become more and more like I first envisioned. (Or maybe some other ideas will become apparent later on ... this isn't a rigorously planned-out project.)
Some other things I intend to add to the site:
Qayin wa-Habel
(Cain and Abel)
Ardipithecus ramidus juveniles
An auto-generated March of Man collage.Okay, so there's still a lot to be done. There are only 13 images in the database so far (all mine, although some are heavily based on others' photos), so there are plenty of gaps to fill in.
Collage features planned for the future:
- Better backgrounds.
- Different algorithms for generating the collages. (This will only become important once the database has many, many more images.)
- The ability to move, rotate, and scale images in the collage.
- The ability to add filters to images (adjusting the color, contrast, etc.).
- The ability to save collages.
As I further refine this tool, and as the database of images continues to grow, the collages will become more and more like I first envisioned. (Or maybe some other ideas will become apparent later on ... this isn't a rigorously planned-out project.)
Some other things I intend to add to the site:
- The ability to attribute more than one artist per image.
- "Starter" PSD files that can be downloaded, including tiled isometric backgrounds and scale indications.
- A scale widget that's easier to use.
- Illustrated instructions for exporting the right kind of file.
- An administration tool, so I can update data on the various taxa more readily.
- More illustrations (and better ones) for the "About" and "F.A.Q." sections.
- Thumbnail images for browsing.
Qayin wa-Habel(Cain and Abel)
Ardipithecus ramidus juveniles
21 November 2007
Trees, Bubbles, and Hooves
"Bubble-Thinking"
Over the past few decades, there has been a major shift in how scientists think about organism relationships at larger scales. Open up a textbook on evolution and you will probably see what's referred to as a "bubble diagram". Over the ages, it will show various groups swelling in size and then tapering off, but often spitting off one or more other such "bubbles" before they completely die out. Here's an example:
If your textbook has a diagram like this, you may need a new textbook.This shows the evolution of hoofed mammals since the end of the Cretaceous (about 65 million years ago). A generalized bunch of mammals called "Condylarthra" spits off several radiations before it goes extinct: Artiodactyla (even-toed ungulates: pigs, hippos, camels, ruminants, etc.), Perissodactyla (odd-toed ungulates: horses, rhinos, tapirs, etc.), Tubulidentata (aardvarks), Hyracoidea (the superficially rodent-like hyraxes), Proboscidea (elephants, etc.), Sirenia (manatees, dugongs, etc.), and some extinct groups like Desmostylia and a large South American group. At least one of these radiations, Artiodactyla, spits off its own new radiation: Cetacea, the whales.
This diagram nicely shows population changes over time and is pretty instantly comprehensible. Unfortunately, it's also wrong, WRONG, WRONG.
First of all, it obscures the actual relationships of the "parent taxon" to the "daughter taxon". Obviously, some "condylarths" will be closer to one or more of the "daughter taxa" than they are to other condylarths. Why lump them in with organisms they share less common ancestry with? The group "Condylarthra" is simply unnatural. "Artiodactyla", as shown here, is unnatural, too—hippos are probably closer to cetaceans than they are to other artiodactyls.
Furthermore, recent molecular studies have shown that "Ungulata" is not a natural group. Some of these lineages—Hyracoidea, Proboscidea, Sirenia, and Tubulidentata—are part of Afrotheria, an endemic African clade including golden moles, tenrecs, otter shrews, elephant shrews (sengis), etc. Perissodactyla is allied to Ferae (carnivorans and pangolins), and Artiodactyla is allied to a group including Chiroptera (bats), Ferae, and Perissodactyla, which was rather creatively named Pegasoferae ("Pegasus wild beasts").
(As for the extinct South American ungulates, obviously molecular studies aren't going to tell us much, and I don't think anyone's done the morphological legwork yet—if anyone can knows of such a study, please enlighten me.)
In short, "ungulates" are not a phylogenetic group, but more of a general ecological form, one which several placental lineages arrived at independently (and some, like cetaceans and sirenians, secondarily lost as they became aquatic). There is no such thing as one "origin of the ungulates"—there were many such origins.
"Tree-Thinking"
Under newer paradigms, we don't think of higher taxa as bubbles that spit off other bubbles. Instead, higher taxa are clades: an ancestor and all of its descendants. Artiodactyla did not spit off Cetacea; instead, Artiodactyla includes Cetacea.
Placentalia
|--Atlantogenata
| |--Xenarthra (sloths, armadillos, anteaters)
| `--Afrotheria
| |--Afroinsectiphilia
| | |--Macroscelididae (elephant shrews)
| | `--+--Orycteropus afer (aardvark) *
| | `--Afrosoricida (golden moles, tenrecs, etc.)
| `--Paenungulata *
| |--Elephantidae *
| `--+--Procaviidae (hyraxes) *
| `--Sirenia *
`--Boreotheria
|--Supraprimates
| |--Glires (rodents, rabbits, etc.)
| `--Euarchonta (primates, etc.)
`--Laurasiatheria
|--Eulipotyphla (shrews, moles, hedgehogs, etc.)
`--Scrotifera
|--Artiodactyla *
| |--Camelidae (camels, llamas) *
| `--+--Suoidea (pigs, peccaries) *
| `--+--Ruminantia (deer, antelope, etc.) *
| `--Whippomorpha *
| |--Cetacea *
| `--Hippopotamidae *
`--Pegasoferae
|--Chiroptera
`--Zooamata
|--Perissodactyla *
`--Ferae
|--Carnivora (dogs, cats, etc.)
`--Manis(pangolins)
* hoofed or ancestrally hoofed
Cladogram showing the distribution of hooves among extant placental mammals. Some of the particulars remain under debate, but the picture is becoming clearer.
So What?
Understanding phylogeny is crucial to investigating questions about the history of life. For example: what caused the mass extinctions at the end of the Cretaceous? This is a question which has received a lot of attention, both scientific and popular.
To even begin to answer this question, we have to know which groups of organisms perished and which made it through. Specifically, many researchers are curious as to whether a given diverse crown group started to diversify before the extinction, or survived as a single lineage which diversified afterwards. As an example, there is evidence to suggest that the crown group of birds had started to diversify earlier, with at least six lineages surviving into the Cenozoic (the current era).
Obviously, one such group of interest is Placentalia (all researchers being lifelong members). Did a single lineage squeak through (ha ha!) by the hair on its chin (my sides!) to give rise to atlantogenates and boreotheres later, or had placental mammals already begun to diversify before the mass extinctions began, at the feet of the dinosaurs?
Earlier this month (a day before my birthday, in fact), a paper was published which tentatively suggests the latter case: placentals diversified before the extinction. Titled A Cretaceous Hoofed Mammal from India, it names a new species, Kharmerungulatum vanvaleni, based on a single lower molar. As this molar shows similarities to those of Protungulatum, an early condylarth, K. vanvaleri is assigned to Condylarthra. The authors suggest that this may mean that the ancestors of ungulates had diversified before the end of the Cretaceous, perhaps especially in Gondwana.
To me this is a clear example of the dangers of "bubble-thinking". Phylogenetic research has shown us that "ungulates" are not an evolutionary unit. Hence, the "ancestors of ungulates" are really "ancestors of placentals". Furthermore, it may be that Protungulatum is part of a side-branch to the placentals, so if this new Indian taxon is closely related to Protungulatum (and even that evidence is scanty), then it may not even be a placental. All this tooth really tells us is that some therian lived in India toward the end of the Cretaceous. And that has no bearing at all on the question of whether placentals originated during or after the Cretaceous.
However, if Kharmerungulatum does share a clade with Protungulatum to the exclusion of placentals, then it would be part of another clade that persisted across the boundary, but died out soon thereafter. Why did this clade and the ancestors of placentals survive? Why did placentals win out in the aftermath? Perhaps this new taxon can help us answer these types of questions, which come from a "tree-thinking" perspective. Of course, so far, Kharmerungulatum is just a tooth—but maybe more material is out there.
Phylogeny diagram showing major placental groups and some "condylarths", including a tentative position for the new taxon. The Cretaceous/Paleogene extinction occurred at the color boundary, about 65 million years ago.
What about the condylarths? Work is still going on to see how these fit into the newer ideas about placentalian phylogeny. They are probably an unnatural group with multiple origins. One recent study suggests that some may not even belong to the crown group—they may be stem-placentals, on one or more side-branches to Placentalia.
So What?
Understanding phylogeny is crucial to investigating questions about the history of life. For example: what caused the mass extinctions at the end of the Cretaceous? This is a question which has received a lot of attention, both scientific and popular.
To even begin to answer this question, we have to know which groups of organisms perished and which made it through. Specifically, many researchers are curious as to whether a given diverse crown group started to diversify before the extinction, or survived as a single lineage which diversified afterwards. As an example, there is evidence to suggest that the crown group of birds had started to diversify earlier, with at least six lineages surviving into the Cenozoic (the current era).
Obviously, one such group of interest is Placentalia (all researchers being lifelong members). Did a single lineage squeak through (ha ha!) by the hair on its chin (my sides!) to give rise to atlantogenates and boreotheres later, or had placental mammals already begun to diversify before the mass extinctions began, at the feet of the dinosaurs?
The Kharmer "Ungulate"
Earlier this month (a day before my birthday, in fact), a paper was published which tentatively suggests the latter case: placentals diversified before the extinction. Titled A Cretaceous Hoofed Mammal from India, it names a new species, Kharmerungulatum vanvaleni, based on a single lower molar. As this molar shows similarities to those of Protungulatum, an early condylarth, K. vanvaleri is assigned to Condylarthra. The authors suggest that this may mean that the ancestors of ungulates had diversified before the end of the Cretaceous, perhaps especially in Gondwana.
To me this is a clear example of the dangers of "bubble-thinking". Phylogenetic research has shown us that "ungulates" are not an evolutionary unit. Hence, the "ancestors of ungulates" are really "ancestors of placentals". Furthermore, it may be that Protungulatum is part of a side-branch to the placentals, so if this new Indian taxon is closely related to Protungulatum (and even that evidence is scanty), then it may not even be a placental. All this tooth really tells us is that some therian lived in India toward the end of the Cretaceous. And that has no bearing at all on the question of whether placentals originated during or after the Cretaceous.
However, if Kharmerungulatum does share a clade with Protungulatum to the exclusion of placentals, then it would be part of another clade that persisted across the boundary, but died out soon thereafter. Why did this clade and the ancestors of placentals survive? Why did placentals win out in the aftermath? Perhaps this new taxon can help us answer these types of questions, which come from a "tree-thinking" perspective. Of course, so far, Kharmerungulatum is just a tooth—but maybe more material is out there.
Phylogeny diagram showing major placental groups and some "condylarths", including a tentative position for the new taxon. The Cretaceous/Paleogene extinction occurred at the color boundary, about 65 million years ago.References
- Beck, R. M. D., O. R. P. Bininda-Emonds, M. Cardillo, F.-G. R. Liu, and A. Purvis (2007 Nov. 13). A higher-level MRP supertree of placental mammals. BMC Evolutionary Biology 6(93). doi:10.1186/1471-2148-6-93
- Clarke, J. A., C. P. Tambussi, J. I. Noriega, G. M. Erickson, and R. A. Ketcham (2005 Jan. 20). Definitive fossil evidence for the extant avian radiation in the Cretaceous. Nature 433: 305-308. doi:10.1038/nature03150
- Hallström, B. M., M. Kullberg, M. A. Nilsson, and A. Janke (2007). Phylogenomic data analyses provide evidence that Xenarthra and Afrotheria are sister groups. Molecular Biology and Evolution 24(9): 2059-2068. doi:10.1093/molbev/msm136
- Nishihara, H., M. Hasegawa, and N. Okada (2006 June 27). Pegasoferae, an unexpected mammalian clade revealed by tracking ancient retroposon insertions. Proceedings of the National Academy of Sciences 103: 9929-9934. doi:10.1073/pnas.0603797103
- Prasad, G. R., O. Verma, A. Sahmi, V. Parmar, and A Khosta (2007 Nov. 9). A Cretaceous hoofed mammal from India. Science 38: 937. doi: 10.1126/science.1149267
- Wible, J. R., G. W. Rougier, M. J. Novacek, and R.J. Asher (2007 June 21). Cretaceous eutherians and Laurasian origin for placental mammals near the K/T boundary. Nature 447: 1003-1006. doi:10.1038/nature05854
09 November 2007
Who Ate What Now?
Most fossils, especially the older ones, are annoyingly incomplete. They'll find a few bones, or some footprints, a smudgy outline, etc. Then there are the more-or-less complete specimens, which are rarer but still not infrequent. And finally there are real "snapshots of life" which come along once in a great while. This latest discovery, for example:
Specimens with the remains of ingested animals are sometimes found, but I've never heard of this kind of "Russian doll" fossil before. Truly remarkable.
And now that I've finished marveling at it, it's time for me to return to character and bemoan the nomenclatural inaccuracies!
First, what are the actual animals involved? It's an Acanthodes bronni, eaten by a temnospondyl, eaten by a Triodus sessili. Is the headline accurate? Let's establish a few ground rules first.
Most taxa (at least of those that have been around a while) are based on living organisms. When related fossil organisms are found, there is often some dispute as to whether to include them or not. For example, when Archaeopteryx was discovered, people couldn't decide if it was a bird or not. It had feathered wings and bird-like feet, but also had teeth and a long tail. Did it fly? Who knows.
In the past, some people have recommended letting taxa extend as far as possible, encompassing what is known as the total group. A total group includes everything sharing closer ancestry with the living members of a group than with any other living organisms. This approach can run into some serious problems, though. For example, it would make all dinosaurs birds. More generally, it lumps the earliest, barely differentiated members of a lineage in with their derived, living descendants. This encourages the use of unjustified inferences. For example, I know that all living birds have tertial feathers (long feathers along the upper arm), so, since Archaeopteryx is a bird, it should have them, too, right? WRONG. Analysis of the available fossils has yet to indicate the presence of any tertials.
This is why many others encourage the use of crown groups for common taxonomic names. A crown group is the final common ancestor of certain living organisms, and all descendants of that ancestor. Using a crown group definition for Aves, for example, would limit it to the clade of modern birds, thereby excluding Archaeopteryx. This practice has the effect of discouraging unjustified inferences.
One other term to note here is stem group. This is simply a total group minus its included crown group. For example, a stem-avian is anything sharing closer ancestry with birds than with other living organisms (e.g., crocodylians), but outside the crown group Aves. Archaeopteryx and all the classic dinosaurs are stem-avians, as are (probably) pterosaurs.
Is Acanthodes a fish? Well, yes, they got that right. "Fish" is a really, really broad category, tantamount to "any craniate that isn't a tetrapod" (more or less). Specifically it is an acanthodian, which makes it a stem-osteichthyan (Osteichthyes being the crown group that includes bony vertebrates, e.g., ray-finned fishes, lungfishes, coelacanths, and tetrapods).
Are temnospondyls amphibians? O.K., this is harder. Traditionally, Amphibia was used as a "wastebasket taxon" for any tetrapod that was not an amniote. More recently, it has been limited to one of two groups: the total group including frogs, salamanders, and caecilians; or the crown group including frogs, salamanders, and caecilians. There is actually quite a bit of debate on this matter and I don't expect it to be resolved any time soon. According to the crown group usage, temnospondyls are definitely not amphibians. But according to the total group usage, they might be. (But they might also be stem-tetrapods or stem-amniotes.)
Is Triodus a shark? "Shark" is a really abused term in paleontology. (In fact, acanthodians are sometimes called "spiny sharks" even though they're not even chondrichthyans.) Among modern animals, the term is generally limited to Selachii, the flatter members of which are called skates or rays. Triodus is a stem-selachian, closer to sharks, rays, and skates than to ratfishes (Holocephali). So is it a shark? If we want to limit unjustified inferences, then we should say no.
Okay, smarty, how would YOU dumb this down? Argh, that's pretty hard. Personally I think the lay public might be ready for the term "stem-", but I seem to have a bad habit of overestimating the lay public. Anyway, the best I can come up with is "Stem-Shark Ate Limbed Creature Ate Fish." Doesn't roll off the tongue, you say? Well, I guess this is why I'm not a journalist....
(References to be added later, if I have time.)
Specimens with the remains of ingested animals are sometimes found, but I've never heard of this kind of "Russian doll" fossil before. Truly remarkable.
And now that I've finished marveling at it, it's time for me to return to character and bemoan the nomenclatural inaccuracies!
First, what are the actual animals involved? It's an Acanthodes bronni, eaten by a temnospondyl, eaten by a Triodus sessili. Is the headline accurate? Let's establish a few ground rules first.
Most taxa (at least of those that have been around a while) are based on living organisms. When related fossil organisms are found, there is often some dispute as to whether to include them or not. For example, when Archaeopteryx was discovered, people couldn't decide if it was a bird or not. It had feathered wings and bird-like feet, but also had teeth and a long tail. Did it fly? Who knows.
In the past, some people have recommended letting taxa extend as far as possible, encompassing what is known as the total group. A total group includes everything sharing closer ancestry with the living members of a group than with any other living organisms. This approach can run into some serious problems, though. For example, it would make all dinosaurs birds. More generally, it lumps the earliest, barely differentiated members of a lineage in with their derived, living descendants. This encourages the use of unjustified inferences. For example, I know that all living birds have tertial feathers (long feathers along the upper arm), so, since Archaeopteryx is a bird, it should have them, too, right? WRONG. Analysis of the available fossils has yet to indicate the presence of any tertials.
This is why many others encourage the use of crown groups for common taxonomic names. A crown group is the final common ancestor of certain living organisms, and all descendants of that ancestor. Using a crown group definition for Aves, for example, would limit it to the clade of modern birds, thereby excluding Archaeopteryx. This practice has the effect of discouraging unjustified inferences.
One other term to note here is stem group. This is simply a total group minus its included crown group. For example, a stem-avian is anything sharing closer ancestry with birds than with other living organisms (e.g., crocodylians), but outside the crown group Aves. Archaeopteryx and all the classic dinosaurs are stem-avians, as are (probably) pterosaurs.
Archosauria
|-Pan-Crocodylia (including Crocodylia)
`-Pan-Aves
|-Pterosauria *
`-+-Marasuchus *
`-+-Silesaurus *
`-Dinosauria *
|-Ornithischia *
`-+-Herrerasauridae *
`-+-Sauropodomorpha *
`-+-Eoraptor *
`-+-Coelophysoidea *
`-+-Dilophosauridae *
`-+-Ceratosauria *
`-Tetanurae
Tetanurae
|-Spinosauroidea *
`-+-Carnosauria *
`-+-Compsognathidae *
|-Tyrannosauroidea *
`-+-Ornithomimosauria *
`-+-Oviraptoriformes *
`-+-Deinonychosauria *
`-+-Archaeopterygidae *
`-+-Confuciusornithidae *
`-+-Enantiornithes *
`-+-Hesperornithes *
`-+-Ichthyornithes *
`-Aves
* extinct stem-avian taxon
Cladograms (somewhat abridged) showing the avian stem group.
Is Acanthodes a fish? Well, yes, they got that right. "Fish" is a really, really broad category, tantamount to "any craniate that isn't a tetrapod" (more or less). Specifically it is an acanthodian, which makes it a stem-osteichthyan (Osteichthyes being the crown group that includes bony vertebrates, e.g., ray-finned fishes, lungfishes, coelacanths, and tetrapods).
Are temnospondyls amphibians? O.K., this is harder. Traditionally, Amphibia was used as a "wastebasket taxon" for any tetrapod that was not an amniote. More recently, it has been limited to one of two groups: the total group including frogs, salamanders, and caecilians; or the crown group including frogs, salamanders, and caecilians. There is actually quite a bit of debate on this matter and I don't expect it to be resolved any time soon. According to the crown group usage, temnospondyls are definitely not amphibians. But according to the total group usage, they might be. (But they might also be stem-tetrapods or stem-amniotes.)
Is Triodus a shark? "Shark" is a really abused term in paleontology. (In fact, acanthodians are sometimes called "spiny sharks" even though they're not even chondrichthyans.) Among modern animals, the term is generally limited to Selachii, the flatter members of which are called skates or rays. Triodus is a stem-selachian, closer to sharks, rays, and skates than to ratfishes (Holocephali). So is it a shark? If we want to limit unjustified inferences, then we should say no.
Gnathostomata (jawed vertebrates)
|--Chondrichthyes (cartilaginous fishes)
| |--Holocephali (ratfishes)
| `--+--Triodus *
| `--Selachii (sharks, rays, skates)
`--+--Acanthodes *
`--Osteichthyes (bony vertebrates)
|--Actinopterygii (ray-finned fishes)
`--Sarcopterygii (flesh-finned vertebrates)
|--Dipnoi (lungfishes)
|--Latimeria (Recent coelacanths)
`--Apo-Tetrapoda (limbed vertebrates)
|?-Temnospondyli *
`--Tetrapoda
|--+?-Temnospondyli *
| `--Amniota
`--Amphibia sensu lato
|?-Temnospondyli *
`--Amphibia sensu stricto
* extinct
Cladogram of the taxa in question, with related extant taxa.
Okay, smarty, how would YOU dumb this down? Argh, that's pretty hard. Personally I think the lay public might be ready for the term "stem-", but I seem to have a bad habit of overestimating the lay public. Anyway, the best I can come up with is "Stem-Shark Ate Limbed Creature Ate Fish." Doesn't roll off the tongue, you say? Well, I guess this is why I'm not a journalist....
(References to be added later, if I have time.)
The Ten Commandments
From time to time I may post things I've written elsewhere, just to aggregate them under this new blog.
A couple of years ago I decided to try my hand at translating the Ten Commandments (from the Torah). Of course, there are three or four different versions. (The "or four" is because of one section that lists commandments, but more than ten.) The version people usually think of is probably a latter-day revision, presented in slightly different forms in two different parts of the Torah. But I was more interested in what is probably the oldest version.
A couple of years ago I decided to try my hand at translating the Ten Commandments (from the Torah). Of course, there are three or four different versions. (The "or four" is because of one section that lists commandments, but more than ten.) The version people usually think of is probably a latter-day revision, presented in slightly different forms in two different parts of the Torah. But I was more interested in what is probably the oldest version.
And he [Yahweh] said, "So, I will cut a deal, making before all your kinsfolk exceptional things which were not created in all the land and in all the [lands of the] Goyim1, and all the kinsmen who are among you will see the deeds of Yahweh2, for it is a fearful thing which I will make your kinsfolk. Keep that which I command you this day. Lo, I will expel from before you the 'Emori3 and the Kana´ani4 and the Khiti5 and the Parizi6 and the Khiwi7 and the Yebusi8.
"[1] And keep yourselves, lest you cut a deal with dwellers of the land which you enter over, lest it turn to be a trap in your midst. For you are to pull down their sacrificial altars and break down their pillars and cut down their 'Asherah9 poles. For you are not to bow down to any other god10, for Yahweh the Jealous is his name; a jealous god he is; lest you cut a deal with dwellers of the land, and they whore themselves to their other Gods, and sacrifice to their Gods, and call to you to eat from their sacrifice, and you take from their daughters [wives] for your sons, and their daughters whore themselves to other Gods, and your sons whore themselves to other Gods.
"[2] Do not make for yourselves molten11 gods.
"[3] Keep the Feast of the Matsoh, seven days of eating matsoh, whose season, as I commanded to you, is the month 'Abib12, for in the month 'Abib you went forth from Mitsrayim13.
"[4] The firstlings of all wombs are for me: all your firstling male livestock, herdling14 and flockling15. But you are to redeem firstling donkeys with flocklings, and whenever you cannot redeem [one], break its neck. Redeem all your firstborn sons and do not face me emptyhanded.
"[5] You are to work for six days, and rest on the seventh day. You must rest [even] in plowing season and in harvest.
"[6] And make for yourselves the Feast of Sevens16 [with] the first crops of the harvested wheat, and the Feast of the Harvest Gathering at the turnings of the year.
"[7] Three times in a year all your males are to appear before the Lord Yahweh, God of Yishra’el17. For I will dispossess Goyim in front of you, and I will extend your boundaries, and no man will desire your land when you rise to appear before Yahweh your God three times in a year.
"[8] Do not slaughter to me with yeast [in the] blood of my sacrifice, and do not lodge a sacrifice from the Feast of the Passover through to morning.
"[9] [The] foremost first crops of your ground are to enter into [the] house of Yahweh your God.
[10] You are not to cook a kid18 in its mother’s milk."
[10] You are not to cook a kid18 in its mother’s milk."
And Yahweh said to Mosheh19, "Write for yourself these Statements20, for in accord with these Statements I cut a deal with you and Yishra’el." And he was there with Yahweh forty21 days and forty nights, not eating food nor drinking water, and he wrote upon the slabs22 the Statements of the Deal23: The Ten Statements.
—We'eleh Shemoth24 34:10–28
Footnotes:
1. sometimes translated as "nations"
2. sometimes translated as "LORD", but this is a different word ('adon) whose vowel markings were used over the four letters of YHWH to signify that the name of the god of Israel should not be spoken
3. or "Amorite"—literally, "Speaker"
4. or "Canaanite" or "Phoenician"—literally, "Lowlander"; Canaanites were great sailors and inventors of the alphabet, formulating the script that the scripts for Hebrew, Greek, Latin, etc. derived from.
5. or 'Hittite"—literally, "Son of Heth", "Heth" meaning "Terror"
6. or "Perizzite"—literally, "Rural Villager"
7. or "Hivite"—literally, "Villager"
8. or "Jebusite"—literally, "Son of Yebus", "Yebus" meaning "Trampler"; Jebusites were the founders of Jerusalem
9. Sometimes translated as "groves", but 'Asherah is a goddess, known as 'Astarte in Babylon. Her name is related to the word "straight", hence the meaning here of "'Asherah poles". Although known as the consort of 'El, archaeological evidence suggests she was worshiped by Judahites as the consort of Yahweh.
10. I have render "'el" as "god" and "'elohah" as "God".
11. literally "poured"
12. the first month of Spring, roughly March and/or April
13. Egypt; this is a dual word, possibly reflecting the Upper and Lower Kingdoms
14. e.g., ox
15. e.g., goat or sheep
16. or "Weeks"
17. Israel
18. i.e., a young male goat
19. Moses
20. or, more popularly, "Commandments"
21. literally "fours"
22. or, more popularly, "tablets"
23. or, more popularly, "covenant"
24. "And These Are The Names...", also known as "Exodus"
08 November 2007
Inglish av dha Fyuwchrr
Whan that Aprille with his shoures soote
The droghte of Marche hath perced to the roote,
And bathed every veyne in swich licour,
Of which vertu engendred is the flour
The droghte of Marche hath perced to the roote,
And bathed every veyne in swich licour,
Of which vertu engendred is the flour
—Geoffrey Chaucer
English has changed a lot in the past 600-odd years. None of us will (probably) know how much it will change in the next 600. But I think it's fun to make guesses.
I had an idea once for a way to get an idea of how the sounds of English might change if current trends continue. It was based on the observation that spoken language changes much faster than written language (which is one reason why English is spelled so horribly—the phonology has changed a lot, but we still spell things as Shakespeare might have pronounced them). The basic concept would be to do something like this:
Of course, it'd be silly to think that this would be an accurate way of divining the future. Even if it did reflect past trends continuing, that's not always how language evolution works. But it might be a fun exercise to try, nonetheless. We already have reconstructed languages; why not preconstructed?
English has changed a lot in the past 600-odd years. None of us will (probably) know how much it will change in the next 600. But I think it's fun to make guesses.
I had an idea once for a way to get an idea of how the sounds of English might change if current trends continue. It was based on the observation that spoken language changes much faster than written language (which is one reason why English is spelled so horribly—the phonology has changed a lot, but we still spell things as Shakespeare might have pronounced them). The basic concept would be to do something like this:
- Record native speakers, Group A, reading a list of words and phrases out loud. Some of the words should be fictitious, but plausible according to the rules of English phonology and spelling (such as they are).
- Use a phonetic or phonemic system to write down how Group A pronounced the list.
- Have another group of native speakers, Group B, read the lists based on Group A's pronunciation. (Note: people in this group must be unfamiliar with the phonetic or phonemic system, and preferably unfamiliar with the study of phonology in general.)
- Extrapolate patterns from the differences in the two groups' pronunciations.
Of course, it'd be silly to think that this would be an accurate way of divining the future. Even if it did reflect past trends continuing, that's not always how language evolution works. But it might be a fun exercise to try, nonetheless. We already have reconstructed languages; why not preconstructed?
The Ancestry of Gods
(Fair warning: I'm still fairly early in my serious studies of this field, so beware the occasional mistake.)
One of my "someday I'd like to do this" projects is a design (suitable for shirts, posters, etc.) showing the genealogy of the major Christian gods. Yes, gods. Monotheism, my butt. You got Deus Pater, Yesous Christos, Yahweh, 'El Shaddai, the 'Elohim, and the Holy Spirit, not to mention rival factions (many of which were allies, early on) like the Şaţan (originally Yahweh's attorney, later coöpted into a Pan-like rival), Be'el Zebub, Asherah, etc. (Sure, the rivals aren't usually termed "gods", but they're considered supernaturally powerful people, and what is a "god", if not that?)
The major problem I've run into is that there are two kinds of genealogy when it comes to gods. One might be termed familial genealogy: Zeus and Hera are the parents of Ares, Odin is the father of Thor, etc. This is "genealogy" in the same sense as it's used for actual people.
Bust of Zeus from the British Museum.
The other might be termed cultural genealogy. This follows etymology fairly closely. As an example, Jupiter, the name of the chief god of the ancient Romans, is a contraction from something like Iou Pater, meaning "Jove the Father". The name Iou/Jove, in turn, descends from *Dyeus, the reconstructed name of the patriarchal sky god of the early Indo-Europeans. (The asterisk before the name indicates that it is reconstructed, not known from documents.) This name and its associated god were also inherited by other Indo-European cultures: *Tiwaz of the ancient Germanians (whence "Tuesday"), Zeus of the ancient Greeks, Dyauş Pitār of the ancient Indians, etc.
Týr, an Icelandic variant of *Tiwaz.
Something interesting happened in some cases: the name was inherited, but a new meaning was inquired. Greek theos, Latin deus, and Anglo-French divin refer not to particular gods, but to the general concept of a supernaturally powerful person. English, that great borrower of vocabulary, has a number of generic words ultimately derived from *Dyeus via various paths (mostly through Anglo-French): deity, diva, and divine from Latin, and theist and theologian from Greek. My own first name, Timothy (from Greek Timotheos) means "god-honorer", but the last syllable is ultimately traceable to *Dyeus. (And, yes, it's ironic that I turned out to be an atheist, especially given that my middle name means ... well, more on that in a bit.)
The ancestry of our own generic word, god, is a bit murky. All of the Germanic languages have some form like god or Gott or guth, but none of the other Indo-European languages have such a word (with the possible exception of Farsi khoda). Perhaps its origins are from some obliterated "Old European" language. But a possibly more likely explanation is descent from the proto-Indo-European root *gheu-, meaning "to invoke", "to pour", or "to offer sacrifice". If so, it may not descend from any god's proper name.
But with the advent of Christianity in Europe, god underwent the exact opposite transformation that *Dyeus had undergone. It diversified, going from being a general term to becoming the proper name of a deity: God, the patriarchal deity of modern Christianity. This usage was, of course, inspired by the usage of the generic Latin word deus to signify the supreme deity. Indeed, from a purely etymological standpoint, Jupiter and Deus Pater ("God the Father") are the same thing!
Clearly, though, Roman Catholic priests are referring to something different from the chief Olympian god when they invoke Deus Pater. These supernatural figures have many things in common: power, masculinity, an association with the sky, etc. But they are different in other respects. Jupiter leads a pantheon of other gods, many of them his relatives. Deus Pater acknowledges no other gods, and his court is run by lesser beings (angels, kerubim, serafim, etc.) which bear no familial relation to him. Jupiter consorts with humans, even mating with them (lots of them). Deus Pater is asexual. Jupiter can be tricked, incited, enraged. Deus Pater is clear-headed, omniscient, and without fault.
But a look into Deus Pater's conceptual ancestry shows that those differences are fairly recent inventions. The Christian idea of a single god was, of course, taken from the Judaism. The Judaeans worshiped a single god, Yahweh, with many of the same attributes as the Christian god: wisdom, power, asexuality, etc. Early Christian sects were divided on how to interpret the single god (or, indeed, if it should be single), but the view that won out was sort of a beefed-up version of Yahweh (also known as Jehovah, thanks to an interesting clerical misunderstanding that I may go into another time—or you could just look it up).
So where did Yahweh come from? By the time of the early Christians, he was actually already an amalgam of earlier deities. The amalgamation process began during the Assyrian Empire. When the Assyrians conquered the coastal land of Canaan, they forced many of the Canaanites into exile. A good number headed into the wild highlands occupied by the Judahites, where they were safely out of reach. These Canaanites became known as the Israelites, or Yishra'eli, the "people of 'El", 'El being the name of their chief, patriarchal god (whence my middle name Michael, "next to 'El"). The Judahites, or Yahudi, by contrast, worshiped Yahweh. Since the Yahudi and the Yishra'eli spoke similar West Semitic dialects, their cultures merged, eventually becoming synonymous. As the cultures merged, the gods merged, too.
The Canaanite religion is well-attested from an early (i.e., pre-Biblical) time. The chief god was 'Il or 'El, and he had many sons called the 'Ilohim or 'Elohim. Chief among these were Haddu/Hadad (also considered the son of Dagon, and frequently referred to with the honorific Ba`al, meaning "lord"), the god of the sky; Yamm (later dubbed Yaw), the god of the waters; and Mot, the god of death (his name also literally meaning "Death"). 'El's consort was 'Athtart/Astarte/Asherah. This is all necessarily simplified, since various ancient Middle Eastern traditions related these gods to each other a bit differently.
'El and various beasts adorn the Gebel-el-Arak knife hilt.
The origins of the Judahite religion are not as well known. Canaanites were early innovators of written language (this Latin script you're reading is actually descended from their script, via Greek script). Judahites, on the other hand, were a bit more backwoods, and didn't produce much writing until later. We know their chief god was Yahweh or Yehueh (whence their own name for themselves, Yahudi, and the later ethnonyms Judaean and Jew). Archaeological evidence also suggests that many worshiped Asherah as Yahweh's consort. But this is all by a fairly late time. It's tempting to draw an earlier connection to the Canaanite deity Yaw, or the Hebrew verb meaning "to be", or the Babylonian god Ea (better known as Enki), but we simply don't know. (Then there are the theories linking early Judahites to exiled Egyptian practitioners of Atenism, often cited as the first monotheistic religion, but that's another can of worms.)
Sumerian/Akkadian lamassu, the general sort of creature Yahweh would have employed. From the British Museum.
In English translations of the Tanakh (the Old Testament), the chief deity is variously referred to as God or LORD or the LORD of Hosts or God Almighty or the LORD God. This reflects several names in Hebrew. God generally refers to 'Elohim (a plural!) or, more rarely, 'El. LORD always refers to Yahweh. God Almighty is the honorific term 'El Shaddai., and the LORD of Hosts is the honorific Yahweh Tsaba'ot. Thus, parts of the Old Testament with the word God are of Canaanite (i.e., Israelite) origin, while parts with the word LORD are of Judahite origin. The awkward combination LORD God reflects a later redaction of originally Judahite sources, a latter-day attempt to secure the synonymy of the two cultures' gods. They hadn't invented parenthetical markers (or, indeed, any punctuation) when these texts were written, but if they had, they might have written it as Yahweh ('Elohim) instead. 'Elohim, by the way, sometimes is translated correctly as a plural (gods), wherever it is obviously referring to multiple entities.
Depiction of a singular 'Elohim creating 'Adam, by William Blake.
In the Tanakh, particularly in the Judahite texts, you can see that the modern Christian God comes from a rather different source. Unlike God, Yahweh is fallible. He regrets his past actions (as in the various versions of the Noachian saga). He can be brought to change his mind (as in the various versions of the Mosaic saga). He has a temper, and it often erupts in genocidal demands. He demands fealty, even unto the killing of firstborn sons (in the pre-edited tale of Isaac). The Israelites and Judahites worship him not because he is perfect, but because he is strong, and will smite their enemies if they cleave to his demands. The differences between Jupiter and Yahweh begin to dissipate.
There is still the matter of sexual voracity, though. Although Asherah was worshiped as Yahweh's consort by the people, the priests tended to revile this worship, and hence no mention is ever made of any sexual proclivites in the Tanakh. There is a passage where the sons of the 'Elohim mate with human women, producing the heroes of old (shades of Hercules!), but that's about as close as it gets. In terms of character, Jupiter and Yahweh are not dissimilar, but Jupiter is more of a lover and Yahweh is more of a fighter. (How odd then, that it was the Greeks and Romans who conquered the Judaeans, not vice versa. But I digress.)
Jupiter gets some attention from Thetis, by Jean Ingres.
So, like many cultures, ancient Semites and ancient Indo-Europeans revered mighty, patriarchal chief gods. These chief gods lead pantheons of lesser gods. They sometimes made mistakes. And, while often generous to their followers, on occasion their behavior can be described in no other way than evil. (Indeed, some early Christian sects believed Yahweh to be an evil deity, inferior to the beneficent 'Elohim.) In essence, these gods were big, powerful men, not the ethereal, cerebral force that 'Elohim and later Deus Pater became. As the civilizations evolved, so did the gods.
By now it should be clear that tracing these divine genealogies can get pretty complicated. My attempts to synthesize a nice, clear chart have so far failed. But I'll keep at it.
One of my "someday I'd like to do this" projects is a design (suitable for shirts, posters, etc.) showing the genealogy of the major Christian gods. Yes, gods. Monotheism, my butt. You got Deus Pater, Yesous Christos, Yahweh, 'El Shaddai, the 'Elohim, and the Holy Spirit, not to mention rival factions (many of which were allies, early on) like the Şaţan (originally Yahweh's attorney, later coöpted into a Pan-like rival), Be'el Zebub, Asherah, etc. (Sure, the rivals aren't usually termed "gods", but they're considered supernaturally powerful people, and what is a "god", if not that?)
The major problem I've run into is that there are two kinds of genealogy when it comes to gods. One might be termed familial genealogy: Zeus and Hera are the parents of Ares, Odin is the father of Thor, etc. This is "genealogy" in the same sense as it's used for actual people.
Bust of Zeus from the British Museum.The other might be termed cultural genealogy. This follows etymology fairly closely. As an example, Jupiter, the name of the chief god of the ancient Romans, is a contraction from something like Iou Pater, meaning "Jove the Father". The name Iou/Jove, in turn, descends from *Dyeus, the reconstructed name of the patriarchal sky god of the early Indo-Europeans. (The asterisk before the name indicates that it is reconstructed, not known from documents.) This name and its associated god were also inherited by other Indo-European cultures: *Tiwaz of the ancient Germanians (whence "Tuesday"), Zeus of the ancient Greeks, Dyauş Pitār of the ancient Indians, etc.
Týr, an Icelandic variant of *Tiwaz.Something interesting happened in some cases: the name was inherited, but a new meaning was inquired. Greek theos, Latin deus, and Anglo-French divin refer not to particular gods, but to the general concept of a supernaturally powerful person. English, that great borrower of vocabulary, has a number of generic words ultimately derived from *Dyeus via various paths (mostly through Anglo-French): deity, diva, and divine from Latin, and theist and theologian from Greek. My own first name, Timothy (from Greek Timotheos) means "god-honorer", but the last syllable is ultimately traceable to *Dyeus. (And, yes, it's ironic that I turned out to be an atheist, especially given that my middle name means ... well, more on that in a bit.)
The ancestry of our own generic word, god, is a bit murky. All of the Germanic languages have some form like god or Gott or guth, but none of the other Indo-European languages have such a word (with the possible exception of Farsi khoda). Perhaps its origins are from some obliterated "Old European" language. But a possibly more likely explanation is descent from the proto-Indo-European root *gheu-, meaning "to invoke", "to pour", or "to offer sacrifice". If so, it may not descend from any god's proper name.
But with the advent of Christianity in Europe, god underwent the exact opposite transformation that *Dyeus had undergone. It diversified, going from being a general term to becoming the proper name of a deity: God, the patriarchal deity of modern Christianity. This usage was, of course, inspired by the usage of the generic Latin word deus to signify the supreme deity. Indeed, from a purely etymological standpoint, Jupiter and Deus Pater ("God the Father") are the same thing!
Clearly, though, Roman Catholic priests are referring to something different from the chief Olympian god when they invoke Deus Pater. These supernatural figures have many things in common: power, masculinity, an association with the sky, etc. But they are different in other respects. Jupiter leads a pantheon of other gods, many of them his relatives. Deus Pater acknowledges no other gods, and his court is run by lesser beings (angels, kerubim, serafim, etc.) which bear no familial relation to him. Jupiter consorts with humans, even mating with them (lots of them). Deus Pater is asexual. Jupiter can be tricked, incited, enraged. Deus Pater is clear-headed, omniscient, and without fault.
But a look into Deus Pater's conceptual ancestry shows that those differences are fairly recent inventions. The Christian idea of a single god was, of course, taken from the Judaism. The Judaeans worshiped a single god, Yahweh, with many of the same attributes as the Christian god: wisdom, power, asexuality, etc. Early Christian sects were divided on how to interpret the single god (or, indeed, if it should be single), but the view that won out was sort of a beefed-up version of Yahweh (also known as Jehovah, thanks to an interesting clerical misunderstanding that I may go into another time—or you could just look it up).
So where did Yahweh come from? By the time of the early Christians, he was actually already an amalgam of earlier deities. The amalgamation process began during the Assyrian Empire. When the Assyrians conquered the coastal land of Canaan, they forced many of the Canaanites into exile. A good number headed into the wild highlands occupied by the Judahites, where they were safely out of reach. These Canaanites became known as the Israelites, or Yishra'eli, the "people of 'El", 'El being the name of their chief, patriarchal god (whence my middle name Michael, "next to 'El"). The Judahites, or Yahudi, by contrast, worshiped Yahweh. Since the Yahudi and the Yishra'eli spoke similar West Semitic dialects, their cultures merged, eventually becoming synonymous. As the cultures merged, the gods merged, too.
The Canaanite religion is well-attested from an early (i.e., pre-Biblical) time. The chief god was 'Il or 'El, and he had many sons called the 'Ilohim or 'Elohim. Chief among these were Haddu/Hadad (also considered the son of Dagon, and frequently referred to with the honorific Ba`al, meaning "lord"), the god of the sky; Yamm (later dubbed Yaw), the god of the waters; and Mot, the god of death (his name also literally meaning "Death"). 'El's consort was 'Athtart/Astarte/Asherah. This is all necessarily simplified, since various ancient Middle Eastern traditions related these gods to each other a bit differently.
'El and various beasts adorn the Gebel-el-Arak knife hilt.The origins of the Judahite religion are not as well known. Canaanites were early innovators of written language (this Latin script you're reading is actually descended from their script, via Greek script). Judahites, on the other hand, were a bit more backwoods, and didn't produce much writing until later. We know their chief god was Yahweh or Yehueh (whence their own name for themselves, Yahudi, and the later ethnonyms Judaean and Jew). Archaeological evidence also suggests that many worshiped Asherah as Yahweh's consort. But this is all by a fairly late time. It's tempting to draw an earlier connection to the Canaanite deity Yaw, or the Hebrew verb meaning "to be", or the Babylonian god Ea (better known as Enki), but we simply don't know. (Then there are the theories linking early Judahites to exiled Egyptian practitioners of Atenism, often cited as the first monotheistic religion, but that's another can of worms.)
Sumerian/Akkadian lamassu, the general sort of creature Yahweh would have employed. From the British Museum.In English translations of the Tanakh (the Old Testament), the chief deity is variously referred to as God or LORD or the LORD of Hosts or God Almighty or the LORD God. This reflects several names in Hebrew. God generally refers to 'Elohim (a plural!) or, more rarely, 'El. LORD always refers to Yahweh. God Almighty is the honorific term 'El Shaddai., and the LORD of Hosts is the honorific Yahweh Tsaba'ot. Thus, parts of the Old Testament with the word God are of Canaanite (i.e., Israelite) origin, while parts with the word LORD are of Judahite origin. The awkward combination LORD God reflects a later redaction of originally Judahite sources, a latter-day attempt to secure the synonymy of the two cultures' gods. They hadn't invented parenthetical markers (or, indeed, any punctuation) when these texts were written, but if they had, they might have written it as Yahweh ('Elohim) instead. 'Elohim, by the way, sometimes is translated correctly as a plural (gods), wherever it is obviously referring to multiple entities.
Depiction of a singular 'Elohim creating 'Adam, by William Blake.In the Tanakh, particularly in the Judahite texts, you can see that the modern Christian God comes from a rather different source. Unlike God, Yahweh is fallible. He regrets his past actions (as in the various versions of the Noachian saga). He can be brought to change his mind (as in the various versions of the Mosaic saga). He has a temper, and it often erupts in genocidal demands. He demands fealty, even unto the killing of firstborn sons (in the pre-edited tale of Isaac). The Israelites and Judahites worship him not because he is perfect, but because he is strong, and will smite their enemies if they cleave to his demands. The differences between Jupiter and Yahweh begin to dissipate.
There is still the matter of sexual voracity, though. Although Asherah was worshiped as Yahweh's consort by the people, the priests tended to revile this worship, and hence no mention is ever made of any sexual proclivites in the Tanakh. There is a passage where the sons of the 'Elohim mate with human women, producing the heroes of old (shades of Hercules!), but that's about as close as it gets. In terms of character, Jupiter and Yahweh are not dissimilar, but Jupiter is more of a lover and Yahweh is more of a fighter. (How odd then, that it was the Greeks and Romans who conquered the Judaeans, not vice versa. But I digress.)
Jupiter gets some attention from Thetis, by Jean Ingres.So, like many cultures, ancient Semites and ancient Indo-Europeans revered mighty, patriarchal chief gods. These chief gods lead pantheons of lesser gods. They sometimes made mistakes. And, while often generous to their followers, on occasion their behavior can be described in no other way than evil. (Indeed, some early Christian sects believed Yahweh to be an evil deity, inferior to the beneficent 'Elohim.) In essence, these gods were big, powerful men, not the ethereal, cerebral force that 'Elohim and later Deus Pater became. As the civilizations evolved, so did the gods.
By now it should be clear that tracing these divine genealogies can get pretty complicated. My attempts to synthesize a nice, clear chart have so far failed. But I'll keep at it.
07 November 2007
Minor "March of Man" Update
I've just launched the update mentioned in my last post. The only major change (apart from all those behind-the-scenes refactorings) is a new Image Gallery section, where one can peruse all submitted images, from most to least recent. (Somewhat less interestingly, I also added a process for resetting your password should you forget it.)
Threatening Paranthropus robustus.
Check out The March of Man.
Threatening Paranthropus robustus.Check out The March of Man.
06 November 2007
The Wonderful Process of Refactoring
In many ways, programming is as much an art as a science. Good code is like good writing: crisp, clear, streamlined, and well-structured. But it's not always possible to foresee the best structure. When working on a project, you just do what seems best at the time. Eventually you'll finish it and work out the bugs, but the underlying code may not be elegant. There may be duplicated code, unclear functionality, unoptimized sections, and sections that do too much with sections that do too little. When you come back to the code to add or refine features, you often face a major headache.
This is why many developers use a general process called refactoring. Refactoring means that you change the design of the code without changing the functionality. An analogy would be rewriting a news article so that it reads better without changing what the article is actually about.
Ensuring that the functionality remains the same is not always easy. It involves frequent testing and retesting. Changing one section might affect another section, so the retesting has to be thorough. Testing a particular section during development is called unit testing.
Sometimes it's worth the extra time to create a program that actually does the testing for you. During heavy refactoring, this can save oodles of time. If you make changes, then you can just run a test that takes a few seconds, quickly showing whether you broke anything (and generally showing exactly what you broke).
I went through this process recently while working on March of Man.
Typically a rich Internet application (RIA) has three tiers. The client-side application is something you view in a browser (for example, this website). The database is an application on the server that stores data. The server-side application facilitates communication between the database (and potentially other server-side information) and the client-side. To sum up:
In case you were curious, for March of Man, the client-side application is an interactive Flash movie made with Flex Builder, the server-side application uses Java running on JBoss, and the database is PostgreSQL.
All this communication between tiers can get a bit complicated. Fortunately, Adobe provides an excellent tool called LiveCycle Data Services (LCDS) for communicating between the client- and server-side applications. What exactly does it do? Well, March of Man deals with certain types of data: user accounts, images, hominin taxa, location/time ranges, etc. In programming, these types are referred to as classes, and classes are instantiated (i.e., realized) as objects. Specifically, these ones would be considered value objects. So, for example, there is a class called Account that specifies certain types of data, like email address, personal name, password, etc. An instance of Account (i.e., an Account object) might represent a particular person. For the client-side, the Account class is written in ActionScript. For the server-side, it's written in Java. What LiveCycle does is take care of all of the translation: when I send an ActionScript Account object to the server, it is automatically recreated as a Java Account object, and vice versa when the server reports to the client.
As an example, when you log in, the client collects your email address and password, and sends them (encrypted) to the server, specifying a login method. That method looks up the information for the specified account, packages it as an Account object, and sends it back to the client. Voilà, you are logged in.
Unfortunately, there isn't a similarly easy tool for translating from the server-side application to the database, where data is stored in tables as rows and columns. The only way to interface is using SQL, a common language used for database queries. Java provides some ways to facilitate this (the java.sql package of classes), but it can't do everything.
So I created a package of classes called org.marchofman.mappers to map the information from Java to PostgreSQL and back. Each mapper class corresponds to a type of value object, e.g. AccountMapper handles Account objects, ImageMapper handles Image objects, etc. They all have certain functionality in common, such as what are called the "CRUD" commands: create, retrieve, update, and delete. When you register, the Java service uses the AccountMapper.create method. When you log in, it uses AccountMapper.retrieve. When you change your information, it uses AccountMapper.update. And, should you ever decide you don't want an account any more (heavens forfend), it would use AccountMapper.delete.
For the initial version of the site (still up as of this writing, but soon to be upgraded), the "mapper" classes did their job. But all was not well under the hood. Since there were many different ways to select data, I sometimes had to make multiple mapper classes for the same type of value object. For example, a user might want to pull up information on a particular image, on their own images, on the images corresponding to a particular taxon, or just on all images. Each of these required a completely different method, and I had to struggle to keep the levels of duplicated code down. Duplicated code might sound like a minor annoyance, but it can have serious effects. It really complicates both testing and updating code.
Eventually I realized that the mapper classes should not be concerned with how to decide which objects to handle, only with how to handle them once they were specified. I created a new type of object, called a Qualifier, to store information on how to specify certain objects. As an example, a TotalQualifier object specifies all value objects of a given type. A FieldQualifier object specifies all value objects with a certain piece of data, for example, all accounts with a given email address. A KeyQualifier specifies one particular object by a unique identifier. And a ConjunctionQualifier qroups other qualifiers and selects only those objects which satisfy all of those qualifiers.
Formerly I had to write methods like retrieveForOwner, retrieveAll, retrieve, retrieveForTaxon, retrieveForLogin, etc. With the new structure, I could just have one method, retrieve, and pass it any kind of Qualifier object I wanted. The number of classes in the org.marchofman.mappers package shrunk down to a fraction of what it had been. Now it was down to the ideal: one mapper class for each type of value object.
Doing all this was a fair bit of work. Fortunately, I had already built automated unit tests using the excellent flexunit framework. Once I finished my initial refactoring work, I just ran the tests and could instantly see what I still needed to fix.
Now not only do I have a more streamlined and flexible server-side architecture, but also some generalized mapping classes which may greatly facilitate work on future projects. Is the code perfect? No, but it's much better than it was. And I can always refactor again if I need to....
This is why many developers use a general process called refactoring. Refactoring means that you change the design of the code without changing the functionality. An analogy would be rewriting a news article so that it reads better without changing what the article is actually about.
Ensuring that the functionality remains the same is not always easy. It involves frequent testing and retesting. Changing one section might affect another section, so the retesting has to be thorough. Testing a particular section during development is called unit testing.
Sometimes it's worth the extra time to create a program that actually does the testing for you. During heavy refactoring, this can save oodles of time. If you make changes, then you can just run a test that takes a few seconds, quickly showing whether you broke anything (and generally showing exactly what you broke).
I went through this process recently while working on March of Man.
The Setup
Typically a rich Internet application (RIA) has three tiers. The client-side application is something you view in a browser (for example, this website). The database is an application on the server that stores data. The server-side application facilitates communication between the database (and potentially other server-side information) and the client-side. To sum up:
user ↔ client-side app ↔ server-side app ↔ database
In case you were curious, for March of Man, the client-side application is an interactive Flash movie made with Flex Builder, the server-side application uses Java running on JBoss, and the database is PostgreSQL.
All this communication between tiers can get a bit complicated. Fortunately, Adobe provides an excellent tool called LiveCycle Data Services (LCDS) for communicating between the client- and server-side applications. What exactly does it do? Well, March of Man deals with certain types of data: user accounts, images, hominin taxa, location/time ranges, etc. In programming, these types are referred to as classes, and classes are instantiated (i.e., realized) as objects. Specifically, these ones would be considered value objects. So, for example, there is a class called Account that specifies certain types of data, like email address, personal name, password, etc. An instance of Account (i.e., an Account object) might represent a particular person. For the client-side, the Account class is written in ActionScript. For the server-side, it's written in Java. What LiveCycle does is take care of all of the translation: when I send an ActionScript Account object to the server, it is automatically recreated as a Java Account object, and vice versa when the server reports to the client.
As an example, when you log in, the client collects your email address and password, and sends them (encrypted) to the server, specifying a login method. That method looks up the information for the specified account, packages it as an Account object, and sends it back to the client. Voilà, you are logged in.
Unfortunately, there isn't a similarly easy tool for translating from the server-side application to the database, where data is stored in tables as rows and columns. The only way to interface is using SQL, a common language used for database queries. Java provides some ways to facilitate this (the java.sql package of classes), but it can't do everything.
So I created a package of classes called org.marchofman.mappers to map the information from Java to PostgreSQL and back. Each mapper class corresponds to a type of value object, e.g. AccountMapper handles Account objects, ImageMapper handles Image objects, etc. They all have certain functionality in common, such as what are called the "CRUD" commands: create, retrieve, update, and delete. When you register, the Java service uses the AccountMapper.create method. When you log in, it uses AccountMapper.retrieve. When you change your information, it uses AccountMapper.update. And, should you ever decide you don't want an account any more (heavens forfend), it would use AccountMapper.delete.
The Problem
For the initial version of the site (still up as of this writing, but soon to be upgraded), the "mapper" classes did their job. But all was not well under the hood. Since there were many different ways to select data, I sometimes had to make multiple mapper classes for the same type of value object. For example, a user might want to pull up information on a particular image, on their own images, on the images corresponding to a particular taxon, or just on all images. Each of these required a completely different method, and I had to struggle to keep the levels of duplicated code down. Duplicated code might sound like a minor annoyance, but it can have serious effects. It really complicates both testing and updating code.
Eventually I realized that the mapper classes should not be concerned with how to decide which objects to handle, only with how to handle them once they were specified. I created a new type of object, called a Qualifier, to store information on how to specify certain objects. As an example, a TotalQualifier object specifies all value objects of a given type. A FieldQualifier object specifies all value objects with a certain piece of data, for example, all accounts with a given email address. A KeyQualifier specifies one particular object by a unique identifier. And a ConjunctionQualifier qroups other qualifiers and selects only those objects which satisfy all of those qualifiers.
Formerly I had to write methods like retrieveForOwner, retrieveAll, retrieve, retrieveForTaxon, retrieveForLogin, etc. With the new structure, I could just have one method, retrieve, and pass it any kind of Qualifier object I wanted. The number of classes in the org.marchofman.mappers package shrunk down to a fraction of what it had been. Now it was down to the ideal: one mapper class for each type of value object.
Doing all this was a fair bit of work. Fortunately, I had already built automated unit tests using the excellent flexunit framework. Once I finished my initial refactoring work, I just ran the tests and could instantly see what I still needed to fix.
The Payoff
Now not only do I have a more streamlined and flexible server-side architecture, but also some generalized mapping classes which may greatly facilitate work on future projects. Is the code perfect? No, but it's much better than it was. And I can always refactor again if I need to....
05 November 2007
A Collaborative Paleo-Art Project
I recently launched a new website, March of Man.
The goal is to create a gigantic collage that illustrates human (and chimpanzee) evolution through time and space. Paleo-artists can register and upload images of hominin* figures. Once enough are collected, I'll provide tools for synthesizing large collages. More specific details can be found at the website.
The site's in an "alpha" stage right now, so there may be some quirks. Readers, please let me know if you come across anything.
Soon I'll be making some updates, including a browseable gallery.
Running Praeanthropus afarensis
* What's a hominin? You're a hominin! Well, specifically, Hominini is the "tribe" that includes our species, and is sometimes used to refer to the smallest clade containing us and chimpanzees (excluding gorillas, orangutans, etc.).
The goal is to create a gigantic collage that illustrates human (and chimpanzee) evolution through time and space. Paleo-artists can register and upload images of hominin* figures. Once enough are collected, I'll provide tools for synthesizing large collages. More specific details can be found at the website.
The site's in an "alpha" stage right now, so there may be some quirks. Readers, please let me know if you come across anything.
Soon I'll be making some updates, including a browseable gallery.
Running Praeanthropus afarensis* What's a hominin? You're a hominin! Well, specifically, Hominini is the "tribe" that includes our species, and is sometimes used to refer to the smallest clade containing us and chimpanzees (excluding gorillas, orangutans, etc.).
My First Paper
The inauguration of this blog was just barely in time for me to report my first paper as primary (and sole) author:
KEESEY, T. M. 2007. A mathematical approach to defining clade names, with potential applications to computer storage and processing. Zoologica Scripta 36 (6): 607–621. doi:10.1111/j.1463-6409.2007.00302.x
Here's the abstract, also available here:
What is a "clade"?
An ancestor and all of its descendants. As an example, mammals form a clade. Fish do not form a clade, since they exclude some descendants (tetrapods). Hoofed mammals ("ungulates") do not form a clade, since their common ancestors were not hoofed (instead, hooves have evolved several times among placental mammals).
What is "branch-based", again?
The PhyloCode is a set of rules being put together to deal with the naming of clades. It recommends certain forms of definition. The main ones (but certainly not the only ones), with examples, are:
(Actual definitions would use proper scientific names instead of "platypuses", "humans", etc. but you get the idea.)
This stands in contrast to the current taxonomic codes, which are rank-based. Definitions under rank-based codes look more like, "Homo is the genus that includes Homo sapiens." There is a very important difference between these two styles of definition. Rank-based definitions are based (at least partly) on subjective opinions, since the ranks (with the possible, but contentious, exception of species) do not have any objective meaning. We all probably learned about kingdoms, classes, orders, families, and genera in biology class, but these ranks don't have any intrinsic meaning. A family of birds might include a few closely related species, while a family of insects might include thousands, with more distant common ancestry.
Phylogenetic definitions, on the other hand, proceed directly from our knowledge of phylogeny. When two researchers disagree on the content of a rank-based taxon, they might be arguing about aesthetics, actual relationships, or both. When they disagree about the content of a phylogenetic taxon, they can only be arguing about actual relationships.
So, what did you do?
Since phylogenetic definitions are based directly on phylogeny, without need for opinions, this means they can be expressed in completely unambiguous language. This includes:
Well, la-ti-da. So what?
This means more of the taxonomic process can be automated. With rank-based definitions, there has to be an expert to "feel out" how expansive a genus, family, order, etc. should be. But with phylogenetic definitions, you can feed a computer application the phylogeny encoded in a popular file format (e.g., NEXUS) and taxonomic definitions encoded in a popular file format (MathML), and it can figure out the content referred to by a taxonomic name in fractions of a second.
Okay, so where's the application?
I'm still working on one, called Names on NEXUS. So far it's going well; I just need to refactor and complete the server-side application and touch up the client-side application. Should have some time for that next year.
KEESEY, T. M. 2007. A mathematical approach to defining clade names, with potential applications to computer storage and processing. Zoologica Scripta 36 (6): 607–621. doi:10.1111/j.1463-6409.2007.00302.x
Here's the abstract, also available here:
Clade names may be objectively defined based on conditions of phylogeny. Definitions usually take one of three forms — node-, branch- or apomorphy-based — but other forms and complex permutations of these forms are also possible. Some database projects have attempted to store definitions of clade names in a manner accessible to computer applications, but, so far, they have only provided ways of storing the most common types of definition. To create a more extensible system, I have taken a mathematical approach to defining clade names. To render definitions accessible to computer storage and analysis, I propose using Mathematical Markup Language (MATHML) with extensions. Since the mathematical approach is granular to the level of the organism, not to fuzzy higher levels such as population or species, it sheds light on some theoretical difficulties with defining clade names. For example, some definitions do not resolve to a single organism as the ancestor, but to sets of organisms which are not ancestral to each other and share common descendants. I term such sets ‘cladogenetic sets’.If you made it through that, congratulations. Now you may have some questions.
What is a "clade"?
An ancestor and all of its descendants. As an example, mammals form a clade. Fish do not form a clade, since they exclude some descendants (tetrapods). Hoofed mammals ("ungulates") do not form a clade, since their common ancestors were not hoofed (instead, hooves have evolved several times among placental mammals).
What is "branch-based", again?
The PhyloCode is a set of rules being put together to deal with the naming of clades. It recommends certain forms of definition. The main ones (but certainly not the only ones), with examples, are:
- node-based. "Mammalia is the final common ancestor of platypuses and humans, and all descendants of that ancestor."
- branch-based. "Synapsida is the initial ancestor of humans which is not also ancestral to sand lizards, and all descendants of that ancestor." (The image below represents two branch-based clades, one in red and one in yellow. White dots represent organisms in both clades.)
- apomorphy-based. "Avialae is the first ancestor of Andean condors to possess powered flight homologous with that in Andean condors, and all descendants of that ancestor."
(Actual definitions would use proper scientific names instead of "platypuses", "humans", etc. but you get the idea.)
This stands in contrast to the current taxonomic codes, which are rank-based. Definitions under rank-based codes look more like, "Homo is the genus that includes Homo sapiens." There is a very important difference between these two styles of definition. Rank-based definitions are based (at least partly) on subjective opinions, since the ranks (with the possible, but contentious, exception of species) do not have any objective meaning. We all probably learned about kingdoms, classes, orders, families, and genera in biology class, but these ranks don't have any intrinsic meaning. A family of birds might include a few closely related species, while a family of insects might include thousands, with more distant common ancestry.
Phylogenetic definitions, on the other hand, proceed directly from our knowledge of phylogeny. When two researchers disagree on the content of a rank-based taxon, they might be arguing about aesthetics, actual relationships, or both. When they disagree about the content of a phylogenetic taxon, they can only be arguing about actual relationships.
So, what did you do?
Since phylogenetic definitions are based directly on phylogeny, without need for opinions, this means they can be expressed in completely unambiguous language. This includes:
- Mathematical formulas.
- Computer languages.
Well, la-ti-da. So what?
This means more of the taxonomic process can be automated. With rank-based definitions, there has to be an expert to "feel out" how expansive a genus, family, order, etc. should be. But with phylogenetic definitions, you can feed a computer application the phylogeny encoded in a popular file format (e.g., NEXUS) and taxonomic definitions encoded in a popular file format (MathML), and it can figure out the content referred to by a taxonomic name in fractions of a second.
Okay, so where's the application?
I'm still working on one, called Names on NEXUS. So far it's going well; I just need to refactor and complete the server-side application and touch up the client-side application. Should have some time for that next year.
Subscribe to:
Posts (Atom)