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)?
Ask the LEMDO director (lemdo@uvic.ca) to facilitate an email introduction to an experienced LEMDO developer and/or designer.
Introduction to Markup, XML, and TEI
Introduction
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 typcial 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 new LEMDO editors. 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, ISE, or QME). You may be an experienced editor who is encoding a play for the first time. You may be a new editor who has 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 will direct you towards further
helpful 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 for publication
online, in PDF form, and, in some cases, as part of the printed LEMDO Hornbooks series. As a LEMDO editor, you will edit your edition according to your anthology’s
editorial guidelines and you will either encode your own work or will hire somebody
else 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 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 we are giving them as well. 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, ISE, 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 your work editing, you must get set up to work with LEMDO:
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 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 send us a bio-bibliographical
note to add to our list of contributors. We will also assign them an xml:id.
Additionally, if you are encoding your own 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.
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 is correct. 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 for use in your edition.
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 the modernized text of your play and check in with your anthology lead.
Modernize your play.
Write the remainder of your annotations.
Write your critical paratexts as 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 typcial 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.
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 on 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 get more detailed instructions for 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 send us a bio-bibliographical
note to add to our list of contributors. We will also assign them an xml:id.
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.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typcial 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 Repository Users
Introduction
This page is for anyone who is working on files in the LEMDO subversion repository,
including encoders, remediators, developers, designers, anthology leads, and editors
who are doing their own encoding (or correcting encoded texts). We have role-based
Quickstarts for most of these users. See Prior Reading.
Make sure you have been added to the lemdo_repo_users mailing list. You will receive
a subscription notification when we add you. Sometimes we will make changes across
all the files in the repository. In these cases, you will receive an email asking
you to commit the files you have worked on and stop working in the repo until we let
you know it is okay to continue working.
We recommend that you work through these tasks in the order listed:
Read this page.
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. If you are an Editor, email us to indicate that you are ready to begin encoding your work on the LEMDO platform.
Apply for UVic affiliate identity if you are not at UVic. See Get a NetLink ID.
When your affiliate identity is approved, make a NetLink ID and password for yourself.
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.)
Reach out to the LEMDO team for additional training on how to check out the LEMDO
repository, open the project file, and navigate to your edition directory.
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.
MoMS editions are unique on the LEMDO platform in that they do not require a semi-diplomatic
transcription, they frequently link out to the MoEML website, and their modernized texts do not typically follow the act/scene/speech division
structure common in early modern plays. As such, your workflow for completing your
edition will be slightly different from that of a non-MoMS editor. You will not need
to read our documentation on semi-diplomatic transcriptions, and you will likely need
to consult with the LEMDO team about how to encode the structure of your modernized text.
As a MoMS editor, you will edit your edition according to the MoMS Editorial Guidelines. Please direct questions about your mayoral show and editorial principles to your
anthology leads. You will either encode your own work or will hire somebody else 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 gotten set up to work in the repository, you will likely follow this
basic workflow. For editors that are working directly in TEI:
Ask Janelle to create a basic modernized file for you from MoEML’s semi-diplomatic
transcription of your mayoral show.
Collate necessary editions for 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.
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 Oxygen.8 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, Janelle likes to paste and encode the structural
elements one paragraph or one speech at a time.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typcial encoding workflow described
in Typical Workflow for MoMS Editors, though it does also include documentation for 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 (such as the Coordinating Editors of the
ISE, DRE, or MoMS, or the QME General Editors). 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 pieces of LEMDO anthologies and editions must be marked up using LEMDO’s customization
of TEI-XML before they can be published. As an anthology lead, you are responsible
for knowing what your editors, editorial assistants/encoders, and developers need
to do and for guiding them to access training, documentation, and support from the
LEMDO team when needed. To this end, we recommend that you read Quickstart for Editors,Quickstart for Encoders, and Quickstart for Developers in addition to this documentation page.
Relationship of Anthology to Platform
An anthology is an independent editorial project that chooses to use the LEMDO platform
either (1) for encoding files and generating a static HTML site, or (2) for encoding
files, generating a static HTML site, and publishing that site with the University
of Victoria. Anthologies have their own editorial and advisory boards. They are responsible
for commissioning and supporting their own editors, and, eventually, arranging for
scholarly peer review. LEMDO will do a code review, and 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). 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. 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 are necessarily consistent across all anthologies.
Some features are customizable. Anthologies write their own About pages and create their own menus. They can customize the look and brand of their
static site using an anthology-specific Cascading Style Sheet (CSS). They 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. As such, we strongly encourage 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 chosen
style guidelines.
There are a few style matters that must be consistent across all anthologies using
the LEMDO platform. 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 annotations 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
them 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 must get set up to
work with LEMDO:
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.
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:
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 developer to work
with at this stage.
Decide which editions and anthology pages you wish to include in your first anthology
release.
Work with the LEMDO project manager to set up workflows leading up to your first release.
Arrange for peer-review of editions and your anthology as needed.
Work with the LEMDO team to publish a version of your anthology. Note that you will
continue adding pages and editions in iterative releases until your anthology is complete.
In addition to this standard workflow, you will support your editors as they move
through the editorial workflow. Please familiarize yourself with our Documentation Index so that you can direct editors to the appropriate documentation as required.
You will find documentation chapters on encoding each piece of an edition in our documentation
index. The chapters are laid out to reflect the typcial 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
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.
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). This includes plays that were part of the ISE anthology itself, and part of
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 they all 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.
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 editor, 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, the Remediator, and the Remediating Editor
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, 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 them. 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 will make a judgement call.
The bottom line is that it is not your job to edit the text. You may ask questions,
flag errors, make suggestions, and make changes that are within your remit. But always
keep in mind that you are remediating someone else’s scholarly work.
In some cases, the remediator makes such significant contributions and corrections
to the edition that they come to play the role of remediating editor. The LEMDO director
will let you know if you have moved into this role perforce or if you need to move
into this role. Thus far, 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 Responsibility Statement
Most of the
<teiHeader>
has been completed by the conversion process and can be safely ignored by you. The
work of checking the metadata in the
<teiHeader>
falls to the LEMDO director in consultation with the editors and the anthology leads.
However, you still need to add a responsibility statement for yourself. At the time
of writing (November 2020), we are rethinking our current practice of having all
<respStmt>
elements as children of the
<titleStmt>
element. For now, continue to put your
<respStmt>
element under the
<titleStmt>
element as the last
<respStmt>
in the list.
The encoding for a remediator’s
<respStmt>
element is as follows:
The encoding for a remediating editor’s
<respStmt>
element uses the same elements and values. Change the wording in the text node of
<resp>
element as follows:
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 ISE, NISE, and DRE because Janelle Jenstad (Director of LEMDO and PI on LEMDO’s SSHRC PDG, Connection, and Insight grants) is
also the UVic-appointed Technical Adviser to the ISE (i.e., to editors who worked
on the old ISE platform) and is sharing the Coordinating role of the NISE and DRE
anthologies with Brett Greatley-Hirsch, James Mardock, and Sarah Neville. Generally Janelle focuses on technical and encoding matters for NISE and DRE. For
the ISE and NISE, she also maintains the records.↑
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 and will be published as a standalone anthology
called Early Modern England Encyclopedia.↑
8.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.↑
Prosopography
Brett Greatley-Hirsch
Brett Greatley-Hirsch is Professor of Renaissance Literature and Textual Studies at
the University of Leeds. He is a coordinating editor of Digital Renaissance Editions, co-editor of the Routledge journal Shakespeare, and a Trustee of the British Shakespeare Association. He is the author (with Hugh
Craig) of Style, Computers, and Early Modern Drama: Beyond Authorship (Cambridge, 2017), which brings together his interests in early modern drama, computational
stylistics, and literary history. His current projects include editions of Hyde Park for the Oxford Shirley (with Mark Houlahan) and Fair Em for DRE, a history of the editing and publishing of Renaissance drama from the eighteenth
century to the present day, and several computational studies of early modern dramatic
authorship and genre. For more details, see notwithoutmustard.net.
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.
James D. Mardock
James Mardock is Associate Professor of English at the University of Nevada, Associate
General Editor for the Internet Shakespeare Editions, and a dramaturge for the Lake
Tahoe Shakespeare Festival and Reno Little Theater. In addition to editing quarto
and folio Henry V for the ISE, he has published essays on Shakespeare, Ben Jonson, and other Renaissance
literature in The Seventeenth Century, Ben Jonson Journal, Borrowers and Lenders, and contributed to the collections Representing the Plague in Early Modern England (Routledge 2010) and Shakespeare Beyond Doubt (Cambridge 2013). His book Our Scene is London (Routledge 2008) examines Jonson’s representation of urban space as an element in
his strategy of self-definition. With Kathryn McPherson, he edited Stages of Engagement (Duquesne 2013), a collection of essays on drama in post-Reformation England, and
he is currently at work on a monograph on Calvinism and metatheatrical awareness in
early modern English drama.
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 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.
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 is the Founding
Editor of the Internet Shakespeare Editions, of which he was the Coordinating Editor
until 2017. 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.
Sarah Neville
Sarah Neville is an associate professor of English and Theatre, Film and Media Arts
at the Ohio State University. She specializes in early modern English literature,
bibliography, theories of textuality and Shakespeare in performance, chiefly examining
the ways that authority is negotiated in print, digital and live media. She is an
assistant editor of the New Oxford Shakespeare (2016-17), for which she edited five plays in both old and modern-spelling editions,
as well as an associate coordinating editor of the Digital Renaissance Editions. She
regularly publishes on textual theory, digital humanities, pedagogy, and scholarly
editing. Neville’s book, Early Modern Herbals and the Book Trade: English Stationers and the Commodification
of Botany (Cambridge, 2022), demonstrates the ways that printers and booksellers of herbals
enabled the construction of scientific and medical authority in early modern England.
A theatre director and film artist who is a great believer in experiential learning,
Neville is the founder and creative director of Ohio State’s Lord Denney’s Players, an academic theatre company that enables students to see how technologies of textual
transmission have shaped the reception of Shakespeare’s plays.
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.
Glossary
Anthology Lead
“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.”
