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. They include one or more <respStmt>s. The taxonomies to specify a contributor’s responsibilities are located at the top of the PERS1.xml file. Each <respStmt> contains
  • a <name> element with a @ref attribute pointing to a contributor and
  • at least one <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 markup editor, the transcriber, and the toponymist for The Triumphs of Truth (TRIU1.xml), he gets three <respStmt> elements with his name inside the <name> element. If Quinn MacDonald also serves as markup editor 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.
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 with the @ref value "molresp:mrk".

<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:
  • 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.
  • Information about editing, transcribing, and identifying locations
    • First Transcriber (if there is one): use the @ref value "molresp:trc". In many cases, the first transcriber 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.
    • MoEML Transcriber: use the @ref value "molresp:trc". In most cases, the MoEML transcriber will be the paid team member who corrects the EEBO-TCP transcription and supplies gaps, with or without reference to another source. If the first transcriber is a student at UVic or elsewhere, the MoEML transcriber will check the transcription against the page images. Add a <respStmt> for each person who transcribes any part of the text or checks the transcription. Add a qualifying statement after the name, as appropriate.
    • Toponymist: use the @ref value "molresp:top". The toponymist is the person who identifies the place references in the document, for example, a primary text in the Library or an Encyclopedia entry. 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. You may qualify the term if necessary (for example, if there are different toponymists for different sections of the text).
    • Other roles as necessary (e.g., Annotator, Translator).
  • 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, and <name> tags.
  • 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.
  • Information about project supervisors
    • MoEML Research Fellow (if relevant): use the @ref value "molresp:res". Normally, this person will be the postdoctoral fellow with the team at the time the contribution was added to the project, unless that person is also the Assistant Project Director, in which case we credit him/her as Assistant Project Director instead.
    • Assistant Project Director: use the @ref value "molresp:rth" (Research Team Head) and describe the person as Assistant Project Director. From 15 May 2013, Kim McLean-Fiander is the Assistant Project Director and the MoEML Research Fellow; her former title supersedes the latter.
    • Programmer: use the @ref value "molresp:prg". Normally, this person will be Martin Holmes. Every single file should include this responsibility statement in the penultimate place in the list.
    • 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.
  • Information about born-digital content on this page
    • Author of Critical Introduction (if there is one): use the @ref value "molresp:aui" and describe the person as Author of Critical Introduction, qualifying this term as necessary (e.g., if different parts of the introduction are authored by different people).
    • Author of Textual Introduction (if there is one): use the @ref value "molresp:aui" and describe the person as Author of Textual Introduction, qualifying this term as necessary.
    • Copy Editor: use the @ref value "molresp:pfr" and describe the person as Copy Editor.
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">Aug. 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:top">Toponymist<date when="2012"/></resp>
              <name ref="mol:JENS1">Janelle Jenstad</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:trc">First Transcriber<date notAfter="2010"/></resp>
              <name ref="mol:EEBO3">EEBO-TCP</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:trc">MoEML 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">Markup Editor<date when="2012"/></resp>
              <name ref="mol:JENS1">Janelle Jenstad</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:cpy">Copy Editor<date when="2012"/></resp>
              <name ref="mol:BUTT1">Cameron Butt</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:rth">Assistant Project Director<date from="2013"/></resp>
              <name ref="mol:MCFI1">Kim McLean-Fiander</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:prg">Programmer<date from="2013"/></resp>
              <name ref="mol:HOLM3">Martin Holmes</name>
            </respStmt>

            <respStmt>
              <resp ref="molresp:pdr">Project Director<date from="2012-11"/></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:
  • 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.
  • Create a new <change> element. Your new element should be nested above the other <change> elements, within the <revisionDesc> element.
  • 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.
  • 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.
  • 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.
  • 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, edited by Janelle Jenstad, U of Victoria, 26 Jun. 2020, mapoflondon.uvic.ca/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. Ed. Janelle Jenstad. Victoria: University of Victoria. Accessed June 26, 2020. https://mapoflondon.uvic.ca/encode_teiHeader.htm.

APA citation

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

RIS file (for RefMan, 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
PY  - 2020
DA  - 2020/06/26
CY  - Victoria
PB  - University of Victoria
LA  - English
UR  - https://mapoflondon.uvic.ca/encode_teiHeader.htm
UR  - https://mapoflondon.uvic.ca/xml/standalone/encode_teiHeader.xml
ER  -

RefWorks

RT Web Page
SR Electronic(1)
A1 Jenstad, Janelle
A1 Landels-Gruenewald, Tye
A1 Butt, Cameron
A1 Holmes, Martin
A6 Jenstad, Janelle
T1 Create a MoEML TEI Header
T2 The Map of Early Modern London
WP 2020
FD 2020/06/26
RD 2020/06/26
PP Victoria
PB University of Victoria
LA English
OL English
LK https://mapoflondon.uvic.ca/encode_teiHeader.htm

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 <title level="m">MoEML</title> TEI Header</title>. <title level="m">The Map of Early Modern London</title>, edited by <editor><name ref="#JENS1"><forename>Janelle</forename> <surname>Jenstad</surname></name></editor>, <publisher>U of Victoria</publisher>, <date when="2020-06-26">26 Jun. 2020</date>, <ref target="https://mapoflondon.uvic.ca/encode_teiHeader.htm">mapoflondon.uvic.ca/encode_teiHeader.htm</ref>.</bibl>

Personography