A Choice of Routes

A Choice of Routes

By: Henry Hintermeister   

A lonely ship bobs up and down on the wine dark sea. It’s quiet. The only sound is the sail beaten by the breeze, and the crash of the waves as the wind whips spray across the half deck. The salt stings the eyes of the crew, but they continue to ply their oars back and forth, driving the prow forward. They keep their gaze on the horizon, fixated, waiting.

Odysseus stands amidships, and notices his knuckles clench around the haft of his spear. He looks down, in thought, and the furrows on his brow deepen. Rain begins to patter against the deck. He hardly notices. Now days away from Circe’s island, the Queen of Aeaea’s warnings reverberate in his skull.

“A choice of routes is yours. I cannot advise you

which to take, or lead you through it all‒

you must decide for yourself”


The lieutenants lean against the ship’s railing, looking ahead in anticipation, casting furtive looks back at their captain. They murmur in hushed voices. A knot ties itself in Odysseus’ stomach. Circe’s words refuse to leave him, her voice fills his ears.

“On one side beetling cliffs shoot up, and against them

pound the huge roaring breakers…

The Crashing Rocks they’re called by the blissful gods.

Not even birds can escape them, no, not even the doves…

No ship of men has ever approached and slipped past‒

always some disaster‒ big timbers and sailors’ corpses

whirled away by waves and lethal blasts of fire…”

(Od. 12.59-68)

The Crashing Rocks loom ahead, black against a grey sky. They spew smoke against the rain, and the splintering waves thrash against them with deafening sound. The ribs of ships’ hulls jut from the jagged cliffs, hopelessly dashed against the rocks in some other age. No easy way past them, no.

Odysseus strides to the prow and surveys the cliffs for the narrow strait between the two largest peaks, the only way through. He sees the passage, almost hidden by the ocean’s spray, and directs the helmsman towards it. The crew lets out a cheer, thinking themselves saved, but Odysseus’ heart sinks. He strains his eyes, searching, searching, for a little black speck atop the western peak.

“On the other side loom two enormous crags…

One thrusts into the vaulting sky its jagged peak…

And halfway up that cliffside stands a fog-bound cavern

gaping west towards Erebus, land of death and darkness‒

…Scylla lurks inside it‒ the yelping horror…

She’s a grizzly monster, I assure you.

No one could look on her with any joy.”

(Od. 12.75-88)

A small dot appears in the rock, barely visible, unless you were looking for it. They’re not far off now. The mast groans. Odysseus knows what lies ahead.

“…six long swaying necks, a hideous head on each,

Each head barbed with a triple row of fangs, thickset,

Packed tight‒ and armed to the hilt with black death!

…with each of her six heads she snatches up

a man from the dark-prowed craft and whisks him off”


The waves grow choppier, and the men brace themselves as the ship rises and falls over violent crests. The crags appear larger now, pillars of black rock. Odysseus grips the railing harder, and squints against the brine. There’s more than a monster in that straight, he knows. The whirlpool. Where is it?

“The other crag is lower‒ you will see Odysseus‒ though both lie side-by-side, an arrow-shot apart…

beneath it awesome Charybdis gulps the dark water down.

Three times a day she vomits it up, three times she gulps it down”

(Od. 12.101-106)

The ship climbs the top of a wave and there, for what is undoubtedly a second but seems an eternity, he sees it, the epicenter of this water’s violence, sending up froth from it’s depths. Breakers crashing, and smoke billowing. He shudders.

“A choice of routes is yours. I cannot advise you.”


The Runner’s eyes are open. His alarm clock reads two in the morning. He finally sits up in his bed, and runs his hands through his hair. He can’t sleep. He picks up his pen, and begins to write.

You know, before you run, you come to this place in the sea. It’s like this hand clutching at your throat. And you it feel in your chest, like a gnarled knot in the oak tree, near the roots. And you count your breath to try and slow your heart down, because you can see it beating through your shirt. And you make the hours stretch into days.

You know, really, you know, that the exertion you’re about to do isn’t really so bad. It takes a few seconds, a minute, a few minutes, less than a half hour. It’s a short lived kind of pain.

But your anxious mind can’t help but recall anyway. You remember when your veins filled with acid instead of blood. You remember when your lungs felt like they were bleeding, working overtime, drowning in oxygen. When your legs locked up, and it took all the strength of your arms just to throw yourself over the finish line. And you stood, with your hands on your knees, gasping and you let the sweat pour out of your skin like river deltas down your back.

These things have a way of resurfacing the night before you race– the agitations of an anxious memory.

It’s like this whirlpool that sucks you down so that you can’t think about anything else. Your mind fixates on the labors the body must do. It can’t help it.

What’s funny about the whirlpool is that, your battle doesn’t really lie there. You can’t fight it. You can’t wish it away. It just, exists. There’s not much you can do. It’s this frightening, deathless, distraction.

The Runner stares out his window. He gets out of bed, and opens a bottle of melatonin. He puts three tablets in his mouth, and swallows. He crawls back under the covers, and he falls into a light sleep.

The crags are almost on them. The oarsmen can see the whirlpool for themselves, now, sending up brine and fire.

The oars cease in their locks, and for a moment there is only the sound of the storm. Then, shouting, as the men leap from their benches. The helmsman abandons the rudder. Odysseus wheels around, angry, but is thrown off balance as Charybdis ceases her crashing and pulls the ship towards her. Her eye opens in her center, small at first, and then wider, wider, and pitch black. An empty nothing. Circe’s words are almost shrieks now:

“Don’t be there when the whirlpool swallows down‒

Not even the earthquake god could save you from disaster

No hug Scylla’s crag‒ sail on past her- top speed!

Better by far to lose six men and keep your ship

than lose your entire crew”


The Runner has his earphones in, stretching in lane 8, reaching for his lead leg. He keeps getting distracted, looking at the races on the track, watching middle distance burn the last hundred meters. He keeps looking at their wincing faces.

Second Call. He peels the back off his adhesive number, and sticks it to his hip. He turns his music up, shakes himself loose again, and leans further into his stretch.

Odysseus regains his balance and looks at his quavering crew. He pierces them with his eyes even as the ship begins to yaw.

“Friends, we’re hardly strangers at meeting danger and this danger is no worse than what we faced before. And even there my courage, my presence of mind and tactics saved us all, and we will live to remember this someday, I have no doubt. Up now, follow my orders. Lay on with the oars and strike the heaving swells, trusting that Zeus will pull us through these straits alive. You, helmsman, here’s your order‒ burn it in your mind‒ the steering-oar of our rolling ship is in your hands.”

(Od. 12.208-118)

The crew begins to gather itself.

The Runner is in lane 3, standing in front of his blocks. The others stand ahead of him in the stagger, in their own lanes. He starts to hop from one foot to another like a boxer, he lets his shoulders loosen. He centers his breathing into his diaphragm.

“Runners to your marks.” The referee raises his pistol. The Runner sets down into his blocks.

The crew plant themselves back on their benches. They start to pull in unison.

“Keep to that cliff” Odysseus shouts, pointing to the Western peak, “or the whirlpool will pull us down.” He’s made his decision. The helmsman scrambles back to the rudder, and points the ship away from Charybdis, and towards Scylla’s cave.


The Runner closes his eyes and opens them, inhaling deeply. He has a choice here. He knows exactly what a good race feels like. He can ease off a little. He doesn’t have to push himself to that point of breaking, so familiar. No one would know, except him.  

He remembers his own words, scrawled on paper the night before so that he might never forget.

The real battle the place where you might have some success, is the race itself. The only victory you can have is in passing through that agony you’re so afraid of. No runner yet can boast that they have reached the finish line without pain. You need only choose to confront it.

You can drown in Charybdis. You can drown in your fears. You can let your anxieties dictate your life. You can run from every heartbreak. Retreat from every failure. Tell yourself you’re never going out there again, because out there hurts.

But, pain is impermanent. Better by far to spend a minute intensely suffering than your whole life trying to dodge it.

Bang. The Runner bursts out of the blocks. He drives around the bend to the first hurdle, and launches over it. He rushes down the straight-away, smooth over the crossbars, a ship over cresting swells, and around the second bend, coming on what he knows is the most difficult part of the race.

And why not rid the world of pain? Pitch Scylla from the cliffs? Make the waters safer?

The oars cut through the waves speeding them faster and faster toward Scylla’s cave. Circe’s words come once more:

“Scylla’s no mortal, she’s an immortal devastation,

Terrible, savage, wild, no fighting her, no defense‒

Just flee the creature, that’s the only way.”


Scylla’s heads come snaking out of the cave atop the rocks. Odysseus grits his teeth.

The Runner enters the final hundred meters.

Pain, is an old goddess. A neurological construct that can’t be gotten rid of, or wished away. When you run you come to this place in the sea, and all you can do is endure Scylla’s six writhing heads. It’s the sacrifice you make to cross the finish line. It is hard. And it will always be there.

The Runner starts to falter. You can see him slowing down, dying. He can’t help it. His form becomes broken and frantic. He’s breathing hard. The others surge from behind. He can see them in his peripheral vision. He wants to give up. He wants to surrender. He grits his teeth.

But, you don’t have to bow to pain.

Contrary to the will of every neuron firing in his legs, against the advice of his aching arms, and in direct opposition to his lungs’ inability to take in any more oxygen, the Runner begins to pick his feet up faster, driving towards the finish.

Odysseus fastens his helmet, and grabs two long spears.

“So stubborn,” Circe says.

And then, she is silent


He knows none of these can kill Scylla, but as she lunges towards his crew he throws his spears at her, shouting. They careen off into the distance. Scylla snatches six sailors from the benches.

The ship emerges on the other side of the Crashing Rocks. The water calms as the clouds break and the sun reaches the deck for the first time in days. Odysseus takes off his helmet, kneels, and holds his head in his hands. The pull of Charybdis subsides.

The Runner crosses the finish line with the pitter patter of feet just behind. He’s panting, crouching with one hand on the track. He looks up, and he smiles faintly.

A choice of routes is yours.

Note: The excerpts of the Odyssey are taken from Robert Fagles’ translation:

Homer, Robert Fagles, and Bernard M. W. Knox. The Odyssey. N.p.: Penguin, 2002. Print.

Between Scylla and Charybdis by cea + is licensed under CC BY 2.0

Return to the introduction to Athlos: A Journey through Running

Or Check out the complete list of Athlos posts

Teach the Teachers Summer 2017

Teach the Teachers Workshop

Tufts University Boston MA August 14-16th, 2017

The Perseids Project in conjunction with  the Department of Classics at Tufts University is calling for participants in the second Teach the Teachers workshop.

This three-day workshop aims to explore the uses of digital tools in a classroom setting. Treebanking and Translation Alignments will be the main focus of the workshop, as well as different techniques for integrating them into classrooms at all levels.

As the field of classical studies continues to evolve, technology is playing a larger and larger and larger role both in the interpretation of data, but the in the education of a new generation of scholars. As people begin to use these tools to teach Greek and Latin, it is important that we come together and share our experiences, strategies, and ideas. Moreover, this workshop will offer educators who are unfamiliar with newer digital tools and their use in the classroom, to learn from fellow educators the best techniques for their implementation.

Treebanks are large collections of syntactically parsed sentences. Although originally designed to improve computational linguistic analysis, treebank annotations have proven to be valuable tools for pedagogy and traditional philological pursuits.  Treebanking projects have also proven to be valuable tools for students because they provide targeted assessment and feedback. In addition, treebanking allows students to contribute to a growing collection of ancient language treebanks.

The workshop will contain seminars on how to use the tools available via Perseids, in particular the Alpheios Alignment editor and the Arethusa Treebank editor. These seminars will include comprehensive guidelines so that any user at any level of digital literacy will be able to use the tools to their full potential. This will include:

  • Use of translation alignments for language and non-language students
  • Use of treebank annotations in the classroom, including Prof. Matthew Harrington’s treebanks of the AP Latin Curriculum
  • Use of the gold standard review functionality and the board review systems of Perseids
  • Basic self publication workflow for hosting your own treebank collection online.

The purpose of this workshop is to facilitate the exchange of new ideas for the implementation of the Perseids Platform in the classroom. We encourage you to experiment with our tools before attending the workshop, so that you can bring your own ideas about implementations in the classroom for discussion.

Participants should submit a statement of up to 500-700 words in length. Funding will be provided for travel and lodgings in the Boston area. Applications for attendance will be accepted until May 1st.

Statements should demonstrate that an applicant has a strong desire to work with new and experimental teaching techniques. No experience with digital methods is required, but those with experience will be supported at their own level. Although we work primarily with Greek or Latin teachers, we encourage educators who work with other ancient languages to apply. An ideal candidate needs to be willing to approach teaching these subjects in new ways and should be prepared to implement them in the classroom. Please include in your application whether you are seeking funding for travel and lodging.
Send submissions to teachtheteachers2016@gmail.com

Using Plokamos and Social Networks in the Classical Mythology Classroom

How can undergraduates contribute to research in a large lecture-hall mythology class? More importantly, how can such a class get beyond the rote memorization of stories and genealogies to engage with the primary documents and understand mythology in its own context?


The Perseids team has been experimenting with annotation to tackle these questions, because annotation is well known to produce deep engagement with a text in the form of close reading while promoting collaboration and conversation among students. However, one big pedagogical challenge is to design a workflow that is simple and lightweight so as not to get in the way of learning. On the technical side, the challenge is to produce good data that can then be preserved and aggregated easily.


Our first effort had students annotating Smith’s Dictionary of Greek and Roman Biography and Mythology with the Hypothes.is web annotation tools. The assignment was to collate the relationships among the figures in an entry of the Dictionary by annotating them using Hypothes.is. For instance, in the entry for Achilles, Thetis would be tagged as “MotherOf” and Peleus “FatherOf”. These tags used the SNAP ontology as a controlled vocabulary. The annotations were then harvested via the Hypothes.is API and serialized according to the OA model. In further passes, students documented attestations of relationships, i.e. which ancient text says that this relationship existed. They did so by inserting a Perseus URI in the annotation pointing to the specific passage attesting the relationship. Students also documented places associated with mythological figures using Pleiades URIs. Finally, students associated each mythological figure with the words that ancient texts used to describe them. These characterizations were produced following the “Word Study” exercise in the “Breaking the Language Barrier” series by Anna Krohn and Gregory Crane. Students looked up the Greek and Latin words used to describe a mythological figure and associated it with an English equivalent in the annotations using Perseus citation URIs.


At the end of this multi-part assignment, students had thoroughly researched their mythological figure. They learned who the figure was associated with, not just in strict genealogical terms, but also other associations such as EnemyOf, Companion, etc. They also gained an understanding of the geographical associations of the figure, since Greek mythology is heavily based on local legends. Finally, the students got a sense for the literary treatment of the figures by looking at the original texts.


However, after using this workflow with two different groups of students, we found that while the assignment was valuable, the limitations of the tools affected the data gathered. For instance, the lack of a visualization in real time led to issues with the directionality of the relationships, so a mother could be labeled as the son of her child. Also, our instructions to the students had become very complex as we expanded the assignment with characterizations and attestations.


In order to continue and improve this work, our team began development of the Plokamos application. Plokamos is Greek for “something woven” and it allows students to build a network graph as they annotate. The application also allows users to see their annotations as a table, and the data will soon be downloadable as a CSV and as RDF.


Plokamos has an intuitive and minimalist interface which cuts down on the time needed for annotation and the possibilities for user error. As a result, our instructions to the students became much shorter and simpler. Plokamos also has an attractive interactive visualization which helps to see the characterizations in the context of the network and make sense of the two together.


For instance, students working on Odysseus and Amymone noticed that both these figures, who appear on each side of a Classical pelike in the Boston Museum of Fine Arts, are connected to Poseidon and his offspring of aquatic monsters (fig. 1). These monsters are further connected to Odysseus because they are all eventually pitted against him and defeated. The characterizations strengthen these connections, as Odysseus is depicted with seafaring epithets, bravery, and sound thinking, while Poseidon is depicted with sea epithets and words indicating fertility and progeny. Finally, Amymone is associated with bodies of water such as springs and lakes, and with her descendants, the Danaids, who carry water eternally in Hades. In this way, Plokamos helped students to gain a better understanding of mythology at the conceptual level, and then apply this knowledge to a specific piece of ancient artwork.  


odysseusFig. 1 Social network of Odysseus and Amymone, by Christopher Duff and Patrick Margey

Announcing Plokamos, a Semantic Annotation Tool

Plokamos is a new text annotation framework developed by Frederik Baumgardt and the Perseids project. It is a browser-based tool that can be used to support scholars and students of literary disciplines in their work with text. Plokamos provides users with the ability to assign meaning to segments of text, to share their assertions with colleagues and classmates and to visualize the result of their work in aggregate. We have been using Plokamos as a plugin to our Nemo text browser in the classroom over the last 2-3 months and are looking forward to making it generally available to everyone for use on any source texts in early 2017.

Plokamos is really a continuation of our previous work in building a comprehensive toolset to enable our users to create and use semantically meaningful textual annotations. Our goal in this next step was to better integrate the individual components we used previously, to provide data validation assistance at annotation time, and to be in a better position to adapt our tools to new use cases. In the process we also wanted to make it easier for the users to enter data from a shared and controlled vocabulary. Furthermore, we aimed to add data versioning functionality to the infrastructure to follow students’ progress, to enable parallelism between text and annotations, and to provide this functionality as a tool for scholarly work. Finally, we planned for the application to be easily extensible to allow us to expand into more use cases over time as well as allow collaborators to tailor the annotations and the user interface to their own needs.

plokfig1 Figure 1: Plokamos tooltip embedded into a web article

In more technical terms, Plokamos is made up of an almost fully self-contained Javascript client application to be loaded inside a browser window, and a server-side linked-data named graph store with a SPARQL endpoint. In addition to annotation data, the quad store also serves configuration data that enables the client to validate, interpret and adequately visualize the annotations.

The Plokamos client consists of 3 layers which handle the annotations at different levels of abstraction and each layer provides its own mechanism to extend the application and use it for new kinds of sources, data types, forms of presentation or editing interfaces.

The annotator/applicator layer is the central piece of a Plokamos client application. It manages a local copy of the annotation data, adds interactive highlights to the source text and keeps a history of modified and newly created annotations. It has a core logic that is using SPARQL and the Open Annotation linked data framework to retrieve the available annotations and place them on their correct locations within the text. It can be extended to be able to handle different types of locations (“Selectors”) and different shapes of annotation payloads (“Annotation bodies”).

While the previous layer interprets annotations as just a network of entities and relations, and is agnostic to specific meaning (“Ontologies”) that is embedded in the network, the ontology layer is there to find and extract meaning from it. It can shape parts of the network into objects, translate URIs into easier to understand descriptions, and vice-versa. This is an essential step to negotiate between Plokamos’ general-purpose nature and its goal to provide user-friendly interactions. The ontology layer can be extended with new templates to extract objects from the graph and with additional dictionaries that provide translations between machine- and human-readable representations of the annotations.

The plugin layer takes the extracted objects and creates user interfaces for them which allow users to read and edit the data in different forms. Plugins can either let the ontology layer automatically select ontologies for the object conversion or specify them explicitly. The annotator/applicator layer provides placeholders for plugins to insert themselves into during Plokamos’ initialization, currently there are two such placeholders for annotations on phrases and whole documents, respectively. Inside the placeholders plugins can be designed freely using HTML and Javascript, including libraries such as Bootstrap and d3.js.


Figure 2: Visualization of corpus-level annotations filtered by family relationships

Over the course of the fall semester this architecture has proven itself to be useful and flexible for timely adaptations. We were able to develop new, unobtrusive and intuitive user interfaces for both the annotation reading and editing on single text passages as well as annotation visualization on a corpus. We also achieved our goal of improving the (syntactic) quality of the annotation data by providing the users with suggestions and visual feedback about the plausibility of the entered data. This last step benefited from the feedback that our students gave us while using the tool for their coursework and which we were able to quickly implement as additions to our plugins.

In 2017 we plan to focus on two particular features for Plokamos which we think will help make it a useful tool for many applications. The first one is a refactoring of the component in Plokamos that anchors annotations in their source data — the aforementioned Selectors — to enable higher-level annotations, i.e. annotating annotations. The obvious use case is for educators to grade and comment on their students annotations, but we’re sure that this will unlock further very interesting ways for scholars to express ideas. The second planned feature is the ability to run multiple instances of Plokamos on different regions of a website and let them interact to annotate relationships between segment of the regions. Those relationships can be for example assertions or translations, but again we’re convinced that this provides a foundation for new types of annotations that will emerge with time.

In addition to these features, we will round out the support for open, standards-based access to annotations created through Plokamos.  First, we will add full API support, through an implementation of the RDA Collections API. Second, we will work towards updating the annotation data model as needed to be in compliance with the latest version of the Open Annotation specification, the Web Annotation data model.

We’re excited to watch Plokamos play its part as both a platform for data entry as well as experimentation with new kinds of scholarly concepts, as the Digital Humanities continue to reshape scholarship in the digital era.

Grammatical Treebank Analysis for Teaching and Research Workshop in Toronto: Video Tutorials

In preparation for our Grammatical Treebank Analysis workshop, Vanessa and Bob Gorman have produced a series of videos introducing Arethusa and Treebanking. If you want to prepare for the workshop ahead of time and want some guidance to working with treebanks on your own, these videos are a great place to start.

To register for the workshop fill out the form here.

Preserving Digital Scholarship in Perseids: An Exploration

Fernando Rios, Data Management Services, The Sheridan Libraries, Johns Hopkins University
Bridget Almas, Perseids Project, Tufts University


Software is an important part of many kinds of scholarship. However, it is often an invisible part of the knowledge generation process. As a result, software’s lack of visibility within the scholarly record inhibits the understanding and future use of the scholarship which is dependent on it. One way to mitigate that outcome is to preserve not only the final result but also the actual platform, services and tools upon which it depends.

In order to guide preservation of these platforms and services, Data Management Services at Johns Hopkins University is exploring several aspects of software preservation, one of which is investigating how preservation needs can be determined for particular projects such as Perseids. The Perseids Project at Tufts University is a web-based platform that is being used to produce new forms of digital scholarship for the humanities. Consequently, examining how this scholarship might be preserved by preserving the underlying software is of practical importance.

One of the outputs of the Perseids Project has been a series of prototypes of new forms of data-driven publications and digital editions. The data for these online publication prototypes have been produced through the use of a variety of software tools and services that combine dynamically provided data through orchestrated calls to web services. The software tools and underlying services have gone through several iterations of development throughout the lifetime of the project and publications have been produced at different stages of that development. This scenario poses a series of interesting challenges for preservation of these digital publications, the underlying data, and the tools and services that are intrinsic to them.


This exploratory project had two objectives. The first was to give structure to thinking about how the data-driven publications and digital editions enabled by Perseids could be preserved. The primary concerns were what should be considered in determining how to adequately capture the collection of services and tools that comprise Perseids? Should the entire collection even be captured? The second objective was to develop and trial a set of questions, presented in the form of a questionnaire, that could be used to elicit information to help address the first objective.


The Perseids platform and the publications produced on it rely upon complex pieces of software with many moving parts. In order to begin addressing the question of how such a platform and its publications might be preserved, we had several informal discussions of what the major parts of Perseids were, along with general approaches to preservation and the associated challenges. We focused our investigation on a prototype digital publication that was developed on an early version of the platform and that used versions of the annotation tools and services from Perseids which have since been significantly updated or replaced since the prototype was first produced.

In order to understand how we might proceed with a potential software preservation activity, we decided it was important to answer three questions. First, we agreed it was important to have clarity on what the purpose of preservation is and who would benefit. Second, we determined that understanding what the pieces of the software are and how they are interdependent was critical. Third, we decided that being clear on what the costs versus benefits of preserving the Perseids software were, in relation to alternative approaches (e.g., website capture), was the most important question to address, from a practical perspective.

To structure the information, we used two questionnaires developed by Fernando for the purpose of providing consulting services for software archiving by the Data Management Services group at Johns Hopkins University. The first questionnaire asked very general questions in order to appraise the state of the software and gauge any potential gaps which may hinder its preservation and future reuse. Questions included asking the purpose of the Perseids project, its intended audience, the state of user- and developer-oriented documentation, general information about external software dependencies, and questions meant to gauge the general attitude with respect to software preservation and credit.  After Bridget completed the questionnaire, we decided to move forward with determining what might need to be done in order to preserve the scholarship that the target use case represents (i.e, the prototype digital publication) and how it might be carried out.

To do this, a second, more focused questionnaire was developed (by Fernando, using feedback given by Bridget on the first questionnaire) in order to get us thinking about the specifics of preservation, including most importantly, the why. The figure below shows the sequence in which different aspects of preservation were addressed. The questions are loosely grouped by what kind of information they capture: why, what, when, how long, who, and how.


Although the questionnaires are still undergoing refinement and are not (yet) publicly distributed, a brief description of the information captured by the questionnaire we used is shown in the table below.

Why Questions in this part revolved around really thinking about the true purpose of preserving software (e.g., enabling reproducibility, reuse, or continued access to scholarship) as well as the intended audience.
What This section attempted to help us think through two things. First, at what level of granularity  should the software be described and preserved in order to fulfil the preservation goal? This is important because different goals may require different levels of granularity in the description of the software. An example of a highly granular description is describing not only the software as a whole but also describing and documenting the individual pieces that comprise it as well as their interrelationships. Once an appropriate level of granularity was determined, a series of questions elicited information on those pieces.
When This section attempts to determine what an appropriate time to preserve software is. For normal grant-funded projects, this will likely be at the end of the project or at the time of publication.
How Long This part simply asks at least how long should the software be preserved. It is a simple question with a potentially difficult answer. Ideally, the answer is ‘a long time’ but the longer the time span, the more effort must be made to ensuring the software remains not only accessible but also usable. Therefore, it is important to come up with a number based on available resources.
Who This section is meant to determine who is responsible for not only the software but also who  bears responsibility for archiving it, making it citable, assigning unique identifiers etc. This section also is meant to help in identifying a suitable  archive where it may be stored.
How This section elicits what approach seems reasonable to preserve the software (e.g., by archiving the source code as-is, using virtualization or emulation technology, or by continued development). In addition, this section determines the kind of documentation that will be included and how it will be attached to the software (e.g., readme file, wiki, structured metadata). Although not part of the questionnaire, the Pathways of Research Software Preservation (Rios, 2016) gives an overview of how different parts of research software might be preserved and how different approaches are related.

Lessons Learned

We learned, first, the importance of sorting through the “why” and “what” to identify those pieces of software which warrant preservation activity and to define exactly what approach to take to preservation. Having the framework of the questionnaire to guide our thinking about those issues helped to focus what felt at the beginning like a daunting task.

Bridget entered into the discussions with Fernando with a pragmatic motivation: as development progresses on Perseids, having to support multiple earlier versions of services in order to support the prototype publications becomes increasingly unmanageable. We wanted to be able to retire the earlier service versions that these prototypes depend upon, but the cost versus benefit ratio for upgrading prototype code does not always allow for that. In considering the options for preserving a functioning version of a prototype, some of which themselves imply a fair amount of work (such as creating and preserving a Docker container image of all the supporting pieces), thinking about the the true purpose for preservation helped to put the problem in perspective and also to identify gaps in our planning and preservation capabilities.

While each of the suggested motivations from Fernando’s questionnaire could be considered to be an ideal to which to aspire in general, when held up against the specific software, they didn’t all make practical sense.  For example, while in theory, reproducibility of the exact display of the annotations and textual data from our target use case seemed desirable, we had to ask if that was essential for preserving and reproducing the scholarship.  The answer to that might have been yes if we had amassed large quantities of data for the use case, and expanded it beyond the initial prototype.  But as we have not yet been able to do that, and the tools and services in question have since evolved, the small dataset we have accumulated for our publication would be better reproduced and expanded via newer tools.  With this consideration in mind, it seems the remaining value of the prototype code would be as a demonstration of a methodology for annotation and a proposed service-based infrastructure to support that methodology.  The code itself is of less consequence than a documentation of the ideas and dependencies would be.

This problem is discussed in the context of scientific workflows in “Techniques for Preserving Scientific Software Executions: Preserve the Mess or Encourage Cleanliness?” (Thain, Ivie and Meng, 2015).  The authors found that preservation of distributed environments is still very much an open question and they suggest various approaches.  In our case, a Docker image would allow an end-user to see the prototype functioning as it did when published but would provide little insight into the methodology or infrastructure.  As we don’t intend to reproduce this environment exactly, we might consider just preserving the “working principle”, providing a description of the setup, using a controlled vocabulary.

It also became clear, in reviewing the questionnaire, that simply having code in GitHub or other open source versioning repository is not sufficient.  All code we write is available in the project’s GitHub repository. However, because of the complex history and dependencies of open source software development, what exists in the repository represents, in many cases, only the tip of the iceberg.  In addition, the GitHub repository, as it currently stands, doesn’t present a true picture of all the people who contributed intellectually to these efforts, because the code is just one piece of the puzzle.  As discussed in Matthew Turk’s excellent post, “The Royal ‘We’ in Scientific Software Development”, we need to do a much better job of recording and crediting this intellectual work. Further, we need to be cognizant of the need to to this as the work takes place. An ontology such as TaDiRAH would be worth considering here.

The “who” section of the questionnaire also raised some interesting questions.  Where does the responsibility for preservation lie, between the software developer and the scholar? Many of the use cases we work on in Perseids are not explicitly funded projects in and of themselves. Our approach has been to try to do as much as possible to serve as many real scholarly workflow needs as possible.  This has provided the opportunity for us to explore various questions around what humanities infrastructure needs to support, while hopefully still also providing real value to our users. At the same time, we have learned that without adequate planning for governance and sustainability, things can and do fall through the cracks.  Prototype code which we have developed, such as for the use case we examined here, does not always have a clear owner. For future projects of this nature, we need to take the time at the beginning to ask ourselves these questions about who will take ownership and responsibility for ensuring the preservation in order to eliminate this ambiguity.

Conclusions and Next Steps

Although data preservation and sharing has received much attention from funders, publishers, libraries and research communities in the past 10 years or so, methods, tools, and best practices for preserving and curating the software associated have not been as fully developed. The evaluation of the Perseids project served to contextualize some of the ideas and workflows around capturing information to enable the archiving of research software that are being developed in the Data Management Services group at Johns Hopkins University.  From the Perseids Project’s perspective, the iterative approach we took gave us a clearer idea of the unique requirements and challenges of preserving the scholarship embedded in this software.

We learned that while having an ideal to shoot for is good, the ideal isn’t always the best or most practical approach. We have, however, identified some concrete next steps we can take to move closer to where we would like to be with preservation of the platform components and outputs.

First, we will explore ontologies and approaches for describing the distributed infrastructure we have envisioned for our publications. We have started with an analysis of the Ontosoft Ontology, although at first glance, it does not seem possible to express with it all the layers of intent and dependencies in our environment. We also intend to explore the Linked Resource Model ontology developed by the Pericles-EU project for this purpose.

In order to preserve the end-user experience of our publications, we expect to use  Webrecorder.io service to create web archive snapshots of their current state.  This will allow us to preserve the visual representation of the scholarly output without a dependency upon the software behind it being available in perpetuity.

Finally, we hope to do a better job planning for the sustainability and stewardship of future undertakings on the platform from the outset, including identifying all participants and the nature of their contributions.

Teach the Teachers at Tufts University

Teach the Teachers Workshop

Tufts University Boston MA August 14-16th, 2017


The Perseids Project in conjunction with  the Department of Classics at Tufts University is calling for participants in the second Teach the Teachers workshop.

This three-day workshop aims to showcase the Perseids platform and explore the uses of these tools in a classroom setting. Registration for this workshop will be free and financial support for travel and lodging will be provided. We are looking for participants who teach at the High school or secondary school level, as well as Phd candidates and graduate students.

Treebanks are large collections of syntactically parsed sentences. Although originally designed to improve computational linguistic analysis, treebank annotations have proven to be valuable tools for pedagogy and traditional philological pursuits.  Treebanking projects have also proven to be valuable tools for students because they provide targeted assessment and feedback. In addition, treebanking allows students to contribute to a growing collection of ancient language treebanks.

The workshop will contain seminars on how to use the tools available via Perseids, in particular the Alpheios Alignment editor and the Arethusa Treebank editor. These seminars will include comprehensive guidelines so that any user at any level of digital literacy will be able to use the tools to their full potential. This will include:

The purpose of this workshop is to facilitate the exchange of new ideas for the implementation of the Perseids Platform in the classroom. We encourage you to experiment with our tools before attending the workshop, so that you can bring your own ideas about implementations in the classroom for discussion.

Participants should submit a statement of up to 500-700 words in length. Funding will be provided on an as-needed basis. Submissions will be accepted until December 16th.  

We have extended the deadline to March 17th.

Statements should demonstrate that an applicant has a strong desire to work with new and experimental teaching techniques. No experience with digital methods is required, but those with experience will be supported at their own level. Although we work primarily with Greek or Latin teachers, we encourage educators who work with other ancient languages to apply. An ideal candidate needs to be willing to approach teaching these subjects in new ways and should be prepared to implement them in the classroom.  
Send submissions in the form of a pdf to teachtheteachers2016@gmail.com

Grammatical Treebank Analysis for Teaching and Research Workshop in Toronto

A free two-day workshop sponsored by the Perseids Project
January 4-5th, 2017, 9AM-5PM

1 Harbour Square
Toronto, ON M5J 1A6

This two-day workshop aims to present some of the work currently being done in digital pedagogy for classical studies. As the field of classical studies continues to evolve, technology is playing an even larger role both in educating a new generation of scholars and in opening new approaches to data-driven humanities research.

The workshop will include hands-on seminars on how to use the tools available via Perseids, in particular the Alpheios Translation Alignment editor and the Arethusa Treebank editor. Treebanking (morpho-syntactic diagramming) allows a user to identify all the dependency relationships in a sentence as well as the morphology of each word. Translation alignments allow a user to identify corresponding words between an original text and its translation. With both methods, the resulting data is automatically compiled in an xml file which can be further queried for research.

Participants should plan on attending all sessions of the two day workshop, from 9AM-5PM on January 4th and 5th. Participation is open to college professors, high school teachers, and graduate students.Participants should bring laptop computers. Since we will be working in Latin and Greek, participants should have a basic knowledge of either language. Wifi will be provided as well as coffee breaks and lunch. Participation is free, but seats are limited to 40.

The workshop will be led by Marie-Claire Beaulieu (Tufts University), Tim Buckingham (Perseids Project), Vanessa Gorman (University of Nebraska-Lincoln), and Robert Gorman (University of Nebraska-Lincoln).

Follow this link for more information and to sign up for the workshop.

Keep checking out the landing page, as we will keep adding more information and more content in the future.

The Hacker and the Professor – Switching Roles

As discussed in previous posts in this series, navigating the waters of the scholarly and technical assumptions each of us bring to the Perseids collaboration is not always simple.  Some of this disconnect has been beneficial to the project — when we each stick to our respective roles and areas of expertise we have very little redundancy of effort.


But, when it comes to joint decisions about the direction of the project, our Hacker and Professor run into some disagreements. Bridget regularly has to remind the team that the inclusion of new unplanned features and workflows mean that other things we had hoped for would have to wait or be dropped entirely. But Marie-Claire can be frustrated by the “workplan-waving.” This recurring issue stems in part from Marie-Claire not being able to fully assess the complexity of the technical solutions, and Bridget not understanding what drives the scholarly and pedagogical requests. These misunderstandings make it difficult for them to decide which things should remain in the workplan and which new avenues should be pursued with students.


So, in keeping with the experimental nature of Perseids, The Hacker and the Professor have embarked on a skills exchange as an experiment of their own. Bridget has been coaching Marie-Claire through a self-initiated journey into programming and web design. Marie-Claire has been mentoring Bridget through an assignment she normally gives to her Greek mythology classes, which aims to analyze the transmission of a classical Greek myth through its representation on an ancient artifact.


It has been a truly fascinating journey so far. What follows are some of the thoughts they have about their skills exchange.



First, I have to confess that my interest in helping Marie-Claire obtain some more technical skills is not entirely altruistic … I hate the part of my job that requires that I be realistic about timeframes and the effort needed to develop code. I want Marie-Claire to gain these skills for her own growth, but also so that when we prioritize the work the burden for understanding what takes time is more fully shared. I am not a natural teacher though and I am incredibly thankful for the outstanding free resources available for this. The Khan Academy site in particular has been great in providing a logical order to tackle topics, exercises, and examples to work through.  (A side-benefit of this for the project is that it has been allowing us to think more concretely about certain features of the ePortfolio and self-assessment tools that we hope to make available on Perseids). We then take those examples and Marie-Claire applies them in the context of work she is doing with her students using the Perseids platform.  


I do believe that I have the better end of the bargain here though. Marie-Claire is a world-class teacher who cares tremendously about her students and her subject, and I could not ask for a better mentor. As a young college student I was focused on getting out into the real world as quickly as possible to save time and money and didn’t take advantage of my education to explore some of the topics in ancient religion and myth that serve as the underpinnings for our society. I have passed by thousands of objects in museums and public spaces without thinking about what they say about our social history and our internal perceptions of ourselves, our human relationships, and our culture. I have tried over the years to be more well-read and informed in a self-directed, and often misguided, sort of way, but doing so without context makes it hard to get engaged with the material. Reading the primary and secondary sources with a specific question in mind changes that. What I find particularly interesting about this experiment is that when we first embarked on it, I found myself getting distracted by thinking about superficial aspects of the digital tools that could enhance presentation of the material or my eventual reporting on it. But as I delve deeper into the actual content and discuss the questions I have on it with Marie-Claire, aspects of digital presentation and publication are actually quite far from my mind. I am very curious to see if and how they reenter the picture as I get closer to producing the results of my little research project.



Learning programming has been an exhilarating experience so far. Let me be clear: I am not saying that it all comes easy and everything is great. Quite the contrary. I struggle through the basics and often get stuck on little things. I also often get it into my head to undertake projects that are too difficult at my current level and I sink into quagmires. Yet, every small success is a reward, and Bridget’s support, patience, and encouragement is a constant motivation. In fact, I feel that I’m getting the better end of the bargain in our skills exchange, because I have access to Bridget’s advice and experience, without which it would be very difficult not to be intimidated by the material. The excellent Khan Academy tutorials also do a great job of rewarding every bit of progress. I am constantly reminded of the very similar effort I had to make when I was learning Greek and Latin, and the immense joy of discovery I experienced as I got better. As a teacher, I never want to lose sight of the challenge of learning.


In fact, becoming a better teacher motivates me through this learning experience. Anything I learn, my students will get to learn too. So as I make my way through my lessons and the sessions with Bridget, my head is buzzing with ideas for student projects that will take advantage of these skills and transmit them to my students. As a Classics professor, I strive for my discipline to be taught better and more widely, so that the wealth of wisdom and beauty that we inherited from the ancient world be made accessible to as broad an audience as possible. In today’s world, that includes code and programming. These techniques enable us to study our field in deeper and more meaningful ways than we ever could before and to disseminate the results in sustainable ways. Technology also makes our discipline more inclusive than ever before, because it allows us to approach the Humanities from a common middle ground that crosses cultural and social gaps.


As you can see, I am the dreamer in the Perseids team… For me, programming is very much like fine arts, music, or languages. It is creative, yet also exacting, and forces me to think in a disciplined fashion. Hopefully, that will help me stick to the workplan.


Alright, enough musing. Can we talk about code now?

Musing on Professing for those who Hack…

Professing is a rather mysterious activity. We teach, we write, we read, we muse, we talk… seemingly in no particular order. Understandably horrified, our hacker friends wave their workplan at us and tell us that we need to stay in scope, and that such and such feature is not to be released until the second quarter of next year, and what are the requirements please?

There is a method to the madness, I assure my hacker friends. We do have well-defined research and teaching agendas, and our progress (especially for junior professors) is meticulously charted by our institutions. Yet, the flexibility of our schedules and work culture means that we often have the opportunity (and occasionally the obligation) to take up an unplanned project. We are also responsible for mentoring student theses, the topics of which may vary quite widely, and are renewed with every cohort, every academic year.

So how do we build tools and infrastructure with equal parts of professing and hacking? Obviously, this requires true intellectual engagement on both sides, so that the result is not an immediate means to an end, but rather a process whereby Humanities questions and technology are explored and developed at the same time. Writing user stories and requirements allows us to think about our objectives, not only from the user perspective but also from the inside out. What do we want the data to do? And more importantly, how should it do it?

As Bridget Almas pointed out in her latest post, the wires-exposed nature of Perseids is helpful in the course of this experimentation because it lets us think concretely about the objects we are manipulating, namely the data and the technology itself. And yes, we acquire skills that we never thought we would have when we signed up to be Humanists.

Now, does this change professing? Yes and no. No, because experimentation is built into research and teaching. Hitting roadblocks or dead-ends is a natural part of discovery, and the process of learning is one of trial and error. Yes, because we are now placed in a global environment where we must produce data and tools that can be reused in order to ensure any degree of perennity and sustainability. Explaining this to our administrators is not always easy, since expectations for Humanities faculty are centered on single-author publications, especially books and journal articles. Even so, the highly individualized practices of our profession are eroding to make way for teamwork, which in turn requires us to stick to the workplan.

And that’s not half-bad. In my opinion, one of the greatest benefits of this method is the built-in review system. As we think through our projects with our team and scope out the requirements, we go through a back and forth that helps us all to refine our work. Then, when we release new features and workflows, we try it all out in class or in our offices. In the process, we gather a wealth of feedback that we can immediately (or as soon as the workplan allows) put to use in a new iteration. This differs radically from traditional publishing models in the Humanities, in which most feedback is received after any changes can be made. Although our Frankenstein must deal with all sorts of growing pains, at least we piece him together in a positive and forward-looking environment.

Marie-Claire Beaulieu, Perseids Professor