Home > Project documentation > Documentation for encoders

Create a MoEML <teiHeader>

roseList documents mentioning Create a MoEML TEI Header

Introduction

The <teiHeader> is the first component of any TEI-conformant text in the MoEML document collection. The <teiHeader> contains descriptive and declarative XML metadata that prefaces and categorizes the content being encoded in the <text> by way of four descriptive tags: <fileDesc>, <profileDesc>, <encodingDesc>, and <revisionDesc>. The basic structure of the <teiHeader> has already been encoded in the template documents. This manual describes how to update and customize the <teiHeader> template for each new document.

Responsibility Statements

Responsibility statements are encoded in the <titleStmt> of every page. The taxonomies to specify a contributor’s responsibilities are located at the top of the PERS1.xml file. Each <respStmt> contains:
  1. a <name> element with a @ref attribute pointing to a contributor
  2. a <resp> element with a @ref attribute describing that person’s contribution(s) to the page (itself containing its own <date> specification)
We do not combine multiple <resp> elements within one <respStmt>. We have made the decision to create a unique <respStmt> for each role that each person plays, and for each person who performs a role even if more than one person peforms that role. For example, if Zaqir Virani is the transcriber, encoder, and CSS editor for The Triumphs of Truth (TRIU1.xml), he gets three <respStmt> elements with his name inside the <name> element:
<titleStmt>
  <title>The Triumphs of Truth</title>
  <respStmt>
    <resp ref="molresp:trc">Transcriber<date when="2013"/></resp>
    <name ref="mol:VIRA1">Zaqir Virani</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2013"/></resp>
    <name ref="mol:VIRA1">Zaqir Virani</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:cse">CSS Editor<date when="2013"/></resp>
    <name ref="mol:VIRA1">Zaqir Virani</name>
  </respStmt>
</titleStmt>
If Quinn MacDonald also serves as encoder for this file, then there should be two separate <respStmt> elements with Markup Editor inside the <resp> element: one for Zaqir Virani and another for Quinn MacDonald:
<titleStmt>
  <title>The Triumphs of Truth</title>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2013"/></resp>
    <name ref="mol:VIRA1">Zaqir Virani</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2013"/></resp>
    <name ref="mol:MACD1">Quinn MacDonald</name>
  </respStmt>
</titleStmt>
The responsibility statements included in a particular document will depend on the type of the document and the amount of information available about the document. Primary source files and born-digital files have slightly different patterns for the order of <respStmt> elements.

<respStmt> in Primary-Source Documents

Responsibility statements for transcriptions of primary sources will normally include authors, printers, and book sellers, as well as the transcriber(s), encoder(s), and toponymist(s) who make the text function in the MoEML environment. Consult MoEML’s guidelines for encoding dates to determine which dating method is applicable. In summary, dates before 1752 should be encoded with @when-custom while dates after 1752 should be encoded with @when.
Responsibility statements should be listed in the following order:
  1. Information about primary text
    • Author: use the @ref value "molresp:aut".
    • Printer: use the @ref value "molresp:prt". Check the title page of the book. A title page with the colophon Printed by Nicholas Okes for Thomas Archer, and are to be sold at his shop in Popes-head Palace tells us that the printer is Nicholas Okes and Thomas Archer is both the publisher and the bookseller.
    • Bookseller: use the @ref value "molresp:bsl". Normally, the bookseller and the publisher are the same in early modern London. In the case of the mayoral shows, the pageant books were not for sale; you need list only the printer in most cases.
  2. Information about about editing, transcribing, identifying locations, and encoding
    • Transcriber: use the @ref value "molresp:trc". In many cases, the transcriber listed first will be EEBO-TCP. In some cases, it will be a scholar or student at UVic or elsewhere who has transcribed the text for a research project. Add a <respStmt> for each person who transcribes any part of the text.
    • Toponymist: use the @ref value "molresp:top". The toponymist is the person who identifies the place references in the document. This person may also be the encoder (as in the case of Stow’s Survey, wherein MoEML RAs have identified toponyms while encoding); in such a case, give the person separate <respStmt> elements for each role.
    • Encoder: use the @ref value "molresp:mrk". The encoder is the person who adds TEI tags to the file, including structural tags, <bibl> tags, <name> tags, <date> tags, etc.
    • Markup Editor: use the @ref value "molresp:mrk". The markup editor is the person who checks and corrects the encoder’s tagging.
    • CSS Editor: use the @ref value "molresp:cse". The css editor is the person who adds CSS encoding to style the text.
    • Transcription Proofreader: use the @ref value "molresp:pfr". The transcription proofreader is the person who checks and corrects the transcription against the facsimile images.
  3. Information about project supervisors
    • Data Manager: use the @ref value "molresp:dtm".
    • Junior Programmer: use the @ref value "molresp:prg".
    • Programmer: use the @ref value "molresp:prg". Normally, this person will be Martin Holmes. Every single file should include this responsibility statement at the end of the list.
    • Associate Project Director: use the @ref value "molresp:rth".
    • Project Director: use the @ref value "molresp:pdr". Normally, this person will be Janelle Jenstad. Every single file should include this responsibility statement at the end of the list.
The responsibility statements for EIRE1.xml (Thomas Adam’s Eirenopolis) serve as an example:
<titleStmt>
  <title>Eirenopolis</title>
  <respStmt>
    <resp ref="molresp:aut">Author<date when-custom="1622" datingMethod="mol:julianSic"/></resp>
    <name ref="mol:ADAM3">Thomas Adams</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:prt">Printer<date when-custom="1622" datingMethod="mol:julianSic"/></resp>
    <name ref="mol:MATT2">Augustine Matthews</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:bsl">Bookseller<date when-custom="1622" datingMethod="mol:julianSic"/></resp>
    <name ref="mol:GRIS1">John Grismand</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:trc">Transcriber<date notAfter="2010"/></resp>
    <name ref="mol:EEBO3" type="org">EEBO-TCP</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:trc">Transcriber<date when="2012"/></resp>
    <name ref="mol:STEV2">Michael Stevens</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2012"/></resp>
    <name ref="mol:STEV2">Michael Stevens</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2020"/></resp>
    <name ref="mol:LEBE1">Kate LeBere</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:top">Toponymist<date when="2012"/></resp>
    <name ref="mol:JENS1">Janelle Jenstad</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Markup Editor<date when="2012"/></resp>
    <name ref="mol:JENS1">Janelle Jenstad</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Markup Editor<date when="2020"/></resp>
    <name ref="mol:LEBE1">Kate LeBere</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pfr">Transcription Proofreader<date when="2012"/></resp>
    <name ref="mol:BUTT1">Cameron Butt</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pfr">Transcription Proofreader<date when="2020"/></resp>
    <name ref="mol:LEBE1">Kate LeBere</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:dtm">Data Manager<date notBefore="2015"/></resp>
    <name ref="mol:LAND2">Tye Landels</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:prg">Junior Programmer<date notBefore="2015"/></resp>
    <name ref="mol:TAKE1">Joey Takeda</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:prg">Programmer<date notBefore="2011"/></resp>
    <name ref="mol:HOLM3">Martin Holmes</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:rth">Associate Project Director<date notBefore="2015"/></resp>
    <name ref="mol:MCFI1">Kim McLean-Fiander</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pdr">Project Director<date notBefore="1999"/></resp>
    <name ref="mol:JENS1">Janelle Jenstad</name>
  </respStmt>
</titleStmt>

<respStmt> in Born-Digital Documents

Responsibility statements for born digital documents will normally include authors, encoders, copy editors, proofreaders.
Responsibility statements should be listed in the following order:
  1. Information about text
    • Author: use the @ref value "molresp:aut".
    • Abstract Author: use the @ref value "molresp:aut". Only add an abstract author if the abstract author differs from the main author (i.e., a MoEML team member has to add an abstract for a text written by an outside contributor).
    • Editor: use the @ref value "molresp:edt".
    • Guest Editor: use the @ref value "molresp:ged". Only add a guest editor if the article is from a pedagogical partnership where the author was working under the guidance of an outside editor.
    • Vetter: use the @ref value "molresp:vet". Only add a vetter if the article is from an outside contributor and had to be approved by the MoEML team.
    • Copy Editor: use the @ref value "molresp:cpy".
    • Proofreader: use the @ref value "molresp:pfr".
  2. Information about research (if the text is a location article)
    • Researcher: use the @ref value "molresp:res".
    • Geo-Coordinate Researcher: use the @ref value "molresp:gis".
  3. Information about about encoding
    • Toponymist: use the @ref value "molresp:top". The toponymist is the person who identifies the place references in the document. This person may also be the encoder; in such a case, give the person separate <respStmt> elements for each role.
    • Encoder: use the @ref value "molresp:mrk" and describe the person as Encoder. The encoder is the person who adds TEI tags to the file, including structural tags, <bibl> tags, <name> tags, <date> tags, etc.
    • Markup Editor: use the @ref value "molresp:mrk" and describe the person as Markup Editor. The markup editor is the person who checks and corrects the encoder’s tagging.
  4. Information about project supervisors
    • Data Manager: use the @ref value "molresp:dtm".
    • Junior Programmer: use the @ref value "molresp:prg".
    • Programmer: use the @ref value "molresp:prg". Normally, this person will be Martin Holmes. Every single file should include this responsibility statement at the end of the list.
    • Associate Project Director: use the @ref value "molresp:rth".
    • Project Director: use the @ref value "molresp:pdr". Normally, this person will be Janelle Jenstad. Every single file should include this responsibility statement at the end of the list.
The responsibility statements for CUCK1.xml (location article on Cuckold’s Haven) serve as an example:
<titleStmt>
  <title>Cuckold’s Haven</title>
  <respStmt>
    <resp ref="molresp:aut">Author<date when="2014"/></resp>
    <name ref="mol:FERB1">Dana Ferbrache-Darr</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:ged">Guest Editor<date when="2014"/></resp>
    <name ref="mol:HIGH1">Christopher Highley</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pfr">Proofreader<date when="2019"/></resp>
    <name ref="mol:SIMP5">Lucas Simpson</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pfr">Proofreader<date when="2019"/></resp>
    <name ref="mol:LEBE1">Kate LeBere</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pfr">Proofreader<date when="2019"/></resp>
    <name ref="mol:HORN6">Chris Horne</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date notBefore="2013"/></resp>
    <name ref="mol:LAND2">Tye Landels</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:mrk">Encoder<date when="2019"/></resp>
    <name ref="mol:SIMP5">Lucas Simpson</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:dtm">Data Manager<date notBefore="2015"/></resp>
    <name ref="mol:LAND2">Tye Landels</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:prg">Junior Programmer<date notBefore="2015"/></resp>
    <name ref="mol:TAKE1">Joey Takeda</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:prg">Programmer<date notBefore="2011"/></resp>
    <name ref="mol:HOLM3">Martin Holmes</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:rth">Associate Project Director<date notBefore="2015"/></resp>
    <name ref="mol:MCFI1">Kim McLean-Fiander</name>
  </respStmt>
  <respStmt>
    <resp ref="molresp:pdr">Project Director<date notBefore="1999"/></resp>
    <name ref="mol:JENS1">Janelle Jenstad</name>
  </respStmt>
</titleStmt>

Responsibility Statements in Database Files

Make sure to include <respStmt>s for tasks completed in database files like PERS1.xml and BIBL1.xml. In addition to the values listed above like "molresp:mrk" for encoders and "molresp:cpy" for copy editors, not to mention the necessary values for project directors and programmers, some pertinent values may include
  • "molresp:dtm" for Data Manager (the person responsible for the curation of the database)
  • "molresp:dtc" for Data Contributor(s) (a person or organization responsible for contributing data to the database)
For a complete list of available responsibilities, consult. the <taxonomy> of "marcRelators" near the beginning of PERS1.xml.

Understand MoEML’s Document Type Taxonomy

Our document collection is large and disparate; we have everything from digital editions of substantial primary source documents such as Stow’s Survey of London through brief born-digital articles about streets or markets in Early Modern London to technical documentation on how the encoding is done and how the website works. Different types of documents have different requirements in terms of rendering, and users may want to search only specific categories of document. For these and many other reasons, we maintain a fairly extensive taxonomy of document types, and assign all our documents to at least one, and usually two or three, different categories. This document explains how the system works, what the categories are, how to choose and encode the correct categories for the document you are working on, and what the consequences of this are.

A nested tree of categories

Our document type taxonomy is encoded in /db/data/boilerplate/includes.xml, a file which includes other generic header information which is shared among many documents. It appears as a <taxonomy> element inside the <teiHeader>:
<classDecl>
  <taxonomy xml:id="molDocumentTypes">
    <bibl>Map of Early Modern London Document Type Taxonomy</bibl>
    <category xml:id="mdtDatabase" n="Databases">
      <catDesc> Database-like documents containing a sequence of records, such as a personography. </catDesc>
    </category>
    <category xml:id="mdtBornDigital" n="Born-digital documents">
      <catDesc> Born-digital documents created as part of this project, and not based on any pre-existing source text. </catDesc>
    </category>
    <!-- [...] -->
  </taxonomy>
</classDecl>
The @xml:id of the <taxonomy> is "molDocumentTypes"; this is used to link to it from the headers of other documents to which we want to assign categories. The <taxonomy> contains a set of <category> elements. Each <category> has a unique @xml:id, which is also used when assigning categories. It also has an @n attribute containing a brief description of the category suitable for use as a heading in a document; this is used when rendering document listings pages on the website (see below). Finally, the <category> contains a <catDesc> element, where a longer explanation of the document type is provided.
There is one other feature of categories we need to notice: they can nest inside other categories. Here is a small extract from further down the <taxonomy>:
<category xml:id="mdtEncyclopedia" n="Encyclopedia articles">
  <catDesc> Documents which form part of the encyclopedia component of the MoEML project. </catDesc>
  <category xml:id="mdtEncyclopediaLocation" n="Articles on locations">
    <catDesc> Documents describing specific London locations. </catDesc>
    <category xml:id="mdtEncyclopediaLocationBrothel" n="Brothels in Early Modern London">
      <catDesc> Brothels in Early Modern London. </catDesc>
    </category>
    <!-- [...] -->
  </category>
  <!-- [...] -->
</category>
This shows that there is a document type with @xml:id="mdtEncyclopedia"; inside that document type are some subtypes, one of which is "mdtEncyclopediaLocation"; and inside that, there’s another type called "mdtEncyclopediaLocationBrothel".
As you can see, the @xml:id of a nested <category> always begins with the @xml:id of its parent. This convention makes it easy to figure out the hierarchy of nested types even without referring to the <taxonomy> in the includes.xml file.
You can also browse a simple rendering of the entire taxonomy on the Document Types page, which shows it in the form of a nested list.

Choose and Encode Categories for your Document

Now you understand how the system is set up, how do you actually use it when you’re encoding a document? Documents are assigned to categories through a special section of the <teiHeader> called <textClass>, which appears in the <profileDesc>. Here’s an example from one of the location articles:
<profileDesc>
  <textClass>
    <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtBornDigital"/>
    <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtEncyclopediaLocationStreet"/>
  </textClass>
</profileDesc>
There are five important points to note:
  • You link to categories using the <catRef> element.
  • The <catRef>’s @scheme attribute points to the @xml:id of the <taxonomy> element in the taxonomy file.
  • The <catRef>’s @target attribute points to the appropriate <category> element in the taxonomy file.
  • Both attributes use the mdt prefix (MoEML document type).
  • Although there are categories for "mdtEncyclopedia" and "mdtEncyclopediaLocation", we don’t need to include them because "mdtEncyclopediaLocationStreet" is a descendant of those categories in the taxonomy, so those categories are inherited.
So what this says is: this is a born-digital document describing a street in the location section of the encyclopedia.
There is a long list of categories, many of which have nothing to do with each other. For instance, there’s a category called "mdtPeerReviewed" for documents which have been peer-reviewed; there’s one called "mdtUndergraduate" for work which was done by undergraduate students. Which should you include in your document? The answer is all the categories which are relevant, at the lowest level possible for each. If it’s a document by or about Stow, add "mdtStow"; if it’s been peer-reviewed, add "mdtPeerReviewed", and if it’s a critical text, add "mdtCritical". You want to provide as much information as possible about the document (so you would choose as many categories as you can), but you don’t want to include redundant information (so if you already have "mdtEncyclopediaTopic", you don’t need "mdtEncyclopedia" as well).
The schema should help you by prompting you with a list of the values and their meanings when you create a <catRef> element with a @target attribute, and if you put an incorrect value in, your file will be invalid.

How Categories are Used in the Website

Many of the index and listing pages throughout the website are constructed automatically from categories. You can, for instance, replace the filename in a regular URL on the site with any category id + .htm: and you will see a list of all the documents in that category which are publicly available, formatted in a table with columns appropriate to the document type. You can also see the subcategories of a category by doing this:
Categories are also used to determine how a document should be rendered; primary source documents obviously need to be rendered differently from born-digital documents, for instance.

Are these document types set in stone?

Obviously they’re not, because we’ve been adding to them and changing them throughout the process of developing the taxonomy. So if you think there’s something missing, or something is wrong, you can let the programmers know about it. It’s relatively easy to change the taxonomy, but it takes a little work; the taxonomy itself has to be changed, but then the same changes have to be carried over into the ODD file, and a new schema has to be generated. In the case of any substantive change, some of the existing documents in the database may need to be updated too.

List of MoEML Document Types

For a complete list of document types within the MoEML document collection, please refer to the MoEML Document Type Taxonomy.

Revision Descriptions

Revision descriptions are encoded in the <teiHeader> of every document. A revision decription provides a dated record of all revisions to a given document. Accordingly, it consists of a <change> element nested within a <revisionDesc> element. When filling out a revision description, there are five steps:
  1. If necessary, update the status of the document. The @status attribute corresponds with the <revisionDesc> element. Insert one of the following values:
    Value Explanation
    "draft" Still in the process of being written, transcribed or encoded.
    "final" Completed, and awaiting approval before publication.
    "proofing" Complete and ready for final proofing, or in the process of final proofing.
    "published" Publicly available for viewing on the website.
    "archived" An old edition of a document retained as part of the historical record of the site.
    "stub" A short but inadequate article awaiting a full contribution.
    "assigned" An article which has been assigned to a contributor but not yet submitted.
    "empty" A placeholder document required for linking purposes, but not fully completed.
    "hidden" A document which is not displayed on the site as a standalone document.
    "generated" A file whose contents are generated by an automated process.
  2. Create a new <change> element. Your new element should be nested above the other <change> elements, within the <revisionDesc> element.
  3. Declare who is making the revision. Add a @who attribute to the <change> element. Insert your xml:id or the xml:id of the person making the revision as the value.
  4. Declare when the revision occurred. Add @when, @from, and/or @to attributes to the <change> element. Insert the date of the revision as the value. Be sure that the date value is formatted in accordance with MoEML’s guidelines for encoding dates.
  5. Declare whether the revision changes the document status. If you changed the value of the @status attribute attached to the <revisionDesc> element, add another @status attribute to the <change> element. Insert a value that matches the value of the former @status attribute.
  6. Enter revision information. Insert a text string after the <change> element that describes how the document was revised.
The revision description for contact.xml serves as an example:
<revisionDesc status="published">
  <change who="mol:HOLM3" when="2014-03-06" status="published">Published this document. For some reason it was left in draft until now.</change>
  <change who="mol:HOLM3" when="2013-12-19">Added global publicationStmt through XInclude.</change>
  <change who="mol:MCFI1" when="2013-12-10">Add team photos to contacts page.</change>
  <change who="mol:HOLM3" when="2013-08-13">Put <gi>change</gi> elements inside <gi>revisionDesc</gi> into the correct (latest first) order.</change>
  <change who="mol:HOLM3" when="2013-08-12">Added <gi>profileDesc</gi> containing document type information expressed in <gi>catRef</gi> elements.</change>
  <change who="mol:LAND2" when="2013-07-25" status="draft">Created file. Added contact information and content.</change>
</revisionDesc>
See documentation on general encoding practices for information about how to add draft content to a published page.

References

Cite this page

MLA citation

Jenstad, Janelle, Tye Landels-Gruenewald, Cameron Butt, and Martin D. Holmes. Create a MoEML TEI Header. The Map of Early Modern London, Edition 6.6, edited by Janelle Jenstad, U of Victoria, 30 Jun. 2021, mapoflondon.uvic.ca/edition/6.6/encode_teiHeader.htm.

Chicago citation

Jenstad, Janelle, Tye Landels-Gruenewald, Cameron Butt, and Martin D. Holmes. Create a MoEML TEI Header. The Map of Early Modern London, Edition 6.6. Ed. Janelle Jenstad. Victoria: University of Victoria. Accessed June 30, 2021. mapoflondon.uvic.ca/edition/6.6/encode_teiHeader.htm.

APA citation

Jenstad, J., Landels-Gruenewald, T., Butt, C., & Holmes, M. D. 2021. Create a MoEML TEI Header. In J. Jenstad (Ed), The Map of Early Modern London (Edition 6.6). Victoria: University of Victoria. Retrieved from https://mapoflondon.uvic.ca/editions/6.6/encode_teiHeader.htm.

RIS file (for RefMan, RefWorks, EndNote etc.)

Provider: University of Victoria
Database: The Map of Early Modern London
Content: text/plain; charset="utf-8"

TY  - ELEC
A1  - Jenstad, Janelle
A1  - Landels-Gruenewald, Tye
A1  - Butt, Cameron
A1  - Holmes, Martin
ED  - Jenstad, Janelle
T1  - Create a MoEML TEI Header
T2  - The Map of Early Modern London
ET  - 6.6
PY  - 2021
DA  - 2021/06/30
CY  - Victoria
PB  - University of Victoria
LA  - English
UR  - https://mapoflondon.uvic.ca/edition/6.6/encode_teiHeader.htm
UR  - https://mapoflondon.uvic.ca/edition/6.6/xml/standalone/encode_teiHeader.xml
ER  -

TEI citation

<bibl type="mla"><author><name ref="#JENS1"><surname>Jenstad</surname>, <forename>Janelle</forename></name></author>, <author><name ref="#LAND2"><forename>Tye</forename> <surname>Landels-Gruenewald</surname></name></author>, <author><name ref="#BUTT1"><forename>Cameron</forename> <surname>Butt</surname></name></author>, and <author><name ref="#HOLM3"><forename>Martin</forename> <forename>D.</forename> <surname>Holmes</surname></name></author>. <title level="a">Create a MoEML TEI Header</title>. <title level="m">The Map of Early Modern London</title>, Edition <edition>6.6</edition>, edited by <editor><name ref="#JENS1"><forename>Janelle</forename> <surname>Jenstad</surname></name></editor>, <publisher>U of Victoria</publisher>, <date when="2021-06-30">30 Jun. 2021</date>, <ref target="https://mapoflondon.uvic.ca/edition/6.6/encode_teiHeader.htm">mapoflondon.uvic.ca/edition/6.6/encode_teiHeader.htm</ref>.</bibl>

Personography

Locations