Copyright held by
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Further details of licences are available from our
Licences page. For more
information, contact the project director,
Most
The molagas prefix points to the shape representation of a location on
Links to page-images in the Chadwyck-Healey
Links to page-images in the
The mdt (
The mdtlist (
_subcategories, meaning all subcategories of the category.
The molgls (
This molvariant prefix is used on <ref>/@target attributes during automated generation of gazetteer index files. It points to an element in the generated variant spellings listing file which lists all documents which contain a particular spelling variant for a location.
This molajax prefix is used on <ref>/@target attributes during the static build process, to specify links which point to MoEML resources which should not be loaded into the source page during standalone processing; instead, these should be turned into links to the XML source documents, and at HTML page load time, these should be turned into AJAX calls. This is to handle the scenario in which a page such as an A-Z index of the whole site would end up containing virtually the whole site inside itself.
The molstow prefix is used on @facs attributes to link to the HCMC verison of the Stow facsimiles. Usually the first group is the year (1633) and then last is the image number (0001).
Our editorial and encoding practices are documented in detail in the Praxis section of our website.
The <teiHeader> is the first component of any TEI-conformant text in the
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
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
Markup Editorinside 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".
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
Responsibility statements should be listed in the following order:
Printed by Nicholas Okes for Thomas Archer, and are to be sold at his shop in Popes-head Palacetells us that the printer is Nicholas Okes and Thomas Archer is both the publisher and the bookseller.
Encoder. The encoder is the person who adds TEI tags to the file, including structural tags, <bibl> tags, and <name> tags.
Markup Editor. The markup editor is the person who checks and corrects the encoder’s tagging.
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, qualifying this term as necessary.
Copy Editor.
The responsibility statements for EIRE1.xml (
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
For a complete list of available responsibilities, consult. the
<taxonomy> of "marcRelators" near the beginning of
PERS1.xml.
Our document collection is large and disparate; we have everything from digital editions of substantial primary source documents such as
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>:
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>:
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.
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:
There are five important points to note:
mdtprefix (
).MoEML document type
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.
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.
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.
For a complete list of document types within the
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:
The revision description for contact.xml serves as an example:
See documentation on general encoding practices for information about how to add draft content to a published page.
Encoder, research assistant, and copy editor, 2012–13. Cameron completed his undergraduate honours degree in English at the University of Victoria in 2013. He minored in French and has a keen interest in Shakespeare, film, media studies, popular culture, and the geohumanities.
Janelle Jenstad, associate professor in the department of English at the University of Victoria, is the general editor and coordinator of
Research assistant, 2013-15, and data manager, 2015 to present. Tye completed his undergraduate honours degree in English at the University of Victoria in 2015.
Director of Pedagogy and Outreach, 2015–present; Associate Project Director, 2015–present; Assistant Project Director, 2013-2014; MoEML Research Fellow, 2013. Kim McLean-Fiander comes to
Programmer, 2018-present; Junior Programmer, 2015 to 2017; Research Assistant, 2014 to 2017. Joey Takeda is an MA student at the University of British Columbia in the Department of English (Science and Technology research stream). He completed his BA honours in English (with a minor in Women’s Studies) at the University of Victoria in 2016. His primary research interests include diasporic and indigenous Canadian and American literature, critical theory, cultural studies, and the digital humanities.
Programmer at the University of Victoria Humanities Computing and Media Centre (HCMC). Martin ported the MOL project from its original PHP incarnation to a pure eXist database implementation in the fall of 2011. Since then, he has been lead programmer on the project and has also been responsible for maintaining the project schemas. He was a co-applicant on MoEML’s 2012 SSHRC Insight Grant.
Church of England clergyman.
Historian and author of