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.
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.
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.
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.
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.
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 markup. 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 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.
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 at https://www.w3.org/TR/2008/REC-xml-20081126/. In the meantime, you’ll learn more about the basics of XML later in this Quickstart.
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
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:
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 texts 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 ſing a Song that old was ſung,
<lb type="wln" n="3"/>From aſhes, auntient Gower is come,</ab>
Empty elements can still have attributes and values, but they do not wrap around a
text node.
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,
<p>
is the parent of
<list>
because it contains the
<list>
element.
<list>
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>
.
<item>
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> <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.
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.
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 begin 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.
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.
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
This page is for new encoders. You may be an Editor who is encoding a play for the
first time. You may be a Research Assistant or Editorial Assistant who is helping
an Editor encode a play. This page is designed to give you an overview of what it
means to be an encoder, a list of things you need to do to start encoding, and links
to more advanced information.
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.
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 the Anthology
Lead. LEMDO defers to anthology leads on textual or editorial matters.
You will be adding special computer-readable tags to texts in order to say things
about the texts. This work is called encoding,tagging, or marking up a text. (See Terminology.) LEMDO uses tags devised by the Text Encoding Initiative (TEI), a widely used standard for marking up historical and literary texts. (See
What is TEI?.) When you have finished reading this page, you will want to read LEMDO’s Introduction to Markup, XML, and TEI in order to learn more about TEI and LEMDO’s tagset.
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 portfolio that contains the files for the play you are encoding. (RAs: If
you are a Research Assistant or Editorial Assistant anywhere other than at UVic, the
Editor of your play will need to contact us to confirm your role. Ask your Editor
to contact us so that we can approve your request for a UVic affiliate identity (a V00- number)
and grant you portfolio-level permissions. To request a UVic affiliate identity, see
Get a NetLink ID.)
Your portfolio, 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),
portfolio, or even the entire project. The SVN repository is like the cloud. See Work in Subversion.
Initially, you will probably work entirely in the main directory in your portfolio. The main directory is where the semi-diplomatic and modern texts of the play are stored. You
will probably start by checking, correcting, and encoding an semi-diplomatic early
version of the play: a quarto, octavo, or folio text of a play from the early modern
period. (RAs: If you do not know what these terms mean, ask the Editor of your play.)
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.
Install Subversion commands. See Access the Repository and follow the links to precise instructions for your operating system. Ask the LEMDO
team for help on this step if necessary.
You will find 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.
This page 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 is designed to give you
a list of things you need to read and do to start editing your play in the LEMDO repository,
and links to more advanced information.
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.
If you have a Research Assistant or Editorial Assistant working with you to encode
the play, we have special documentation to get them started. You will want to point
them to this page: Quickstart for Encoders. We recommend that you familiarize yourself with the type of information that we are
giving them. 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 encoding the play yourself as well as editing it, then 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 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
Once your proposal to edit a work has been approved, you’ll need to contact the LEMDO
team at UVic. Normally, your anthology lead will facilitate an introduction. You and/or
your RA will need to get set up to work in the LEMDO repository. Be ready to answer
the following questions:
What is your operating system? (Mac, PC, Linux)
Which version of the OS are you running?
Do you have an RA whom you want to have trained? If yes, what is their name and email
address?
To work on the LEMDO platform, you need to have:
UVic affiliate identity and a NetLink ID. Apply for your UVic affiliate identity by
following our instructions in Get a NetLink ID. Once you have chosen your NetLink ID, send it to lemdo@uvic.ca so that we can give you write privileges on your edition portfolio.
A LEMDO xml:id, which is your personal, unique id across the entire LEMDO project.
We will create this for you and tell you what it is. At the same time, we can add
your bio-bibliographical note to the development site if you are ready to submit one.
Sample bios are here. We can update your bio any time at your request.
Find the Terminal (command line) on your computer.
Install a Subversion client so that you can interact with our Subversion repository
(check out, commit, and update your local copy of the LEMDO repository).
Install Subversion commands. See Access the Repository and follow the links to precise instructions for your operating system. Ask the LEMDO
team for help on this step if necessary.
Introduce your RA to us via email (unless you are paying LEMDO to have a UVic RA do your encoding).
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.)
Learn about TEI. Even if you are not doing the encoding yourself, you will want to
understand what is happening to your text in the encoding stage. See Introduction to Markup, XML, and TEI.
Write critical paratexts (textual and contextual introductions, critical and performance
histories) and complete the bibliography. See the Critical Paratexts chapter.
This page 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.
We5 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.
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.
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.)
Editors who are preparing texts for the MoMS anthology (MoEML Mayoral Shows) will
not need all of the documentation. This page offers a quick guide to the sections
of LEMDO documentation you will need to encode your edition and makes some suggestions
for your workflow.
Mark and Janelle suggest the following workflow for encoding if you have already prepared
most of your edition in a word processing program or editing space:
Paste your modern text into the modern template file that Janelle will make for you.
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.
Create your edition bibliography.
Add the texts you are collating to your edition bibliography and to your collation
file (you will probably want help from LEMDO HQ with this task).
Encode your collations (Janelle will set up a template file for you). You will add
anchors to your modern text and point to those anchors from your collation file.
Encode your critical paratexts.
Encode your annotations (Janelle will set up a template file for you). You will add
anchors to your modern text and point to those anchors from your annotation file.
You may use the anchors you added for your collations if the anchor happens to be
in the right place. If the text of your annotations directs readers to your critical
paratexts, you may make a link to your critical paratexts.
Finalize links between pieces of the edition if/as necessary.
If you are beginning your edition directly in TEI, follow the above workflow with
the following exception:
Ask Janelle and the LEMDO team to prepare a template file for your modern text from the MoEML semi-diplomatic transcription.
The file will have the semi-diplomatic text with the basic tagging for your modern
text in place.
Encode your collations before you modernize the text.
This page 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. 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.
Before you read further on this page, please familiarize yourself with our other Quickstart
guides. As Anthology Leads, you are responsible for knowing what your Editors and
Editorial Assistants/Encoders need to do. Bookmark the following pages and send them
to your Editors and team members.
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.
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 customization. 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.
You are welcome to create and follow your own style guidelines for your About pages, edition critical paratexts, and edition apparatus. You may also choose to
adopt the DRE Style Guidelines. You are responsible for ensuring that your anthology and your editors follow your
chosen style guidelines.
However, 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.
We strongly recommend that you adopt the DRE Editorial Guidelines, which have been
written with knowledge of the LEMDO encoding protocols. 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.
For example, anthologies may choose to do a semi-diplomatic transcription of semi-diplomatic
texts or an in-type facsimile transcription. LEMDO will support either. It is up to
you to decide how far you want your editors to go in representing the bibliographical
and typographical features of the witness. This point and others 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.
Skim through the entire chapter on Editions and Anthologies so that you understand
the relationship between editions and anthologies. You will want to return to this
chapter often. See Editions and Anthologies.
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.
This document presupposes that you are working on a Linux operating system (e.g.,
Ubuntu, Debian, Fedora). All workstations in HCMC use Ubuntu, an open-source Linux
distribution.
This document contains instructions for getting set up to work in the Subversion repository. It is meant primarily for new LEMDO team members at UVic, but may also be useful
to RAs and editors elsewhere.
If you are unsure whether or not you have checked out the repository on the computer you are working on (and it is common to be unsure if you are in HCMC
working on various machines), follow these steps:
Tell you that there is No such file or directory
. If Terminal tells you there is no such file or directory, you need to check out the repository to your computer. Go to First Checkout and follow the steps.
Type cd lemdo into Terminal and press Enter. Terminal should now show that you are in the lemdo directory. If it says No such file or directory (which may be the case if HCMC has wiped the computers, which they do from time to
time), go to First Checkout and follow the steps. Once you are in the lemdo directory, follow these steps:
Type svn up and press Enter
You should see one of two messages:
Updated to revision followed by the number of the revision (this message will appear if files in the
repository have been modified since you last did an svn update)
At revision followed by the number of the revision (this message will appear if no files have
been modified since you last did an svn update)
In the top left corner of your Oxygen window, there is an icon that looks like a blue floppy disk. This is the save button.
Click it to save your work.
Validating your file against the LEMDO schema determines whether your file has any
errors that need to be corrected before you commit the file to the repository. If Oxygen shows that your file has errors, you must fix them before committing the file. There
are three ways to validate your file:
In the Oxygen toolbar, there is an icon that looks like a piece of paper with a red check mark
on it. This the validate button. Click it to validate your file.
In the window that pops up, navigate the lemdo folder and open it (if it is not already
open)
Click lemdo-all.xpr and then click Open to open the project file
On the left of your Oxygen window, you should now see the lemdo folder. You can click to open it and view the
sub-folders within it.
If you would like to enable line wrap so lines of text do not stretch outside of the
Oxygen window, follow these instructions:
Click Options, then Preferences
In the window that pops up, click Appearance
Click Text
Check the box next to Line wrap
Click OK
¶ If you have opened the LEMDO project in Oxygen on this computer before:
Make sure the LEMDO project file (lemdo-all.xpr) is open in Oxygen. If you open Oxygen and the lemdo folder and sub-folders are visible on the left side of the Oxygen window, then lemdo-all.xpr is already open. You can begin working.
Using the cd command in Terminal, navigate to the directory that contains the file you were working on
Once you are in the correct directory, type svn commit –m followed by a quotation mark, then type a short message describing the work you did
in the file (e.g., “remediated quotations”, “tagged titles”), followed by a period
and a closing quotation mark.
The first step to ending your work session is saving the file you are working on.
See How to save your file in Oxygen: for instructions on how to save files.
This command will show you which files you have modified. It is handy for cases where
you have worked on several files and cannot remember exactly which files you modified.
Once all the files you have worked on have been saved and validated successfully, you can close Oxygen.
You should now see the file path indicating the directory that your file is in (and the directories containing that directory). To commit the file, you will need to move into the directory that contains the file you are trying to commit.
It is helpful to think of directories like Russian nesting dolls. There is the outermost
doll (the lemdo directory) that contains all the others. Within that doll are smaller dolls that contain even
smaller dolls. Our hierarchy of directories works much the same, although we often
have several directories that are at the same level in the hierarchy (which would
be like having two nesting dolls that are the same size, each of which contains smaller
dolls). File paths visualize this nesting by having the outermost directory on the far left. Each step down in the hierarchy is shown by a / and the name of
the directory.
For example, if we have the file pathlemdo/data/texts then the directory called “texts” is at the third level of the hierarchy. Using Terminal, you can move into and out of directories by using the cd command. If you are in the lemdo directory and you enter cd data into Terminal, Terminal will show that you are now in the data directory. If you enter cd ../ into Terminal, it will show that you have moved back into the lemdo directory. Entering cd ../ into Terminal moves you out of the current directory and into the directory one level back in the hierarchy.
Using the cd command in Terminal, navigate to the directory that contains the file you were working on
Once you are in the correct directory, type svn commit –m followed by a quotation mark, then type a short message describing the work you did
in the file (e.g., “remediated quotations”, “tagged titles”), followed by a period
and a closing quotation mark.
Press Enter
Example of an SVN commit message:
svn commit –m "remediated quotations."
Terminal should say Committed revision followed by the number of the revision. This means that you have successfully committed
your file. Above that message you can see the files that were committed, so you can
confirm that the correct file was committed.
Once you commit all the files you worked on, you can close Terminal and log off or shut down the computer. At the start of your next work session, go
to Scenarios: Accessing the Repository to get started again.
Remember when you are reading through documentation that you need to ask questions
and draw attention to aspects you don’t understand. You are not supposed 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 modern
texts generally. When you ask questions, you are clarifying for yourself and helping
to make the documentation clearer for future RAs.
This page is for new-to-the-team remediators. You may 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.
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.
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 the Anthology
Lead. LEMDO does not provide textual or editorial advice. Ask the project director
to be connected with the Editor of a play.
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.
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 regex (regular expression). 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 the current Conversion Editor 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 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.
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:
Editions consist of various documents. The most logical pathway through a remediation
is as follows:
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 modern text file.
The rest of the modern text: If there is more than one modern 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 modern 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 text. Then they may choose to either
do the collation of early editions or modernize the text.
The next piece of documentation you will want to read is Remediation Pathways, which describes the various types of files we remediate, why we remediate them, where
they came from, what type of content they contain, and brief notes on special treatments.
Once you begin remediating, use the following section of this page to help you find
the right documentation to guide you through the specific remediation processes required
for the file you are remediating.
¶ Links to Documentation on Specific Remediation Processes
Every type of file we remediate has unique challenges. We have therefore created documentation
for various remediation processes, listed in the order you will need them if you follow
the remediation order listed above:
All of this documentation is contained in the Remediations chapter of the LEMDO documentation. Most of it contains links to the regular LEMDO
documentation, where you’ll find more information on how to encode an early modern
play and all the components of an edition thereof. On all matters not covered by the
Remediation Documentation, your job is to bring the edition being remediated in line
with LEMDO’s general encoding and editorial practices.
You will also need to be aware of the general encoding guidelines that pertain to
various types of texts, including but not limited to:
There is no such thing as a Quickstart for developers. To become a developer, you
need a long apprenticeship with a lead developer.
But if you already are a developer or web designer, you’ll find documentation written
by developers for developers in Chapter 21. Programming. We also have some internal documentation that we can share with you. Write to the
LEMDO Director (lemdo@uvic.ca) to ask for an email introduction to an experienced LEMDO developer or designer.
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 grant) 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.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.↑
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.↑
Prosopography
Chloe Mee
Chloe Mee is a research assistant on the LEMDO team who is working as a remediator
on Old Spelling texts. She is about to start her second year at UVic in Fall 2022
and is pursuing an Honours degree in English. Currently, she is working on the LEMDO
team through a VKURA internship. She loves literature and is enjoying the opportunity
to read and encode Shakespeare quartos!
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 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.
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.
Navarra Houldin
Project manager 2022–present. Textual remediator 2021–present. Navarra Houldin (they/them)
completed their BA in History and Spanish at the University of Victoria in 2022. During
their degree, they worked as a teaching assistant with the University of Victoriaʼs
Department of Hispanic and Italian Studies. Their primary research was on gender and
sexuality in early modern Europe and Latin America.
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.
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.”
directory
“Another word for folder.”
file path
“A list of nested directory names separated by slashes. It is a way of showing directories
nested within other directories (e.g., lemdo/data/texts).”
Oxygen
“The application that we use to encode and edit LEMDO’s XML files.”
Portfolio
“A directory (i.e., folder) in the LEMDO repository containing all the files for an
edition. The name of each portfolio 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.”
revision number
“A number that indicates the most recent version of the repository. The revision number
goes up by 1 with every SVN commit.”
Subversion
“An open-source version control system that allows us to keep, track, and restore
every version of every file in the repository.”
svn checkout
“A Terminal command used to download a copy of the entire LEMDO repository to your
local computer.”
svn update
“A Terminal command used to sync your local copy (the one on your workstation’s computer)
of any LEMDO files on the LEMDO repo.”
Terminal or command line
“The program on your computer that allows you to navigate through your directories
and make changes to the files therein.”
validate
“The process you run in Oxygen to check files for errors.”
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.”
