LEMDO: Chapter 16. Annotations

Chapter 16. Annotations

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 Annotations

¶ Rationale

Annotations are a form of critical paratext. Their purpose, length, and type will depend on the scholarly objectives and intended readership of your anthology and as well as the particular aims of your edition. In general, however, annotations serve the following purposes:

They offer information necessary for the intended reader to understand the text. For example, a student reader needs translations of non-English passages and explanatory glosses. An anthology aimed at scholars will not need to provide such glosses.

They work in tandem with the collations to offer more information about textual variants and cruces. They offer justifications for the editor’s emendations.

They point out intertextual connections, offer longer paraphrases than a gloss can offer, and identify critically controversial or ambiguous passages, citing other primary texts and secondary sources that will help the reader. The goal of such annotations is not to display the editor’s erudition or lock down a single interpretation, but rather to help the intended readership and support the scholarly objectives of the edition within the anthology. They may constitute original scholarship in their own right and may be cited by readers, critics, and future editors.

¶ Annotation Types

LEMDO’s annotation types are designed to categorize annotations by their purpose:

Notes of


                                             @type

gloss capture the editor’s translations and explanatory glosses.

Notes of


                                             @type

textual and lineation allow the editor to say more about text and emendations thereof.

Notes of


                                             @type

commentary, the most capacious category, allow the editor to comment on any aspect of the play not covered by the other categories.

Editors can use notes of


                                             @type

lexical to offer commentary on etymology or nuances of word usage, with links to the OED and/or LEME.

Anthologies can customize their interfaces to set a default view and to allow users to turn annotations on and off by type.

LEMDO also allows for two additional types of annotations:

pedagogical annotations, which can be added either by the editor or by another scholar who has experience teaching the play.

performance annotations, which can be used either to capture the results of a performance-as-research editorial process or to describe stage history.

¶ Digital and Print Views

By default, LEMDO includes all annotation types in the digital edition (the HTML pages). By default, our LaTeX processing includes only gloss and commentary notes in the print output.

Editors can also use the subtypes printOnly and onlineOnly to designate where an annotation should appear. These subtypes are useful if the editor wants to have a short commentary note in the print output and a longer version of the same note in the digital output.

Note that commentary notes longer than 225 characters are flagged by our LaTeX processing as being too long for the LEMDO Hornbooks series.

¶ Collaborative Annotation

Annotations for an edition can be written synchronously by one or more editors, or asynchronously by a later annotator. Annotations can bear a


                                       @resp

in order to give credit to multiple contributors. Pedagogical and performance annotations lends themselves particularly well to asynchronous collaboration.

¶ Anthology-Level Decisions

LEMDO supports various editorial approaches and ways of working. Consult with your anthology lead to find out which types of annotations are required for your edition, how verbose or terse your annotations should be, and how much you should be linking to other texts and resources.

¶ Categories

¶ Prior Reading

Read about the LEMDO Taxonomies: Introduction to LEMDOʼs Taxonomies

¶ Rationale

LEMDO processes different types of documents in different ways. The processor looks for the


                                          <catRef>

elements inside the


                                          <textClass>

element in the


                                          <teiHeader>

of your document and then applies the appropriate processing for the document types that are captured in the


                                          <catRef>

elements. If you document does not have


                                          <catRef>

elements, our processor will not know what type of file it is. If your document has the wrong values in the


                                       @target

attribute of the


                                          <catRef>

elements, our processor will apply the wrong processing to your file.

LEMDO has special processing for annotations. Following this documentation will ensure that your annotation file is processed correctly.

¶ Practice: Encode Categories for Annotation Files

An annotations file will have one required


                                          <catRef>

element using the value ldtBornDigParatextAnnotation.

Optionally, you can add a


                                          <catRef>

to describe the origin of the document using the LEMDO Document Histories Taxonomy. Annotation files might have come from a converted IML file. If this is the case for your file, use the appropriate value: edhSourceIML. If you have created the annotations yourself into a LEMDO XML template file, you do not need to describe the origin of the document using a


                                          <catRef>

element. Depending on your anthology’s practice, you will write brief a narrative explanation in the


                                          <sourceDesc>

element.

Note that


                                          <catRef>

is an empty element.

¶ Examples

¶ Types of Annotations

¶ Rationale

LEMDO provides for seven types of annotations. All of them will be displayed with your digital edition. Only some of them will be included in your print edition.

¶ Table of Types

`@type`	Schema Definition	Where they appear
gloss	(A glossary note) a short note that gives a short description of the term	online and print by default
commentary	(Commentary) discussion of the meaning of the text, roughly equivalent to current annotation in editions like the Arden or New Cambridge.	online and print by default. Add the `@subType` attribute with the value onlineOnly to limit to the HTML output. Add the `@subType` attribute with the value printOnly to limit to the print edition. The maximum length of a commentary note in print is currently 225 characters.
textual	(Textual note) explains textual decisions made in the present and previous editions (often paired with a collation)	online only
pedagogical	(Pedagogical note) offer teaching tips and strategies, often with links to pedagogical materials.	online only
performance	(Performance note) describes performance or production choices in specific productions named in the Production database, cited in the Performance essay, and/or made in Performance-as-Research productions that were part of the editorial process.	to be determined by anthology; online and print (QME)
lexical	(Lexical) discussions of the etymology of a word/phrase and/or its meaning and prevalence in the early modern period. Such notes will usually cite the OED and/or Lexicons of Early Modern English.	online only
lineation	(Lineation)discussion of the lineation or relineation of one or more lines in the text (often paired with a collation)	online only

¶ Annotation subtypes

When you create a


                                          <note>

with


                                       @type

=commentary, that note may be used in the web version of the play, and it may also appear in the printed published version (if there is one). However, the print document, unlike the web version, cannot be infinitely long; annotations in that version appear as footnotes, and they must be constrained to a reasonable length. Since we want to retain long annotations where we can, but we also want to provide an alternative where necessary for the print version, you can also supply the


                                       @subtype

attribute with one of these values:

onlineOnly means that the annotation should only be rendered in the HTML version, because itʼs too long for the print version.

printOnly means that this is a shorter version of the annotation intended only for the print edition; it should be ignored when building the web output.

Any annotation that does not have


                                       @subtype

will be used in both versions.

¶ Write Annotations

The annotations for the text you are annotating live in a separate file with an attribute


                                    @xml:id

: textId_annotation.xml. The annotation file is saved in the app folder of your play portfolio. If the app folder does not already contain that file, create an annotations file using the LEMDO template entitled annotations_template. (See Use LEMDOʼs Oxygen Templates.)

¶ Placing Anchors in the Source Document


                                          <anchor>

is an empty (self-closing) element whose only purpose is to be pointed at from somewhere else. It looks like this:

It has an


                                       @xml:id

attribute which starts with the id of the text containing it (here emdH5_FM), and then has _anc_ (= this is an anchor) and a number. The number has no significance except to ensure that every anchor in a document has a unique


                                       @xml:id

attribute. Numbers do not go in sequence through the document; they are assigned in the order that anchors are added, and are created automatically (see below).

A single anchor marks a specific point in the text. However, for annotation you normally need to mark a range of text, with a starting point and a finishing point. This is done simply by using two anchors:

<lg>


<l>Received the <anchor xml:id="emdH5_FM_anc_1539"/>golden earnest of<anchor xml:id="emdH5_FM_anc_1540"/> our death,</l>

</lg>

These two anchors delimit the phrase “golden earnest of”, and an annotation can use them to specify that itʼs talking about that specific phrase. Since anchors are self-closing elements, they can appear anywhere in the text, and therefore you can annotate a span of text which crosses the normal XML hierarchy if you need to. For example, you can annotate a phrase that begins in the middle of one line and ends in the middle of another.

Creating anchors manually is difficult because you canʼt easily know what the next available number for its


                                       @xml:id

will be. Therefore we use an Oxygen shortcut to insert them automatically. To insert anchors in the document you are annotating, identify the string you want to annotate, and select it with your cursor. Once the selection is made, press Control+Shift+A (on Linux or Windows computers) or Command+Shift+A (on OSX computers). This shortcut will automatically generate an


                                          <anchor>

to the left of your selection, and another to the right. Each


                                          <anchor>

has a generated attribute


                                       @xml:id

with the a unique value, as described above. You will need these anchor IDs when writing your annotation in the annotation file.

¶ Things to Avoid

When you insert anchors into the text, bear in mind that they are turned into footnote numbers in the print output. That means you should not place a single anchor or a final anchor anywhere that footnote numbers would be inappropriate or distracting. For example, if you were to place an anchor at the beginning of a


                                             <head>

element and point to it as a single locus, the result would be the appearance of a footnote number right at the beginning of a heading on the page; thatʼs distracting and problematic from the point of view of font sizing. LEMDO therefore drops anchors in such locations when we build the PDF, which may result in a missing anchor error. You will therefore want to be strategic (and even creative) if you want to offer a commentary on a heading.

¶ Writing Annotations in the Corresponding Annotation File

In the annotation file, the struture of every annotation is as follows:


                                          <note>

: the parent element that will contain all elements and content of the current annotation you are writing. Give this element an attribute


                                       @type

with a value of annotation. You also need two attributes that refer to the anchors placed in the source document. These are


                                       @target

and


                                       @targetEnd


                                       @target

will point to the left anchor on the annotated string, and


                                       @targetEnd

will point at the right anchor.

You will have to turn the


                                       @xml:id

attributes of the anchors into full pointers by specifying the target document; so when you have two anchors that look like this:

<lg>


<l>Received the <anchor xml:id="emdH5_FM_anc_1539"/>golden earnest of<anchor xml:id="emdH5_FM_anc_1540"/> our death,</l>

</lg>

you will need to point to them by prepending the doc:[docId] followed by a hash, like this:

The next element required in your annotation is a child


                                          <note>

that identifies the label, which is the string of text you want to annotate (normally referred to as the lemma). Add an attribute


                                       @type


                                          <note>

, with a value label. The content of this note is the literal string to be annotated (which, if itʼs longer than three or four words, should be abbreviated using an ellipsis). Following this are the actual


                                          <note>

s. Assign an attribute


                                       @type

with a value of gloss or commentary. Gloss corresponds to the short form and commentary to the fuller version of your note. Encode the content of the notes as appropriate. Below is an example.

Note from the annotation file:

<note type="annotation" target="doc:emdFBFB_M#emdFBFB_M_anc_11" targetEnd="doc:emdFBFB_M#emdFBFB_M_anc_12">
  <note type="label">Lacy, earl of Lincoln</note>
  <note type="gloss">a pseudo-historical character probably inspired by Edmund de Lacy (d. 1258), a courtier and heir of John de Lacy, second earl of Lincoln (d. 1240)</note>
  <note type="commentary">Holinshed states that both "William earle Warren and John earle of Lincoln" died in 1240 (<hi rendition="rnd:italic">Chronicle</hi> 225). The chronicler’s pairing of these magnates may have inspired Greene to include their heirs as members of Edward’s entourage (Round 20). Greene seems unaware of the fact that the younger Lacy died before he could inherit the earldom of Lincoln, which (<hi rendition="rnd:italic">suo jure</hi>) remained invested in his mother the countess Margaret de Lacy (Wilkinson 121-22).</note>
</note>

This is what the note is pointing at, in the original source document:

<p>

with <anchor xml:id="emdFBFB_M_anc_11"/>Lacy, earl of <lb type="tln" n="2"/>Lincoln<anchor xml:id="emdFBFB_M_anc_12"/>

</p>

¶ Encode Annotations

¶ Write Annotations

This section explains the process for writing annotations in texts and their corresponding annotation files.

The annotations for the text you are encoding live in a separate file with the file name textID_annotation.xml. Give the file an xml:id on the root element with an attribute of


                                       @xml:id

with the value textID_annotation. The annotation file is saved in the app folder of your text folder. If the app folder does not contain an annotation file, please add it or ask a member of the LEMDO team to add it for you. When encoding the annotation file, assign a


                                       @type

attribute to the main


                                          <div>

element, with a value of annotations.

¶ Place Anchors in the Source Document

In the document you are annotating, identify the string you want to annotate, and select it with your cursor. Once the selection is made, press Control+Shift+A (on Linux or Windows machines) or Command+Shift+A (on iOS machines). This shortcut will automatically generate an element


                                             <anchor>

to the left of your selection, and another to the right. Each


                                             <anchor>

has a generated


                                          @xml:id

with the following value: “doc:” followed by the ID of the text you are encoding, followed by a “#” followed by _anc_followed by the appropriate anchor number. You will need these anchor IDs when writing your annotation in the annotation file, as described below.

For richer documentation on anchors, see Create Anchors.

¶ Write Annotations in the Corresponding Annotation File

In the annotation file, the struture of every annotation is as follows:


                                             <note>

: the parent element that will contain all elements and content of the current annotation you are writing. Give this element an attribute


                                          @type

with a value of annotation. You also need two attributes that refer to the anchors placed in the source document. These attributes are


                                          @target

and


                                          @targetEnd


                                          @target

refers to the left anchor on the annotated string, and


                                          @targetEnd

refers to the right anchor on the annotated string. Copy the value of the


                                          @xml:id

of the respective anchor (in the source document) into the appropriate target. The next element is a


                                             <note>

that identifies the label, which is the string of text you want to annotate. Add an attribute


                                          @type

to the


                                             <note>

, with a value label. The content of this note is the literal string to be annotated. Following are the actual


                                             <note>

s. Assign an attribute


                                          @type

with a value of gloss or commentary. Gloss corresponds to the short form and commentary to the fuller version of your note. Encode the content of the notes as appropriate. Below is an example.

Note from the annotation file:

<note type="annotation" target="doc:emdFBFB_M#emdFBFB_M_anc_11" targetEnd="doc:emdFBFB_M#emdFBFB_M_anc_12">
  <note type="label">Lacy, earl of Lincoln</note>
  <note type="gloss">a pseudo-historical character probably inspired by Edmund de Lacy (d. 1258), a courtier and heir of John de Lacy, second earl of Lincoln (d. 1240)</note>
  <note type="commentary">Holinshed states that both <quote>William earle Warren and John earle of Lincoln</quote> died in 1240 (<title level="m">Chronicle</title> 225). The chronicler’s pairing of these magnates may have inspired Greene to include their heirs as members of Edward’s entourage (Round 20). Greene seems unaware of the fact that the younger Lacy died before he could inherit the earldom of Lincoln, which (<foreign xml:lang="la">suo jure</foreign>) remained invested in his mother the countess Margaret de Lacy (Wilkinson 121-122).</note>
</note>

Note from the source file (text document):

<p>

with <anchor xml:id="emdFBFB_M_anc_11"/>Lacy, earl of <lb type="tln" n="2"/>Lincoln<anchor xml:id="emdFBFB_M_anc_12"/>

</p>

Prosopography

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.

Mahayla Galliford

Research assistant, remediator, encoder, 2021–present. Mahayla Galliford is a fourth-year student in the English Honours and Humanities Scholars programs at the University of Victoria. She researches early modern drama and her Jamie Cassels Undergraduate Research Award project focused on approaches to encoding early modern stage directions.

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.

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

empty element

“Empty elements are also called milestone or self-closing elements, but LEMDO uses the term empty element. Empty elements do not have child text or element nodes.”

ISE Markup Language (IML)

“The boutique markup language of the Internet Shakespeare Editions (ISE).”

Metadata

Authority title	Chapter 16. Annotations
Type of text	Documentation
Short title
Publisher	Linked Early Modern Drama
Series
Source
Editorial declaration
Edition
Encoding description
Document status	prgGenerated
License/availability