This chapter of our documentation is still in beta. We welcome feedback, corrections,
and questions while we finalize the page in our 2024–2025 work cycle.
Introduction to Quickstart Guidelines
This documentation is for all those who are new to working with LEMDO, including editors,
encoders, anthology leads, and developers. It will direct you towards the best place
to start navigating our documentation from based on your role with LEMDO.
The first question you are likely to ask is Where do I start? The Quickstart documents are designed to tell you what to do first and then guide
you to the documentation you need.
Introduction
Across our documentation (including in our Quickstarts), we refers to the LEMDO team based at the University of Victoria. You refers to you, the reader of this page. You are welcome to email us at any time with questions. We also welcome suggestions that will improve this documentation
for future readers.
Ask Questions
If you don’t understand an aspect of documentation as you read through it, please
ask questions of the LEMDO team. You are not expected to know and understand everything in this documentation. Ask
questions about TEI, XML, and encoding, and also ask questions about Shakespeare,
early modern bookmaking, and early modernized texts generally. When you ask questions,
you are clarifying for yourself and helping to make the documentation clearer for
those working on LEMDO in the future.
Note: If you are a research assistant or editorial assistant, you will want to direct
questions about the play to the editor of the play, who may in turn consult their
anthology lead. LEMDO defers to anthology leads on textual or editorial matters.
Select Your Quickstart
There are various Quickstart documents, each written for a different user group. Scan
the list below to find the right Quickstart for you. You may inhabit different roles
at different times. Come back to these Quickstarts as your roles evolve.
Are you an anthology lead coordinating or directing a major editorial project or anthology (e.g., DRE, NISE,
QME, MoMS)?
This page is for anthology leads, editors, and research assistants new to TEI markup.
It can also be used in undergraduate and graduate classrooms as a quick introduction
to markup, XML languages in general, and TEI-XML in particular.
Why Do We Mark Up Texts?
Unlike past generations of editors, we are producing texts that must be readable by
machines before they are rendered and made readable by humans. Thus, virtually every
editorial choice must be tagged in such a way that a computer can process it in various
ways. We call this level of machine-readable information markup.
Markup has an additional advantage: we can process a marked-up text in many different
ways. We can change how we render it. We can give readers the choice to display or
suppress corrections, display or normalize the long s, show supplied readings, and
to expand abbreviations. We can transform the marked-up text into many different types
of outputs: HTML pages for display on a website, PDFs, ePubs, camera-ready print copies,
actors’ scripts, and other XML languages. We can index it, link to it, generate concordances
from it, count things in it (e.g., words, stage directions, lines, speeches), search
it, and store it for long-term digital archiving. The effort you put into markup,
therefore, makes your text extraordinarily valuable for many users and for diverse
purposes.
What Is Markup?
Markup is information added to a text in order to say something about a text. As a
skilled reader of texts (and possibly already an experienced editor), you already
have an incipient understanding of textual markup. White space, paragraph breaks,
italicization, punctuation, capitalization, square brackets, and other features of
a printed text are all forms of markup that signal something to the reader about the
textual content.
We add markup to our own documents as we write, inserting spaces, paragraph breaks,
italicizing titles, and punctuating our clauses. We don’t think too much about the
fact that italics (for example) can signal multiple things: foreign words, monograph
titles, things we want to emphasize, and words that we want to talk about as words.
Early modern writers and compositors did likewise. Both now and then, context helps
make meaning clear. For example, we recognize monograph titles in bibliographies not
just because they are italicized but also because they occupy the place in the sequence
of metadata where we usually record titles. Likewise, we recognize stage directions
in early modern texts not just because they are often italicized but also because
of what they say and where they are located on the page.
As we shall see, TEI markup needs to be more precise because computers are not as
good at reading contextual clues as we are. Nonetheless, you have an incipient understanding
of markup because you’ve been doing it and interpreting it for your entire reading
life.
Terminology
Some terms will come up many times in this tutorial.
Tagging, marking up, and encoding are interchangeable terms.
The information added to a text is markup.
When we add markup to a text, we tag, mark up, or encode the text.
Text with markup is called tagged, marked-up, or encoded text.
You will also see markup (the noun) spelled mark-up or mark up. At LEMDO, we use markup to refer to the tags you will add to your text, and reserve mark up for the action of adding markup to a text.
LEMDO’s Markup Language
LEMDO uses a markup language known as TEI-XML. It is a dialect of XML devised by the
Text Encoding Initiative (thus the acronym TEI), a consortium of people who came together to devise a markup language specifically
for text-bearing objects (e.g., manuscripts, books, documents, scripts, computer-mediated
communication, performance texts).
If you are familiar with the Internet Shakespeare Editions’ Markup Language (IML)
that was used to prepare texts for the old ISE platform, you will notice many similarities
between IML and TEI. You will also notice many points where TEI is much simpler than
IML, and a few points where TEI is more complex.
The value of encoding our editions in TEI is that our texts become usable in multiple
platforms and processable by many open-access tools. The value of learning TEI is
that you gain a transferable skill. Thousands of digital editions are encoded in TEI.
So are legal cases, library records, parliamentary records, account books, and their
associated metadata.
What Is XML?
XML stands for eXtensible Markup Language. XML itself is not a single language, but a metalanguage prescribing a set of standards
for writing XML languages. The standard was published in 1996 by the World Wide Web Consortium.
The XML specification is long and we do not recommend that you read it just yet. But
if you really get into XML, the specification is hosted on the World Wide Web Consortium’s website. In the meantime, you’ll learn more about the basics of XML later in this Quickstart.
What Does Markup Look Like?
Let’s start with an example using italics. In a printed or word-processed text, italics
can indicate many different things:
Do you know what the word palimpsest means?
In Measure for Measure, Angelo is the main antagonist.
But since at Wakefield in a battell pitcht ….
These came by degrees, as additamenta honoris.
A human reader can read ambiguous markup. When we see italics, we can infer the meaning
of the italics through contextual clues. A computer, however, is not very good at
making contextual inferences about italics. As encoders, we do not use ambiguous markup.
We use precise markup to describe how the word or phrase functions in our sentence.
If we think about the examples above, we can work out that all the examples of italicized
text are italicized for different reasons. We can have unique tags for each situation.
Words as words:
<p>Do you know what the word <term>palimpsest</term> means?</p>
Title:
<p>In <title level="m">Measure for Measure</title>, Angelo is the main antagonist.</p>
Italics in source:
<p>But since at <hi rendition="rnd:italic">Wakefield</hi> in a battell pitcht ….</p>
Foreign words:
<p>These came by degrees, as <foreign xml:lang="la">additamenta honoris</foreign>.</p>
These are all examples of descriptive markup. We aren’t saying anything about how we want the words and phrases to appear in our
output. We decide later (in conjunction with a designer/developer) how we want the
marked-up text to appear on a computer screen or in the print output we generate from
our marked-up text. This precision in tagging also allows us to change our rendering
in the future, if the MLA Handbook or the Chicago Manual of Style prescribes new treatment of foreign words, or if we need to output our encoded text
in a way that conforms to an entirely different style manual.1
Elements, Attributes, and Values
All XML languages have components that we call elements, attributes, and values. You need to understand these terms—and text node, string, opening tag, closing tag, and empty element—before you read any other documentation.
An element is the descriptive tag that identifies an item in the text. In the following example,
<title>
is the element:
<title>Measure for Measure</title>
You can think of an element as being like a noun. The element describes what something
is. In this case, Measure for Measure is a title. By tagging this string of alphanumeric characters with the
<title>
element, we are ensuring that the computer processor treats the string as a title.
The character, string, word, phrase, or text you are marking up is called the text node. In the previous example, Measure for Measure is the text node. The text node is the thing you are describing, identifying, and/or
clarifying with your markup.
Every element has both an opening tag and a closing tag. Elements wrap around the text node, clearly marking the beginning and the end of
the text node about which you want to say something. The opening tag is <title> and the closing tag is </title>. Note that the closing tag in XML begins with a forward slash character /.
What if you want to say more about the text that you’ve identified as a title? For
example, you might want to indicate that Measure for Measure is the title of a book-like thing? You can add an attribute to your opening element tag:
<title level="m">Measure for Measure</title>
You can think about an attribute as a big category. Attributes are incomplete by themselves.
You have to add a specific value that describes the text node. In this example, the value of the
@level attribute is m (for monograph-like).
The element describes what the text node is (animal).
The attribute is a category or quality of the element (size, colour).
The value is the precise value of the attribute (big, grey).
Colour is to grey as an attribute is to its value.
Note that the attribute and value go in the opening tag only. The closing tag does
not repeat the attribute and value.
Elements can have more than one attribute. In this example, as above, we’re using
the recommended TEI attribute and value for
<title>
. The
@m attribute means “monograph or monograph-like work”. The
@when attribute allows us to add a date to the title:
<title level="m" when="1603">Measure for Measure</title>
While particular elements, attributes, and values vary from one XML language to another,
the structure of an XML element is always the same:
<element attribute="value">text node</element>
Empty Elements
Some elements do not have a text node. These elements are called empty elements, milestone elements, or self-closing elements. Common milestone elements in LEMDO’s semi-diplomatic transcriptions are
<lb>
(“line beginning”),
<pb>
(“page beginning”), and
<cb>
(“column beginning”). Milestone elements can be written with an opening tag and a
closing tag, or you can abbreviate the closing tag by adding a forward slash at the
end of an opening tag to indicate that it is both the opening and the closing tag
of a content-less element.
<ab> <lb type="wln" n="2"/>TO sing a Song that old was sung,
<lb type="wln" n="3"/>From ashes, auntient Gower is come,</ab>
Empty elements can still have attributes and values, but they do not wrap around a
text node.
<pb n="3|A2v" facs="facs:MV_Q1_BPL_03.jpg"/>
XML Structure
XML markup languages are hierarchical. Elements are contained by (or nested within)
other elements. In order to talk about the relationship between nested elements, we
use the terms parent, child, and sibling. We use these terms frequently in our documentation. Make sure you understand them
before you read additional documentation.
Parent elements contain child elements. If a parent has multiple child elements, those
child elements are siblings of each other. In the following example, the
<p>
element is the parent of
<list>
because it contains the
<list>
element. The
<list>
element is the child of
<p>
because it is contained within the
<p>
element. Note that the hierarchy can multiple levels:
<list>
is the parent of
<item>
. The
<item>
element is the child of
<list>
. We have three sibling
<item>
elements:
<p>According to the Shakespeare Census Project, copies survive at the following locations:
<list rend="bulleted"> <item>British Library</item> <item>Huntington Library</item> <item>Folger Shakespeare Library</item> </list>
The British Library copy is the control text for the semi-diplomatic transcription.</p>
Note that an element can be both a parent and a child if it is contained by another
element and contains an element. To phrase it another way, an element can have both
a parent and a child.
An XML document must be well-formed. In a well-formed XML document, all child elements are closed with a closing tag
before the parent element is closed. Another way to put this requirement: all tags
must be closed in the reverse order they were opened.
What is TEI?
The Text Encoding Initiative is two things: (1) a consortium, and (2) an XML standard. The TEI Consortium describes
itself and its work thus:
The Text Encoding Initiative (TEI) is a consortium which collectively develops and
maintains a standard for the representation of texts in digital form. Its chief deliverable
is a set of guidelines which specify encoding methods for machine-readable texts,
chiefly in the humanities, social sciences and linguistics. Since 1994, the TEI Guidelines
have been widely used by libraries, museums, publishers, and individual scholars to
present texts for online research, teaching, and preservation. In addition to the
Guidelines themselves, the Consortium provides a variety of resources and training
events for learning TEI, information on projects using the TEI, a bibliography of
TEI-related publications, and software developed for or adapted to the TEI.
(https://tei-c.org/)
The TEI standard predates XML, but became XML-compliant after the XML standard was
introduced in 1996. TEI is now a global standard published in eight languages (English,
French, Spanish, Italian, German, Japanese, Mandarin Chinese, and Korean).
The TEI standard is captured in a robust set of guidelines known as the TEI Guidelines. The first set of guidelines, TEI P1, was released in 1990. The current edition of
the guidelines is P5.
The standard is driven by the community of users. The guidelines have evolved continuously
since the TEI was first proposed in November 1987. Anyone can post questions and suggestions
for the TEI Technical Council" to the TEI listserv. There is also an active GitHub channel for ticketing and commenting. The TEI Technical Council2 meets monthly to respond to community requests and to improve both the standard and
the guidelines. The community gathers for an annual meeting and conference, which
features keynotes, conference papers, poster sessions, meetings of special interest
groups, and business and council meetings.
TEI File Structure
The first line in the file starts with a pointy bracket and a question mark. It will
be purple if you have opened this file in the default view in Oxygen:
This first line tells the processor that this present file is an XML file. Do not
alter the first line at all.
Green text in the file is an XML comment:
<p><!-- This is a comment. --></p>
You can leave XML comments in your file. Note that an XML comment begins with an exclamation
mark, two hyphens, and a space. Everything written inside an XML comment is ignored
by the processor. XML comments are how we as encoders and editors can leave notes
in the file for ourselves or other editors. Note that leaving a comment for someone
else does not send them a notification, so you should let people know if you have
left comments for them in a certain file.
The second line in the file contains the opening tag of the root element. The root element contains the entire file (i.e., it is the biggest container in
the document and contains all the other tags). For a TEI-XML document, the root element
is
<TEI>
:
The root element is the first element in the file and contains all the other elements;
in other words, all the other elements are nested within the root element. If you
scroll down to the very bottom of the file, you will see that the file ends with the
closing tag of this root element.
Note that there are two attributes on the root element:
@xmlns and
@xml:id.
Namespace: The
@xmlns attribute stands for XML namespace. Every XML language has its own namespace to which its elements and attributes belong
(which is a bit like saying that French words belong to the French language, English
words belong to the English language, and so on). The value of
@xmlns is a URL that points to a page on the TEI website. This value tells the processor
that we are encoding this file in TEI-XML (i.e., we are using the elements and attributes
defined by the TEI instead of elements and attributes defined by another XML language).
The document ID: The
@xml:id attribute stands for XML identifier. This string of letters and numbers is unique
within the project. No other file or piece of data or element may have the XML identifier
that we give to this file.3
The
<TEI>
root element has two children in most LEMDO files: a
<teiHeader>
element and a
<text>
element. You will put the metadata about the text in the
<teiHeader>
. The content you are encoding goes in the
<text>
element.
Further Reading
Read more about markup language in general: Wikipedia.
Read more about XML markup languages in general: Wikipedia.
Read a highly accessible description of TEI: Burnard, Lou. What is the Text Encoding Initiative? How to Add Intelligent Markup to Digital Resources. Marseille: OpenEdition Press, 2014. http://books.openedition.org/oep/426
See how other projects use TEI markup: Melissa Terras, Edward Vanhoutte, and Ron Van
den Branden, TEI by Example (https://teibyexample.org).
Quickstart for Encoders
This documentation is for new encoders, including editors who are encoding their own
editions, research and editorial assistants helping editors to encode an edition,
remediators working with the LEMDO team, and anthology leads encoding their anthology’s
About pages. It will introduce you to encoding with LEMDO and the typical workflow for
encoding an edition. It will also direct you towards further helpful documentation.
All pieces of a LEMDO edition must be marked up using LEMDO’s customization of TEI-XML
before it can be published online, in PDF form, and, in some cases, as part of the
printed LEMDO Hornbooks series. As an encoder, your role is to mark up files following the instructions given
in our documentation so that they can be processed into these publishable formats.
The Work of Encoding
You will be adding computer-readable tags to texts in order to say things about the
texts. This work is called encoding,tagging, or marking up a text. LEMDO uses tags devised by the Text Encoding Initiative (TEI), a widely used standard for marking up historical and literary texts. As a
new encoder, you may want to return to LEMDO’s Introduction to Markup, XML, and TEI frequently for reminders of the key terminology and practices in marking up text
using TEI.
All of the files you will need to encode your play are in a repository stored on a server at the University of Victoria. Anyone can look at the repository,
but you need special permission to create and change files in the repository. We will
give you write-permission on the directory that contains the files for the play you are encoding. For information
on how to request permissions, see Workflow to Get Started with LEMDO.
Your edition directory, along with all of LEMDO’s project files and code, is stored in a Subversion (SVN) repository. This repository keeps a copy of every version of every file so
that, if needed, we can retrieve a previous version of a file, directory (i.e., folder),
or even the entire project. For more information about Subversion, including how LEMDO
uses it, common commands you will use, and best practices for working in it, see Work in Subversion.
Workflow to Get Started with LEMDO
Before you can begin your work encoding, you must get set up to work in the LEMDO
repository. You should also complete some additional training tasks. To get started
working as a LEMDO encoder:
Read this page.
Email the LEMDO team to get more detailed instructions for getting started and to set up an initial training
meeting. If you are an RA who is not a member of the LEMDO team (i.e., not at UVic),
ask your editor to introduce you to us via email.
Apply for a UVic affiliate ID and a NetLink ID if you are not at UVic. For information
on how to do so, see Get a NetLink ID.
Send us your NetLink ID. (UVic students, staff, and faculty: your NetLink ID is your
UVic email handle.)
Send us a bio-bibliographical note for our list of contributors. At this point, we will create an xml:id for you and send it to you.
Install Oxygen (the application that we use to edit XML). Read Install Oxygen.
Do a test commit with a LEMDO team member.
Familiarize yourself with the standard workflow in your command line that you will
follow each work session. Read Workflow for Working in the Command Line (Terminal). We recommend bookmarking that documentation page, as encoders refer to it frequently.
Once you have gotten set up to work in the repository, you will likely follow this
workflow for encoding an edition:
Create an edition landing page if there is not one already for the edition.
Encode the semi-diplomatic transcription for an early edition of your play.
Generate a basic modernized text from the encoded semi-diplomatic transcription.
Encode the edition’s collation, anchoring it to the modernized text.
Create a bibliography file from the LEMDO template and begin populating it with your
collation witnesses.
Check the encoding of the modernized text, correcting it as needed. The basic encoding
that is in place when you generate the modernized text from the semi-diplomatic transcription
will ensure that it is a valid file, but needs to be updated to reflect editorial
decisions.
Encode the edition’s annotations, anchoring them to the modernized text.
Encode your critical paratexts, adding sources to your bibliography as you go.
Check that the edition bibliography contains all sources referenced in the edition.
If they are not already in LEMDO’s sitewide bibliography, ask the LEMDO team to add them.
Check that all edition components have been added to the edition landing page.
You will find documentation chapters on encoding each piece of an edition in our Documentation Index. The chapters are laid out to reflect the typical encoding workflow described in
Typical Workflow for Encoders, starting with semi-diplomatic transcriptions and ending with critical paratexts.
You can quickly search for all documentation that has been written specifically for
encoders by going to the search page and selecting Documentation from the Document Types menu and Encoder from the LEMDO Target Audience menu.
Quickstart for Editors
This documentation is for editors who are new to LEMDO. You may be editing a play
for the general LEMDO anthology (e.g., as a graduate student preparing a LEMDO edition
for your thesis) or you may be editing a play for one of the anthologies that uses
LEMDO as a publishing platform (i.e., DRE, NISE, or QME). You may be an experienced
editor who is encoding a play for the first time. You may be new to editing but have knowledge of text encoding.
Or you may be new both to editing and to encoding. This page will introduce you to
the typical workflow for editing a LEMDO edition and direct you towards further documentation.
All LEMDO editions must be marked up using the TEI-XML encoding language. This encoding
captures your editorial decisions and allows your work to be processed into various
outputs: the online publication, a PDF, and, in some cases, a print volume for the
LEMDO Hornbooks series. As a LEMDO editor, you will edit your edition according to your anthology’s editorial guidelines. Your edition must
be encoded according to LEMDO’s encoding guidelines, whether you do the encoding yourself
or pay someone (a trusted student or a LEMDO team member) to encode it for you.
If you are encoding your own edition as well as editing it, you will want to read
the Quickstart for Encoders carefully for your own edification. It is written to be comprehensible to students
and people with no experience of encoding or no experience encoding for LEMDO.
If you have a research assistant or editorial assistant working with you to encode
the play, point them to Quickstart for Encoders. Even if you are not encoding your edition yourself, we recommend that you familiarize
yourself with the type of information that LEMDO provides to encoders. Note that the
LEMDO team at UVic is normally happy to include your RA in any of our training sessions
and to give them a virtual space to connect with our local RAs.
If you are contributing to a LEMDO anthology (such as DRE, NISE, or QME), please direct
questions about your play, copytext, and editorial principles to your anthology lead.
The LEMDO team is not ignorant of such matters, being editors and encoders ourselves;
indeed, we advise anthology leads on many matters. However, we take direction from
anthology leads when it comes to your edition and progress. We do not interfere with
the editorial process or governance of the anthology projects.4
Workflow to Get Started with LEMDO
Before you can begin any editorial work that involves encoding, you must be set up
to work with LEMDO:
Read this page.
Email the LEMDO team to receive detailed instructions on getting started and to set up an initial training
meeting. If you have an RA who is not a member of the LEMDO team (i.e., not at UVic),
introduce them to us via email.
Apply for a UVic affiliate ID and a NetLink ID if you are not at UVic. For information
on how to do so, see Get a NetLink ID.
Send us your NetLink ID. (UVic students, staff, and faculty: your NetLink ID is your
UVic email handle.)
Send us a bio-bibliographical note for our list of contributors. At this point, we will create an xml:id for you and send it to you.
If you have an RA, ensure that they also apply for a UVic affiliate ID, create a NetLink
ID, and send us their NetLink ID and a bio-bibliographical note.
If you are encoding your own edition, you should also complete the following training
tasks:
Install Oxygen (the application that we use to edit XML). Read Install Oxygen.
Do a test commit with a LEMDO team member.
Familiarize yourself with the standard workflow in your command line that you will
follow each work session. Read Workflow for Working in the Command Line (Terminal). We recommend bookmarking that documentation page and referring to it often, especially
if you are picking up your encoding work after a period away from it.
Once you are set up to work in the repository, you will likely follow this workflow:
Confer with your anthology lead about which editorial guidelines your anthology follows.5
Complete a semi-diplomatic transcription of an early edition of your play. In many
cases, you will check a pre-existing transcription to ensure that it is correct; if
the LEMDO team has prepared this transcription, you are effectively peer reviewing
LEMDO’s work. In other cases, you will need to prepare a full transcription yourself.
Contact the LEMDO team to see if there is a pre-existing semi-diplomatic transcription for your play, or
if we are able to convert an EEBO-TCP transcription of a print witness for use in
your edition. Manuscript witnesses must be transcribed by you.
If you are encoding your own edition, generate a basic modernized text from your semi-diplomatic
transcription. If you are not encoding your own edition, ask the LEMDO team to generate a basic modernized text for you.
Collate necessary editions for your play as required by your anthology and write textual
notes. You may also start work on your textual introduction if you are writing one
for your edition.
Create your edition bibliography from a template, add your collation witnesses, and
begin adding sources from your critical paratexts.
Emend your text and check in with your anthology lead.
Modernize your text.
Write the remainder of your annotations.
Write whatever critical paratexts are required by your anthology.
Ensure your bibliography is complete.
Ensure that your edition landing page contains all of the content that you want to
appear for readers.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typical encoding workflow described
in Typical Workflow for Editors, starting with semi-diplomatic transcriptions and ending with critical paratexts.
You can quickly search for all documentation that has been written specifically for
editors by going to the search page and selecting Documentation from the Document Types menu and Editor from the LEMDO Target Audience menu.
Quickstart for Legacy Editors
This documentation is for editors whose editions were originally encoded in the ISE
Markup Language (IML)—i.e., editors who finished or began working on editions for
the Internet Shakespeare Editions, Digital Renaissance Editions, or Queen’s Men Editions before December 2018. This page will introduce you to the typical workflow for remediating
an edition previously encoded in IML and will direct you towards further helpful documentation.
All editions that were encoded in IML that are being published on the LEMDO platform
must be marked up using LEMDO’s customization of the TEI-XML encoding language. We
have converted the encoding of your edition or components thereof to TEI P5 and are
in the process of remediating your files for republication on the LEMDO platform.
The full remediation workflow entails programmatic conversion processes run by a developer,
followed by evaluation, correction, and tidying by a human markup editor
Your role in the process of remediation and what you need to learn depends on several
factors:
The completeness of your edition in December 2018 at the moment when the old ISE server
was taken offline.
Your willingness to keep working on the edition or to pass the components thereof
to another editor.
Your willingness to learn TEI at least well enough to edit the files that we create
for you.
The extent to which your anthology lead(s) can:
Support ongoing work in IML.
Support you in the transition to TEI.
Oversee the remediation process themselves.
Just as LEMDO defers to anthology leads on textual or editorial matters that are within
the anthology’s control, LEMDO will defer to anthology leads about the best way to
proceed with the remediation of your edition.
The Plan for Your Edition and Anthology
All QME and DRE editions are being republished along with the QME and DRE anthologies.
Some ISE editions are being republished in the New Internet Shakespeare Editions anthology.6 The new LEMDO-generated QME and DRE anthologies will include all the content from
the old anthologies and replace them at the old URL as well as the new URLs (lemdo.uvic.ca/qme and lemdo.uvic.ca/dre). However, the old ISE website (at https://internetshakespeare.uvic.ca) has been staticized in its 2018 form (with minor revisions to the HTML undertaken
by Michael Best in Fall 2022) and will be preserved at its original URL for as long as it remains
functional. The New Internet Shakespeare Editions, to be published at lemdo.uvic.ca/nise, will not replace the old ISE nor will it
include all of the extensive ISE materials that were ancillary to the editions (e.g.,
image database, performance database7). Given that a user survey answered by 198 people identified the facsimiles as the
most important asset of the ISE, the NISE will include all of the facsimiles collected by the ISE plus new facsimiles.
Workflow to Get Started with LEMDO
The tasks you must do as a legacy editor depend on whether or not you will be working
on the encoding of your edition in the LEMDO repository. All legacy editors should:
Email the LEMDO team to receive detailed instructions on getting started and to set up an initial training
meeting. If you have an RA who is not a member of the LEMDO team (i.e., not at UVic),
introduce them to us via email.
Apply for a UVic affiliate ID and a NetLink ID if you are not at UVic and you do not
already have them. For information on how to do so, see Get a NetLink ID.
Send us your NetLink ID. (UVic students, staff, and faculty: your NetLink ID is your
UVic email handle.)
Send us a bio-bibliographical note for our list of contributors. At this point, we will create an xml:id for you and send it to you.
If you have an RA, ensure that they also apply for a UVic affiliate ID, create a NetLink
ID, and send us their NetLink ID and a bio-bibliographical note.
Additionally, if you will be involved in the remediation of your edition, you should
complete the following training tasks:
Install Oxygen (the application that we use to edit XML). Read Install Oxygen.
Do a test commit with a LEMDO team member.
Familiarize yourself with the standard workflow in your command line that you will
follow each work session. Read Workflow for Working in the Command Line (Terminal). We recommend bookmarking that documentation page, as encoding editors refer to it
frequently.
There is no one workflow because IML-encoded editions were in various states of completion
in 2018 and editors are at different career/life stages, but we can describe some
of the workflows that we have implemented for some editions:
Finished, peer-reviewed, and published edition:
LEMDO fully remediates the edition; the editor proofreads the result before we publish8.
LEMDO fully remediates the edition. The bibliography, performance history, and critical
history can be updated by the original editor(s) or another scholar.
LEMDO does not remediate the edition, a decision that can be made by the anthology
lead(s) or by the original editor(s). The anthology seeks a new editor to prepare
a new edition.
Partially finished edition with some components peer-reviewed:
LEMDO remediates and republishes the peer-reviewed sections. Unfinished components
of the editions can be completed by the original editor, passed on to a new editor,
or withdrawn.
Partially finished edition that has not yet undergone any peer review:
LEMDO will remediate the semi-diplomatic transcriptions (formerly old-spelling texts) and update them to match the particular copy that LEMDO has permission to embed
in the transcription. Since unfinished/unreviewed components of the editions can be
completed by the original editor, passed on to a new editor, or withdrawn, LEMDO will
take direction from anthology leads on the question of if/when to remediate unfinished
components.
On the matter of switching from IML to TEI, we have also faced a number of scenarios.
We prefer to get all editors working in TEI but can accommodate editors who wish to
finish an edition in IML.9 Options:
LEMDO converts your IML files (provided they are perfect or near-perfect IML) to TEI
and then you finish your work in TEI. If the edition is large or the IML is messy,
LEMDO will ask you or the anthology lead(s) to contribute to the cost of remediation.
You finish your work in IML, preparing your text and markup in a text file (.txt),
in a word-processed file (.doc, .docx, or .odt), or in a GoogleDoc. Your anthology
leads handle the peer review before LEMDO encodes the files in TEI. LEMDO may ask
you or the anthology lead(s) to contribute to the cost of remediation.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typical encoding workflow, starting
with semi-diplomatic transcriptions and ending with critical paratexts.
You can quickly search for all documentation that has been written specifically for
editors by going to the search page and selecting Documentation from the Document Types menu and Editor from the LEMDO Target Audience menu.
Quickstart for MoMS Editors
This documentation is for editors who are preparing texts for the MoMS (MoEML Mayoral
Shows) anthology. Typically, MoMS editors will not need all of information available
in the LEMDO technical documentation. This page will introduce you to the typical
workflow for encoding a MoMS edition with LEMDO and will direct you towards the sections
of documentation that you will need.
their modernized texts do not typically follow the act/scene/speech division structure
common in early modern plays
Your editorial workflow will thus be slightly different from that of a non-MoMS editor.
You will not need to read our documentation on semi-diplomatic transcriptions. You will need to consult with the LEMDO team about how to encode the structure of your modernized text.
Editing: As a MoMS editor, you will edit your edition according to the MoMS Editorial Guidelines. Please direct questions about your mayoral show and the MoMS editorial principles
to your anthology leads.
Encoding: You will either encode your own work or will pay an RA to encode it for you according
to LEMDO’s encoding guidelines. If you are encoding your own edition as well as editing
it, you will also want to read the Quickstart for Encoders.
Once you have been set up to work in the repository, follow one of these basic workflows.
For editors who are starting their edition in TEI:
Ask Janelle to create a basic modernized file for you from MoEML’s semi-diplomatic
transcription of your mayoral show.
Collate prior editions of your show and write textual notes. You may also start work
on your textual introduction if you are writing one for your edition.
Create your edition bibliography from LEMDO’s bibliography template, add your collation
witnesses, and begin adding sources from your critical paratexts.
Emend the modernized text of your show and check in with your anthology leads before
proceeding to modernization.
Modernize your show.
Write the remainder of your annotations.
Write your remaining critical paratexts.
Ensure that your bibliography is complete
Ensure that your edition landing page contains all of the content that you want to
appear for readers.
If you have already prepared your edition (or parts thereof) in a word processing
program, you will follow the same general workflow, though you will not need to emend
or modernize at this point. Before you begin to encode your text, you will first need
to move your text into Oxygen. If you have prepared your texts in Microsoft Word or
Google Docs, copy-and-paste the text into a .txt file (e.g., in your Notebook app) and then copy the text from the .txt file into an XML file in Oxygen.10 You may choose to encode it as you go, or work in passes (e.g., encode all the structural
elements, then encode all the names, then encode all the foreign words, if that procedure
works best for you). For the first pass, we advise you to copy and encode the structural
elements one paragraph or one speech at a time.
If you do not wish to do your own encoding, you may hire an RA or pay a LEMDO RA to
do your encoding for you. If you hire an RA at your institution, LEMDO will train
your RA. If you wish to pay a LEMDO RA, email LEMDO to inquire about procedures and cost.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typical encoding workflow described
in Typical Workflow for MoMS Editors. (You may ignore references to semi-diplomatic transcriptions.
You can quickly search for all documentation that has been written specifically for
editors by going to the search page and selecting Documentation from the Document Types menu and Editor from the LEMDO Target Audience menu.
Quickstart for Anthology Leads
This documentation is for anthology leads. If you lead or co-lead a project that uses
the LEMDO repository and publishing platform (DRE, EMDP, EMEE, MoMS, NISE, QME, or
EMEE), you are an anthology lead in LEMDO’s ecosystem. In the context of your project, you probably have a title like
Coordinating Editor or General Editor.
Bookmark this page and return to it often. It is your gateway into the resources you
need to build your anthology, support your editors and editorial assistants, and liaise
with us.
All components of a LEMDO anthology, including the editions therein, must be marked
up using LEMDO’s customization of TEI-XML before they can be published. If you have
no or limited experience with TEI markup, we strongly recommend that you add to your
editorial team someone who does have experience with TEI. We also encourage you to
read our Introduction to Markup, XML, and TEI so that you understand why your editors are marking up texts in TEI. LEMDO offers
regular training in TEI and has published a series of training videos on YouTube. You are very welcome to attend training sessions and to ask questions of the LEMDO
team.
Relationship of Anthology to Platform
An anthology is an independent editorial project that chooses to use the LEMDO platform
either (1) for encoding files, generating a static HTML site, and publishing that
site with the University of Victoria (UVic), or (2) for encoding files and generating
a static HTML site for hosting elsewhere. Anthologies have their own editorial and
advisory boards. They are responsible for commissioning and supporting their own editors,
and, eventually, for arranging for scholarly peer review. LEMDO will supply a contract
to each editor, provide training and some support (as LEMDO’s funding and time permits),
and undertake a review of the TEI markup. The University of Victoria ePublishing Services
will do a sign-off review of any print publications.
Some of the anthologies using the LEMDO platform are legacy anthologies that had been published on the old ISE platform. These legacy anthologies are the
ISE, QME, and DRE projects. UVic has tasked LEMDO with fulfilling the outstanding
obligations of the former ISE Inc. Others are new anthologies that have negotiated with LEMDO and UVic to use the platform
(e.g., MoMS). Still others are legacy projects from other sources (e.g., EMDP, CWBJO).
There is information for both types of anthologies on the LEMDO site. See Legacy Projects and Propose Anthology.
Consistency and Customization
The point of LEMDO is to provide an encoding and editing platform that can be used
by scholars across our field to prepare editions of early modern dramatic works (and
sometimes other types of works). The advantage of consistency is that editions prepared
on the LEMDO platform are interoperable and, ultimately, re-combinable into new anthologies
if all parties agree. Therefore, the TEI tagset and encoding protocols must be consistent
across all anthologies.
Some features are customizable. As anthology lead, you will write your own About pages and create your own menus. You may customize the look and brand of your anthology’s
collection of static HTML pages (i.e., your website) using an anthology-specific Cascading
Style Sheet (CSS). You have some control over the behaviours of things like pop-ups
via an anthology-specific JavaScript file.
Style Guidelines
LEMDO has worked closely with the Coordinating Editors of Digital Renaissance Editions on the preparation of the DRE Editorial Guidelines, which contain a set of style
guidelines. LEMDO’s encoding guidelines are designed to realize the editorial principles
of those guidelines. We advise new anthologies to adopt the DRE Editorial Guidelines.
You are, however, welcome to create and follow your own style guidelines for your
About pages, edition critical paratexts, and edition apparatus should you so choose. You
are responsible for ensuring that your anthology and your editors follow your style
guidelines.
There are a few style matters that must be consistent across all anthologies using
the LEMDO platform, including the way that sources are cited. All anthologies share
a LEMDO-wide bibliography. These matters are set out in Style Guidelines for Anthologies.
Anthology-Level Editorial Decisions
If you choose to write your own editorial guidelines, they must be achievable through
the LEMDO encoding guidelines. For example, LEMDO does not currently offer support
for versioned editions or extended variants, so you cannot require those of your editors.
LEMDO has a set of annotation types that you must follow. If you wanted to add a new
annotation type, you would have to submit a feature request to LEMDO before making
this type of annotation required of your editors. You will want to consult with the
LEMDO project leads before you finalize your editorial guidelines.
LEMDO has anticipated a number of points on which anthologies will want some latitude.
These points are flagged throughout the documentation with phrases like Check with your anthology lead. Pages with such phrases also have metadata that ensures they show up in a search
for documentation pitched at anthology leads.
Workflow to Get Started with LEMDO
Before you can begin your working on your anthology pages, you (or your delegate,
such as a Research Assistant) must take the following steps to be set up to work with
LEMDO’s technologies:
Read this page.
Email the LEMDO team to receive more detailed instructions on getting started and to set up an initial
training meeting.
Apply for a UVic affiliate ID and a NetLink ID if you are not at UVic. For information
on how to do so, see Get a NetLink ID.
Send us your NetLink ID. (UVic students, staff, and faculty: your NetLink ID is your
UVic email handle.)
Send us a bio-bibliographical note for our list of contributors. At this point, we will create an xml:id for you and send it to you.
Install Oxygen (the application that we use to edit XML). Read Install Oxygen.
Do a test commit with a LEMDO team member.
Familiarize yourself with the standard command line workflow that you will follow
each work session. Read Workflow for Working in the Command Line (Terminal). We recommend bookmarking that documentation page; you will want to refer to it frequently
as you encode.
Once you have gotten set up to work in the repository, you will likely follow this
workflow:
Ask the LEMDO team to create a directory for your anthology in the LEMDO repository.
Write and encode your anthology About pages.
Decide how you want to customize the look and functionality of your anthology.
Customize your anthology, including adding images, uploading a logo, updating your
navigation bar, and specifying anthology colour scheme. Depending on what you wish
to customize and your technical expertise, you may need to hire a front-end developer
to work with you at this stage.11
Decide which editions and anthology pages you will include in your first anthology
release.
Arrange for peer-review of editions and your anthology as needed.
Work with the LEMDO project manager to set up workflows leading up to your first release.
Work with the LEMDO team to publish a static, numbered release of your anthology.
Note that you will continue adding pages and editions in iterative releases until
your anthology is complete.
Supporting Your Editors’ Workflow
You will need to support your editors as they move through the LEMDO editorial and
encoding workflows. Please familiarize yourself with our Documentation Index so that you can direct editors to the appropriate documentation as required.
We recommend that you work through the items below in the order they are listed.
Skim through the entire chapter on Editions and Licensing so that you understand the relationship between editions and anthologies. You will
want to return to this chapter often.
If you are going to be using the platform yourself (as opposed to delegating the oversight
of encoding to other team members), read through The LEMDO Platform.
Familiarize yourself with the table of contents for the documentation so that you
are ready to support your editors as they move through the editorial workflow. See
Documentation Index.
Practice searching the documentation. You can quickly search for all documentation
that has been written specifically for anthology leads by going to the search page
and selecting Documentation from the Document Types menu and Anthology Lead from the LEMDO Target Audience menu.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typical encoding workflow described
in Typical Workflow for Editors, starting with semi-diplomatic transcriptions and ending with critical paratexts.
Quickstart for Research Assistants Working in HCMC
This documentation is for Research Assistants who are working in the Humanities Computing and Media Centre (HCMC) at the University of Victoria. It will introduce you to the expectations for
working in HCMC and to working on a Linux operating system (all workstations in HCMC
use Ubuntu, an open-source Linux distribution). It will also direct you towards further
helpful documentation.
The Humanities Computing and Media Centre supports LEMDO by hosting our websites,
providing developer support, and allowing LEMDO RAs to work in their collaborative
workspace. If you are working at UVic, you will attend team meetings in HCMC and may
book a workstation to complete your LEMDO work on campus.
Book a Workstation in HCMC
You are responsible for booking your workstation in HCMC. Email the HCMC administrative assistant to book regular workstation times at the beginning of each semester and to book extra
sessions if/as you need them. If, for any reason, you are unable to come into HCMC
when you are booked on a workstation (e.g., you are sick), you must email the HCMC
administrative assistant to cancel your booking.
HCMC has a number of workstations. When they book you in, the HCMC administrative
assistant will assign you to a specific workstation and tell you the name of that
workstation. Each workstation’s name is printed on a label; check the labels to make
sure you are in the correct spot. If you are uncertain of which workstation you are
booked on for a specific day, you can check the booking calendar to see where and when you are booked in. You do not have permissions to edit the
calendar yourself.
Work on One of HCMC’s Linux Workstations
If you have never worked on a Linux computer before, you may find the experience of
working on one of HCMC’s computers slightly different from what you are used to. If
you have questions about how to use the computer, please ask one of the HCMC staff.
Additionally, if there is an issue with your computer or its accessories (keyboard
and mouse), please let the HCMC staff know.
Log into an HCMC Computer
You must use your NetLink ID and password to log into any HCMC computer. Logging into
an HCMC computer with your NetLink ID will create a user for you on that machine.
Although you may save files to your user profile on an HCMC computer, remember that
they are not private computers and that you should not save any private or personal
information on them.
Use Teams in HCMC
You will need to use the Microsoft Teams web app when working in HCMC. When you click
on the web browser icon on an HCMC computer, it will automatically open a Firefox
browser. Microsoft Teams is not fully compatible with Firefox on Linux (you cannot
open or edit files when using Teams in Firefox on Linux), so we recommend you open
Teams in a Microsoft Edge browser instead. To open Edge on an HCMC computer:
On your desktop, right-click the web browser icon.
Select Edge.
Edit Documents in HCMC
The HCMC computers do not have the Microsoft Office suite of apps downloaded. If you
need to edit a non-XML document (e.g., a .docx file or a .xlsx spreadsheet), you can
either use LibreOffice (which is an installed app that works similarly to Office apps)
or use Microsoft’s web applications in your browser.
Use Terminal on a Linux Machine
There are a few ways in which Terminal differs on a Linux machine compared to either
Mac or Windows:
You must use the correct case for directory names when changing directories (e.g.,
you must use the command cd data/BIBL1 rather than cd data/bibl1).
To copy text in Terminal, simply highlight it with your mouse. The Ctrl+C keyboard
command does not work in Terminal on Linux.
To paste text in Terminal, click the scroll wheel on your mouse. The Ctrl+V keyboard
command does not work in Terminal on Linux.
Access the LEMDO Repository from an HCMC Computer
You will need to check out the LEMDO repository on each HCMC workstation that you
work at. You may also need to re-check out the repository on a workstation that you
have previously worked at after the HCMC staff update their computers.
If you are unsure whether or not you have checked out the repository on the computer
that you are working on, open Terminal and run the command cd lemdo. If it shows that you are in the lemdo directory, you have previously checked out the repository and should run svn up before working in Oxygen. If it returns the message No such file or directory, you must check out the repository following the instructions in Check Out the LEMDO Repository.
When you commit your files back to the shared LEMDO repository from an HCMC computer,
you will always be required to input your NetLink username and password. Make sure
that you either remember your NetLink ID and password (the same username and password
that you use to sign into your online tools on the UVic website) or that you have access to them when you work in HCMC.
End Your Work Session in HCMC
At the end of your work session in HCMC, make sure that you commit your work following
the instructions in Commit Changes to the LEMDO Repository. You can then sign out of the computer
If you have modified the workstation in any way (e.g., plugged in your own keyboard),
ensure that you return it to the state that it was in when you arrived.
This documentation is for new-to-the-team remediators, including those who have done
TEI encoding on other projects. Now you are taking on the task of remediating texts
that were encoded in another markup language before being programmatically converted
to a rough version of LEMDO’s TEI customization. This documentation will introduce
you to remediating texts for LEMDO and the typical workflow for remediating an edition.
It will also direct you towards further helpful documentation.
The LEMDO project has been tasked by UVic to republish (or, in some cases, publish
for the first time) editions that were under contract with LEMDO’s predecessor, the
Internet Shakespeare Editions (ISE). Our remit includes the remediation of plays that were part of the ISE anthology
itself, and those plays prepared for the Digital Renaissance Editions and Queen’s Men Editions anthologies that used its platform.
A vital part of this republication work is converting the edition files from the ISE’s
markup language, IML, to TEI-XML and then remediating each file so that all the files
conform to LEMDO’s customization of TEI. As a remediator, you will work on the converted
files to ensure they meet LEMDO’s encoding standards.
Over time, we have also taken on the work of converting and remediating the TEI-encoded
files created by the Text Creation Partnership (TCP) in order to provide our editors with a semi-diplomatic transcription of one
or more witnesses. The LEMDO team has become skilled at preparing these texts.
In 2026, LEMDO began remediating the TEI-encoded files of the Cambridge Works of Ben Jonson Online.
Remediation: What is It?
The Oxford English Dictionary says that remediation is the action of remedying or correcting something (OED, remediation, n. 1.). As a LEMDO remediator or remediating editor12, you will certainly be taking that action with respect to texts.
We also use the term to describe the process of taking a text produced in one medium
and reproducing it in another medium. For us, reproducing means “to produce again”. It is not our job to create exactly the same thing again.
LEMDO remediations necessarily change the text being remediated. Our remediations
entail re-encoding the text, which invites us to confront the text anew.
Conversion versus Remediation
The full remediation workflow entails programmatic conversion processes run by a developer,
followed by evaluation, correction, and tidying by a human markup editor (i.e., you
in your role as remediator).
The programmatic conversions are multi-step processes that require validation at each
step. The code for these conversions was written by developers Martin Holmes, Joey Takeda, and Tracey El Hajj. The developers run the conversions because the IML source texts have to be run through
an IML validator and iteratively corrected and converted.
As a remediator, you won’t have anything to do with the conversion processes (although
you are welcome to read more about them at Convert IML to LEMDO TEI and Convert TCP to LEMDO TEI). But, as the first person to work on the file after conversion, you are in a position
to give feedback to the developers.
If you notice that you are correcting the same problem repeatedly, flag the problem
for the LEMDO project manager or director, who will then decide if we need to build
that correction into the conversion.
If the correction is not one that we can build into the conversion, consider using
a regular expression (regex). Regex is more sophisticated than a simple find-and-replace
function; it allows you to replace one pattern with another pattern in cases where
different text nodes, attributes, or values prevent a find-and-replace. We have a
growing library of regex that we have written for LEMDO remediations. For a guide
on using regex and a list of prefabricated regex written for LEMDO remediations, see
Text Conversions with Regular Expressions.
You may also contact a senior member of the LEMDO team to request a new regex. Describe the problem carefully, providing both an example
from the text-as-converted and the end result of your intervention as remediator.
The Editor and the Remediator
As a remediator, you will need to balance the need to respect the editor’s initial
work, which was produced under a particular set of constraints at a particular point
in time, with the opportunities offered by LEMDO’s TEI encoding practices to clarify
and improve their work. In some cases, LEMDO asks you, the remediator, to be more
precise than the editor could be. Most cases are straightforward for skilled readers
of texts (a job requirement for LEMDO remediators). In other cases, you will need
to ask for help from someone with better knowledge of the edition and the work being
edited.
If the editor is still active in the profession and willing to help, we will be able
to put questions directly to the original editor. In some cases, you will be able
to correspond with the editor yourself, after the LEMDO director makes an email introduction.
In other cases, you’ll be asked to put questions to the LEMDO director or project
manager first for triage and forwarding.
If we are not able to call upon the editor, then the anthology lead(s) will answer
questions for us. In some cases, the LEMDO director (who is an editor herself and
has editorial roles with a number of the LEMDO anthologies) will make a judgement
call.
The bottom line is that it is not your job to re-edit the text. You will not change
an established modern text, revise a critical paratext (including annotations), or
add any new information. You may ask questions, flag errors, make suggestions, and
make those minor corrections that are within your remit. But you will always keep
in mind that you are remediating someone else’s scholarly work.
Remediating Editor
In some cases, the remediator (usually an established scholar or a senior graduate
student) makes such significant contributions and corrections to the edition that
they come to play the role of remediating editor. Remediators have become remediating
editors under various circumstances: (1) the original editor is deceased, (2) the
semi-diplomatic transcription was never checked or corrected by an editor and the
remediator takes on a critically significant role, or (3) the original editor empowers
the remediator to take on a bigger role.
Adding your Change Elements
Other than tracking your daily work via the
<revisionDesc>
, you will not normally need to intervene in the
<teiHeader>
. The work of checking the metadata in the
<teiHeader>
falls to the LEMDO director in consultation with the editors and the anthology leads,
usually just before the edition is released.
As a remediator, you will receive credit for your work on files in the edition via
the responsibility statements in the edition page. You leave a record of your contributions
to each file via the
<change>
elements in the
<revisionDesc>
of the file. Change elements are the primary mechanism for you to track your work,
and the only permanent, publicly available encoded record of your contributions to
a file.
Once you have gotten set up to work in the repository, you will likely follow this
workflow for remediating an edition:
Bibliography: This ensures that all the editor’s sources are in our sitewide bibliography
and that we can point to their citations from all their other files.
General introduction: If you are new to the play, you may want to turn your attention
next to the critical paratext that offers a general introduction to the play. This
file might be called Critical Introduction,General Introduction, or Introduction. Encoding this file will give you a chance to read something about the play before
you have to encode the text of the play.
Character list and speech prefixes: The character list goes in the
<teiHeader>
of the modernized text file.
The rest of the modernized text: If there is more than one modernized text (as is
the case for multi-text plays like Hamlet, Henry V, and others), consult with the Director about which one is the best classroom text
to determine the remediation priority.
Annotations: You may switch to other critical paratexts when/as you need a break from
annotations.
Remainder of the critical paratexts.
Collations.
Semi-diplomatic transcription(s): Consult with the LEMDO Director before you embark
on the semi-diplomatic transcription(s). We are choosing to defer some of these remediations
in order to get all of the modernized texts into usable form for teachers and students.
Note that the order of remediation is different from the order of editing. Editors
begin by preparing or proofing the semi-diplomatic transcription. Then they may choose
to either do the collation of early editions or modernize the text.
You will find all documentation specific to remediators in Chapter 24. Conversions and Remediation. You can also quickly search for all documentation that has been written specifically
for remediators by going to the search page and selecting Documentation from the Document Types menu and Remediator from the LEMDO Target Audience menu.
Quickstart for Developers
This documentation is for developers working on a specific LEMDO anthology. It will
introduce you to the development side of the LEMDO project, list LEMDO’s technical
requirements specific to developers, and direct you towards further helpful documentation.
Introduction
Although all LEMDO anthology websites have full functionality and a standard style
without any intervention, all anthology’s are required to make some customizations
such as updating their top navigation bar and adding a logo. Additionally, some may
choose to further customize their look and feel by customizing their anthology-specific
HTML, CSS, and JavaScript. As an anthology’s developer, you will be doing this front-end
work. Discuss with your anthology lead which aspects of your anthology you will be
customizing. LEMDO’s programmers do the back-end work for all anthologies.
Developing with Endings Principles
LEMDO is an Endings-compliant project, meaning that our websites are designed to be
stable and to last. Your customization of your anthology’s site must follow the Endings Principles for Digital Longevity. We recommend reading through the principles before you start work.
Technical Requirements for Anthology Developers
All people working in the LEMDO Subversion repository require:
Before you can begin your work developing, you must get set up to work in the LEMDO
repository. You should also complete some additional training tasks. To get started
working as a LEMDO developer:
Read this page.
Email the LEMDO team to get more detailed instructions for getting started and to set up an initial training
meeting.
Apply for a UVic affiliate ID and a NetLink ID if you are not at UVic. For information
on how to do so, see Get a NetLink ID.
Send us your NetLink ID. (UVic students, staff, and faculty: your NetLink ID is your
UVic email handle.)
Send us a bio-bibliographical note for our list of contributors. At this point, we will create an xml:id for you and send it to you.
If you will be working on any of your anthology’s XML files, install Oxygen (the application
that we use to edit XML). Read Install Oxygen.
Do a test commit with a LEMDO team member.
Familiarize yourself with the standard workflow in your command line that you will
follow each work session. Read Workflow for Working in the Command Line (Terminal). We recommend bookmarking that documentation page, as encoders refer to it frequently.
Additionally, we have some internal documentation that we can share with you. Write
to the LEMDO team to ask for an email introduction to an experienced LEMDO developer or designer.
You can quickly search for all documentation that has been written specifically for
developers by going to the search page and selecting Documentation from the Document Types menu and Developer from the LEMDO Target Audience menu.
Notes
1.This affordance is what makes citation managers able to output references in multiple
styles, for example. There’s underlying markup that identifies the components of a
bibliography entry so precisely that the information can be restyled as needed simply
by writing rendering instructions for each different marked-up component.↑
2.LEMDO Project Director Janelle Jenstad, founding Lead Programmer Joey Takeda, and
current Lead Programmer Martin Holmes have all served or currently serve on the TEI
Technical Council.↑
3.It is a specific rule of the LEMDO platform that the xml:id you give to a document
and the file name by which you save the document must be the same.↑
4. Admittedly, it gets a bit murky for NISE, DRE, MoMS, and QME because Janelle Jenstad (Director of LEMDO and PI on LEMDO’s SSHRC grants) has editorial roles with those
projects (Co-Coordinating Editor for MoMS, DRE, and NISE; General Textual Editor for
QME).↑
5.LEMDO has worked closely with the Coordinating Editors of Digital Renaissance Editions
on the preparation of the DRE Editorial Guidelines. LEMDO’s encoding guidelines are designed to realize the editorial principles of those
guidelines. LEMDO strongly encourages new anthologies to adopt the DRE Editorial Guidelines. Any editor using the LEMDO platform to prepare an edition that has not yet been accepted
by an anthology must follow the DRE Editorial Guidelines.↑
6.Some ISE editors have passed away, retired, withdrawn their work, or chosen to pass
their editorial work on to other editors.↑
7.Shakespeare’s Life and Times is undergoing extensive revision by Kate McPherson; the first release of entries has been published at https://lemdo.uvic.ca/emeeas a standalone anthology called Early Modern England Encyclopedia.↑
8.If the editor is deceased, retired, no longer in academia, or unable to proofread,
then the anthology leads take on the proofreading role↑
9.To be clear, if you complete an edition in IML and wish to embark on a new edition,
you must do so in TEI. LEMDO will not accept any new editions encoded in IML.↑
10.We never copy-and-paste directly from Word into Oxygen as doing so can introduce text
and formatting errors that are very difficult and time consuming to locate and correct.↑
11.Please do not hire an inexperienced developer. Student and newly graduated developers
will make more work for LEMDO. If you have funds, we can match you up with a freelance
developer who understands LEMDO well.↑
12.In a few cases, the work of remediation is so extensive that the remediator (usually
a senior LEMDO team member) is in the position of making editorial decisions, especially
when the original editor is no longer available to provide direction.↑
Prosopography
Chloe Mee
Chloe Mee (she/her) worked as a research assistant with the LEMDO team over several
periods from 2022 to 2025. She graduated from the University of Victoria in 2025 with
a BA (Hons with distinction) in English. She will be studying at the University of
British Columbia to complete her MA in English. Chloe collaborated with the LEMDO
team on a VKURA internship in summer 2022, mainly focusing on Hamlet quartos. Following
her internship, she also worked as a research assistant in 2022–23 and 2025.
Isabella Seales
Isabella Seales is a fourth year undergraduate completing her Bachelor of Arts in
English at the University of Victoria. She has a special interest in Renaissance and
Metaphysical Literature. She is assisting Dr. Jenstad with the MoEML Mayoral Shows
anthology as part of the Undergraduate Student Research Award program.
Janelle Jenstad
Janelle Jenstad is a Professor of English at the University of Victoria, Director
of The Map of Early Modern London, and Director of Linked Early Modern Drama Online. With Jennifer Roberts-Smith and Mark Beatrice Kaethler, she co-edited Shakespeare’s Language in Digital Media: Old Words, New Tools (Routledge). She has edited John Stow’s A Survey of London (1598 text) for MoEML and is currently editing The Merchant of Venice (with Stephen Wittek) and Heywood’s 2 If You Know Not Me You Know Nobody for DRE. Her articles have appeared in Digital Humanities Quarterly, Elizabethan Theatre, Early Modern Literary Studies, Shakespeare Bulletin, Renaissance and Reformation, and The Journal of Medieval and Early Modern Studies. She contributed chapters to Approaches to Teaching Othello (MLA); Teaching Early Modern Literature from the Archives (MLA); Institutional Culture in Early Modern England (Brill); Shakespeare, Language, and the Stage (Arden); Performing Maternity in Early Modern England (Ashgate); New Directions in the Geohumanities (Routledge); Early Modern Studies and the Digital Turn (Iter); Placing Names: Enriching and Integrating Gazetteers (Indiana); Making Things and Drawing Boundaries (Minnesota); Rethinking Shakespeare Source Study: Audiences, Authors, and Digital Technologies (Routledge); and Civic Performance: Pageantry and Entertainments in Early Modern London (Routledge). For more details, see janellejenstad.com.
Joey Takeda
Joey Takeda is LEMDO’s Consulting Programmer and Designer, a role he assumed in 2020
after three years as the Lead Developer on LEMDO.
Kate LeBere
Project Manager, 2020–2021. Assistant Project Manager, 2019–2020. Textual Remediator
and Encoder, 2019–2021. Kate LeBere completed her BA (Hons.) in History and English
at the University of Victoria in 2020. During her degree she published papers in The Corvette (2018), The Albatross (2019), and PLVS VLTRA (2020) and presented at the English Undergraduate Conference (2019), Qualicum History
Conference (2020), and the Digital Humanities Summer Institute’s Project Management
in the Humanities Conference (2021). While her primary research focus was sixteenth
and seventeenth century England, she completed her honours thesis on Soviet ballet
during the Russian Cultural Revolution. She is currently a student at the University
of British Columbia’s iSchool, working on her masters in library and information science.
Kate McPherson
Kate McPherson is Professor of English and Honors Program Director at Utah Valley
University (Orem, UT, USA). In 2015, she began working to redevelop Shakespeare’s Life and Times, created by Michael Best, into the Early Modern England Encyclopedia. Her other publications include commentary on Pericles and The Comedy of Errors for the New Oxford Shakespeare (2016); the co-edited volumes Stages of Engagement: Drama and Religion in Post-Reformation England with James Mardock (Duquesne University Press, 2014) and Shakespeare Expressed: Page, Stage, and Classroom in Shakespeare and His Contemporaries, with Kathryn M. Moncrief and Sarah Enloe (Fairleigh Dickinson University Press,
2013). With Kathryn M. Moncrief, Kate has also two edited collections, Performing Pedagogy in Early Modern England: Gender, Instruction, and Performance (Ashgate, 2011) and Performing Maternity in Early Modern England (Ashgate 2008). She has also published numerous articles on early modern maternity
in scholarly journals. Kate participated in the 2008 National Endowment for the Humanities
Institute, Shakespeare’s Blackfriars: The Study, the Stage, the Classroom, at the American Shakespeare Center. She also served as Play Seminar Director, a public
humanities position, for the Utah Shakespeare Festival in 2017 and 2018.
Kim Shortreed
Kim is a PhD Candidate in Media Studies and Digital Humanities, through UVic’s English
Department. Kim has worked for years in TEI and XML, mostly through the Colonial Despatches
website, and in a number of roles, including technical editor, research and markup,
writing and editing, documentation, and project management. Recently, Kim worked with
a team of Indigenous students to find ways to decolonize the Despatches project’s content and encoding practices. Part of Kim’s dissertation
project, Contracolonial Practices in Salish Sea Namescapes, is to prototype a haptic map, a motion-activated topography installation that plays audio clips of spoken toponyms,
in SENĆOŦEN and English, of the W̱SÁNEĆ Territory/Saanich Peninsula, respectively.
Mahayla Galliford
Project manager, 2025-present; research assistant, 2021-present. Mahayla Galliford
(she/her) graduated with a BA (Hons with distinction) from the University of Victoria
in 2024. Mahayla’s undergraduate research explored early modern stage directions and
civic water pageantry. Mahayla continues her studies through UVic’s English MA program
and her SSHRC-funded thesis project focuses on editing and encoding girls’ manuscripts,
specifically Lady Rachel Fane’s dramatic entertainments, in collaboration with LEMDO.
Martin Holmes
Martin Holmes has worked as a developer in the UVic’s Humanities Computing and Media
Centre for over two decades, and has been involved with dozens of Digital Humanities
projects. He has served on the TEI Technical Council and as Managing Editor of the
Journal of the TEI. He took over from Joey Takeda as lead developer on LEMDO in 2020.
He is a collaborator on the SSHRC Partnership Grant led by Janelle Jenstad.
Michael Best
Michael Best is Professor Emeritus at the University of Victoria, BC. He founded the
Internet Shakespeare Editions in 1996, and was Coordinating Editor until 2017, contributing two editions to the
ISE: King John and King Lear (the latter also available in print from Broadview Press). In print, he has published editions of works of Elizabethan magic and huswifery,
a collection of letters from the Australian goldfields, and Shakespeare on the Art of Love (2008). He contributed regular columns for the Shakespeare Newsletter on Electronic Shakespeares, and has written many articles and chapters for both print and online books and journals,
principally on questions raised by the new medium in the editing and publication of
texts. He has delivered papers and plenary lectures on electronic media and the Internet Shakespeare Editions at conferences in Canada, the USA, the UK, Spain, Australia, and Japan.
Navarra Houldin
Training and Documentation Lead 2025–present. LEMDO project manager 2022–2025. Textual
remediator 2021–present. Navarra Houldin (they/them) completed their BA with a major
in history and minor in Spanish at the University of Victoria in 2022. Their primary
research was on gender and sexuality in early modern Europe and Latin America. They
are continuing their education through an MA program in Gender and Social Justice
Studies at the University of Alberta where they will specialize in Digital Humanities.
Nicole Vatcher
Technical Documentation Writer, 2020–2022. Nicole Vatcher completed her BA (Hons.)
in English at the University of Victoria in 2021. Her primary research focus was women’s
writing in the modernist period.
Rylyn Christensen
Rylyn Christensen is an English major at the University of Victoria.
Tracey El Hajj
Junior Programmer 2019–2020. Research Associate 2020–2021. Tracey received her PhD
from the Department of English at the University of Victoria in the field of Science
and Technology Studies. Her research focuses on the algorhythmics of networked communications. She was a 2019–2020 President’s Fellow in Research-Enriched
Teaching at UVic, where she taught an advanced course on Artificial Intelligence and Everyday Life. Tracey was also a member of the Map of Early Modern London team, between 2018 and 2021. Between 2020 and 2021, she was a fellow in residence
at the Praxis Studio for Comparative Media Studies, where she investigated the relationships
between artificial intelligence, creativity, health, and justice. As of July 2021,
Tracey has moved into the alt-ac world for a term position, while also teaching in
the English Department at the University of Victoria.
Orgography
Digital Renaissance Editions Anthology Leads and Co-Coordinating Editors (DREC1)
Brett Greatley-Hirsch, Janelle Jenstad, James Mardock, and Sarah Neville.
“A person responsible for the creation of an anthology of editions created via the
LEMDO Platform. Anthologies may use their own internal terminology for this role,
such as General Editor or Coordinating Editor.”
Edition directory
“A directory (i.e., folder) in the LEMDO repository containing all the files for an
edition. The name of each edition directory is the abbreviation for the edition, such
as AYL for As You Like It.”
repository or repo
“The repository contains all the files in the LEMDO project. The LEMDO repository
is saved to a server in the basement of the Clearihue Building at UVic. All LEMDO
files are under version control through Subversion, a repository maintenance tool
that keeps a complete history of every change ever made to every LEMDO file.”
Subversion
“An open-source version control system that allows us to keep, track, and restore
every version of every file in the repository.”
xml:id
“A unique value that we use to tag an entity. Strictly speaking,
@xml:id is an attribute that can be added to any XML element. We use it as a shorthand for
“value of the xml:id”. Every person, role, glyph, ligature, bibliographical entry,
act, scene, speech, paragraph, page beginning, XML file, division within XML files,
and anchor has a unique xml:id value, some of which are assigned automatically during
the processing of our XML files.”
