Home > Project Documentation > Documentation for Encoders

Understand MoEML’s Website and Document Structure

roseList documents mentioning Understand MoEML’s Website and Document Structure

Introduction

This manual provides instructions for encoders, editors, and contributors working on MoEML’s XML documents. It includes information about the website structure and document types. Please do not hesitate to contact the MoEML team for additional assistance.
Because MoEML’s practices are always being updated, please refer back to this manual frequently.

Static Website Build

Beginning with version 6, MoEML’s publication process moved to a static build model. What this means is that all of the encoded documents, which are kept in the Subversion repository, are processed into HTML documents that all sit together in the same folder. Subfolders contain various other resources such as images, JavaScript and CSS files, and the various XML versions of our files that we provide for others to download and use.
When the build runs (either locally if you run it on your own machine, or more commonly when our Jenkins Continuous Integration server runs it automatically), a folder called site is created inside the static folder. site contains, as you might expect, the entire MoEML website. It is fully functional; you can open any of its pages in a web browser and it will work. This fully-functional site is the development version we access and use every day from the Jenkins server. Beginning with version 6.4, this static version now includes a static search engine built using the Project Endings staticSearch codebase developed by Martin Holmes and Joey Takeda, so we have no further need for the eXist XML database which was previously used to power the search.
When we are ready to publish a new version, we simply set the new version number in the VERSION file (in the root folder of the repository), let Jenkins do run its build process, and after final checks, we archive the old version of the site and push the new content up to the HCMC web server.

Document Collection

MoEML’s document collection (i.e. the data folder in the Subversion repository) consists of several types of documents. With the exception of files that are themselves database-like (such as the personography, PERS1.xml, or the bibliography, BIBL1.xml), these documents fall into two main categories: born-digital documents and transcriptions of primary sources. These different types of scholarly endeavour have different encoding needs.
In the case of born-digital documents, we are creating the resource for the first time; that means we are generating both the content and the representational features as a single creative act, and we encode following our project style guide with the intention that the rendered result conforms with the rest of the born-digital content on our site. In this sense, we tend to encode with one eye on the rendered result.
The case of primary-source transcriptions is very different. We strive to represent the original source document as faithfully as possible. In other words, we classify different components of the document (front matter, body, back matter, title page, chapter, etc.) and describe how things appear (small-caps, italic, centre-aligned, and so on). The overriding concern here is to tell the truth. We transcribe the source text, tag it to represent its structure and components, and describe how it appears using CSS properties and values in the @style attribute.

Document Structure

All of MoEML’s data is in TEI P5 XML document form. This structure is made public through the See XML link in the sidebar on every page. These documents should all validate against a standard P5 schema, and they fall into three distinct categories: simple documents, location documents, and complex (multi-text) documents. Each of these document types has a template that editors can use. These files are saved in the subversion repository under templates.

Simple Documents

Most of the XML files in the MoEML database, whether they are born-digital contributions or primary sources that we have transcribed, share a common file structure. They consist of a <teiHeader> and a single <text> element. The basic structure of a simple document looks something like this:
<TEI version="5.0" xml:id="about">
  <teiHeader>
    <fileDesc>
      <titleStmt>
        <title>About MoEML</title>
        <respStmt>
          <name ref="mol:BUTT1">Cameron Butt</name>
          <resp ref="molresp:mrk">Encoder<date from="2012" to="2013"/></resp>
        </respStmt>
        <!-- Many more respStmts -->
        <respStmt>
          <name ref="mol:JENS1">Janelle Jenstad</name>
          <resp ref="molresp:pdr">Project Director<date notBefore="1999"/></resp>
        </respStmt>
      </titleStmt>
      <publicationStmt>
        <!-- Our publication statements are brought in through a process called xincludes -->
        <!-- &lt;xi:include xmlns:xi="http://www.w3.org/2001/XInclude" ...&gt; &lt;/xi:include&gt; -->
      </publicationStmt>
      <sourceDesc>
        <p>[Information about the source document, if applicable]</p>
      </sourceDesc>
      <profileDesc>
        <textClass>
          <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtBornDigital"/>
          <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtParatext"/>
          <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtLandingPage"/>
        </textClass>
      </profileDesc>
      <encodingDesc>
        <p>Our editorial and encoding practices are documented in detail in the <ref target="mol:praxis">Praxis</ref> section of our website.</p>
      </encodingDesc>
      <revisionDesc status="published">
        <change who="mol:HOLM3" when="2013-12-19">Added global publicationStmt through XInclude.</change>
      </revisionDesc>
    </fileDesc>
  </teiHeader>
  <text>
    <front>
      <docTitle>
        <titlePart>About MoEML</titlePart>
      </docTitle>
    </front>
    <body>
      <div>
        <head>Topic the first</head>
        <p>[Paragraph content]</p>
        <p>[Paragraph content]</p>
      </div>
    </body>
  </text>
</TEI>
Some points to note:
  • The @xml:id attribute on the root <TEI> element should be the same as the name of the file, but without its extension (.xml). So when the file is called about.xml, the @xml:id attribute should be "about".
  • Some of the content in the header is pulled in to the file automatically through the use of XInclude. This enables us to maintain a single central copy of blocks of content which are going to be the same for many different files.
  • Every document is characterized by several <catRef> elements which refer to categories in our document type taxonomy.
  • There is only one <text> element.
  • The title of the document (which will appear at the head of the page in the rendered web output) is contained in a <titlePart> element inside <front>/<docTitle>.
  • The main content is contained in one or more <div> element(s), containing <head>s.
Tags and attributes used to mark up the content itself are covered in more detail below.
Some simple documents will have subsections and even sub-subsections. This is achieved by using nested <div> elements. Nesting can be as deep as required, but should be kept as simple as possible. For instance, this is a page which has an introduction and two subsections:
<text>
  <front>
    <docTitle>
      <titlePart>Document Title</titlePart>
    </docTitle>
  </front>
  <body>
    <div>
      <p>Introduction</p>
      <div>
        <head>Subsection 1 Title</head>
        <p>Paragraph one</p>
        <p>Paragraph two</p>
      </div>
      <div>
        <head>Subsection 2 Title</head>
        <p>Paragraph one</p>
        <p>Paragraph two</p>
      </div>
    </div>
  </body>
</text>

Location Documents

Location documents are similar to simple documents insofar as they contain only one text element and usually have a straightforward structure. The two defining aspects of location documents are the <facsimile> element, which specifies the location’s position on the Agas map, and the <div> element with a @type value of "placeInfo", which contains the location’s geo-coordinates. ABCH1.xml exemplifies is the basic outline of a location document:
<TEI version="5.0" xml:id="ABCH1">
  <teiHeader>
    <profileDesc>
      <textClass>
        <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtBornDigital"/>
        <catRef scheme="mdt:molDocumentTypes" target="mdt:mdtEncyclopediaLocationStreet"/>
      </textClass>
      <abstract>
        <p><ref target="mol:ABCH1">Abchurch Lane</ref> runs north-south from <ref target="mol:LOMB1">Lombard Street</ref> to <ref target="mol:CAND1">Candlewick (Cannon) Street</ref>. The Agas Map labels it <quote><ref target="mol:ABCH1">Abchurche lane</ref>.</quote> It lies mainly in <ref target="mol:CAND2">Candlewick Street Ward</ref>, but part of it serves as the boundary between <ref target="mol:LANG1">Langbourne Ward</ref> and <ref target="mol:CAND2">Candlewick Street Ward</ref>.</p>
      </abstract>
    </profileDesc>
  </teiHeader>
  <facsimile>
    <surface>
      <graphic url="agas_full.jpg"/>
      <zone xml:id="ABCH1_agas" points="17255,5911 17255,5644 17281,5484 17314,5303 17345,5182"></zone>
    </surface>
  </facsimile>
  <text>
    <front>
      <docTitle>
        <titlePart>Abchurch Lane</titlePart>
      </docTitle>
    </front>
    <body>
      <div type="placeInfo">
        <head>Abchurch Lane</head>
        <listPlace>
          <place corresp="#ABCH1_agas">
            <placeName>Abchurch Lane</placeName>
            <location source="mol:LAAR1 http://archive.museumoflondon.org.uk/laarc/catalogue/siteinfo.asp?id=4926" resp="mol:JENS1">
              <geo>51.5123897,-0.0875297</geo>
            </location>
          </place>
        </listPlace>
      </div>
      <div>
        <p><ref target="mol:ABCH1">Abchurch Lane</ref> runs north-south from <ref target="mol:LOMB1">Lombard Street</ref> to <ref target="mol:CAND1">Candlewick (Cannon) Street</ref>.<!-- [More about Abchurch Lane] --> </p>
      </div>
    </body>
  </text>
</TEI>

The <abstract> Element

Use the <abstract> element to tag a 150 word abstract that provides a summative and interesting overview of the location. Preferably, the abstract should be equal to (or at least a portion of) the first paragraph. This description appears in the pop-up generated when users click on the hyperlinked name of the location in a library and encyclopedia document. As noted in the example above, the <abstract> element is nested within the <profileDesc> element in the <teiHeader>. Note that the description itself should be tagged with a <p> element within the <abstract> element.

Authority Names

The <title> element determines the authority name of the location, the name that we determine to be most commonly used in London around 1598-1603. From all the place’s name variants, the authority name is the definitive name by which we refer to the place. Often the authority name is the one used by the institution occupying the place itself, if such a self-referential document is available. For example, the Bills of Mortality serve as a good source of authority names for parish churches because the Parish Clerks’ Company compiles the bill, which is full of place names of churches and parishes (Jenstad 138).

The <facsimile> Element

The <facsimile> element specifies that there is one surface (<surface>) on which this location is depicted. In all location documents, the graphic for that surface is agas_full.jpg, our facsimile of the Agas map; we encode this graphic using a simple TEI <graphic> tag with a @url attribute. On that graphic, the location is depicted as a series of pixel points, which, together, constitute a zone (<zone>) of the graphic. Each pixel point consists of an x and y coordinate separated by a comma without a space. A space ( ) separates each pair of coordinates. We assign the <zone> element an @xml:id value, which enables us to point to it later in the file. The @xml:id value, "ABCH1_agas" in the example above, is constructed from the @xml:id of the location document, an underscore, and agas. For more information about the <facsimile> element, see documentation on adding MoEML locations to the Agas map.
Note that some older location documents may include an additional <surface> element nested within the <facsimile> element. The contents of this additional <surface> element point to the location’s position on MoEML’s former, now-deprecated version of the Agas map, which was divided into tiles. This content may be removed in the future, but should be ignored for the time being.
Note also that, sometimes, a place will be located outside of the area depicted in the Agas map. In such instances, leave the @url value field associated with the <graphic> element blank and encode only a self-closing <zone> element without an @xml:id. For example,
<facsimile>
  <surface>
    <graphic url=""/>
    <zone></zone>
  </surface>
</facsimile>

The <div type="placeInfo"> Element

The <div type="placeInfo"> element nests a <head> element, which designates the location page’s title, and the <listPlace> element, which contains geographical information about the location. In the example above, <listPlace> contains only one <place> element, but in some cases there will be several. For example, if the same street appears on multiple map tiles, it may be split into separate sections. In such cases, different sections may require different names, so each <place> has contains a <placeName> element. <place> elements must also have a @corresp value that points to the <zone> element nested inside the <facsimile> element, thereby specifying that the <place> element is located at the position specified by the corresponding <zone> element. The value of the @corresp attribute should be the @xml:id of the corresponding <zone> element.
For information about encoding geo-coordinates inside the <place> element using the <location> and <geo> elements, see documentation on encoding geo-coordinates in a location document.

Database Files

Some special files—the bibliography (BIBL1.xml), the personography (PERS1.xml), the glossary of terms (GLOSS1.xml), the orgography (ORGS1.xml), and the linksography (LINKS.xml)—are centralized databases, containing information related to bibliographical material, events, terms, organizations, and people that are mentioned on the site.

Bibliography (BIBL1.xml)

BIBL1.xml, MoEML’s bibliography database, is structured as follows:
<TEI version="5.0" xml:id="BIBL1">
  <teiHeader>
  </teiHeader>
  <text>
    <body>
      <div>
        <listBibl>
          <bibl xml:id="XXXX1">[Bibliographical reference.]</bibl>
          <bibl xml:id="XXXX2">[Bibliographical reference.]</bibl>
          <bibl xml:id="XXXX3">[Bibliographical reference.]</bibl>
        </listBibl>
      </div>
    </body>
  </text>
</TEI>
BIBL1.xml is a works cited and consulted list for MoEML. Each individual <bibl> entry corresponds to a source referenced in our document structure. The content of a <bibl> tag should reflect MoEML’s standards for citation, which are outlined fully in the MoEML Guide to Editorial Style. Each <bibl> element should be assigned a unique @xml:id and a @type value of "prim", "sec", or "both":
  • Entries for primary sources should have a @type value of "prim". Primary sources are materials that provide first-hand information or original data on a topic (Primary or Secondary Sources). The Agas map and Thomas Dekker’s The Shoemaker’s Holiday are both primary sources in BIBL1.xml.
  • Entries that are secondary sources should have a @type value of "sec". Secondary sources are works that are one step removed from the original source, usually describing, summarizing, analyzing, evaluating, derived from, or based on primary source materials (Primary or Secondary Sources). David Bevington’s Tudor Drama and Politics and Janelle Jenstad’s The City Cannot Hold You: Social Conversion in the Goldsmith’s Shop are both secondary sources in BIBL1.xml.
  • Entries that function both as primary sources and secondary sources should have a @type value of "both". For example, John Stow’s Survey of London uses both unmediated, primary source methodologies and mediated, secondary source methodologies; we therefore assign this source a @type value of "both".
Inside the <bibl> tag, the following citation components, when present, should be tagged as follows:
Component ▼ Relevant Tag ▼ Example ▼
Author’s name Tag each author’s name with the <author> tag.
<author>Barber, Bruno</author> and <author>Christopher Thomas</author>
Title of an article in a periodical Tag the title of an article with the <title> tag with a @level value of "a".
<title level="a">Middleton’s Civic Employments</title>
Title of a chapter in a monograph Tag the title of a chapter with the <title> tag with a @level value of "a".
<title level="a">The Significance of the Metropolis</title>
Title of a webpage Tag the title of a webpage with the <title> tag with a @level value of "a".
<title level="a">Catalogue</title>
Title of a periodical Tag the title of a periodical with the <title> tag with a @level value of "j".
<title level="j">Early Theatre</title>
Title of a monograph Tag the title of a monogrpah with the <title> tag with a @level value of "m".
<title level="m">Literature and Architecture in Early Modern England</title>
Title of a website Tag the title of a website with the <title> tag with a @level value of "m".
<title level="m">Shakespearean London Theatres</title>
Editor, translator, or compiler’s name Tag each editor, translator, or compiler’s name with the <editor> tag.
Ed. <editor>Ian Gadd</editor> and <editor>Alexandra Gillespie</editor>
Trans. <editor>David Gerard</editor>
Identification Numbers Tag identification codes such as, DOI, STC, and ESTC numbers with the <idno> tag with a @type attribute whose value corresponds to the identifier type.
doi:<idno type="DOI">10.1111/j.1475-6757.2000.tb01171.x</idno>.
or
STC <idno type="STC">25264</idno>.
Stable URLs Tag stable URLs with the <ref> element with a @target attribute whose value is the URL itself.
<ref target="https://www.museumoflondon.org.uk/collections/other-collection-databases-and-libraries/museum-london-archaeological-archive">https://www.museumoflondon.org.uk/collections/other-collection-databases-and-libraries/museum-london-archaeological-archive</ref>.
Dates Tag dates with the <date> element. See documentation on encoding dates.
<date when="1912">1912</date>
or
<date when-custom="1583" datingMethod="mol:julianSic" calendar="mol:julianSic">1583</date>
At this moment, all other components of a citation do not need to be tagged. In the long term, MoEML plans to elaborate the markup of bibliographical entries so that dates, publishers, and publication places will also be tagged.

Sample Entries

The following table oultines how to structure BIBL1.xml entries for common source types.
Source Type▼ Template▼ Example Code▼
Printed monograph
Author Surname, Author Forename. Title of Monograph. Place of Publication: Publisher, Year of Publication. Medium designation (Print).
<bibl xml:id="BEVI6" type="sec"><author>Bevington, David</author>. <title level="m">Tudor Drama and Politics: A Critical Approach to Topical Meaning</title>. Cambridge: Harvard UP, <date when="1968">1968</date>. Print.</bibl>
Article or chapter in a printed volume
Author Surname, Author Forename. Title of Article/Chapter. Title of Volume. Ed. Editor Forename Editor Surename Place of Publication: Publisher, Year of Publication. Page range of article/chapter. Medium designation (Print).
<bibl xml:id="ADEL2" type="sec"><author>Adelman, Janet</author>. <title level="a">Making Defect Perfection: Shakespeare and the One-Sex Model</title>. <title level="m">Enacting Gender on the English Renaissance Stage</title>. Ed. <editor>Viviana Comensoli</editor> and <editor>Anne Russell</editor>. Chicago: U of Illinois P, <date when="1999">1999</date>. 23–52. Print.</bibl>
Entire website
Title of Website. Website Sponsor or Publisher (if available and different from website title). Homepage URL.
<bibl xml:id="LBTD1" type="sec"><title level="m">London Book Trades Database</title>. <sponsor>Oxford Bibliographical Society</sponsor>. <ref target="http://lbt.bodleian.ox.ac.uk/mediawiki/index.php/Main_Page">http://lbt.bodleian.ox.ac.uk/mediawiki/index.php/Main_Page</ref>.</bibl>
Page within a website
Author Surname, Author Forename (if available). Title of Page on Website. Title of Website. Ed. Editor Forename Editor Surname (if available). Website Sponsor or Publisher (if available and different from website title). Page URL.
<bibl xml:id="BEVI7" type="sec"><author>Bevington, David</author>. <title level="a">Henry IV, Part 1</title>. <title level="m">Enyclopedia Britannica</title>. <ref target="http://www.britannica.com/EBchecked/topic/261756/Henry-IV-Part-1">http://www.britannica.com/EBchecked/topic/261756/Henry-IV-Part-1</ref>.</bibl>
<bibl xml:id="BLAI2" type="sec"><author>Blaisdell, Theodore A</author>. <title level="a">Mapping Significance: Geographical Musings on the Three <quote>hoe</quote> plays</title>. <title level="m">Lehigh Preserve</title>. <sponsor>Lehigh University</sponsor>. <ref target="https://preserve.lehigh.edu/etd/488/">https://preserve.lehigh.edu/etd/488/</ref>.</bibl>
Journal article accessed online
Author Surname, Author Forename. Title of Article. Title of Periodical Volume.Issue (YYYY): Page range of article. doi:doi_number (if available).
<bibl xml:id="LILL3" type="sec">
  <author>Lilley, Keith D.</author> <title level="a">Urban Planning After the Black Death: Townscape Transformation in Later Medieval England (1350–1530)</title>. <title level="j">Urban History</title> 42.1 (<date when="2015">2015</date>): 22–42. doi:<idno type="DOI">10.1017/S0963926814000492</idno>. </bibl>
If there is no DOI, leave an XML comment.
<bibl xml:id="BLAN2" type="sec">
  <author>Bland, Mark</author>. <title level="a">The Appearance of the Text in Early Modern England</title>. <title level="j">Text</title> 11 (<date when="1998">1998</date>): 91–154.<!-- No DOI. -->
</bibl>

More Information

For more information about MoEML’s bibliogrpahy practices, see documentation on styling works cited.
For information about how to encode in-text citations, see documentation on linking to reference material in BIBL1.xml..

Personography (PERS1.xml)

The personography file is structured as follows:
<TEI version="5.0" xml:id="PERS1">
  <teiHeader><!-- TEI header goes here. --> </teiHeader>
  <text>
    <body>
      <div>
        <listPerson>
          <person><!-- Person entry --> </person>
          <person><!-- Person entry --> </person>
          <person><!-- Person entry --> </person>
        </listPerson>
      </div>
    </body>
  </text>
</TEI>
The file contains information about historical and literary persons, as well as modern contributors. An individual entry looks like this:
<person xml:id="BARO3" sex="1">
  <persName type="hist">
    <reg>William Barons</reg>
    <forename>William</forename>
    <surname>Barons</surname>
    <roleName>Bishop of London</roleName>
  </persName>
  <death when-custom="1505" datingMethod="mol:julianSic" precision="high"/>
  <note>
    <p>Bishop of <ref target="mol:LOND5">London</ref>
      <date from-custom="1504" to-custom="1505" datingMethod="mol:julianSic">1504–1505</date>.</p>
    <list type="links">
      <item><ref target="http://www.oxforddnb.com/view/article/1501?docPos=5"><title level="m">ODNB</title></ref></item>
      <item><ref target="https://en.wikipedia.org/wiki/William_Barons"><title level="m">Wikipedia</title></ref></item>
    </list>
  </note>
</person>
For a thorough explanation of how to encode a personography entry, see Encode Persons.

Linking Names to the Personography

For instructions on how to tag and link to personography entries within a document, refer to MoEML’s instructions for linking to people in PERS1.xml.

Glossary (GLOSS1.xml)

The Glossary of Early Modern Terms database (GLOSS1.xml) is arranged in much the same way as PERS1.xml and BIBL1.xml. However, instead of listing the entries in a <listPerson> or <listBibl>, a simple <list> element is used, with a @type value of "glossary". Each term is then listed as an <item> with its @xml:id declared in an attribute. Each <item> contains a <term> with its regularized spelling and a <note> element with a <p> element containing a description of the term. For example,
<list type="glossary">
  <item xml:id="XXXX10"><term>Term</term>
    <note><p>Definition of term.</p></note>
  </item>
  <item xml:id="XXXX11"><term>Term</term>
    <note><p>Definition of term.</p></note>
  </item>
</list>
For instructions on how to tag and link to glossary entries within a document, refer to MoEML’s instructions for linking to glossary entries in GLOSS1.xml.

Orgography (ORGS1.xml)

The orgography database (ORGS1.xml) consists of six <listOrg> elements in which related <org> elements are nested:
<TEI version="5.0" xml:id="XMPL1">
  <teiHeader><!-- TEI header goes here. --> </teiHeader>
  <text>
    <front>
      <docTitle>
        <titlePart type="main">Complete Orgography</titlePart>
      </docTitle>
    </front>
    <body>
      <div>
        <listOrg xml:id="xmpl_em_livery_greater">
          <head>Greater Livery Companies</head>
          <org xml:id="XMPL2">[Organization entry]</org>
          <org xml:id="XMPL3">[Organization entry]</org>
        </listOrg>
        <listOrg xml:id="xmpl_em_livery_lesser">
          <head>Lesser Livery Companies</head>
          <org xml:id="XMPL4">[Organization entry]</org>
          <org xml:id="XMPL5">[Organization entry]</org>
        </listOrg>
        <listOrg xml:id="xmpl_em_playing">
          <head>Playing Companies</head>
          <org xml:id="XMPL6">[Organization entry]</org>
          <org xml:id="XMPL7">[Organization entry]</org>
        </listOrg>
        <listOrg xml:id="xmpl_em_other">
          <head>Other EM Organizations</head>
          <org xml:id="XMPL8">[Organization entry]</org>
          <org xml:id="XMPL9">[Organization entry]</org>
        </listOrg>
        <listOrg xml:id="xmpl_modern">
          <head>Modern Organizations</head>
          <org xml:id="XMPL10">[Organization entry]</org>
          <org xml:id="XMPL11">[Organization entry]</org>
        </listOrg>
        <listOrg xml:id="xmpl_ppp">
          <head>Pedagogical Partnership Project</head>
          <org xml:id="XMPL12">[Organization entry]</org>
          <org xml:id="XMPL13">[Organization entry]</org>
        </listOrg>
      </div>
    </body>
  </text>
</TEI>
Each <org> element represents an individual database entry for an organization. Databse entries (i.e., <org> elements) must be assigned a unique @xml:id as well as a @type attribute with a value of either "greater", "lesser", "playingCo", "other", "modern", or "ppp". Database entries must also contain the following elements:
  1. An <orgName> element, which is used to tag the full name of the organization
  2. A <note> element
    1. A <p> element, which is nested inside of the <note> element and is used to tag a short text string describing the organization
Depending on the type of organization, databse entries (i.e., <org> elements) may be assigned a @subtype element and may contain one or more of the follwoing elements:
  1. A <reg> element, which is nested inside of the <orgName> element and is used to tag a regularized spelling of the name of the organization
  2. A <figure> element, which is nested inside of the <note> element and encodes a graphic associated with the organization. For instructions on encoding graphics, see Graphics.
  3. A <listPerson> element, which is used to reference one or more person(s) associated with the organization
    1. A <head> element, which is nested inside of the <listPerson> element and is used to tag a label for the list
    2. People associated with the organization are represented by a self-closing <person> element. At least one <person> element must be nested inside of the <listPerson> element. Each <person> element must have a @corresp attribute that points to the @xml:id of a person in the personography database (PERS1.xml).
  4. A <listOrg> element in which database entries for subsidiary organizations (i.e., <org> elements) are nested.
The following subsection, Types of Organizations, outlines when to use the optional elements and attribute isted above.

Types of Organizations

Six categories of organizations are included in the orgography database (ORGS1.xml):
  1. greater livery companies
  2. lesser livery companies
  3. playing companies
  4. other early modern organizations
  5. modern organizations
  6. pedagogical partnership project groups
Each category corresponds with an individual <listOrg> parent element. Depending on how an organization is classified, you must use different elements, attributes, and values when encoding a database entry.
Greater Livery Companies
Each of the twelve great livery companies of London have already been added to the ORGS1.xml database. In these entries, the <org> element has a @type value of "greater" as well as a @subtype value of one one of "R1", "R2", "R3" Gap in transcription. Reason: Editorial omission for reasons of length or relevance. Use only in quotations in born-digital documents.[…] "R12". The latter value indicates the ranking of the greater livery company, as established in 1515. Consider the following example of a database entry for a greater livery company:
<org xml:id="XMPL14" type="greater" subtype="R3">
  <orgName>The Worshipful Company of Drapers</orgName>
  <note><p><name type="org" ref="mol:XMPL14">The Drapers’ Company</name> was one of the twelve great companies of London. <name type="org" ref="mol:DRAP3">The Drapers</name> were third in the order of precedence established in <date when-custom="1515" datingMethod="mol:julianSic" calendar="mol:julianSic">1515</date>. <name type="org" ref="mol:DRAP3">The Worshipful Company of Drapers</name> is still active and maintains a website at <ref target="http://www.thedrapers.co.uk/">http://www.thedrapers.co.uk/</ref>, with a <ref target="http://www.thedrapers.co.uk/History/1_Introduction.html">history</ref> and <ref target="http://www.thedrapers.co.uk/History/reading.html">short bibliography</ref>.</p></note>
</org>
Lesser Livery Companies
When adding an entry for one of the lesser livery companies of London, add only a @type value of "lesser" to the <org> element. No @subtype attribute is required. Consider the following example of a database entry for a lesser livery company:
<org xml:id="XMPL15" type="lesser">
  <orgName>The Worshipful Company of Carpenters</orgName>
  <note><p><name type="org" ref="mol:XMPL15">The Carpenters’ Company</name> was one of the lesser livery companies of London.</p></note>
</org>
Playing Companies
When adding an entry for an early modern playing company, add only a @type value of "playingCo" to the <org> element. No @subtype attribute is required. Consider the following example of a database entry for a playing company:
<org xml:id="XMPL16" type="playingCo">
  <orgName>Lady Elizabeth’s Men<reg>Lady Elizabeth’s Men</reg></orgName>
  <note><p><name type="org" ref="mol:XMPL16">Lady Elizabeth’s Men</name> was a playing company in early modern London. The group was formed in 1611 and was named after Princess Elizabeth, daughter of <name ref="mol:JAME1">King James I</name>. After she married in 1618, the company changed its name to The Queen of Bohemia’s Men.</p></note>
</org>
Other Organizations
When adding an entry for an early modern organization that is not a livery company, add only a @type value of "other" to the <org> element. No @subtype value is required. Consider the following example of a database entry for an organization other than a livery company:
<org xml:id="XMPL17" type="other">
  <orgName>The Corporation of London</orgName>
  <note><p>The <name type="org" ref="mol:XMPL17">Corporation of London</name> was the municipal government for the <ref target="mol:LOND5">City of London</ref>, made up of the <name type="org" ref="mol:MAYO2">Mayor of London</name>, the <name type="org" ref="mol:ALDE7">Court of Aldermen</name>, and the <name type="org" ref="mol:COUN5">Court of Common Council</name>. It exists today in largely the same form.</p></note>
</org>
Modern Organizations
When adding an entry for a modern organization, add only a @type value of "modern" to the <org> element. No @subtype value is required. Consider the following example of a database entry for a modern organization:
<org xml:id="XMPL18" type="modern">
  <orgName><reg>EEBO-TCP</reg>Early English Books Online–Text Creation Partnership</orgName>
  <note><p>
    <quote><name ref="mol:XMPL18" type="org">EEBO-TCP</name> is a partnership with ProQuest and with more than 150 libraries to generate highly accurate, fully-searchable, SGML/XML-encoded texts corresponding to books from the Early English Books Online Database. <name type="org" ref="mol:XMPL17">EEBO-TCP</name> maintains a website at <ref target="http://www.textcreationpartnership.org/tcp-eebo/">http://www.textcreationpartnership.org/tcp-eebo/</ref>.</quote>
  </p></note>
</org>
Teams
Teams (e.g., the Editorial Board, the Advisory Board, the MoEML Team) are also considered modern organizations. When adding an entry for a team, add a @type value of "modern" to the <org> element. No @subtype value is required. Unlike other modern organizations, entries for teams require a list of team members. To encode a list of team members, insert a <listPerson> element after the <orgName> element but before the <note> element. Inside the <listPerson> element nest self-closing <person> elements with @corresp values pointing to each team member’s @xml:id in the personography database (PERS1.xml).
Teams can be divided into subunits. For example, the MoEML Team is divided into Project Leaders, Student Research Assistants, Alumni, etc. If a team includes subunits, insert a <listOrg> element inside the database entry (i.e., <org> element) for the team. Nest additional database entries (i.e., <org> elements) for each subunit inside the <listOrg> element. Entries for subunits should follow the data structure outlined here for teams and should be assigned an @xml:id that is prefixed with the @xml:id of their parent entry (e.g., XMPL20_1, XMPL20_2, etc.). Note that it is possible to encode database entries for subunits of subunits (and so on) using the <listOrg> element. Note also that, when a team includes subunits, team members should be listed in the specific subunit to which they belong (e.g., project leaders are listed in the database entry for the Project Leaders subunit, which is a child of the database entry for the MoEML team).
Consider the following examples of database entries for teams:
<org xml:id="XMPL19" type="modern">
  <orgName>Editorial Board</orgName>
  <listPerson>
    <person corresp="mol:XMPL20"></person>
    <person corresp="mol:XMPL21"></person>
    <person corresp="mol:XMPL22"></person>
    <person corresp="mol:XMPL23"></person>
    <person corresp="mol:XMPL24"></person>
    <person corresp="mol:XMPL25"></person>
  </listPerson>
  <note><p>Editorial board.</p></note>
</org>
<org xml:id="XMPL26" type="modern">
  <orgName>The University of Victoria Humanities Computing and Media Centre <reg>HCMC</reg></orgName>
  <listOrg>
    <org xml:id="XMPL26_1" type="modern">
      <orgName>HCMC Programmers for MoEML</orgName>
      <listPerson>
        <person corresp="mol:ARNL1"></person>
        <person corresp="mol:HOLM3"></person>
      </listPerson>
      <note><p>HCMC staff who have worked as programmers on the MoEML project.</p></note>
    </org>
    <org xml:id="XMPL26_2" type="modern">
      <orgName>HCMC Graphic editors for MoEML</orgName>
      <listPerson>
        <person corresp="mol:NEWT2"></person>
        <person corresp="mol:HOLM3"></person>
      </listPerson>
      <note><p>HCMC staff who have worked as graphics editors on the MoEML project.</p></note>
    </org>
  </listOrg>
  <listPerson>
    <person corresp="mol:NAZA1"></person>
  </listPerson>
  <note>
    <p>HCMC staff have collaborated in the project as <name type="org" ref="mol:XMPL26_1">programmers</name> and <name type="org" ref="mol:XMPL26_2">graphics editors</name>. The mandate of the HCMC is to further research, teaching and learning in the faculty of Humanities, in particular the fields of Humanities Computing and Language Learning. We host a research and development office and manage a room of bookable computer workstations for use by faculty, research assistants etc. participating in projects supported by the HCMC.</p>
  </note>
</org>
Pedagogical Partnership Project Groups
When adding an entry for a pedagogical partnership group, add a @type value of "ppp" to the <org> element. No @subtype value is required. Next, insert a <listPerson> element after the <orgName> element but before the <note> element. Inside the <listPerson> element nest self-closing <person> elements with @corresp values pointing to each student’s @xml:id in the personography database (PERS1.xml). Insert a header (tagged using the <head> element) that reads Student Contributors inside the <listPerson> element before the series of <person> tags.
Pedagogical partnership groups can be divided into student groups. For example, a set of student groups in a class will often work on a series of encyclopedia articles. If a pedagogical partnership group includes student groups, insert a <listOrg> element inside the database entry (i.e., <org> element) for the group. Nest additional database entries (i.e., <org> elements) for each student group inside the <listOrg> element. Entries for student groups should follow the data structure outlined here for pedagogical partnership groups and should be assigned an @xml:id that is prefixed with the @xml:id of their parent entry (e.g., XMPL28_1, XMPL28_2, etc.). Note that students should be listed in the specific student group to which they belong (e.g., members of the Student Group A are listed in the database entry for the Student Group A, which is a child of the database entry for the Class 101).
Consider the following examples of a database entries for pedagogical partnership groups:
<org type="ppp" xml:id="XMPL27">
  <orgName>Exeter University EAS 124 Fall 2014 Contributors</orgName>
  <listPerson>
    <head>Student Contributors</head>
    <person corresp="mol:AINS1"></person>
    <person corresp="mol:DAWS2"></person>
    <person corresp="mol:FORD2"></person>
  </listPerson>
  <note><p>Student contributors enrolled in <emph>EAS 124: Country, City and Court: Renaissance Literature, 1558-1618</emph> at University of Exeter in the Fall 2014 session, working under the guest editorship of <name ref="mol:FROS1">Briony Frost</name>.</p></note>
</org>
<org type="ppp" xml:id="XMPL28">
  <orgName>Marylhurst University English 386 Fall 2014 Students</orgName>
  <listOrg>
    <org type="ppp" xml:id="XMPL28_1">
      <orgName>Marylhurst University English 386 Fall 2014 Student Group 1</orgName>
      <listPerson>
        <head>Student Contributors</head>
        <person corresp="mol:ANDE1"></person>
        <person corresp="mol:BRIM1"></person>
        <person corresp="mol:LAMP1"></person>
        <person corresp="mol:SMIT16"></person>
      </listPerson>
      <note><p>Student contributors enrolled in <emph>English 386: The Eternal City: Rome in the Western Literary Imagination</emph> at Marylhurst University in the Summer 2014 session, working under the guest editorship of <name ref="mol:ROLA1">Meg Roland</name>.</p></note>
    </org>
    <org type="ppp" xml:id="XMPL28_2">
      <orgName>Marylhurst University English 386 Fall 2014 Student Group 2</orgName>
      <listPerson>
        <head>Student Contributors</head>
        <person corresp="mol:ALLE7"></person>
        <person corresp="mol:BEAC3"></person>
        <person corresp="mol:GILB5"></person>
        <person corresp="mol:STEA2"></person>
      </listPerson>
      <note><p>Student contributors enrolled in <emph>English 386: The Eternal City: Rome in the Western Literary Imagination</emph> at Marylhurst University in the Summer 2014 session, working under the guest editorship of <name ref="mol:ROLA1">Meg Roland</name>.</p></note>
    </org>
  </listOrg>
</org>

Linking Organization Names to the Orgography

For instructions on how to tag and link to orgography entries within a document, refer to MoEML’s instructions for linking to organizations in ORGS1.xml.

MoEML Paratext (Info Pages)

Paratextual pages such as About are XML files like any other. They are saved in the /data/info subcollection. These files have a slightly different convention for file names and @xml:id attributes: they are named with lower-case filenames and @xml:ids. These names and IDs are typically longer and more descriptive, with multiple-word names separated with underscores. For example,
  • credits.xml
  • website_structure.xml
To create a new page on the site, simply create a new XML file in the /data/info subcollection. For example, to create a page titled Future Plans, create the following XML file:
  • /data/info/future_plans.xml
with @xml:id="future_plans" on its root element:
<TEI version="5.0" xml:id="future_plans"><!-- Information goes here. --> </TEI>
The page would then be seen at the web address mapoflondon.uvic.ca/future_plans.htm and would be linked as follows:
<ref target="mol:future_plans">Future Plans</ref>

Boilerplate Text on the Site

Text that appears in captions and labels can be edited in /data/boilerplate/boilerplate.xml. Most of the smaller captions appear in <seg>s with an @xml:id="captions". For example:
<seg xml:id="clickToZoomCaption">Click on a square to zoom in.</seg>
Changing the <seg> content will change the text on the website. Do not change the @xml:id attribute, which determines the appropriate caption. To create a new caption, collaborate with a MoEML programmer.
Also in the /data/boilerplate folder is /data/boilerplate/site_menus.xml, which controls what appears in the main site menu and in the links in the footer of every page. Be cautious in making changes to this content, because it will affect every page on the website.

References