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.

plokfig2

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
10.5281/zenodo.159569

Introduction

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.

Objectives

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.

Methods

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.

flowchart

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

Location:
THE WESTIN HARBOUR CASTLE, TORONTO
1 Harbour Square
Toronto, ON M5J 1A6
Canada

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.

 

Bridget

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.

 

Marie-Claire

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

First Teach the Teachers Workshop

Teach the Teachers, Leipzig April 18-19th, 2016
The Perseids Project, in collaboration with the Humboldt Chair of Digital Humanities at the University of Leipzig and the Department of Classics at Tufts University is calling for participants in the first Teach the Teachers workshop. The two-day workshop aims to present and develop lesson plans and syllabi including digital methods for the high school and university Humanities curriculum. Registration for the 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.

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.

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, but is not limited too:

  • Use of translation alignments for non-language students
  • Use of treebank annotations to assess understanding of grammar and morpho-syntax
  • Use of the gold standard review functionality and the board review systems of Perseids
  • The Perseids Social network annotation workflow
  • Assessment strategies for digital assignments

The purpose of this workshop is to facilitate the exchange of new ideas for the implementation of the Perseids Platform in the classroom. During the two-day workshop we will produce resources for digital projects in a classroom setting. We will incorporate these resources into a growing collection of shared resources which will help future educators integrate the Perseids to their classroom practice.Those resources may include:

  • Syllabi for high school and college level courses.
  • Lesson plans for in-class digital projects.
  • collaborative, inter-institutional workflows and project plans

Contributors should submit statements of up to 500-700 words. Submissions will be accepted until January 8th.

We have extended the deadline to Monday, January 18th.

Send submissions in the form of a pdf to teachtheteachers2016@gmail.com Statements can include:

  • Plans or ideas for the implementation of digital tools in the classroom
  • Description of experience or interest in digital methods
  • Other experience involving the use of digital tools in an educational setting

Peer Instruction in the Lab Style Greek Course

Treebanking, and the collaborative environment that surrounds treebanking allows undergraduates to participate in research and scholarship in new ways. This fall I am a teaching assistant, or peer-instructor, for an intermediate Greek course. Although I am a Junior in college, and taking my fifth Greek course right now, but because of treebanking I am able to instruct and assess students with one year less Greek than I have.

My role in the class is to lead close reading sessions and a treebanking lab, and to grade treebanking assignments. In the close reading sections, I go over the readings, drawn from Plato’s Apology, and answer questions. In the treebanking lab, I demonstrate how to treebank different Greek constructions.  For instance, near the start of the semester a student asked about the difference between coordinating and subordinating conjunctions. I walked the class through how these conjunctions are treebanked and how the tree shows us the relationship between conjunctions and the words they govern and are governed by. In general, during this hour and twenty minute lab session students work independently on treebanking assignments while I go around the room and answer questions. When students submit their treebanks, I grade them for accuracy using the review tools built into the treebanking program we use, Arethusa. It is possible to automatically compare my treebank with a student’s treebank, and also to manually enter feedback on a particular word, sentence, of assignment.

I see real benefits for the students in the class and myself from this practice. The students in the class are able to ask every question they have about treebanking (and by extension Greek syntax) and get an answer immediately. I spent hundreds of hours treebanking Plato and Xenophon over the past summer, so I can refer back to my trees or to the resources I learned to use while I worked on that project if questions come up that I cannot answer off-hand. I think that small things, like understanding the relationship between the μέν and δέ of the classic μέν…δέ (“on the one hand… on the other hand”) construction, that would otherwise fall through the cracks are brought to the surface and addressed in this type of class. Before I started treebanking I could not have explained that the μέν…δέ construction is a type of coordination, because the structure is not explained that way in traditional Greek textbooks. That is, the traditional explanation of “on the one hand…on the other hand,” while useful for beginners to translate, does not explain the grammatical role of these words the way a treebank does. So in this way I can address the holes in students’ grammatical understanding and hopefully give them more of the tools they need to really read Greek.

But in terms of the benefits for me as a peer-instructor, I have never thought more about Greek than while I am answering questions from the students in this class. People say that you never learn something until you teach it. I cannot agree more – I had never thought about just what is going on syntactically with the “extra” ἤ in an ἤ…ἤ (“either…or”) construction. It is perfectly clear that one the ἤ’s is the coordinator and the other is only setting up the construction, but until I actually had to explain this common construction I had never thought much about it. It’s the sort of thing grammar books normally gloss over but that you have to know to understand the syntax. In short, treebanking with students has provided me a rigorous review of syntax. But the main reason this opportunity is so important is that before treebanking an undergraduate as a teaching assistant in Greek would be almost unheard of. The opportunity to really learn something through teaching has been given to me because of my experience with treebanking and the hands-on, collaborative work that treebanking encourages.

 

Drew Latimer

Tufts University, Greek and Latin Major

Class of 2017