LEMDO: Remediate Modern Texts

Remediate Modern Texts

¶ Setting Priorities

When remediating a text, flag anything you think may be a mistake (typos, misplaced punctuation, etc.) by adding an XML comment. Do not make changes to the text without consulting an experienced team member first. Remember that it is not our work to edit the play.

¶ Suggested Workflow

Give Credit in the Metadata

Update Document Status: In Progress

Remove Square Brackets

Remove Extraneous Line Beginnings

Remove Spaces

Replace Apostrophes

Correct the Character List

Check Character List Against IML Character List

Remove Collective and Non-Character Speakers

Match Names in Character List to Speakers

Match Names in Character List to Unique IDs of Speakers

Fix Duplicate Entries for a Single Character

Add Names

Reorder Character Entries

Add Notes to Character Entries

Link Citations in Character Notes to BIBL1.xml

Standardize Headings

Check Tagging of Verse and Prose

Remove Mode Milestones

Check Part and Shared Lines

Check In-line Stage Directions

Replace Quotation Marks

Encode Songs

Encode Foreign Words

Encode Accented Words

Check the Text for Accuracy

Copyedit the Text

Change American Spellings to Canadian

Add Anchors

Remove TLNs

Proofread the PDF

¶ Give Credit in the Metadata

Add a


                                          <respStmt>

element for the LEMDO team in the TEI Header of the document. See also Encode Responsibility Statements. Record your particular contributions to the remediation of the edition by adding


                                          <change>

elements under the


                                          <revisionDesc>

Note: LEMDO Director Janelle Jenstad is responsible for liaising with the editor and/or anthology lead to ensure the rest of the metadata in the


                                          <teiHeader>

is correct. However, if you notice anything that is obviously missing or problematic, leave an XML comment.

¶ Update Document Status: In Progress

Each time you begin remediating a new document, you must change the value of the


                                       @status

attribute on the


                                          <revisionDesc>

element to "IML-TEI_INP". This reflects that your remediations are in progress and triggers the full schema and Schematron on your file. Fiven that it often takes multiple work sessions to remediate a file to the point that it is fully valid by LEMDO standards, we have a special interim status that allows us to commit an invalid file to the repository without breaking the build. That interim status is "IML-TEI". You may save the file that you are working on with an "IML-TEI" status if your file is not valid at the end of a work session. Once it is valid, save and commit your file with the "IML-TEI_INP" status.

Documents that have been converted from IML to TEI by a developer using the LEMDO programmatic conversions will have the


                                       @status

value of either "prgGenerated" or "IML-TEI". In the latter case, there should be an earlier change element with the


                                       @status

value "prgGenerated". Here is an example of a file that was converted by Joey Takeda in 2018. In 2020, Janelle Jenstad began the remediation process by tidying the metadata before an RA like you began to work on the file:

<revisionDesc status="IML-TEI">
<change who="pers:JENS1" when="2020-07-10" status="IML-TEI">Tidied metadata.</change>
<change when="2018-06-29" who="pers:TAKE1" status="prgGenerated">Created TEI from IML file.</change>
</revisionDesc>

(Note that the


                                       @status

attribute appears on the


                                          <revisionDesc>

element and the


                                          <change>

element. This apparent redundancy allows us to keep a full history of the documents progress through the conversion and remediation process. Because the


                                          <change>

element has the


                                       @when

attribute, we can determine exactly when the document passed from one status to the next.)

To change the status of a modern text that you are remediating, do the following:

Change the value of the


                                             @status

attribute on the


                                                <revisionDesc>

element to "IML-TEI" or "IML-TEI_INP".

Add a new


                                                <change>

element as a child of


                                                <revisionDesc>

Write the substantive change in the text node (i.e., Began remediating document).

Add a


                                             @who

, a


                                             @when

, and a


                                             @status

attribute to the


                                                <change>

element.

Add the prefix pers: followed by your xml:id to the


                                             @who

attribute.

Add the date you began the remediation to the


                                             @when

attribute.

Add the new status (i.e., "IML-TEI" or "IML-TEI_INP") as the value of the


                                             @status

attribute. Note that if you did not change the


                                             @status

of the file you do not need to add a


                                             @status

attribute to your


                                                <change>

element.

¶ Remove Square Brackets

Square brackets in converted files are left over from IML and must be deleted. Square brackets will prevent files from rendering on the LEMDO site, so deleting them is a top priority. Other remediation tasks will be easier to do if you can look at your text rendered on the LEMDO site.

The DRE Editorial Guidelines, which LEMDO supports through encoding practices and which the ISE and QME have adopted, does not use square brackets to denote editorially supplied text in modern or born-digital documents.

The


                                          <supplied>

element was used as a replacement for square brackets to denote editorially supplied material, but LEMDO no longer uses this element either. Our assumption is that the entire modern text is supplied.

These elements were programmatically deleted en masse, so you shouldnʼt encounter them in converted texts. If you do encounter a


                                          <supplied>

element without any attributes, delete it. If you encounter a stray


                                          <supplied>

element with attributes, leave a comment in the file for the LEMDO Director and let her know that sheʼll need to look at it. Stray opening or closing square brackets may not have been converted to


                                          <supplied>

, and will generate a Schematron error until you delete them.

¶ Remove Extraneous Line Beginnings

The TEI will contain leftover


                                          <lb>

tags from the IML. There are two types of


                                          <lb>

elements in the IML file:

Editorial line numbers (the


                                             <lb>

element with the

@n

attribute and a number as the value). Delete these immediately.

TLNs and/or QLNs (the


                                             <lb>

element with the


                                          @type

attribute and the value "tln", and the

@n

attribute with a number as the value). Retain these until later.

LEMDO doesnʼt ultimately need or want any


                                          <lb>

tags. However, you will want to retain line numbers that correspond to the annotations file until after you have checked anchor placement.

Conversion yields:

<div>


  <lb n="2"/>
  <lb type="tln" n="6"/>
  <p>Good morrow, sweet <lb type="tln" n="7"/>Lodovico.</p>
  
</div>

As you can see, there are two


                                          <lb>

milestone elements for every single line beginning: one is the editorial line number (n="2") and the other is the TLN corresponding to a compositorial line in the semi-diplomatic transcription of 2 Honest Whore (type="tln" n="6".

Before you delete any of those numbers, check the converted annotations file. In this case, the corresponding annotations file is keyed to the TLNs (


                                       @target

="tln:6").

Corresponding annotation:

<div>


  <note type="annotation" target="tln:6">
    <note type="label">sweet</note>
    <note type="gloss">dear (not ‘sweet’); also often = pleasant, agreeable (as in <ref target="doc:2HW/M#tln-12-12">TLN 12</ref>).</note>
  </note>
  
</div>

With that knowledge, you can safely delete the editorial line numbers right away. Keep the TLNs until later in this remediation process.

Amend to:

<div>


  <lb type="tln" n="6"/>
  <p>Good morrow, sweet <lb type="tln" n="7"/>Lodovico.</p>
  
</div>

LEMDO has developed a Regular Expression (regex) to programmatically delete editorial line numbers en masse. Follow these instructions to programmatically delete them:

To delete


                                          <lb>

elements with the


                                       @type

attribute and the value "tln" and an

@n

attribute with a numerical value:

Click Ctrl+F

In the Find field, paste <lb type="tln" n="\d*\.*\d*"/>

Leave the Replace field empty

Check the Regular expression box

Click Replace All

To delete


                                          <lb>

elements without the


                                       @type

attribute and the value "tln":

Click Ctrl+F

In the Find field, paste <lb\sn="(\w)*"\/>

Leave the Replace field empty

Check the Regular expression box

Click Replace All

To delete Editorial Line Numbers:

Click Ctrl+F

In the Find field, paste <lb n="\d*\.*\d*"/>

Leave the Replace field empty

Check the Regular expression box

Click Replace All

¶ Remove Spaces

These


                                          <space>

elements are left over from IML and can be deleted. We do not capture page layout in modern texts, so there is no need to indicate the presence of space between text.

The


                                          <space>

elements will most likely have the


                                       @unit

attribute with the value "chars" and the


                                       @quantity

attribute with a number as the value.

¶ Replace Apostrophes

Convert straight apostrophes to right curly apostrophes. The easiest way to convert apostrophes is to run a find-and-replace.

¶ Correct the Character List

First, read through the Encoding Guidelines on how to Encode Character Lists in Modern Texts.

The IML-TEI conversion will have created a


                                          <listPerson>

(child of


                                          <particDesc>

) in the


                                          <teiHeader>

from the tagging in the IML modern text. It generates the


                                          <person>

elements, values for the


                                       @xml:id

attribute, and


                                          <reg>

elements from


                                          <speaker>

elements and the ids on characters in the IML.

In IML, the Character List was a separate .txt file and the Annotations on the character list (if any) were a separate .xml file from the .xml file of the modern text. In LEMDO, the


                                          <listPerson>

removes the need for the character list and its annotations to be in separate files. However, our conversion does not take the old character list or annotations thereon into account, so we have to ensure that the information in the IML List of Characters is included in the


                                          <particDesc>

of our TEI file.

Note that the text node of the


                                          <name>

element is what will appear in the finalized character list.

¶ Check Character List Against IML Character List

The list of characters generated by the conversion may not match the IML List of Characters created by the editor because the conversion generates


                                             <person>

elements from


                                             <speaker>

elements in the text. Thus, a character that does not have any assigned lines (i.e., does not show up in at least one speech prefix) will not appear in the


                                             <listPerson>

generated by the conversion. To create an accurate


                                             <listPerson>

, you must check the


                                             <listPerson>

against the IML List of Characters to ensure all characters are included in it.

The list of characters generated by the conversion may also generate


                                             <person>

elements for characters that are not listed on the IML List of Characters. This is because the editor may have referred to the character by a different name than the one tagged with the


                                             <speaker>

element. This character will not show up because the


                                             <listPerson>

is generated from the


                                             <speaker>

elements in the modern text.

If the editor is still working on the edition (i.e., we are doing a one-time IML-TEI conversion so that the editor can continue working in TEI), the LEMDO Director or Project Manager will send an email and a .docx file to the editor(s) to give them the opportunity to make decisions about their character list. The editor(s) will send back a file with comments and corrections. You will need to incorporate those changes into the


                                             <listPerson>

of the file.

In Henry IV Part 2, the conversion yields a


                                             <person>

element for servant who has a speaking part but is not on the IML List of Characters. To make the character list as useful as possible to performers of the play, we must indicate how many actors are required to fill each role. Since there is more than one servant in the play, we must amend the


                                             <person>

element for servant to reflect this.

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_Servant">
    <persName>
      <reg>Servant</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Servants">
    <persName>
      <name>Servants</name>
      <reg>Servants</reg>
      <reg>Servant</reg>
    </persName>
  </person>
  
</listPerson>

¶ Remove Collective and Non-Character Speakers

The conversion produces spurious hybrid speakers (such as GloucesterandClarence or All in 2H4).

Delete any nonsensical hybrid persons from the


                                             <listPerson>

. Add new values on


                                          @who

, which can take multiple values, one for each speaker that speaks simultaneously. In this case, the


                                             <speaker>

element does not have to match a


                                             <reg>

element.

Conversion yields:

Amend to:

Delete any auto-generated non-character speakers (like All or Voices within). See also Groups of Characters.

¶ Match Names in Character List to Speakers

The text node of each


                                             <speaker>

element in the modern text must match with a


                                             <reg>

element in the


                                             <listPerson>

in order for the file to be valid. Thus, some


                                             <persName>

elements will have multiple child


                                             <reg>

elements.

Conversion yields:

<div>


  <reg>KingHenry</reg>
  <speaker>King Henry</speaker>
  
</div>

Remediate to:

<div>


  <reg>King Henry</reg>
  <speaker>King Henry</speaker>
  
</div>

A character may be referred to using more than one name throughout the play. In this case, add a


                                             <reg>

element for each name so every


                                             <speaker>

element has a corresponding


                                             <reg>

element.

Example: Prince Hal in Henry IV Part 2, who is later crowned king

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_Prince">
    <persName>
      <reg>Prince</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Henry">
    <persName>
      <name>Prince, Henry, afterwards crowned King Henry the Fifth</name>
      <reg>Prince</reg>
      <reg>King Henry</reg>
    </persName>
  </person>
  
</listPerson>

Alternatively, we also want to group characters in one


                                             <person>

element when it is logical to do so. For example, there are two lords in As You Like It that both have speaking roles. Rather than having an entry for each lord, combine both into a single


                                             <person>

element and add


                                             <reg>

elements to capture the contents of all


                                             <speaker>

elements related to the lords in the play.

Make the value of the


                                          @xml:id

attribute on the


                                             <person>

element plural, along with the text node of the


                                             <name>

element. Add whatever you enter as the text node of the


                                             <name>

element as a


                                             <reg>

element as well, because the


                                             <reg>

element is what links to the


                                             <speaker>

elements in the play. The example below shows every variant name of the lords as a


                                             <reg>

element.

Conversion yields:

<listPerson>


  <person xml:id="emdAYL_M_FirstLord">
    <persName>
      <reg>First Lord</reg>
    </persName>
  </person>
  <person xml:id="emdAYL_M_SecondLord">
    <persName>
      <reg>Second Lord</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emdAYL_M_Lords">
    <persName>
      <name>Lords</name>
      <reg>Lords</reg>
      <reg>Lord</reg>
      <reg>First Lord</reg>
      <reg>Second Lord</reg>
    </persName>
  </person>
  
</listPerson>

IML List of Characters shows:

Grooms

Responsible for strewing rushes at the kingʼs coronation (5.5).

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_Groom1">
    <persName>
      <reg>Groom 1</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_Groom2">
    <persName>
      <reg>Groom 2</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_Groom3">
    <persName>
      <reg>Groom 3</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Grooms">
    <persName>
      <name>Grooms</name>
      <reg>Grooms</reg>
      <reg>Groom</reg>
      <reg>Groom 1</reg>
      <reg>Groom 2</reg>
      <reg>Groom 3</reg>
    </persName>
    <note>
      <p>Responsible for strewing rushes at the kingʼs coronation (5.5).</p>
    </note>
  </person>
  
</listPerson>

¶ Match Names in Character List to Unique IDs of Speakers

The editor gives each


                                             <sp>

element in the modern text a


                                          @who

attribute and a value that indicates the text it appears in and the character who is speaking. For example, the


                                             <sp>

element in Q1 of Romeo and Juliet for one of Romeoʼs speeches has the


                                          @who

attribute with the value "#emdRom_Q1_Romeo".

The characterʼs name in the value for the


                                          @who

attribute must match a


                                             <reg>

element in the


                                             <listPerson>

or the file will not be valid.

Note that the


                                          @who

attribute does not function as a speech prefix. A


                                             <speaker>

tag with appropriate speech prefix is still necessary.

¶ Fix Duplicate Entries for a Single Character

LEMDO doesnʼt give new


                                          @xml:id

values to characters if they change roles or names, so you may have to merge some characters. Remember to change the


                                          @xml:id

values on the


                                             <sp>

elements in the text as well.

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_PrinceHenry">
    <persName>
      <reg>PrinceHenry</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_KingHenry">
    <persName>
      <reg>KingHenry</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Henry">
    <persName>
      <name>Prince Henry, later King Henry</name>
      <reg>Prince</reg>
      <reg>King</reg>
    </persName>
  </person>
  
</listPerson>

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_Bardolph">
    <persName>
      <reg>Bardolph</reg>
    </persName>
  </person>
  <person xml:id="emd2H4_M_LordBardolph">
    <persName>
      <reg>LordBardolph</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Bardolph">
    <persName>
      <name>Bardolph, later Lord Bardolph</name>
      <reg>Bardolph</reg>
      <reg>Lord Bardolph</reg>
    </persName>
  </person>
  
</listPerson>

¶ Add Names

The conversion auto-generates


                                             <reg>

elements from the


                                             <speaker>

elements in the file. You must add a


                                             <name>

element for each


                                             <person>

. The content of


                                             <name>

is the information that will be displayed in the list of characters online and in print.

For the content of the


                                             <name>

element, follow the editorʼs IML Character List. The editor will give different (usually longer) names for the characters therein. These longer names are the ones that the editor wants to have in the online and print Character List.

In some cases, the


                                             <reg>

element (generated from the speakers in the IML file) will be the same as the


                                             <name>

element. You need to add the


                                             <name>

even if it seems redundant to do so.

Conversion yields:

<listPerson>


  <person xml:id="emd2H4_M_Porter">
    <persName>
      <reg>Rumor</reg>
    </persName>
  </person>
  
</listPerson>

Amend to:

<listPerson>


  <person xml:id="emd2H4_M_Porter">
    <persName>
      <name>Rumor, the presenter</name>
      <reg>Rumor</reg>
    </persName>
  </person>
  
</listPerson>

¶ Reorder Character Entries

The


                                             <listPerson>

arranges


                                             <person>

elements in the order that the characters appear in the text. You must reorder the


                                             <person>

elements to match the order that the editor lists them in the IML Character List.

¶ Add Notes to Character Entries

If the editor has prepared annotations on the characters, they will be in a separate XML file in the ../app directory. They will have been converted from IML but not remediated. You have to find that file and manually add those notes in a


                                             <note>

element below


                                             <persName>

on each


                                             <person>

element.

If the editor had not prepared character annotations, the LEMDO Director or anthology lead will liaise with the editor about annotations at the same time that the editor is given a chance to update the character list.

¶ Link Citations in Character Notes to Entries in BIBL1.xml

If the character notes for your modern text contain citations to external sources, you will need to check if these works are cited in BIBL1.xml. If they arenʼt, you will need to create a new BIBL entry. If the work is cited in BIBL1.xml, you need to add a


                                                <ref>

tag to the in-text citation to link it to the BIBL entry. See also Converting IML Bibliographies.

¶ Standardize Headings

The conversion formats act and scene numbers with a period between them, but we want them formatted as Act #, Scene #. The easiest way to find and replace these is to use your Outline view in Oxygen to filter


                                          <head>

elements.

Remember to delete the


                                          <supplied>

elements as you go.

Conversion yields:

Amend to:

<div>


<head>Act 2, Scene 3</head>

</div>

¶ Check Tagging of Verse and Prose

Milestones are a holdover from the IML way of indicating prose and verse. In IML, the editor inserted a


                                       <mode>

tag whenever a verse or prose passage began. There was no closing


                                       <mode>

tag. One mode was considered to end when another mode began. Our conversion supplies a


                                          <milestone>

tag where the first


                                       <mode>

tag was. It adds a


                                       @subtype

to indicate whether the mode is verse or prose. Our conversion supplies a second


                                          <milestone>

element with


                                       @subtype

="end" immediately before the new milestone with its


                                       @subtype

value of verse or prose.

Our conversion takes those milestone elements (which sort of stand in for XMLʼs container structure) and adds

<p>

elements in the speeches that are now contained between two kinds of


                                          <milestone>

elements:


                                                <milestone>

elements with the


                                             @unit

attribute and the value "nonstructural",


                                             @type

attributes with the value "mode", and


                                             @subtype

attributes with the value "prose".


                                                <milestone>

elements with the


                                             @unit

attribute and the value "nonstructural",


                                             @type

attributes with the value "mode", and


                                             @subtype

attributes with the value "end".

LEMDOʼs conversion does the same to


                                          <milestone>

elements with the value "verse" on the


                                       @subtype

attribute instead of "prose", but replaces them with


                                          <lg>

and

<l>

elements instead of

<p>

elements.

If the


                                       <mode>

tags were encoded correctly in the IML, then our conversion will be correct. But if the


                                       <mode>

tags were incorrect by IML standards, then itʼs possible that our conversion has not correctly wrapped prose in

<p>

tags and verse in


                                          <lg>

and

<l>

tags. Your job is to ensure that the


                                          <lg>

<l>

, and

<p>

elements are in place. If they are, you can delete all the milestones with


                                       @unit

="nonstructural" and


                                       @type

="mode".

It should be obvious when a verse passage tagged with

<p>

is actually verse. Youʼll notice capitalization in the middle of sentences (usually corresponding to the placement of one or both sets of


                                          <lb>

elements). If you notice capitalization in the middle of sentences in passages wrapped in

<p>

tags, itʼs very likely meant to be verse. Leave an XML comment and check with the LEMDO Director, who will make a judgement call or confer with the Anthology Lead and/or play editor.

Example of mode milestones in AYL:

<div>


  <milestone unit="nonstructural" type="mode" subtype="verse"/>
  <quote type="verse">Wind away, Begone, I say, I will not to wedding with thee.</quote>
  <milestone unit="nonstructural" type="mode" subtype="end"/>
  
</div>

Note that our more recent conversions will have deleted those milestones before you begin remediating the file. We periodically update the conversions to obviate the labour of hand remediation.

¶ Remove Mode Milestones

The remediator must confirm that the verse and prose in the text are tagged correctly using

<l>

and

<p>

tags. Once you have confirmed that, you can delete the


                                          <mode>

milestone tags. Multiple find-and-replace operations will suffice (i.e., replace with nothing).

¶ Check Part and Shared Lines

See also the Refresher on Shared Verse Lines .

LEMDO adds the


                                       @part

attribute to

<l>

elements wrapping part and shared lines and adds a value based on the position of each part line in the series of lines that it is part of.

The allowed values on


                                       @part

are "I", "M", and "F", for initial, medial, and final. This tagging is how we indicate that two or more characters share a single verse line. The modern text is where we indicate the versification of the text. See also the TEI Guidelines for information about the


                                       @part

attribute and its allowed values.

This tagging should have been added during the conversion, so you just have to check its accuracy. As long as this tagging is in place, you can delete elements that are IML holdovers. The IML holdovers will be


                                          <milestone>

elements with the


                                       @unit

attribute and the value "linepart", and the

@n

attribute with the value "i", "m", or "f".

Conversion yields:

<sp who="">


  <milestone unit="linepart" n="i"/>
  <speaker>Hippolito</speaker>
  <l part="I">Your business, sir? To me?</l>
  <milestone unit="linepart" n="f"/>
  <speaker>Antonio</speaker>
  <l part="F">Yes, my good lord.</l>
  
</sp>

Amend to:

<div>


  <sp who="#emd2HW_M_Hippolito">
    <speaker>Hippolito</speaker>
    <lg>
      <l part="I">
        <stage type="delivery"> To Antonio </stage> Your business, sir? To me?</l>
    </lg>
  </sp>
  <lb type="tln" n="139"/>
  <sp who="#emd2HW_M_Antonio">
    <speaker>Antonio</speaker>
    <lg>
      <l part="F">Yes, my good lord.</l>
    </lg>
  </sp>
  
</div>

¶ Check In-line Stage Directions

Ensure in-line stage directions render on the correct line. Stage directions that state who is being addressed should appear before the corresponding line of dialogue. In the following example, To Silvius renders at the end of line 63 (Foul is most foul, being foul to be a scoffer), but it should render at the beginning of line 64 (So take her to thee, shepherd. Fare you well). Add an opening

<l>

<p>

tag before the opening


                                          <stage>

tag and a closing

<l>

<p>

tag at the end of the corresponding line of dialogue so the stage direction will render on the same line as the dialogue.

Conversion yields:

<lg>


<l>Foul is most foul, being foul to be a scoffer. <stage type="delivery">To Silvius</stage> So take her to thee, shepherd. Fare you well.</l>

</lg>

Amend to:

<lg>


  <l>Foul is most foul, being foul to be a scoffer.</l>
  <l>
    <stage type="delivery">To Silvius</stage>So take her to thee, shepherd. Fare you well.</l>
  
</lg>

Sometimes there are multiple in-line stage directions indicating who is being spoken to in one paragraph, such asd in AYL Act 5, Scene 2:

<sp who="#emdAYL_M_Rosalind">


  <speaker>Rosalind</speaker>
  <p>Pray you, no more of this; ’tis like the howling of Irish wolves against the moon.</p>
  <p>
    <stage type="delivery">To Silvius</stage> I will help you if I can.</p>
  <p>
    <stage type="delivery">To Phoebe</stage> I would love you if I could.—</p>
  <p>
    <stage type="delivery">To All</stage> Tomorrow meet me all together.</p>
  <p>
    <stage type="delivery">To Phoebe</stage> I will marry you if ever I marry woman, and I’ll be married tomorrow.</p>
  <p>
    <stage type="delivery">To Orlando</stage> I will satisfy you if ever I satisfied man, and you shall be married tomorrow.</p>
  <p>
    <stage type="delivery">To Silvius</stage> I will content you if what pleases you contents you, and you shall be married tomorrow.</p>
  <p>
    <stage type="delivery">To Orlando</stage> As you love Rosalind, meet.</p>
  <p>
    <stage type="delivery">To Silvius</stage> As you love Phoebe, meet.</p>
  <p>
    <stage type="delivery">To All</stage> And as I love no woman, I’ll meet. So, fare you well. I have left you commands.</p>
  
</sp>

¶ Replace Quotation Marks

After the IML to TEI conversion, the file will contain

<q>

elements in place of quotation marks. The quotation marks will be re-added when the file is reprocessed into HTML.

For quotations that extend over two or more lines of verse, assign each quotation element a unique value on the


                                       @xml:id

attribute and add


                                       @next

and/or


                                       @prev

attributes as needed to link the lines together. See also Encode Split Elements.

¶ Encode Songs

In IML, songs were usually encoded as quotations. LEMDO does not want songs wrapped in quotation tags unless the song contains explicitly quoted material. Delete any quotation marks or quotation tags that are not surrounding quoted material. See also Remediate Letters and Songs.

¶ Encode Foreign Words

Tag foreign words with the


                                             <foreign>

element, the


                                          @xml-lang

attribute, and a standardized BCP 47 value from the list below. Consult the IANA Language Subtag Registry for a list of relevant values. See also Introduction to Quotations, Terms, Expressions, Glosses, Emphasis, and Foreign Languages:

<p>


<q>Accommodated</q>—it comes of <foreign xml:lang="la">accommodo</foreign>—very good, a good phrase. </p>

¶ Encode Accented Words

See Special Characters: Encode Characters from the Character Map.

¶ Check the Text for Accuracy

Make sure that the text is complete and correct. Do this by reading the text in your file against a version of the text published elsewhere. You can check as you go or do a final check at the end.

If the text was peer reviewed and published on one of the sibling sites (ISE, QME, or DRE), compare your file to the online rendering of the original IML. Make sure that we didnʼt accidentally delete a passage while the IML was being run through the various conversions (which always entails some clean-up of the IML).

Keep in mind that the Broadview texts went through an additional phase of copyediting, and those copyedits did not always make it back into the digital editions.

We have noted that some


                                          <speaker>

elements seem to be missing. If you check against the ISE, DRE, or QME site, add in the intended speakers.

When you are looking at the ISE, DRE, and QME sites, make sure you are looking at the Desktop Version. Some editions seem to be defaulting to the mobile view, in which lines are repeated.

¶ Copyedit the Text

It is not really your job as remediator to copyedit the editorʼs work, but if you notice things that you can easily fix (like missing serial commas) and you are confident in your knowledge of the LEMDO Style Guidelines, then go ahead and implement the change. If you are unsure, always check with the LEMDO Director (or the play editor/anthology lead, if you have been authorized to correspond directly with them).

¶ Change Canadian Spellings to American

There may be some leftover Canadian spelling in the IML (especially if the editor was Canadian). Broadview seems to have used American spelling. Convert words like honour and practise to honor and practice. Here, you are functioning as a copyeditor while remediating the text. See LEMDO Style Guidelines.

¶ Add Anchors

When you start remediating the annotations, collations, and critical paratexts, you will revisit the modern text and add anchors for those other texts to point to.

If you are looking for information on remediating annotations, collations, or critical paratexts, go to Remediate Annotations, Remediate Annotations for Print, Remediate Collations, or Remediate Critical Paratexts.

¶ Remove TLNs

We leave the TLNs on


                                          <lb>

elements during the IML-TEI remediation process because the remediator needs to consult them to confirm the annotations on the modern text are linked to the correct words or lines of text. TLNs were the glue that allowed for the string-matching that IML used to tie the lemma in the annotation to the word(s) in the modern text that the annotation glossed. Once you have added the anchors to the modern text and confirmed that each annotation is linked to the correct word(s), you must delete the


                                          <lb>

elements and their TLN attributes.

¶ Proofread the PDF

Some texts being remediated are converted into PDF files in preparation for publishing. You must proofread the PDF after you have completed this remediation process to check for mistakes in your encoding. Ask a developer for a link to the PDF copy of your text.

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.

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.

Tracey El Hajj

Junior Programmer 2019–2020. Research Associate 2020–2021. Tracey received her PhD from the Department of English at the University of Victoria in the field of Science and Technology Studies. Her research focuses on the algorhythmics of networked communications. She was a 2019–2020 President’s Fellow in Research-Enriched Teaching at UVic, where she taught an advanced course on Artificial Intelligence and Everyday Life. Tracey was also a member of the Map of Early Modern London team, between 2018 and 2021. Between 2020 and 2021, she was a fellow in residence at the Praxis Studio for Comparative Media Studies, where she investigated the relationships between artificial intelligence, creativity, health, and justice. As of July 2021, Tracey has moved into the alt-ac world for a term position, while also teaching in the English Department at the University of Victoria.

Orgography

LEMDO Team (LEMD1)

The LEMDO Team is based at the University of Victoria and normally comprises the project director, the lead developer, project manager, junior developers(s), remediators, encoders, and remediating editors.

Metadata

Authority title	Remediate Modern Texts
Type of text	Documentation
Short title
Publisher	University of Victoria on the Linked Early Modern Drama Online Platform
Series	Linked Early Modern Drama Online
Source	TEI Customization created by Martin Holmes, Joey Takeda, and Janelle Jenstad; documentation written by members of the LEMDO Team
Editorial declaration	n/a
Edition	Released with Linked Early Modern Drama Online 1.0
Encoding description	Encoded in TEI P5 according to the LEMDO Customization and Encoding Guidelines
Document status	prgGenerated
Funder(s)	Social Sciences and Humanities Research Council of Canada
License/availability	This file is licensed under a CC BY-NC_ND 4.0 license, which means that it is freely downloadable without permission under the following conditions: (1) credit must be given to the author and LEMDO in any subsequent use of the files and/or data; (2) the content cannot be adapted or repurposed (except in quotations for the purposes of academic review and citation); and (3) commercial uses are not permitted without the knowledge and consent of the editor and LEMDO. This license allows for pedagogical use of the documentation in the classroom.