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.

eXist Database Structure

The eXist database contains the entire application, including data, XQuery, XSLT, JavaScript, etc. This allows the database to be copied from one machine to another. It requires only Apache Tomcat to run. As a result, the database application can be downloaded onto a laptop for a conference rather than relying on an internet connection, which can be unreliable.
The database is divided into three subcollections:
  • data
  • site
  • dev
  • system
  • data_old
  • site_old
The data subcollection contains all of the website’s XML files. Editors and programmers have write permission on this subcollection.
The site subcollection contains the machinery that makes the website work, including XQuery, XSLT, CSS, and JavaScript. Only programmers have write permission on this subcollection.
The dev subcollection contains a development copy of what is in site. Any changes proposed for site are developed and tested here before being migrated to site and going live. Only programmers have write permission on this subcollection. dev code points at the normal data collection for its data, and the interface created by the dev code can be viewed at mapoflondon.uvic.ca/dev/.
The system subcollection contains the configuration of indexes for optimizing queries and other housekeeping items. Only programmers have write permission on this subcollection.
The data_old and site_old collections contain respectively a copy of the data tree as it stood on December 3 2013 (just before the 2013 redesign went live) and the original site code which created the original interface dating back to 2006. This is preserved (for the moment) for archive and demonstration purposes. The site_old code points at the data_old data, and is therefore unaffected by changes subsequent to the archive date.

Document Collection

MoEML’s document collection (i.e. the data subcollection in eXist) consists of several types of documents. With the exception of files that are themselves databases, 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 <title level="m">MoEML</title></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 <title level="m">MoEML</title></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> elements, 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 xml:id="content">
                  <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"></graphic>
                    <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.

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=""></graphic>
                    <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)—act rather like centralized databases. They contain 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 essentially a digitized works cited and consulted list for MoEML. Individual <bibl> entries correspond with sources referenced throughout our document structure. The content of a <bibl> tag should reflect MoEML’s standards for citation, which are adapted from the MLA Handbook for Writers of Research Papers and outlined fully in the MoEML Guide to Editorial Style. Moreover, each <bibl> element should be assigned a unique @xml:id and a @type value of "prim", "sec", or "both":
  • Entries that are 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 an <author> tag.
<author>Barber, Bruno</author> and <author>Christopher Thomas</author>...
Title of an article in a periodical Tag the title of an article using 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 using 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 using the <title> tag with a @level value of "a".
<title level="a">Catalogue</title>
Title of a periodical Tag the title of a periodical using 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 using 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 using the <title> tag with a @level value of "m".
<title level="m">Shakespearean London Theatres</title>
Editor’s name Tag each editor’s name using the <editor> tag.
Ed. <editor>Ian
                      Gadd</editor> and <editor>Alexandra Gillespie</editor>
or, alternatively,
<editor>Gadd, Ian</editor>, and <editor>Alexandra Gillespie</editor>, eds
Sponsor institution’s name Tag the name of an institutional sponsor using the <sponsor> tag.
<sponsor>University of Victoria</sponsor>
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 are also marked up.

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, 1968.
                      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"/>. 23–52. Print. </bibl>
Entire website
Developer Surname, Developer Forename, dev. Title of Website. Sponsor Institution. Medium designation (Web). Availability (Open or Subscr., linked to webpage).
<bibl xml:id="LBTD1" type="sec">
                      <editor>Turner, Michael, L.</editor>, dev. <title level="m">London Book Trades Database</title>. <sponsor>Oxford Bibliographic Society</sponsor>. <ref target="http://lbt.bodleian.ox.ac.uk/mediawiki/index.php/Main_Page">Open</ref>.</bibl>
Page within a website
Author Surname, Author Forename. Title of Page/Article on Website. Title of Website. Ed. Editor Forename Editor Surname. Sponsor Institution. Medium designation (Web). Availability (Open or Subscr., linked to webpage).
<bibl xml:id="BEVI7" type="sec">
                      <author>Bevington, David</author>. <title level="a">Henry IV, Part 1</title>.
                        <title level="m">Enyclopedia Britannica Academic Edition</title>. Subscr.
                        <ref target="http://www.britannica.com/EBchecked/topic/261756/Henry-IV-Part-1">BAE</ref>. </bibl>
Journal article accessed online
Author Surname, Author Forename. Title of Article. Title of Periodical Volume.Issue (Year of Publication): Page range of article. Web.
<bibl xml:id="MUNR1" type="sec">
                      <author>Munro, Ian</author>. <title level="a">The City and Its Double: Plague
                        Time in Early Modern London</title>. <title level="j">English Literary
                        Renaissance</title> 30.2 (2000): 241–61. Web.</bibl>
ODNB article
Author Surname, Author Forename. Title of Article. Oxford Dictionary of National Biography Ed. H.C.G. Matthew and Brian Harrison. Oxford: Oxford UP, 2004. Medium designation (Web).
<bibl xml:id="BEER3" type="sec">
                      <author>Beer, Barrett L.</author>
                      <title level="a">Stow [Stowe], John (1524/5–1605)</title>. <title level="m">Oxford Dictionary of National Biography</title>. Ed. <editor>H.C.G. Matthew</editor> and <editor>Brian Harrison</editor>. Oxford: Oxford UP, 2004. <ref target="http://www.oxforddnb.com/view/article/26611">Web</ref>.</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>[...]</teiHeader>
              <text>
                <body>
                  <div>
                    <listPerson>
                      <person>[...]</person>
                      <person>[...]</person>
                      <person>[...]</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="ABBO25" sex="1">
              <persName type="hist">
                <reg>Abbot, George</reg>
                <forename>George</forename>
                <surname>Abbot</surname>
              </persName>
              <birth when-custom="1562" datingMethod="mol:julianSic"/>
              <death when-custom="1633" datingMethod="mol:julianSic"/>
              <note>
                <p>Vice-Chancellor of the University of Oxford, 1601-06; Archbishop of Canterbury,
                  1611-33.</p>
                <list type="links">
                  <item>
                    <ref target="http://www.oxforddnb.com/index/101000004/">ODNB</ref>
                  </item>
                </list>
              </note>
            </person>
To encode a personography entry, nest a <persName> element and a <note> element inside a <person> entry. If you know the person’s date of birth and/or date of death, you can also include a <birth> element and/or a <death> element after the <persName> element. Use the following instructions to fill in the database entry.

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) is structured as follows:
<TEI version="5.0" xml:id="ORGS1">
                <teiHeader>[...]</teiHeader>
                <text>
                  <body>
                    <div>

                      <listOrg>
                        <head>Greater Livery Companies</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                      <listOrg>
                        <head>Lesser Livery Companies</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                      <listOrg>
                        <head>Playing Companies</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                      <listOrg>
                        <head>Other EM Organizations</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                      <listOrg>
                        <head>Modern Organizations</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                      <listOrg>
                        <head>Pedagogical Partnership Project</head>
                        <org>[Organization entry...]</org>
                        <org>[Organization entry...]</org> [...] </listOrg>

                    </div>
                  </body>
                </text>
              </TEI>
This document consists of six <listOrg> elements that contain related <org> elements, each representing an individual database entry for an organization. Each <org> element contains both an <orgName> element and a <note> element. The first component, <orgName>, contains a text string with the full name of the organization; when applicable, a regularized spelling of the organization, tagged with the <reg>, element may be included within the <orgName>. The second component, <note>, contains a short text string describing the organization, tagged with the <p> element.
Six categories of organizations are included in the ORGS1.xml database:
  • greater livery companies
  • lesser livery companies
  • playing companies
  • other early modern organizations
  • modern organizations
  • 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"... "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="DRAP3" type="greater" subtype="R3">
                  <orgName>The Worshipful Company of Drapers</orgName>
                  <note><p><name type="org" ref="mol:DRAP3">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="CARP3" type="lesser">
                  <orgName>The Worshipful Company of Carpenters</orgName>
                  <note><p><name type="org" ref="mol:CARP3">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="LAEL1" type="playingCo">
                  <orgName>Lady Elizabeth’s Men<reg>Lady Elizabeth’s Men</reg></orgName>
                  <note><p><name type="org" ref="mol:LAEL1">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="CORP1" type="other">
                  <orgName>The Corporation of London</orgName>
                  <note><p>Description of the Corporation of London forthcoming.</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 an organization other than a livery company:
<org xml:id="EEBO3" type="modern">
                  <orgName><reg>EEBO-TCP</reg>Early English Books Online–Text Creation
                    Partnership</orgName>
                  <note><p>
                      <quote><ref target="mol:EEBO3">EEBO-TCP</ref> 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. <ref target="mol:EEBO3">EEBO-TCP</ref>
                        maintains a website at <ref target="mol:EEBO3">http://www.textcreationpartnership.org/tcp-eebo/</ref>.</quote>
                    </p></note>
                </org>

Pedagogical Partnership Project Groups

When adding an entry for a pedagogical partnership project group, add a @type value of "ppp" to the <org> element. No @subtype value is required. Next, nest a <listPerson> element inside the entry’s <org> element after the <orgName> describing the organization. The <listPerson> element should contain empty <person> elements with @corresp values pointing to the student’s @xml:id in PERS1.xml. Insert a header (tagged using the <head> element) that reads Student Contributors inside the <listPerson> element before the series of <person> tags. Consider the following example of a database entry for a pedagogical partnership group:
<org type="ppp" xml:id="EXON1">
                  <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>

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"> [...] </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