A half-dozen ways to die (in myth)

Written by Greta Hawes

Collecting large piles of data is one thing. Making it comprehensible is another.

Now that we’ve extracted what we need from four big texts (Apollodoros, Pausanias, the Iliad, the Theogony) and a scattering of smaller ones, some of our entities are involved in a several hundred ties. You can’t exactly just run your eye over Heracles’ data to find what you need any more.

A small sample of Heracles’ raw data

One solution is to create what we’re calling ‘filecards’. The eclecticism of our ties means that displaying them as is would be too chaotic. But we can distill from them some basic information and display that systemaitically. So, for an object, we would want to know the fundamentals: who created it and where; who used it; what was it used to do; whether it still survived in the historical period. For an agent the fundamentals are a bit more extensive: where were they born; how were they born; who were their parents; who were their offspring; did they play particular roles; did they join in particular adventures; who did they kill; what did they create; where did they die; where were they buried; and who buried them.

Filecard for Penelope

Filecard for the Scepter of Agamemnon

Behind these filecards lie some 130 potential categories (‘created by’, ‘survives as a relic at’…) which are triggered and populated by various reversals. Reversals are essentially instructions about how to cut and slice our raw data. Some are pretty straightforward:

IF there is a tie where ‘ENTITY1 creates ENTITY2’ and ENTITY2 is an object or landmark,

THEN on the filecard ‘ENTITY2’ populate ‘created by’ with ENTITY1 and on the filecard ‘ENTITY1’ populate ‘creates’ with ENTITY2.

 Others … are less straightforwad:

IF there is an ENTITY1 called ‘the Bones of ENTITY2’ and a tie ‘ENTITY2 is relic in ENTITY3’ or a tie ‘ENTITY4 buries ENTITY1 in ENTITY3’, and ENTITY3 is a place within ENTITY5,

THEN on the filecards ENTITY1 and ENTITY2 populate ‘buried in’ with ENTITY3 and on the filecards for ENTITY3 and ENTITY5 populate ‘burial place of’ with ENTITY2

The filecards allow us to present a quickly-scannable version of our data without giving up the richness that Greek myth demands, and the nuances in the data that will be useful in other contexts. So, for example, a fundamental category for agents is the place of death. But when we are collecting data, we very rarely simply record that a hero dies in a certain place; mythic deaths tend to be memorable, and we want to capture something about how the death occurred, So, the ties that might trigger the reversal ‘dies at’ on a filecard include:

ENTITY dies in ENTITY

ENTITY dies by suicide in ENTITY

ENTITY kills ENTITY in ENTITY using ENTITY

ENTITY makes sacrifice of ENTITY to ENTITY in ENTITY using ENTITY

We can of course extract more basic data from these. There’s also a category ‘killed by’, which is populated by the ties ‘kills’ and ‘makes sacrifice’. And we can potentially create categories of kinds of death (e.g. by suicide, as a human sacrifice, at the hands of a close family member, at Troy, etc).

The biggest problem with dying (well, for MANTO at least) is easy to miss: many of our agents don’t die. After all, we’re dealing here with a storyworld in which mortality is just one alternative among several.

So we need categories to capture death-alternatives:

‘transforms into’ (Cainis metamorphoses into Caineus; Orion becomes a constellation; Heracles becomes immortal…)

‘disappears at’ (Capaneus disappears near Thebes)

‘resurrected by’ (Glaucos is resurrected by Polyidos)

And finally, we need to acknowledge that death is certainly not the end, so we have the category

‘has post-mortem existence at’

Without these filecards, understanding the data would be so much harder. My heartfelt thanks go out to two stellar ANU students, Glen Goodwin and Rosie Selth, who were instrumental in working out how we would actually implement them, and then uncomplainingly sat down with me for hours setting up and testing each reversal.

The whole process wasn’t absent some black humour. We actually managed to something that no previous users of Nodegoat had achieved: discover that there was a set limit on reversals within a project. (In the course of explaining to the developers why we needed this limit raised – and gently breaking the news that I still had big ambitions for more reversals – Geert exclaimed ‘how were you expecting to do this without Nodegoat?’ I hope at the time I gave him a mysterious, knowing half-smile; in fact an honest answer would have been ‘no idea, we were pretty ignorant when we started this and really we’re still just making it up as we go… ’ In all seriousness, if you need a fully-customizable data platform for the humanities, Nodegoat is it.)