The Landscapes of Injustice Schema and Documentation
Natsuki Abe, Stewart Arneil, Erin Chan, Nathaniel Hayes, Martin Holmes, Kara Isozaki, Lindsey Jacobson, Jennifer Landrey, Gordon Lyall, Lindy Marks, Jordan Stanger-Ross, Joey Takeda and Lisa Uyeda
Welcome to the Landscapes of Injustice Digital Archive project. This document provides detailed guidelines for editors, programmers, maintainers and research assistants working on the project.
2. Using the Subversion Repository
We keep all our XML files and related documents in a Subversion Repository. This is a version-control system that ensures that every version of every file can be retrieved if necessary, and prevents one person from inadvertently overwriting changes to a file made by someone else.
Subversion runs on one of our HCMC servers. In order to use it, you will need to install a Subversion client on your computer, and also learn a couple of simple command-line commands. Subversion is usually abbreviated to ‘svn’.
2.1. Installing a Subversion client
How you will do this depends on which operating system you are using.
2.1.1. Windows
Obtain a command-line client from CollabNet (http://www.open.collab.net/downloads/subversion/). Registration is required to download the program, but there is no cost. Make sure to download the correct version; there are versions for 32-bit and 64-bit Windows. Once the program is downloaded, install it by double-clicking the downloaded installer and following its instructions.
2.1.2. Macintosh
Open a terminal.
Type: xcode-select --install
Press return.
Note that MacOSX updates have sometimes broken the svn install, so you may need to go through the above steps again if svn stops working.
2.1.3. Linux
Subversion is installed as part of a regular desktop on most Linux distributions.
If you do not have subversion on your Linux:
Open a terminal.
Type: sudo apt-get install subversion
Press return and answer "y" to questions about space.
2.2. Checking out the repository for the first time
Once your subversion client is installed, the first thing we need to do is to check out the repository. To do this, you need to open a terminal window:
On Windows, click on the Start menu and type cmd into the search box.
On a Mac, select Terminal from the Utilities folder in Applications.
On Linux, press Control + Alt + T.
Now we'll check that svn is installed and working. Type svn checkout into the terminal window and press return. If the terminal response is that there are Not enough arguments provided, then svn is working OK.
We are then going to create an "loi" local repository. Before we do that, you may want to be in your "Documents" folder, or some other directory other than your root. To do this type:
(It's important to update before committing changes in case anything else has been changed and committed by someone else)
svn commit -m "A message explaining the changes you have made"⚓
That's basically it. If you see any warnings or error messages from svn, check that you're in the right folder in your terminal. You may also see error messages if two people have been editing the same file at the same time, and Subversion needs you to make a decision about whose changes should be kept.
For an introduction to XML please see the w3schools tutorial here. The two main components of XML that you should know are ‘elements’ and ‘attributes’.
4. Working with Oxygen
Your encoding work will all be done in the Oxygen XML Editor (also referred to as Oxygen). When you install Oxygen, there are lots of applications that come with it: Oxygen Author, Oxygen Developer, Compare Files, Compare Directories and others. But the one you want to work with is always Oxygen XML Editor, which has the blue icon with the red cross on it. Here's how to get started:
Open the Oxygen XML Editor.
Click on Project / Open Project...
Navigate to the loi folder in your home directory.
Choose the file loi-production.xpr.
You should see a tree of folders and files down the left of your Oxygen editor. This includes all the files in the project. You can ignore most of them. The folders that matter to data encoders and editors are in the data folder, where all the TEI files and LOI schema are kept. To expand a folder, click the little blue icon beside it. Sometimes you will need to click the icon with two blue squares on the left side of the editor to make this tree appear.
4.1. Validate your files before upload
This is important: always validate any and all XML files in Oxygen before uploading them to the repository in Terminal/SVN. Get into the habit of saving your files often (Ctrl + S on your keyboard), and validating often (Ctrl + Shift + V on your keyboard).
To validate the file upon which you are currently working, use the following keyboard command: Ctrl + Shift + V. Alternatively, click on the validate button in Oxygen's toolbar. The button looks like this:
To validate multiple files, (1) open Oxygen's built-in file browser, (2) select the folder you want, and (3) select Validate. Here's a screenshot of the process:
If your validation is successful, a green box with the words 'Validation successful' will appear at the bottom of the editor. If the validation is unsuccessful, a red box and the words 'Validation failed' will appear along with the number of errors that you have created. You must correct these errors before uploading the file to the repository. Please refer to SVN daily use.
5. TINA and Ography Files XML Mark-up Guide
The TINA files make up our "archive" of primary material. This section will explain how to encode this data and add new people, place, and organization entries into central reference files called "ographies."
5.1. Setup
To work on TINA files you will need to have the following programs open:
Oxygen XML Editor
A terminal window
An internet browser with the Zotero group library open and loaded. You will need to have previously been given permission to access the library.
In Oxygen navigate to the ‘Project’ tab along the top toolbar and select ‘Open Project’. A file selection box will open and it will automatically open your ‘RADish’ folder. You should be looking at a folder called ‘Production’ - open this and select the file ‘loi-production.xpr’
You should now have a sidebar on the left that lists all of the folders and files that exist within this project. Click the little blue icon beside a folder to expand it.
Expand the ‘production’ folder
Expand the ‘data’ folder.
The folders inside ‘data’ that you are concerned with are:
‘orgography’
‘personography’
‘placeography’
‘RADish’
5.2. Choosing Which TINA File to Work On
You will now decide which TINA file you will be working on. Please do this in consultation with other research assistants that are working on the project. RAs who have worked for Landscapes of Injustice previously will know what files need to be worked on, which are priority, etc. Consulting with the other RAs around you will also prevent multiple RAs from working on the same file, which can prove to be disastrous.
Once you know which file you will be working on you will open it in Oxygen:
Expand the ‘RADish’ folder (inside the ‘data’ folder)
Expand the folder of the archive you will be working in (e.g. ‘TINA_LAC’)
Now open the file you have been assigned. The smaller archives may have only one file, but the larger archives have multiple files which have been separated out at the fonds level.
5.3. Checking Diagnostics
Every time you start working in XML, you will need to consult the diagnostics tool. This tool will show you, among other things:
Person, place or organization links that are broken
Duplicate IDs that need to be fixed
Every XML ID that has been created in this project
The diagnostics tool will automatically build itself each time you commit. To open the results of the diagnostics tool after a SVN commit, go to this link: Products
If you would like to manually build the diagnostics to see your current progress, run the diagnosticsTransform.html located at the root folder:
This will build the diagnostics though it may take a few minutes.
To open the results of the diagnostics you ran on your local machine find the diagnostics.html in the ‘products’ folder and open it in a web browser. This is your local copy of diagnostics that you have just built. It will not be what everyone else sees on the Jenkins server version until you commit.
Note: if for some reason the transform does not work, it may mean that there is no build associated with the file. Contact Gord for support.
Opening ‘diagnostics.html’ will open the results that show the problems in the XML files that need to be addressed.
To view the list of errors, such as duplicate IDs and broken links, or to view the list of files that are missing information, open 'products/diagnostics.html'.
products/diagnostics.html
To view the list of each XML ID that has been created in this project, open ‘products/ids.html’. The first column lists the ID and the second column lists the type of ID it is.
products/ids.html
5.4. Working on a TINA File
5.4.1. Creating XML IDs
Each XML ID is unique and it consists of four letters and a number greater than zero. When creating an XML ID you will need to consult the ids.html, as well as the New XML ID Tracker, to ensure that the ID you are creating has not already been used. The first list is the master list of all ids currently used across the database, and the "New XML ID Tracker" is a mechanism to avoid two people creating the same id on the same day working from different machines or remotely.
In each list, use CTRL + F to search for the ID you plan to create. If that ID is already in use, you must choose another, usually by changing the number to one higher than the highest one already in use. An example of this is a person with the last name Tanaka. If the numerically highest ID for the prefix ‘tana’ is tana1, your ID would then be tana2.
*Note: Some persons may be identified as having multiple ids pointing to that same person which means the ids will be collapsed into one resulting in the erasure of an existing id. This means there may be gaps in some of the id list. Example: tana1, tana2, tana4. In this case it is ok to create a new id “tana3”.
Within each ID we follow the practice of marking up all person names, organization names, and place names. An example of this practice can be found in the place ID for Blind Creek where the person name Eikichi Kagetsu and the place name Burnaby are marked up:
<place xml:id="blin1"><placeName>Blind Creek</placeName><desc>A creek in <placeName ref="plc:bnby1">Burnaby</placeName>. <persName ref="prs:kage1">Eikichi Kagetsu</persName> once had logging interests here.</desc></place>
WORKFLOW
Check LOI master list of XML ids for the next logical id to use.
Check the New XML ID Tracker to make sure someone hasn't already added a new id today that you would have used.
**Put your new id in "NEW XML ID Tracker" list to claim it as yours; add, date, your initials, file that the entity came from, and into which ography the entry was added.
Add the new person entry and id into correct ography file (see below).
Give your newly marked-up person, place, org entry this new id (see below).
5.4.1.1. Personography IDs
Each person name that you come across will need to be marked up using a <persName> element. In some cases you will need to create the unique XML ID for the name that you come across. This process is described below.
Person IDs are comprised of the first four letters of the last name followed by an integer greater than zero. If the person’s last name is three letters instead of four, the letter x will be used as a placeholder for the fourth letter.
To create a new entry in the personography, you first need to locate where the new ID will fit. There are 26 personography files inside the ‘personography’ folder, one for each letter of the alphabet. What file the new ID will go in is decided by surname. For example, the person ID for Kazuko Kagawa is in personography_k.xml.
To start building an ID you will begin with the <person> element. Inside of this element will be two attributes: xml:id and sex.
The xml:id is the four letter, one integer ID you chose in consultation with the diagnostics. For Kazuko Kagawa the ID we chose is kaga2.
<person xml:id="kaga2"/>
Now we add the sex element on the same line. We use ‘F’ for female, ‘M’ for male, and ‘U’ for unknown. In this case we know that Kazuko Kagawa is female, so we use ‘F’:
<person xml:id="kaga2" sex="F"/>
You will now be adding the <persName> element. This element will include the <surname> and <forename> elements. This is where you enter the person’s full name. If you have their full name, you will select “yes” when given the choice when you begin typing <persName>. Next, add the <surname> element, and again select “yes” if you know their full surname. In the space between the opening and closing of the <surname> element, enter the person’s surname:
Now we will add the <forename> element on the line underneath the <surname> element and separate them with a comma. Like the <surname> element, select “yes” if you know the person’s full first name and write the forename in the space between the opening and closing of the <forename> element:
This is an example of a person ID in its most basic form.
Ideally we would also be able to add some biographical information in a <note> to a person entry.
<person xml:id="shea1" sex="M"><persName><surname>Shears</surname><forename>Frank</forename><addName>Gould</addName></persName><note>F.G. Shears (born March 3, 1885 in London, England) was a bureaucrat who took on a prominent administrative role in the dispossession of Japanese Canadians in World War II. Shears was hired by the Secretary of State in 1940, and served as the director of the Vancouver Office of the Custodian of Enemy Property from 1942 until the closure of the office in 1952. As director, he oversaw the forced sale of Japanese Canadian assets and the payment of claims arising from Justice Henry Bird’s <orgName ref="org:jpcc1">Royal Commission</orgName>. As one of the longest-serving employees of the Custodian, Shears experienced this history from a unique perspective, privy to the decision-making of his political and bureaucratic masters, but also constantly receiving letters and appeals from the Japanese Canadians he helped to dispossess. (Source: Kimura Appendix)</note></person>
5.4.1.2. Organization IDs
For organization IDs, you should pick an ID that makes sense while still adhering to the strictures of our schematron rules which indicate that each ID must be four letters and a number. Sometimes it will make sense to use the first four letters of the main part of the organization name, like the M. Ebisuzaki Company, the ID for which is “ebis11”. Other times it will make sense to use the first letter of each word in the organization name, like the Exchequer Court of Canada, the ID for which is “ecoc1”. Always remember to check the uniqueness of the ID with the diagnostics.
To start building an org ID you will begin with the <org> element. Inside this element is the xml:id attribute.
Using the Exchequer Court of Canada as an example, your ID would initially look like this:
<org xml:id="ecoc1"/>
Now we need to add the orgName element:
<org xml:id="ecoc1"><orgName>Exchequer Court of Canada</orgName></org>
If this is all of the information you have for this ID you will close the <org> element. This is an org ID in its most basic form. If you have more information you can include it as well, using primarily a <desc> element or a <note> element:
<org xml:id="eocj1"><orgName>Embassy of Canada to Japan</orgName><desc>Located in <placeName ref="plc:toky2">Tokyo</placeName>.</desc></org>
<org xml:id="ktco1"><orgName full="yes">K. Takahashi & Company</orgName><note>A company based in <placeName ref="plc:vanc1">Vancouver</placeName> owned by <persName ref="prs:taka53">Kinji Takahashi</persName>.</note></org>
5.4.1.3. Place IDs
Just like XML IDs for people, the IDs in the placeography consist of the first four letters of a place name and a number. The only mandatory attribute in a <place> element is xml:id. Remember to check the uniqueness of the ID with the diagnostics. Each placeography entry must also contain a <placeName> element and a <desc> element containing a brief description of the place:
<place xml:id="anna2"><placeName>Annacis Island</placeName><desc>An island located on the <placeName ref="plc:fras43">Fraser River</placeName> in <placeName ref="plc:delt4">Delta</placeName>, <placeName ref="plc:brit1">British Columbia</placeName>.</desc></place>
Additional notes about a place should be contained in a <note> element:
<place xml:id="angl12"><placeName>Angler</placeName><desc>A prisoner of war camp in <placeName ref="plc:onta1">Ontario</placeName> near <placeName ref="plc:neys1">Neys Provincial Park</placeName>.</desc><note>Also known as Angler Internment Camp, Internment Camp 101, and Angler POW Camp.</note></place>
5.4.2. Mark Up
All person names, place names, and organization names need to have a <persName>, <placeName>, or <orgName> tag applied to them.
The easiest way to do this is to highlight the piece of text that you would like to mark up and pressing ctrl + e on the keyboard. This will bring up a drop down list that will enable you to select the tag you require.
Doing so will change the text to look like this:
<persName>Eikichi Kagetsu</persName>
This is not complete. All <persName>, <placeName>, and <orgName> elements must include a reference to an ID in the personography, placeography, or orgography. You will need to insert this reference within the opening of the tag. The ID that you reference will be the ID that exists in the respective ography, so you will need to first either find that ID, or create that ID. Then you will insert the reference and your work will look like so:
*Note: all references must include the prefix of the ography they belong to. The prefix “prs:” for person names, “plc:” for place names, “org:” for organization names, and "team:" for LOI team members.
5.4.3. Fields to Complete
There are a large number of fields associated with each object, sub-series, series, and fonds. You are only responsible for some of these fields. This section of the guide will walk you through how to complete the fields that you are responsible for.
First: to find a record that needs work and is currently not being worked on please consult the TINA Status document. Also consult with your co-workers to make sure this document is up to date and chat about which document is best for you to currently be working on.
Second: it is recommended that you work from the bottom to the top, so the fields listed below are listed in the order in which you will come across them. The bottom of an object will begin at the end of the <listObject>.
These are the fields that should be complete:
5.4.3.1. Metadata Author
This is you! Gordon Lyall and Lindsey Jacobson have been added as ubiquitous metadata authors, but in working with the TINA files you are also a metadata author. To add this information you will need to put in a new <respStmt> (responsibility statement) element underneath the last <respStmt> that is present. This element will contain your name wrapped in a <persName> element and a <resp> (responsibility) element. You must have already created an XML ID for yourself in the personography to complete this step. Personography entries for Landscapes of Injustice team members are written in the ‘team.xml’ file within the ‘personography’ folder.
Start with the <respStmt> element. You will follow this with a <persName> element, and finally a <resp> element:
In some cases the researcher’s name will already have been added. In other cases, however, you will have to determine who the researcher is and put their name into the <respStmt> element that has the <resp> element of “Researcher.”
To determine who the researcher is, you will look in Zotero at the name of the person who uploaded the document to Zotero (this will be a username) or read the child notes.
Looking at “lac_rg117_a-1_volume_0003_file_08” as an example, we see that the user who uploaded the document is “adamkos” and the child notes are written by “Adam K.” This means that the researcher is Adam Kostrich. Personography entries for Landscapes of Injustice team members can be found in the ‘team.xml’ file within the ‘personography’ folder.
If you cannot find a researcher, please contact Gord or Kaitlin Findlay, they will likely know, have a good idea, or can find out.
5.4.3.3. Document Date
This information should already be provided.
5.4.3.4. Document Author
The document author is the person and/or group that created or compiled the document. This could be the Office of the Custodian, the Government of Canada, the Supreme Court of Canada, etc. In terms of using the name of a person, the doc author is the person whose name appears most frequently in the file. This is particularly the case for files containing lots of correspondence. The <docAuthor> element should be in place. You need to replace the placeholder of “AUTHOR” with the actual doc author and mark up the person's name or org name that you have listed.
If there are many authors on a file, add the primary author of the file and write “and others.” If there are two individuals conversing back and forth, add both individuals.
Example:
<docAuthor><persName ref="prs:shea1">F.G. Shears</persName>, <persName ref="prs:wrig1">K.W. Wright</persName>, and others.
</docAuthor>
If there is no identifiable doc author you should instead replace the placeholder of “AUTHOR” with “Unknown”:
<docAuthor>Unknown</docAuthor>
5.4.3.5. Digitization Level
Scrolling up, this is the next section that you need to work on. For this section you have three options: “selectively”, “in full” or “unknown”:
<p>This record was digitized selectively.</p>
<p>This record was digitized in full.</p>
<p>The digitization level of this record is unknown.</p>
The child notes in Zotero should list the digitization level as either selectively or in full. In the case that the child notes do not list the digitization level, or in the case that there are no child notes, you will use “unknown.” Or contact Gord, he may know, or know how to find out.
5.4.3.6. Object Description
This is where you write your scope and content describing the object. It will look similar to this:
<summary corresp="rad:radScopeAndContent"><p>!IMAGINE NO TEXT JUST WHITESPACE!</p></summary>
If there is already text in this section you simply need to mark up all person names, place names, and organization names that appear in the text.
If this information is not provided, you will need to navigate to the child notes of this file in Zotero. The child notes should already have a description included, so copy and paste it into the space between the opening and closing of the <p> element. Now you need to mark up all person names, place names, and organization names.
If there is no text provided (no child notes or no description in the child notes) you will have to write your own description which you will then mark up.
These are all of the item level fields that you will be responsible for. Continue following this procedure for all of the items as you scroll up. At some point you will come across fields relating to higher-level descriptions that you will need to fill in. These fields pertain to sub-series, series, and fonds. The higher the level the more vague and general your description will be.
You will know that you have hit a higher level field when scrolling up from an object-level scope and content field you come across another scope and content field, rather than a new object.
To identify what level you are at, scroll to the line that has an item element in it. Part of this element will be an n attribute which will describe the level. An example looks like this:
The sub-series description should briefly describe all of the files that it contains. You will again need to mark up all person, place, and organization names. An example of a sub-series level description is:
<p>This subseries consists of four files containing the <orgName ref="org:cust3">Office of the Custodian</orgName> case file for <persName ref="prs:kage12">Eikichi Kagetsu</persName> with extensive discussion relating to the seizure and sale of his real estate and his debt to the <orgName ref="org:ysbx1">Yokohama Specie Bank</orgName>.</p>
5.4.3.8. Series Description
The series description should describe all of the sub-series that are contained in the series. You will again need to mark up all person, place, and organization names. An example of a series level description is:
<p>This series comprises one file discussing the post-war use of seized Japanese Canadian farms in <placeName ref="plc:neww3">New Westminster</placeName>, <placeName ref="plc:brit1">British Columbia</placeName>.</p>
5.4.3.9. Fonds Description
The fonds level description should describe all of the series contained within it. You will again need to mark up all person, place, and organization names. An example of a fonds level description is:
<p>This fonds comprises one series pertaining to the <orgName ref="org:jfvd1">Japanese Fishing Vessel Disposal Committee</orgName>.</p>
5.5. Committing Your Changes
All changes made to TINA files need to be committed to the server. This is done through the terminal. You should commit with some regularity, at the very least when you leave for the day, though best practice would be to commit when you take a break as well.
First, ensure that all of the files you were working on in Oxygen have been saved.
Next, open the terminal and navigate to the ‘production’ folder which has the repository installed in it.
Now you should do an SVN update to ensure that you have the most up to date version of the repository on your local machine.
Once you have updated it is time to commit with a message about the changes you made:
svn commit -m “continued work on TINA_CHE and added to personography”⚓
To commit your changes press enter. If there are no conflicts, you are done!
If conflicts occur, contact Stewart Arneil immediately.
5.6. Bird Commission Fonds in LAC
The Bird Commission fonds are a set of individual case file records for Japanese Canadians who participated in the Bird Commission. This section assumes that reader/encoder has knowledge of TINA data structure, ographies, and LOI general guidelines for "Working on a TINA File."
5.6.1. Updates
As of July 10, 2020, EC has completed:
fonds and all sub-series level summaries
first pass of volume 59 of claim case files (file #s 1161 to 1180)
volumes 60 to 74 of case files (file #s 1181 to 1406) in full
volumes 75 to 79 of other material pertaining to the commission in full
all digitization statements to reflect “full” digitization
all <docAuthor> fields with the ubiquitous author “<orgName ref="org:jpcc1">Japanese Property Claims Commission</orgName> and others.”
Work still needed to be completed is:
a first and second pass of volumes 1 to 58* of claim case files (file #s 1 to 1160)
a second pass of volume 59 of case files (file #s 1161 to 1180)
*Note: Volumes 1 to 11 (file #s 1 to 203), volume 25 (file #s 507 to 524), and volumes 51 to 53 (file #s 1013 to 1066) already have claimants’ names listed in the <title> of the records (e.g., “Case file 7 Iwata, Mrs. Haruko”).
5.6.2. Bird Commission Workflow
5.6.2.1. Two-stage process
There is a two-stage process for completing the rest of the case files:
First pass will be a “light” treatment for the summaries in preparation for the database launch (approximately 100 hours). “Light” treatment centres on pulling the claimant’s name and Bird Commission and Custodian case file numbers.
Second pass will be a “full” treatment for the summaries (approximately 250 hours). “Full” treatment adds to info from first pass, pulling more information about the claimant, listing the kinds of documents in the file, listing additional docAuthors, and marking up key places, organizations, and people.
See Light and Full treatment sections for details.
5.6.2.2. Basics of working in fonds
Open up the Bird Commission fonds in Oxygen (loi -> data -> TINA_LAC -> lac_rg33-69.xml) and find a volume/file to start with.
You can find incomplete file summaries by executing this path in the XPath box in your tool bar while you have the xml page open:
Navigate to file in the fonds on the database (Archival Datasets -> Library and Archives Canada -> Royal Commission ...) or Zotero (.export -> LAC -> lac_rg33-69 [Bird Commission]). (In recent experience, pdfs load faster from the database.)
Use this general template for summary, modifying it as needed (replace square brackets with claimant’s info):
This file contains documents pertaining to the <orgName ref="org:jpcc1">Bird Commission</orgName> claim of [First name Last name] (claim case number [#]). ⚓
Pull claimant’s name from file (usually found on first claim summary/recommendations page of file before the transcript). Also reference the finding aid and/or the Custodian form in the file (if included) for name as any of these sources may have incorrect spelling. Include any incorrect or alternate spellings of names in following square brackets. Note that some claims have multiple claimants and some may be for companies or organizations, represented by an individual.
Search the list of “All Database Ids in the Project” for the claimant’s name. If matching name(s) found, search corresponding personography file for matching name. If you can quickly determine that it’s the same person as the claimant (from listed address, for example), link to that ID. If not, create a new personography ID and entry for claimant.
In personography entry for claimant, add a <note> with the following template, filling in the claimant’s info and the xml ID for the record (replace square brackets):
<orgName ref="org:jpcc1">Bird Commission</orgName> case file number [#]. <orgName ref="org:cust3">Custodian</orgName> file number [#]. (Source: lac_rg33-69_volume_[XX_file_XXXX].)⚓
The finding aid usually lists “Mrs.” or “Miss” before the names of female claimants (and nothing before the names of male claimants). Use this info to record the sex of the claimant in their personography entry (e.g., “<person xml:id="xxxx1" sex="F">”). Do not include “Mrs.” or “Miss” when recording claimants’ names.
If the claimant’s Custodian file number listed in the file has “X1” in it (noting they were interned), include variants on it in square brackets in their personography entry note to match how we’re treating the case file numbers sequentially and to give more options for searching (e.g., “<orgName ref="org:cust3">Custodian</orgName> file number X1-376 [XI-376 or 376_xi]”).
Here’s an example of a completed “light” treatment for claim number 1168:
Summary example:
<p>This file contains documents pertaining to the <orgName ref="org:jpcc1">Bird Commission</orgName> claim of <persName ref="prs:yosh158">Edward Shigeuki Yoshida</persName> [also listed as Shigeuki Yoshida and Shigeucki Edward Yoshida] (claim case number 1168).</p>
Personography entry example:
<person xml:id="yosh158" sex="M"><persName><surname>Yoshida</surname><forename>Edward</forename><addName>Shigeuki</addName></persName><note><orgName ref="org:jpcc1">Bird Commission</orgName> case file number 1168. <orgName ref="org:cust3">Custodian</orgName> file number 6668. (Source: lac_rg33-69_volume_59_file_1168.)</note></person>
Note that the correct spelling of the claimant’s name was determined from referencing the finding aid and other documents in the file, as the initial claim summary/recommendations page (first image below) had the name spelled incorrectly. (Remember to include alternate or incorrect spellings in square brackets.)
*After completing all files in a volume, go to the volume’s sub-series summary and edit it to reflect the kinds of case files in it, if necessary. For example, volume 58’s summary reads as follows:
This sub-series comprises twenty-four files containing documents pertaining to the Bird Commission claims of various Japanese Canadian individuals and/or organizations or companies. Claim case numbers range from 1137 to 1160.⚓
Once all of its files are complete, edit the italicized text above. If volume 58 contains only case files for people (i.e., no businesses), change the summary to reflect this. See other sub-series summaries for examples.
5.6.2.4. “Full” treatment process (second pass)
Building off the “light” treatment, add this template to existing summary, modifying it as needed:
Documents include the following: claim overview forms; a transcript of hearing proceedings; and ___.⚓
Using the finding aid and referencing documents in the file, generally list the documents included in the file, marking up any key places, organizations, or people according to the focus of the project. Note that the majority of files include the initial “claim overview form” and a hearing transcript, in addition to other documents.
Pull a couple more notable docAuthors from the documents, if relevant.
Include more info about the claimant in their personography ID, including things like their pre-uprooting address, family members relevant to the file/claim, etc.
Here’s an example of a completed “full” treatment of file claim number 1168 (to compare with the info from the finding aid):
Summary example:
<p>This file contains documents pertaining to the <orgName ref="org:jpcc1">Bird Commission</orgName> claim of <persName ref="prs:yosh158">Edward Shigeuki Yoshida</persName> [also listed as Shigeuki Yoshida and Shigeucki Edward Yoshida] (claim case number 1168). Documents include the following: claim overview forms; a transcript of hearing proceedings; a real estate (other than farm) summary; agreements for sales (involving the claimant, <orgName ref="org:vlmc1">Victoria Lumber and Manufacturing Co. Ltd.</orgName>, and <persName ref="prs:yosh161">Henry Shigetoki Yoshida</persName>); an estimate by <orgName ref="org:srpc1">Sidney Roofing & Paper Co.</orgName>; appraisals; a statement of personal chattels; an analysis of personal property claim; correspondence between the <orgName ref="org:cust3">Custodian</orgName> and the claimant; a certificate of encumbrance for a lot in <placeName ref="plc:chem10">Chemainus</placeName>, <placeName ref="plc:brit1">BC</placeName>; a 1944 <placeName ref="plc:noco1">North Cowichan</placeName>, <placeName ref="plc:brit1">BC</placeName>, assessment notice; a <orgName ref="org:cust3">Custodian</orgName> form for the claimant; a photograph of a house at Lot 26, Map 303, District of <placeName ref="plc:noco1">North Cowichan</placeName>, <placeName ref="plc:chem10">Chemainus</placeName>, <placeName ref="plc:brit1">BC</placeName>; a letter to the <orgName ref="org:cust3">Custodian</orgName>; a memorandum listing personal property; a real property summary; and auction sheets.</p>
Personography entry example:
<person xml:id="yosh158" sex="M"><persName><surname>Yoshida</surname><forename>Edward</forename><addName>Shigeuki</addName></persName><occupation>Truck driver and insurance agent</occupation><residence><address><settlement><placeName ref="plc:chem10">Chemainus</placeName></settlement><region><placeName ref="plc:brit1">BC</placeName></region></address></residence><note><orgName ref="org:jpcc1">Bird Commission</orgName> case file number 1168. <orgName ref="org:cust3">Custodian</orgName> file number 6668. (Source: lac_rg33-69_volume_59_file_1168.)</note></person>
docAuthor example:
<orgName ref="org:jpcc1">Japanese Property Claims Commission</orgName>, <orgName ref="org:cust3">Office of the Custodian</orgName>, <orgName ref="org:srpc1">Sidney Roofing & Paper Co.</orgName>, <persName ref="prs:yosh158">Edward Shigeuki Yoshida</persName>, and others.
Finding aid entry example:
Look at processed case files from volumes 60 to 74 in Oxygen or on the database for other examples of “full” summaries and personography entries for claimants.
6. Oral History Transcript Guide
This is the Landscapes of Injustice Oral History Transcript Guidelines. Before working on any of the following stages, it is imperative that you consult and update the spreadsheet LOI Oral History Database_work flow on either Basecamp or Google Docs. This way we can avoid two RAs doing the same job on one transcript. The four columns you will consult are: Transcribed, Pre-Audio Check: Full/Partial, Audio Check, Final Check, and XML. First, make sure your column is blank. Then type your initials into the column and row that corresponds to the narrator and stage you are completing. You will update the spreadsheet after you finish your task(s) and replace your initials with “Y (initials)” to show it is complete and that you have finished the task.
These are the materials you will need:
To access the spreadsheet from Basecamp follow these steps:
Basecamp/Digital Archives Cluster/Docs & Files/Oral histories/LOI Oral History Database_work⚓
To access the audio files, Consent Forms, etc., you will go onto the Landscapes of Injustice file server:
To access the working transcripts, you will need to use the SVN repository. You will access a terminal window (as you have probably already done). Type “svn update” at the start, and “svn commit” after every working period. It is important to only work with the documents on the SVN repository because they are saved at every stage, meaning we can go back if an issue arises. The working transcript files are in:
... and checkout the repository. This mini repository is in a "secret" location only available to LOI svn users. ***You should be challenged with your Netlink and password credentials. If you are not, please let Stewart know immediately.
In the initial stage, you will listen to the audio file and write a rough transcription. Be sure to put your initials in the Spreadsheet to show you are working on it.
It is important to keep a standard for writing all transcripts, so while doing the initial stage, please write as follows:
JORDAN We are here to talk to Mike Abe for the Landscapes of Injustice project. [Long pause.] Well Mike, thanks for speaking to me today.
MIKE [Laughs.] Thank you for having me today, [laughs] Dr. Stanger-Ross. [Both laugh.]⚓
This way first names are fully capitalized, and the square brackets delineate any verbal cues or information that is not spoken aloud by the interviewer or narrator. For example:
[Phone rings; tape is momentarily paused.] [Doorbell goes off, Jordan checks the front door.] [Mike’s voice becomes emotional.] ⚓
Noting moments of emotion is especially important as these do not transfer clearly in the written document. It is also important that when transcribing you listen for moments where the narrator pauses and put commas or other grammar in relation to their verbal cues; spoken speech does not translate easily to the written word and will look strange on the page, but it is important to capture the narrator and interviewer’s way of speaking. This also shows characterization of speech.
Try not to include “uh,” “mhmm,” or “ah,” and limit use of “like” or “you know.” Overuse can seem jarring and distracting, but a few can show characterization of speech or emotion. Use your discretion when transcribing. Try to imagine how the person sounds when reading their words without the audio.
Keep note of moments where you may not be sure of spelling or titles by typing “(?)” beside the information. Titles of companies or areas you can’t find on an easy google search should also be marked with “(?).” This is imperative for the Final Check stage and keeps a consistent standard for searching within the documents. Mark any lines of Japanese with “(?)”. It is important that we check with narrators for this information later. You DO NOT have to find these terms at this stage—just write a rough draft of the interview. For example:
MIKE My daughter, Shizu(?), is also working for Landscapes of Injustice. Shikata ga nai(?).⚓
This way, when we do the Final Check, we are able to search within the document for “(?)” and generate the list of words we need to check with the narrator. Names are especially tricky because Laureen, Loreine, Loreen, etc., are all different variations of the same name. Some transcripts will already have this convention, but the majority do not. For anything that stands out as strange, or if you’re not sure, just put “(?)” because the transcript may have been written before this standard. This stage is the last chance to record these before the Final Check.
Lastly, it is very important to timestamp every five minutes. There is some flexibility, such as [01:21:12] or [00:04:36], but it is important to be as close to five minutes as possible. Once you have finished, add the Cover Page and fill out any metadata fields you can; some fields will be left blank and filled out at a later stage.
Also, if it is clear, please note whether a narrator is issei, nisei, sansei, or yonsei.
6.2.1. Cover Page
This is the cover page for all oral histories. It delineates the metadata that must be filled out for each interview, especially before it gets XML markup. This is available in the file server under “oh_documents” and titled “Oral_History_Transcription_Cover_Page.” There are a few exceptions for the Transcription Stage noted below, so only fill in those that do not say [Leave Blank]:
Interviewee Name: [Last, First]
Interviewer Name: [Last, First]
Interviewee Generation: [Issei, Nisei, Sansei, Yonsei, unknown, or non-applicable]
Interview Date: [YYYY-MM-DD]
Interview Location: [City, Province/State]
Interview Summary: [Leave blank]
Note: [Anything that should be noted about interview. Ex: If interviewer and narrator know each other, or if there is anything out of the ordinary]
Subject Keywords: [Leave blank]
Time Periods: [Key periods, such as: 1914; 1930s-40s, 1980s]
Consent Forms: [Check that the Consent Forms are filled out properly and saved onto the server; put “Digitally archived at UVic” if completed; if missing or incomplete in any way, make a note here as well as the spreadsheet]
Rights: [Check that the Media Release is filled out properly and saved onto the server; put “To project” if completed; if missing from records, make a note here as well as the spreadsheet]
Restrictions: [Include any notes about keeping names private or a narrator’s wish to view transcript etc. in the Consent Form. Note any reasons if you the transcriber or the interviewer believe this interview should be restricted from public access or completely destroyed. Update this on the Spreadsheet.]"
Sensitive material: [Consult the risk matrix.]
Transcriber: [Last, First]
Transcriber notes: [Anything worth noting from a transcribers point of view, such as moments missing because of a distraction that remains untranscribed for a substantial amount of time]
Translator: [Leave blank unless specified]
Translator notes: [Leave blank unless specified]
Equipment Used in Recording: [Should normally be “Zoom H2N”]
Media Type and Format: [Should normally be one “Audio .WAV file”]
Length of Interview: [00:00:000]
Language: [English, unless in rare cases it is in Japanese]
Landscapes ID Number (OFFICE USE): [Should be stated; contact Jennifer/Stewart if blank]⚓
**Make sure your name is in the Transcriber metadata of the Cover Page and that you have updated the Spreadsheet upon completion, as well as any information that is missing (Consent Forms, Media Release, or Restrictions, etc.). Update the Spreadsheet column with “Y(initials)” to show that you have completed stage. DO NOT FORGET TO COMMIT YOUR CHANGES TO THE SVN REPOSITORY.
6.2.2. Naming Convention
After completing your transcription using your transcription software (possibly oTranscribe) copy and paste this information into a word editing document. You will save this word editing document based on the following convention:
You will determine the source out of three options based on when, where, and by whom the interview was done by. The three options are loi, bca, or nmm. You will know the source from where you accessed the audio file, and where the audio files are accessible from is located on the LOI Oral History Database_workflow spreadsheet.
If an interviewee or interviewees conducted multiple interviews on different dates, then all subsequent interviews will receive a number based on when it occurred in the timeline of interviews (i.e. the first interview conducted in January 2019 receives no number, but the second interview conducted in February 2019 receives the number 2 at the end of the name, and the third interview conducted in March 2019 receives the number 3 at the end of the name, etc.) so the convention will be as follows for all interviews conducted after the first one:
This is the pre-audio check stage to determine the accuracy of a transcription and to decide which proper audio check process to proceed with, “Full” or “Partial”.
To start, put your initials in the Spreadsheet column N to show you are working on it. Then update the SVN repository before you open the working transcript.
Only edit documents from the hidden "loiOH" folder from the SVN repository. DO NOT update documents from the file server.
Once you have checked out the repository, you can open the loi_docx file. Next, go to the file server and open the .WAV or .MP3 file for that interview.
For the first, approximately 3-5 minutes, read the interview along with the audio to check for possible errors. You are to look out primarily for multiple discrepancies between the transcription and the audio, especially in the case of mistakes that lead to a change in meaning and intention.
You are to determine whether the next audio check process should be done in “full” or in “partial” process. The “full” audio check involves listening to the entire interview while copyediting, while the “partial” audio check involves listening to only 15 minutes of the audio.
This stage acts as an early indicator to RAs whether or not the transcription is in need of heavy editing and extra care. Please use your discretion when deciding how much work this transcript will need to be up to standard.
After deciding whether this interview requires the “full” or “partial” treatment, save and commit any edits you may have made. For a refresher, see “Using the Subversion Repository” section or refer to the SVN repository guidelines documents received from Stewart or Martin.
Return to the Spreadsheet and change the value to either:
In this stage you will draft the official looking transcript for the standard LOI uses. You will be updating the Cover Page, checking for inaccuracies in the transcript, and writing the interview summary. Many of these transcripts were done prior to these standards and are in varying stages, and may require further editing than others.
To start, put your initials in the Spreadsheet column O to show you are working on it. Then update the SVN repository before you open the working transcript.
Only edit documents from the hidden "loiOH" folder from the SVN repository. DO NOT update documents from the file server.
Once you have checked out the repository you can work on one of the loi_docx files.
6.4.1. Cover Page
First, you will check the metadata on the Cover Page. Many transcripts were first written before this standard, and may have different information. Double check that the Consent Forms and Media Release are in the server and “Digitally archived at Uvic,” and that the rights are “To project.” Note any issues on the Spreadsheet and within the Cover Page of the working transcript for anything missing. Fix any improper standards (make sure it is Last Name, First Name, etc.) in the Cover Page.
Next is to listen to the audio file while reading the transcript line-by-line to “copy-edit”. How much of the audio you are required to listen to during this process is indicated in the Spreadsheet in column N, whether the value is either “Full (RA initials)” or “Partial (RA initials)”.
If “Full”, it was previously determined that there were consistent transcription errors affecting readability not up to the conventions in place now. Listen to the whole interview while continuing the editing process.
If “Partial”, it was determined that there were minimal errors found, none that affected the meaning of the audio interview. Listen to roughly 15 minutes of the interview at minimum while continuing the editing process. It is at your discretion if you later determine it requires the “Full” treatment.
Other than the length of time spent listening to the audio, the editing and conventions are consistent. For all interviews, make sure all timestamps are in the centre of the page and wrapped in square brackets, correct any obvious errors, etc. Edit all ellipses into the format of “. . .” (dot space dot space dot). This is for consistency for future work. It is important to keep a standard for the writing of each transcript, so while doing this stage, please write as follows:
[00:00:00]
JORDAN We are here to talk to Mike Abe for the Landscapes of Injustice project. [Long pause.] Well Mike, thanks for speaking to me today.
MIKE [Laughs.] Thank you for having me today, [laughs] Dr. Stanger-Ross. [Both laugh.]⚓
Return to the "Transcriptions" section for a refresher on conventions.
Keep note of moments where you may not be sure of spelling or titles by typing “(?)” beside the information. Titles of companies or areas you can’t find on an easy google search should also be marked with “(?).” This is imperative for the Final Check stage and keeps a consistent standard for searching within the documents. This should have been done during the transcription stage but might have been transcribed earlier before the standard. Mark any lines of Japanese with “(?)”. It is important that we check with narrators for this information later. Make sure the format follows as the example below:
MIKE My middle name is Kenji(?). My mother would call me a yancha(?) if I was misbehaving as a child. Yancha bozu(?) she would say.⚓
Certain transcripts will need to be heavily edited because they were written before this standard.
It is important to be reviewing the timestamps, especially since previous transcriptions did not have a clear guideline. Moving through the Audio Check, ensure that the timestamp [00:15:46] is every five minutes. There is some flexibility, such as [01:21:12] or [00:04:36], but it is important to be as close to five minutes as possible.
Note: Only do an Audio Check for files that have one .WAV OR .MP3 file. Make a note on the Spreadsheet for any interviews with multiple audio files.
Also, if it is clear, please note whether a narrator is issei, nisei, sansei, or yonsei.
At the very end of the Audio Check, you are also required to fill in the summary within the metadata.
6.4.3. Summaries
Summaries are extremely important for future researchers working with LOI material. They should be about half a page (more or less, depending on the interview). They should be half general/inclusive, and then half LOI specific, meaning focusing on the loss of property, what items seemed important to the narrators, and whether they returned to their homes after the war, etc. Here is a rough guide to help you (however, each interview is different so this is a suggestion rather than a strict standard):
3-4 sentences about topics addressed in the interview (childhood, internment, Redress, etc.)
1-2 sentences about what seemed important to the narrator or the emphasis that they brought
1-2 sentences how it connects to dispossession:
discussion of loss
connection to dispossession
reflections on telling family history/family silences, etc
Be clear and concise, using active voice. Consider the summary as a sort of “teaser” that hits the important notes but doesn’t declare only one interpretation; imagine the narrator and how hard it is to summarize a person with one paragraph. Keep the tone open instead of static. For example:
Interview Summary: Roger Kishi’s father was interned in Christina Lake and his mother in Greenwood. In this interview, Roger explains that his paternal grandfather was a boatbuilder in Steveston and that his father built boats during the internment. Roger speaks about how his parents did not talk about internment, and his immediate and extended family also did not share their experiences. Roger narrates how as a teenager and early adult, he learned about this history during the Redress movement through books and documentaries. He explains that he cannot speak Japanese and feels he has lost his culture. He believes that it is important to record this history, to make sure it does not get lost, to acknowledge the wrongs in Canada’s past, and to focus on fighting discrimination of any kind. Roger recalls how his position as a community council member in Cumberland has led him to discover layers of this history: racism in mining records; the desecration of the Japanese gravesite after dispossession; Florence Bell’s class photographs in 1941 and ‘42 showing the loss of Japanese Canadian school children; and more. He describes an important connection for him that came in the early 2000s when he discovered the Campbell River Museum had a boat his paternal grandfather had built and sold to a Japanese Canadian family: the family sold the boat before seizure but bought it back in 1949 after they returned to the coast, fished it until the 70s, and then tied it up until the museum took possession and restored it. Even though dispossession is a hard history, he believes we must acknowledge and preserve it.⚓
Interview Summary: Linda King was raised in Trail, British Columbia. She begins this interview by describing how when she was a child, she travelled with her mother and sister to visit Dr. Shimotakahara in Kaslo. She recalls how she played with Japanese-Canadian children and her mother visited Amy Fugioka, a woman with chronic arthritis. Despite this experience, Linda explains that she only learned about the internment and dispossession in her 50s. This was when she moved to New Denver to own a shop and her friend Nobby Hyashi brought her books on the internment. When she moved to New Denver, she also met Tad Mori, a Japanese Canadian who in 1942 was in charge of guarding Doukhobor children. She recalls seeing the paper-thin shacks and feeling angry whenever this history is mentioned. Her mother had a kind attitude towards Japanese Canadians, and King attributes her perspectives today to the impact this had on her growing up. She recalls going to a garage sale at her Japanese-Canadian son-in-law’s grandmother’s house where they had jewellery and mink coats; she explains that this gave her the idea that this family was well-off before being uprooted from Vancouver. King discusses how this history should never have happened, and says that the money from Redress was not enough.⚓
Now, you need to update your files to the SVN repository. First using the SVN commands for navigating in the repository (using cd to move in the repository, for a quick refresh please see the "Using the Subversion Repository" section or refer to the documents you received from Stewart or Martin for the SVN repository guidelines):
For this stage, you will be contacting narrators for any spelling or confusing information within the transcript before we do XML markup. To start, be sure to put your initials in the Spreadsheet to show you are working on this stage. Next, proofread the “Interview Summary” in the Cover Page, written by whomever finished the Audio Check. This is to catch any typos and/or other issues.
Now, it is extremely important to note whether a narrator has requested to review the transcript prior to future use or if they have not consented to the use of their full name in published material. This can be found in their Consent Form and should be noted within the “Restrictions” section of the Cover Page (update if it is missing and update the Spreadsheet). If the narrators HAVE NOT requested to review the transcript, then the Final Check is still required for project purposes, but if we never hear from the narrator then we can still go ahead with XML markup.
For the Final Check, you will go through the transcript document and search for any moments of “(?)” then highlight the associated word or name like shown in the image below within the transcript. Make sure there are page numbers in the document. For example:
After this, you will generate a PDF copy of the transcript. It is important that this is a PDF file so that when we send it to narrators, they cannot edit the document itself. After you have marked all the terms that need to be checked and created the PDF, you will then make a new document from the Final Check Document Template (available in the LOI file server in “oh_documents”, in the archival cluster google drive under Oral Histories>Oral History Documents, or on Basecamp). Title this to match the working transcript (loi_tr_abe_mike) with the Final Check suffix so that it lines up beneath the file (loi_tr_abe_mike_finalcheck). Upload this to the loiOH repository. For a refresher, refer to Adding to the SVN Repository. Within that new document, you will fill out the [DATE] and [INTERVIEWEE NAME] as well as the table. For example:
PAGE NUMBER
NAME AND/OR INFORMATION
CORRECTIONS
31
Shizu
31
Shikata ga nai
To minimize the size of the fact checking document being sent to the narrators, please avoid repeating names. Use your discretion. If you think they may be referring to different people with the same name, then include each instance. This is to help make this process more efficient for the RA while asking for less work from our narrators, many of whom may be quite elderly.
After this step, you will then send an email (with the PDF and the new final check document) to the narrator. Their contact information can be found on their bio form in the file server.You will copy and use the Final Check Email Template (available on the file server in “oh_documents”, in the archival cluster google drive under Oral Histories>Oral History Documents, or on Basecamp). The email will offer them the option of submitting their corrections electronically or over the phone where you will fill out the table yourself. Please use the loi researcher gmail so a record of each exchange can be found—ask Stewart for login and credentials.
You may also call the narrators. This is an option because in the past we have had few responses to our electronic attempts. Ideally for ease of process, you can direct them to the email sent where they can choose to make corrections with you over the phone or on their own. They may do so electronically in the document or printed out, then scanned or mailed.
Suggested script for phone calls, please adjust as you see fit.
Hello I’m [your name] from Landscapes of Injustice, may I speak with [narrator’s name].
Hi I’m calling regarding the oral history interview you did with us in [year interview was done]. We are processing the interview now and would like to clarify some names and terms mentioned during your interview so the record is as accurate as possible. Do you have some time now to go over this list over the phone or would you like to fill out the document on your own and send it to us at a later date?⚓
If they only have a phone number listed or the email bounced back, ask if they have access to an updated email address or perhaps a spouse or children’s account that the documents can be sent to. If not, or they have other reasons to be unable to use a visual copy of the list, you will have to verbally verify the correct spelling of each word or name. The easiest method for this could be to spell the name slowly and clearly to them, or for them to spell the name to you depending on how well their hearing is/how clearly they speak.
Note: a narrator might respond requesting edits to be made to the written record because they are concerned by how they sound after reading the transcripts. There is an email drafted to be sent in response to these cases titled “Response EMAIL TEMPLATE” (available on the file server in “oh_documents”, in the archival cluster google drive under Oral Histories>Oral History Documents, or on Basecamp.) If this occurs over the phone, follow the sentiment in the draft, explaining softly that this is a historical record and that although people’s words can read awkwardly at times. This is normal in speech and every interview is like this.
If we have attempted contact with a narrator and not heard back, we will go forward with the XML markup. However, this is only for those who have not requested to review the transcript and who have all their required documents (Media Release and Consent Form). If documents are missing, this should be noted in their Cover Page and the Spreadsheet if it has not already been done.
The Final Check is only completed once:
You have heard back from the narrator and made the corrections (if necessary) to spelling and/or other information;
If the narrator has not responded, and they did not request to review the transcript, then Stewart has given the OK for Japanese language speaking RAs to go forward and check the document;
If the Consent Form and Media Release are filled out and digitally archived at UVic.
We cannot go forward with XML without the documents.
When you have heard back from the narrator or Stewart has given the OK for Japanese language speaking RAs to check the document, you will record this at the very end of the Final Check document. For example:
Another crucial task during the OH process is contacting narrators seeking corrected consent or media release forms, permission to use their real name, or for secondary permission after reviewing the transcript.
You can identify the interviews that have these complications or modifiers by looking at a few places in the OH workflow spreadsheet.
If the Access Location is in Yellow, there is an issue with the forms, no permission to use their real name, or they have requested to review the transcript. This is also indicated in the Permissions column and the NOTES/ISSUES column.
We cannot move forward with an interview if consent/media release forms are incomplete, or if they require the transcript to be reviewed.
We will need to contact the narrator’s according to the information we have available in the bio forms they filled out at the time of the interview. These can be found in the file server under their folder. Please contact them using the “Consent_Forms_EMAIL_TEMPLATE” document as a base for your email. Please adjust the email template as necessary according to the specifics of the missing content. This template document can be found in the LOI file server in “oh_documents”, in the archival cluster google drive under Oral Histories>Oral History Documents, or on Basecamp).
If there is no email listed on the bio form, it bounces back, or you don’t receive a response within a week or more, then try phoning the narrator, explain what the issue is (a missing signature, box not checked, etc.) and ask if they have an updated email address they can access where the documents can be sent to, or to check their inbox for it. We cannot accept consent over the phone as it must be in writing.
Suggested script for phone calls, please adjust as you see fit.
Hello I’m [your name] from Landscapes of Injustice, may I speak with [narrator’s name].
Hi I’m calling regarding the oral history interview you did with us in [year interview was done]. We are processing the interview now and have run into an issue regarding your [consent and/or media release forms]. [Explain what the issue is like there’s a missing signature, a box wasn’t checked, etc.]
It is very important to us that we properly correct this so we can ensure the wonderful interview you conducted with us can be included in the completed database.
[If you have attempted to send an email and didn’t hear back] I have sent an email to [read out the email sent to] with the original forms. Is this email up to date? [If yes] When it is convenient to you, could you please read over the email and reply with confirmation that you agree to the terms of the [consent/media release form]? If you’d rather, I could walk you through the email over the phone now or on another work day. The project requires written consent so I unfortunately cannot accept your consent over the phone but I could help walk you through the email now or another work day that is more convenient to you.
[If no email listed, email bounced back, or you are told the email is not current] Do you have access to an updated email address so I can send the email? When it is convenient to you, could you please read over the email and reply with confirmation that you agree to the terms of the [consent/media release form]? If you’d rather, I could walk you through the email over the phone now or on another work day. The project requires written consent so I unfortunately cannot accept your consent over the phone but I could help walk you through the email now or another work day that is more convenient to you.
Thank you very much for sharing your story with the project and for your cooperation again now. ⚓
6.5.2. Cover Page
Update the Cover Page and ignore those that say [Leave Blank].
6.6. XML Mark Up
Once the transcript has been Audio Checked and Final Checked, has all the necessary forms, then it is ready and polished for XML mark up. At this point, we should no longer have to alter the document or contact narrators.
Take note of the “Keywords” list in the metadata. All proper nouns being marked up within the document will be generated here. If there is a list from the transcript cover page, you can include them here beforehand. It is important for you to take note of any keywords that don’t fit the categories of Persons (personography), Places (placeography), and Organizations (orgography). These kinds of things include: titles of boats, titles of books, etc.
6.6.1. XML Quick Guidelines
When making new IDs for people, places, and organizations, ask yourself if this needs to be marked up and referenced, or if it is redundant information. For example, Ocean Falls is a secluded mill town on the coast of BC, but Chapel Hill, North Carolina is just a place a narrator lived once in their lives and has nothing to do with this history. Ask yourself what is worth mentioning, and what doesn’t need to be coded.
Only include street names within our four research areas: Vancouver, Steveston, Haney, and Salt Spring.
People should have IDs if they have some identifiable character or reference to this history.
6.6.2. XML Mark-up Steps
This a a step-by-step guide for marking up oral history transcriptions in TEI XML. Some details may differ for each interview but in general these steps are the tasks required to complete this task.
If you are starting to work on Oral Histories at this stage, here is how you determine which files to work on, in consultation with the Oral History Database workflow spreadsheet:
Look for a transcript that has someone's initials and a "Y" in the 'Final Check' column. This means that all other previous steps have been completed and it is ready to be worked on. If it is just the initals, it is in progress.
Make sure that nobody has written their initials in the 'XML' column. If there are initials here, someone is already working on it and you need to find another.
Once you have found one to work on, write your initials in the 'XML' column to indicate you are working on it
Now that you have selected which file to work on, open the transcipt. Sometimes there are multiple docx files that appear to be the transcript. Usually, it is one named loi_tr_lastname_firstname but when you open it double check that there is a name listed as having completed the Audio Check and the Final Check. Please also make sure that these names match those listed in the spreadsheet.
The following are the steps for XML mark up:
Location: Every interview has an XML file with incomplete metadata. You will find your assigned transcript in data/oralHistories.
Add timeline and use timestamp values supplied in the svn copy of the transcript for @absolute value. XML DocumentTranscription
Each roughly 5 minute block of the interview is wrapped in an <annotationBlock>. Every time a new person speaks, their statements are wrapped in an <u> element.
To start marking up the transcript replace <div><gap/></div> with interview content wrapped in <annotationBlock> and <u>. Copy and paste the text from the transcription, wrap in these elements and mark up according to the quick guidelines. Add new people to personography if they are either Japanese Canadian or a figure significant to this history that is not yet in the personography. Only add places and organizations if they are important. Make sure to mark up every instance of these (If "Japan" is mentioned 50 times, it needs to be marked up with a <placeName> 50 times). Example:
<annotationBlock start="#timestamp0"
end="#timestamp1"><u who="team:peki2">We'll just start by saying that we are interviewing <persName ref="prs:baba2">Mr. Sam Baba</persName>, today at the <orgName ref="org:jccc2">Japanese Canadian Cultural Centre</orgName> on October 27th, 2015. Thank you very much for meeting with us and doing this interview.</u><u who="prs:baba2">You are more than welcome.</u><u who="team:peki2">Great. So, <persName ref="prs:baba2">Mr. Baba</persName>, please tell me about your life.</u><u>Well, as you know, back in 1945 when the Pacific War ended, all of the Japanese were relocated outside of the <placeName ref="plc:brit1">BC</placeName> coast line into a lot of places, at that time, called ghost towns, which is a mining town that depleted. To accommodate the Japanese, they relocated to these so-called ghost towns. So I was 15 at the time, when the war broke out, and the whole family - of course, men over 18 years old - were all gathered and shipped into what they probably called prisoner camps. So mothers and children were all left without their fathers and big brothers. So we were shipped to a place called <placeName ref="plc:kasl1">Kaslo</placeName>, and that's where we started our life. Yes our dad and all the fellows that were over 18 we're never reunited with their families again for quite a few years. So we lived in the ghost town for about 4 or 5 years, I guess at the time. When the war ended the government gave us a choice of - we couldn't go back to <placeName ref="plc:brit1">British Columbia</placeName>, we had to go east of the Rockies. <placeName ref="plc:albe1">Alberta</placeName><placeName ref="plc:sask6">Saskatchewan</placeName><placeName ref="plc:mani1">Manitoba</placeName> or <placeName ref="plc:queb1">Quebec</placeName>. So we were in a place called <placeName ref="plc:tash9">Tashme</placeName>, and my brother and I -- what happened was -- my brother and I signed for <placeName ref="plc:japa1">Japan</placeName>, my dad made us sign for <placeName ref="plc:japa1">Japan</placeName>. The two oldest sons. He had 7 sons <incident><desc>laughs</desc></incident>, and 4 daughters. So the oldest one, he made us sign to go to <placeName ref="plc:japa1">Japan</placeName>. So we didn't want to go back to <placeName ref="plc:japa1">Japan</placeName>. However when we signed for <placeName ref="plc:japa1">Japan</placeName>, we got shipped out to a place called <placeName ref="plc:tash9">Tashme</placeName>, <placeName ref="plc:brit1">BC</placeName>, where all the people that signed for <placeName ref="plc:japa1">Japan</placeName> got sent there. So after the war they will be shipped to <placeName ref="plc:japa1">Japan</placeName>. So after the end of the war, the government gave us a chance to cancel our trip to <placeName ref="plc:japa1">Japan</placeName>. So I wrote my dad and said, <q> What should we do?</q>. He said, <q>You cancel it</q>, and at the time I was going around with my wife. So we got married. My dad took the whole family to Thunder Bay, Fort Williams. And they went to a bush camp to work in a logging factory. So my wife and I got married in <placeName ref="plc:tash9">Tashme</placeName>, and <placeName ref="plc:toro1">Toronto</placeName> and surrounding areas were all closed to Japanese, you couldn't come in here, you know? Unless you had a sponsor. Fortunately for us my wife had a very good friend living in <placeName ref="plc:toro1">Toronto</placeName> already, so she sponsored us, and rented a Jewish home on Bathurst Street - one bedroom. So we came to <placeName ref="plc:toro1">Toronto</placeName> back in 1946 I think it was. And we started living in this Jewish home. And then fortunately my wife was a seamstress, she had her own dress company, little dress store in Vancouver. So when we came here, she was able to find work right away at a Jewish dress manufacturing company called Exclusive Dress on King St. So she found a job right away. We had no money, you know, to speak of. After paying a couple weeks rent we had nothing. Fortunately she started working so at least we we're able to pay rent and eat. And I used to read <placeName ref="plc:toro1">Toronto</placeName> newspapers every day looking for the want ads, and I would go apply for a job. As soon as they see my black hair - position filled. I walked the streets of <placeName ref="plc:toro1">Toronto</placeName> for 3 months, couldn't find a job, nobody hired me, you know? I said, <q>oh my God, what did I get myself into?</q>. Later on a friend of mine phoned me, said <q>Sam, there is a job at a Jewish factory, a toy company.</q> I said, <q>I don't care what it is, I'll take it.</q></u></annotationBlock>
* Don't forget to change the timestamps on the next <annotationBlock>.
Add incidents of significance (i.e. things that interrupt the interview or the flow such as answers phone call, door, checks on dinner etc) with a <desc> in an <incident> tag:
<incident><desc>Dishes clatter in the background again</desc></incident>
We are marking up all people, places, and organizations. Please refer to the TINA Mark Up guide for details on this process. Also see Creating XML ids for instruction on how to enter a new entity into the database. BUT, before you start marking up your transcript, please see below for tricks and tips on how to do some of the mark up mechanically and efficiently.
Below are more specifics on marking up transcriptions.
6.6.2.1. Action, Pauses, Laughter, and Other Moments
Anytime there are square brackets in the original transcript relating to a non-speech moment in the original interview, encode these moments with elements <incident> and then <desc>. For example, a [Pause] in XML would become:
<incident><desc>Pause.</desc></incident>
Make sure to remove the square brackets. Also, inside the <desc> element the first word should always be capitalized and there should always be a period before the closing <desc> element.
In the instance when something is unclear, tag the "[unclear]" text with:
<unclear/>
The "unclear" text does not need to be included.
If there is text from the transcript noted as unclear, such as:
I think they were happy. [Unclear about this statement because it was difficult to hear the narrator.]⚓
Wrap the uncertain text with the <unclear> element:
<unclear>I think they were happy.</unclear>
6.6.2.2. Editorial Notes
Due to inconsistencies in transcribing oral history interviews, some square brackets also contain editorial notes from transcribers or others.
Editorial notes should be marked up using a <note> element with an type attribute with the value of “editorial” and an resp attribute with the value of “team:(team member’s ID that made the editorial note)”.
For example, if Nathaniel Hayes with XML ID haye1 transcribed an interview and left the editorial note [This Japanese word means fish paste.] The mark-up would be as follows:
<note type="editorial" resp="team:haye1">This Japanese word means fish paste.</note>
These notes should appear in the exact location where they were found in the transcript and the element should be beside the final punctuation of the sentence (i.e. think of them like a footnote; there should be no space between the period, comma, or quotation that the footnote follows):
<p>Here is some text about a thing.<note type="editorial" resp="team:haye1">Note Like This.</note> And here is some more text.</p>
6.6.2.3. Quotes and Quoted Speech from the Transcript
Mark up all literal quotation marks in the original transcript with the <q> element and remove the quotation marks added from the original transcript.
For example:
<p>She would tell me, “Eat all your food.”</p>
Would look like:
<p>She would tell me, <q>Eat all your food.</q></p>
6.6.2.4. Japanese Language Words in English Transcripts
When a Japanese word is in an English transcript, we encode these words with the <foreign> element and the xml:lang attribute with the value of “ja-Latn”:
<foreign xml:lang="ja-Latn">takai</foreign>
If you are unsure if a word is a Japanese word, please ask someone on the LOI team with Japanese language knowledge.
6.6.2.5. Sensitive Text and Personal Information
We have been advised that very little should be redacted from the oral history interviews. Be very selective in what you deem severe enough to be omitted as it should be either personal details that are a risk if made public (like contemporary home address or contact information) or detailed/graphic accounts of mental distress or death. If you are unsure, feel free to reach out to fellow RA’s or contact Gord or Stewart.
6.6.2.5.1. Address or Home Location
If an address is listed or a person’s home has been described in a way that could be identifiable via google searching (i.e. mentioning someone lives in West Vancouver is general enough to include, but mentioning that someone currently lives near a recognizable landmark in a named community is of concern), then this information needs to be redacted for privacy concerns.
To redact the information, we use the <gap> element with the attribute reason and the value “privacy”.
For example:
<p>We are interviewing Nathaniel Hayes at his home at <gap reason="privacy"/>, which is quite beautiful.</p>
6.6.2.5.2. Sensitive Information
Based on our Risk Matrix guidelines, certain information was deemed sensitive. This text should already be marked in the .docx transcript, and the type of sensitivities should be listed at the top of the XML document in the <TEI> element under the ana attribute (if not please refer to metadata mark up steps).
Sensitive text should be wrapped in the <seg> element with the ana attribute and the appropriate sensitivities.
For example:
<p>And that is how fish paste was made in Tofino. But I am remembering something. I never tried it when I was younger. <seg ana="sens:stereotype">It was something you just didn’t do back then, eating food Orientals made.</seg></p>
Outdated language should be flagged for oral histories.
If the sensitive material spans two utterances, then the sensitive material will require multiple <seg> elements because <seg> elements must be within a <u> element. If split by an <annotationBlock> or a new utterance for example, then ensure both <seg> elements are self contained on either side of the <annotationBlock> in <u> elements.
<u who="prs:fake1"><seg ana="sens:stereotype">It was something you just didn’t do back then. . .</seg></u><u who="team:fake2">Didn’t do what?</u><u who="prs:fake1"><seg ana="sens:stereotype">Eat food Orientals made.</seg></u>
6.6.3. Marking up dual language interviews
If your interview is in two languages (English and Japanese) please leave the mark-up for this to our LOI language experts. An example of this kind of interview can be seen in yama81_2018-03-19.xml where the main language spoken is Japanese and the speakers occasionally switch to English. If you are to transcribe a dual language interview, please use this document as a guide for mark-up. Note that xml:id for <u>, in each language, correspond with a <u> of the other language, have an abbreviation indicating the language of the referent and the utterance, and have the id of the interview prepended to it. And the reverse is true for the corresp:
<annotationBlock start="#timestamp0"
end="#timestamp1"><u xml:id="yama81_2018-03-19_en1"
xml:lang="en" corresp="#yama81_2018-03-19_entrans1"
who="team:naka96"> So, this is <persName ref="team:naka96"><forename>Carolyn</forename><surname>Nakagawa</surname></persName>. I'm here with <persName ref="prs:yama81"><forename>Terumi</forename><surname>Yamamoto</surname></persName> and <persName ref="prs:jens1"><forename>Fay</forename><surname>Jensen</surname></persName>, and we are here at their home in <placeName>Richmond</placeName> to record <persName ref="prs:yama81"><forename>Terumi</forename></persName>'s oral history for the <orgName>Landscapes of Injustice</orgName> Project. And, it is <date when="2018-03-19">March 19th, 2018</date>.
So, <foreign xml:lang="ja"><persName ref="prs:yama81"><forename>てるみ</forename></persName>さんと呼んでもいいですか.</foreign></u><u xml:id="yama81_2018-03-19_entrans1"
xml:lang="en" corresp="#yama81_2018-03-19_en1"
resp="#yama81_2018-03-19_trl"> So, this is <persName ref="team:naka96"><forename>Carolyn</forename><surname>Nakagawa</surname></persName>. I'm here with <persName ref="prs:yama81"><forename>Terumi</forename><surname>Yamamoto</surname></persName> and <persName ref="prs:jens1"><forename>Fay</forename><surname>Jensen</surname></persName>, and we are here at their home in <placeName>Richmond</placeName> to record <persName ref="prs:yama81"><forename>Terumi</forename></persName>'s oral history for the <orgName>Landscapes of Injustice</orgName> Project. And, it is <date when="2018-03-19">March 19th, 2018</date>.
So, may I call you <persName ref="prs:yama81"><forename>Terumi</forename></persName>?
</u><u xml:id="yama81_2018-03-19_ja1"
xml:lang="ja" corresp="#yama81_2018-03-19_jatrans1"
who="prs:yama81"> はい.
</u><u xml:id="yama81_2018-03-19_jatrans1"
xml:lang="en" corresp="#yama81_2018-03-19_ja1"
resp="#yama81_2018-03-19_trl"> Yes, you may.
</u><u xml:id="yama81_2018-03-19_en2"
xml:lang="en" corresp="#yama81_2018-03-19_entrans2"
who="team:naka96"> Yes, so can I ask you about your first memory of your life? Do you remember from your childhood, early memories? <foreign xml:lang="ja">子供の頃の<choice><orig>記憶</orig><reg>(きおく)</reg></choice>がありますか。</foreign></u><u xml:id="yama81_2018-03-19_entrans2"
xml:lang="en" corresp="#yama81_2018-03-19_en2"
resp="#yama81_2018-03-19_trl"> Yes, so can I ask you about your first memory of your life? Do you remember from your childhood, early memories?
Do you have any recollection of your childhood?
</u><u xml:id="yama81_2018-03-19_ja2"
xml:lang="ja" corresp="#yama81_2018-03-19_jatrans2"
who="prs:yama81"> (?) 分からん。
</u><u xml:id="yama81_2018-03-19_jatrans2"
xml:lang="en" corresp="#yama81_2018-03-19_ja2"
resp="#yama81_2018-03-19_trl"><unclear>(?)</unclear> I don’t understand.
</u></annotationBlock>
6.6.4. Encoding Tricks and Troubleshooting
This section provides instructions for a search/replace trick using regular expressions (regex) and a way to check <annotationBlock> attribute values with XPath.
6.6.4.1. Global Search/Replace for Place Names
A tool for marking up common place names in an interview.
Within interviews, places are often refered to or mentioned many times. Even copy/pasting an encoded string can be time consuming. It is recommended to leave all the common places alone until the end of the encoding process and then run a search/replace with some regex constraints. Following these instructions is a list of common places that can be used in the search dialogue box.
Tip: When entering the keywords in the keywords list make note of them, they will likely be your most common places to mark up. Also, make sure you tag any places in the list items manually because they will not be matched with the regex search pattern.
In your XML document hit 'ctrl f' to open the search dialogue. Make sure that you have the "Case sensitive" and "Regular expression" options selected.
Your search pattern will look like this (Example is Greenwood):
*** These instructions are designed with the list of places above in mind only. It is possible to use regex for people and organizations, however, caution is advised. Global search/replaces are a powerful tool and bad things can happen if not used with care. If you do choose to experiement with search/replace and regular expressions remember to put "//u" in the XPath box to confine search to interview text. Please note: this only limits your search to the nodes of this element, it will not help you if you, for example, replace the wrong name because two people share a last name, or get another unintended result. Use this tool at your own risk!
6.6.4.2. Using XPath to troubleshoot <annotationBlock> errors
Sometimes (especially while encoding longer interviews) you may find that you forgot to change the values of the timestamp attributes in the <annotationBlock>. You can use XPath to see all the <annotationBlock> and their attribute values.
First enter this query in the XPath box on the toolbar:
Hit enter and down below you should see the list of <annotationBlock>.
Note that the @start and @end are reversed. This is fine; you can still scroll through this list to see where timestamps were missed or duplicated causing error in timestamp markup.
Tip: timestamps are roughly 5 minutes apart. If you are adding an <annotationBlock> at a time that is roughly close to a time that ends in an even number, the number of your @start should be even as well; and vice versa for odd numbers.
6.6.5. Final Steps
Finally, make sure your name is in the XML metadata of the Cover Page and that you have updated the Spreadsheet. DO NOT FORGET TO COMMIT YOUR CHANGES TO THE SVN REPOSITORY.
Thank you for helping us finish these interviews! They are a benefit to the project and your work is highly appreciated!
6.6.6. Encoding Supplementary Materials and Related Items
In some cases, oral histories contain related items that should be distributed with the interview (photographs, scans of documents, et cetera). These files (usually collected into a single PDF) should live on the HCMC server. Once they have been placed on the server, a pointer to the file's location on the server should encoded in the document's <notesStmt> (between the <publicationStmt> and the <sourceDesc> in the document's <teiHeader>) using a <relatedItem> with a type=supplementaryMaterial and an target that points to the file's location on the server:
6.6.7. Specifying Sequences of Oral Histories (Added 2021-02-13)
Sometimes, interviews are conducted over multiple days or are somehow related to one another in a sequence. While this was fomerly specified in the <title> of the document, the project has decided to take a more formal approach for noting sequences to aid in navigating the document collection.
Specifying a sequence of documents is a bit labour intensive, but fairly straightforward. On the document's <text> element, use the next and prev attributes to point to the next and previous documents in the sequence respectively using doc: prefix and the target document's xml:id. Here is an example from the second of three oral histories narrated by Winifred Awmack:
The diagnostics will flag any errors in this sequencing, so make sure to confirm the validity of the pointers by checking the diagnostics after the build has completed.
7. Case Files Data Entry Guide
This process and template are the end result of a period of trying different ways of working with the case files and is what we have found to be the easiest and quickest way to process case files while still maintaining a high level of detail for each file.
7.1. HCMC Setup
7.1.1. Google Drive Permissions
Gain access to the Archival Cluster Google Drive by having another RA with access share it with you (it is only accessible by collaborators). Bookmark this page as you will be working with it often.
7.1.2. Local Machine Setup
In your “Documents” directory (folder), create a subdirectory (subfolder) titled “casefile_conversions” (do not include the quotation marks in the folder name).
Within “casefile_conversions”, create another directory titled “Hopper”.
Retrieve (download and save) the pdf-maker shell script titled “rg117_CaseFiles_pdfMaker.sh” from Archival Cluster Google Drive to your local machine and move it to “casefile_conversions” directory.
To make the pdf-maker shell script executable, right click the program and select properties. Under Permissions, check the box that states “Allow executing file as program”.
Your “casefile_conversions” directory should now be set up as follows:
7.1.3. Access and Drop Point
Open the File Manager tab from the command bar (located in the vertical toolbar on the Desktop).
Select Other Locations noted on the left side (scroll down to the bottom of the list).
Connect to the server:
If this is your first time, where it states “Enter server address” enter “sftp://nfs.hcmc.uvic.ca” then select “connect”. (If you cannot access this server, please talk to Stewart or Martin for permissions; this may take a day or two due to Uvic programming administration.)
If this is not your first time, select the down arrow (next to the “Connect” button), select the recent server titled “/ on nfs.hcmc.uvic.ca sftp://nfs.hcmc.uvic.ca/”, and then select “Connect”.
To access the server, fill in your netlink ID and password when prompted. You may be presented with the option to save your login details so you don’t have to re-enter them every time you log in to your machine; select whichever option you prefer and then select “Connect” (or press the enter key).
Follow this path through directories (folders) to the case files:
The directories inside of “rg117_c-3” contain the various microfilm reels you will be processing (e.g., the directory “C-9322” contains the C-9322 microfilm reel images).
To start, locate the directory “rg117_C-3_PDFs” inside of “rg117_c-3” (it should be the last directory in the list if you have the directory ordered alphabetically by name). Right click on “rg117_C-3_PDFs” and select “Open In New Window”. [Note: Opening directories in this way (right clicking and then opening in a new window or tab) will maintain your access to the server so you don’t have to reconnect every time when opening multiple directories in different windows; however, you can always reconnect in any window by re-following the steps above.]
“rg117_C-3_PDFs” is the directory to which you will upload your pdfs (after making a pdf for a single case file). For now, drag this window aside for later.
7.1.4. Starting a Microfilm Reel
Return to the open “rg117_c-3” window and select a microfilm reel directory to work on (e.g., directory “C-9321”):
Determining which reel to start working on is done by consulting the Case Files (RG117 C-3) Tracker to see which reels have already been completed and which are currently being worked on by other RAs. Reels are processed in sequential order, so it’s recommended that you start on the next sequential reel (i.e., the reel that follows the one[s] currently being worked on by others). [Note: It’s best practice to bookmark the tracker as you will be using it often.]
In the tracker, scroll down to find the last completed case file; note the reel number (column H of spreadsheet) of this file as you will be starting on the next sequential reel.
If you need assistance, ask a fellow RA (who is working on case files) to confirm which reel you can start on.
Open your microfilm reel and starting page
In the same “rg117_c-3” window, open the reel directory you’ve elected to work on.
Open a page (a jpg file) in the reel directory to start working from:
If starting a new reel, you will start on page 0001.
Note: In some cases, the first page of a new reel may not coincide with the first page of a case file (e.g., page 0001 of reel C-9322 is part of case file #1604, which actually begins in the previous C-9321 reel).
If your reel begins with a case file that started on previous reel, ignore it and move to next case file. If your last case file crosses into the next reel, go to that reel, download the images to complete the case file, place them in your "hopper" along with the other images, and then execute the shell script.
If not starting a new reel and continuing one already in-progress, reference the Case Files Tracker to check which page to start from in this reel (i.e., the next sequential page in the reel following the case files that have already been completed and recorded in the spreadsheet).
Drag both the “rg117_c-3” window and the opened case file page (jpg) aside for later.
7.1.5. Hopper and Terminal
Open the “Hopper”:
If not already open, open the “casefile_conversions” directory (on your local machine) that you created in the Local Machine Setup stage.
Right click on “Hopper” and select “Open In a New Window”.
The “Hopper” is where you will copy your microfilm reel images to in order to make pdfs.
Use the Terminal to move to the “casefile_conversions” directory:
Open the Terminal (located in the toolbar on your desktop).
Determine which directory you created “casefile_conversions” in (if not in “Documents”); move to that directory and then move to “casefile_conversions”. For example:
Once in “casefile_conversions”, (Linux .sh users) open the pdf-maker shell script by typing “./r”, press Tab to autocomplete “rg117_CaseFiles_pdfMaker.sh”, and then press the enter key. (Windows .bat users), start typing "rg..." and press tab to autocomplete, and the press the enter key.
This shell script will be used to generate the pdfs and metadata for input into the tracker.
7.1.6. Metadata Notes Document and Templates
Create and set up a text document for your metadata notes:
Open up LibreOffice (in the toolbar on the desktop).
Create a new text document.
Copy and paste the following page into your text document:
[Reel number you’re working on; e.g., C-9321] Metadata Notes - [Your Name]
Microfilm Reel #: [Reel number you’re working on; e.g., C-9321]
Case File #:
File Person’s Name:
Citizenship Status:
Sex:
Metadata Author: [Your Name; e.g., “John Smith”]
Type:
Scope and Content:
He was born on _. He was a(n) _ employed by _. His family includes _. His home address is listed as (or He lived at/in) _. He was forcibly uprooted to _.
or
She was born on _. She was a(n) _ employed by _. Her family includes _. Her home address is listed as (or She lived at/in) _. She was forcibly uprooted to _.
In your text document, replace all the square brackets with the information relevant to you and the reel you’ll be working on.
Save this document in “casefile_conversions”, including the reel number and your name in the title (e.g., “C-9321 Metadata Notes John Smith”).
The template is what you will use to record metadata and write scope and content as you process case files. For each new case file you work on, you will re-use the template section in your text document by copy and pasting, always leaving yourself a blank one in your text document for future use.
Note: The paragraph format is set up in such a way that double clicking on the underscores will select them, allowing you to replace them by inputting the information for that field.
You’re now all set up to process case files!
7.2. Processing Case Files
You will be working page-by-page through each case file, writing metadata notes for the file in your text document as you go along. Afterwards, you will create a pdf for the file using your metadata notes, upload the pdf to the HCMC server, and input the metadata into the Case Files (RG117 C-3) Tracker.
If you’ve followed all the steps in the previous sections above, the following should already be open (if not, open them now):
e.g., “c-9321-0952.jpg” (starting page, or page you left off on, of your microfilm reel)
Terminal with pdf-maker shell script (“rg117_CaseFiles_pdfMaker.sh” or “rg117_CaseFiles_pdfMaker.bat”) open
your “Metadata Notes” text document
7.2.1. Screens Layout
1. First, you’ll need to arrange the windows listed above on your screens in a manner that is efficient for you to navigate between them as you work.
While you’re working page-by-page through a case file, you’ll need to have the Image Viewer window (displaying jpg pages of the file) and your “Metadata Notes” text document (to take notes as you read) most prominently in view.
However, in the background you should also have all the other windows ready for the next steps afterwards.
Recommendation:
On one screen have open the following (on the left screen in the example above, clockwise from the top left):
“casefile_conversions”
“RG117_C-3_PDFs”
your starting case file page.
your chosen microfilm directory
“Hopper”
On the other screen have open the following (on the right screen in example above, left to right):
2. Once you’ve laid out your windows, you can now enlarge your Image Viewer window with the first page of your case file to take up an entire screen (to more easily read through the file).
Note: You can snap a window by clicking its title bar and dragging it to the edge of a screen and holding it, letting go after the blue snap-preview animation appears. Drag and hold to the top of a screen to make the window full screen. Drag and hold to either the right or left side of a screen to make a window half screen (vertically).
Please read through the rest of this guide before starting to process case files on your own.
7.2.2. Metadata Formatting
Certain metadata fields need to be strictly formatted according to the metadata guidelines below to ensure the correct output. For now, read through and familiarize yourself with the guidelines; however, as you work, please refer back to the guidelines often until you’ve memorized the correct formatting.
METADATA FIELDS
NOTES
EXAMPLES
Page # Range:
####–####
Each page range must be 4 digits; add zero(s) before the page numbers if less than 4 digits. Page numbers are listed in the file names of the jpgs (last 4 characters/digits of file name).
0001-0025 0952-1053
Microfilm Reel #:
C-####
Reel number is found in the directory name and also in the file names of the jpgs (first 6 characters of file name).
C-9322
Case File #:
##### #####_xi
Case file numbers must be entered as 5 digits; add zero(s) before the case file number if less than 5 digits.
For case files which have “XI” listed before the case file number (e.g., “XI-1305”), add “_xi” after the file number to assure sequential filing.
00250 01305_xi 12500
File Person’s Name:
last-first
File person’s name must be entirely lowercase, with the last name and first name separated by a hyphen only.
If the person has more than one listed first name or other name, put only one in this metadata field. Use your discretion on which name to use in the metadata (for example, you could use the name that appears in the file most often). Then, include the person’s full name and/or alternate names in the scope and content.
tanaka-kenji suzuki-yuki
Citizenship Status:
naturalized Canadian Canadian born Japanese national unknown
The file person’s citizenship status; found on the “Information from R.C.M.P.” form (usually the second document in file).
Use uppercase for Canadian and Japanese only.
Sex:
0 1 2
0 = unknown 1 = male 2 = female
Metadata Author:
First Last
Your name.
John Smith
Type:
person business
Indicate whether the case file is for an individual person or a company/business. The majority of files are for people.
* See “Businesses” if you come across a business case file.
Note 1: The order of the fields listed above is not necessarily the order that such information will appear in a file; rather, this order is reflective of how you will need to enter data in the Terminal for the pdf-maker shell script. We will explain this process in the pdf Making section.
Note 2: Sometimes you will come across duplicate images of the same case file. In such cases, you will write “DUP” and the page range of the duplicate in square brackets following the actual page range. For example, “0397 - 0400 [DUP 0401 - 0404]”.
Note 3: If a file spans two reels, record the page range of the file in both reels and enter it into tracker as “xxxx - xxxx [xxxx - xxxx]” (with the data in the square brackets being the page range of the second reel). For example, “2354 - 2413 [0001 - 0056]”. Also, record the second reel number in square brackets after the first. For example, “C-9317 [C-9318]”.
7.2.2.1. Process Example Pt. 1: Initial Metadata
In this section, we will start working through case file #1630 from start to finish as an example of the metadata-writing process.
Starting with the first page of your case file, you can already begin filling out some of the metadata. Usually, the first page of a case file starts with an index card with the case file number written on it. From this first page, we can note in our text document the starting page of the file (“0952 - ”), the case file number (“01630”), and the reel number (“C-9322”).Note: Confirm that this initial handwritten case file number matches those listed on the documents following it.
Usually, the next document in the file is an “Office of the Custodian - Japanese Section” form for the file person. From the first page of this form, we can note the file person’s name (“nogami-sankichi”) and their sex (“1”), which we can use to assume which pronoun template to use.Note: The version of this initial Office of the Custodian form may vary from file to file depending on the age of the file person and how much property they owned. The one in the example above is the longer three-page form; you may also see a one-page form instead.
At this point of the file, we can now also start writing the scope and content.
7.2.3. Scope and Content Style Guide
This part of the document is a template for the Scope and Content section of the case files. It is meant to provide guidance for writing Scope and Content to ensure relevant information is included.
The Scope and Content for the case files do not follow archival practices; rather, they are more like brief bios of the file persons with summaries of their dispossession.
Unlike the metadata formatting, the Scope and Content formatting is more flexible to account for differences in lived experience and variances between files; use your discretion on including information that may go beyond the template and provided examples. However, for consistency, please adhere to the scope and content template that you copied and pasted into your Metadata Notes document earlier as well as the Metadata Guidelines.
7.2.3.1. Language
Read through and refer to the LOI Public Outputs Language Guide, written by Project Director Jordan Stanger-Ross, for an overview of terms that we do not use while writing Scope and Content, along with alternatives for each.
7.2.3.2. Pronouns
For the scope and content, you will use the pronouns corresponding with the file person’s listed sex; i.e., use masculine pronouns (he/him/his) for those listed as male and use feminine pronouns (she/her/hers) for those listed as female.
S & C FIELDS
EXAMPLES
He/She was born on
He was born on
He/She was
He was
His/Her family includes
His family includes
He/She lived
He lived
7.2.3.3. Birthdate and Occupation
After determining and filling out pronouns, you can move on to the biographical details of the file person.
S & C FIELDS
NOTES
EXAMPLES
He/She was born on dd Month yyyy
He was born on 03 December 1893.
He/She was [occupation] employed by [employer]*
*If available, include employer information such as name, company/organization, and address.
He was a fisherman employed by B.C. Packers, Claxton, BC.
7.2.3.4. Names and Family Members
7.2.3.4.1. Names
Usually, in the files, last names are listed first and in all caps (for example, “SUZUKI Yuki”); however, this will not always be the case. It’s always best practice to check names listed on official forms (i.e., the initial “Office of the Custodian - Japanese Section” form and the “Information from R.C.M.P.” form) against those in the rest of the file.
Note 1: Often, these initial forms will have incorrectly spelled names, so pay attention to variances throughout the file to determine the correct spelling and/or alternate spellings.
Sometimes, names are difficult to read or are written differently throughout the file. You can use square brackets following the name (but before the parentheses) to indicate other variations on names or other possible readings.
TEMPLATE
EXAMPLES
First Last [alternate names]
Tetsuro Masuda [also, Tetsuro Thomas Masuda]
Yuka Tanaka [possibly Yuko Tanaka]
Note 2: As specified in the Metadata Formatting, if the file person has more than one listed first name or other name, write only one in the metadata field for names (i.e., “last-first”), using your discretion. Then, include the full name and/or alternate name(s) in the Scope and Content. For example, for a person listed as Harry Ryutaro Deguchi, you could write the metadata field as “deguchi-harry” and include in the Scope and Content the sentence “He is also named in the file as Harry Ryutaro Deguchi.”
If you’re having trouble with a name, record your best guess (using square brackets if needed) and move on. A general disclaimer will be included regarding names within the project to cover this uncertainty.
Usually, the last names of file members’ wives and children are omitted in the case file; for this project, you can assume that their last names matched that of the file person’s, unless otherwise specified.
If the file person was a wife, her file will often list her name as “LASTNAME (firstname) Mrs. husband’sfirstname”. Do not include her husband’s first name as part of her name; rather, you will list her husband as a family member (see next section below).
For any person that has a maiden name, include both the person’s first AND last name for BOTH their married name and their maiden name. For example, if the file person was a married woman who was registered with the Office of the Custodian under her married name, use that name for the metadata but in the Scope and Content include an additional sentence listing her maiden name (i.e., “Her maiden name is Firstname Maidenlastname”). This will allow both her married name and maiden name to be string searchable.
7.2.3.4.2. Family Members
Following the “His/Her family includes” field of the scope and content, you will list all the names of the file person’s family members listed in the file, and include relevant information about each member in parentheses.
For each family member, format their information as follows:
First Last [alternate names if applicable] (relevant information)⚓
The family information provided in each file is highly variable. You must include the family members’ names and their relation to the file person, but please include as much relevant information in your scope and content as is provided in the file.
Relevant information includes the options in the following table:
These options are examples of information you may find, but will likely not be present in every case file. The information that is included must be formatted in the following order:
Following the “He/She lived” field of the scope and content, you will list all of the provided locations for the file person.
Generally, you will start by listing the provided home address(es) for the file person and then listing where they were forcibly uprooted to.
If the file person was exiled to Japan, also include this information in this field. Such information is usually stamped on the “Information from R.C.M.P.” form as “RETURNED TO JAPAN” with the boat name and date of exile (please include date).
He/She lived at _, was forcibly uprooted to _, and was exiled to Japan on dd Month yyyy.⚓
Note: If not all of this information is provided or applicable, only record what is and move on.
Examples:
She lived in Hakoda Bay, Tofino, BC and was forcibly uprooted to New Denver, BC.
Her home addresses are listed as 3681 West 6th Avenue, Vancouver, BC and 231 East Cordova Street, Vancouver, BC; she was forcibly uprooted to Tashme, BC and was exiled to Japan on 02 October 1946.
He lived at 776 Powell Street, Vancouver, BC and was forcibly uprooted to Japanese Work Camp, Unit Four, Three Valley, BC; Giscome, BC; Greenwood, BC; and Eagle Lake Sawmills, Giscome, BC.⚓
Stylistic Notes for Locations
Stylistic Notes
Examples
Ordinals:
Format as “1st” and not “first”
“1700 West 1st Avenue, Vancouver, BC”
Places:
Include both city and province Abbreviate province names
“Vancouver, BC” “Winnipeg, MB”
Punctuation:
No internal periods in place names Internal periods in organization names, if it appears that way in the document
“Toronto, ON” “B.C. Security Commission” but “RCMP”
Abbreviations:
All other abbreviations spelled out; for e.g., change “St.” to “Street,” “Dept.” to “Department,” “W.” to “West”, “R.R.” to “Rural Route”, and “Co. Ltd.” to “Company Limited” Maintain “&” in organization names
7.2.3.6. Process Example Pt. 2: Scope and Content, Other Metadata
Continuing with our example case file from Process Example Pt. 1, we can start filling out the scope and content for #1630.
1. Work through the case file page by page to fill out the rest of the metadata (according to the Metadata Formatting) and the scope and content (according to the Style Guide).
Usually, the majority of the file person’s biographical details, including citizenship status, can be found within the first two documents (“Office of the Custodian - Japanese Section” form and “Information from R.C.M.P.” form).
Note: Some file pages will be incorrectly oriented. As you work through a file, make note of which page numbers need to be rotated in your Metadata Notes document. See pdf Making.
Please IGNORE all of these columns EXCEPT for the “Sensitive” column. These other columns concern previous processes for case files.
7.2.4.1. Sensitive
As you work through case files, you will fill out this column out as necessary (i.e., it will not be applicable to all case files).
The column is for indicating that a file contains information deemed by the project as potentially sensitive. Marking a file with these label(s) will assign it a severity label according to our risk matrix. If the combined label severity is equal to or greater than “High-grade” level, the file will be restricted (metadata only, redacted names).
Carefully read through the Risk Matrix section, paying particular attention to the instructions regarding case files. Please refer back to the matrix before assigning any labels to a file and consult other RAs or Stewart if you’re unsure if a file warrants a label.
For quick reference, the labels are as follows:
“sens:illness”
“sens:youth”
“sens:implicate”
“sens:criminal”
“sens:stereotype”
“sens:cultural”
“sens:dishonour”
"sens:details"
Record any labels in your text document for later input into the tracker spreadsheet.
Labels should then be inputted into the “Sensitive” field of the tracker spreadsheet according to the following formatting guidelines:
Every label should be prefaced with “sens:” (beginning with a lowercase letter “s”) followed by the label name/type (with no spaces between); for e.g., “sens:illness”.
You may apply as many of the labels as appropriate to any document.
Include no more than one instance of any label for any document.
Multiple values are separated by a space only.
For example:
7.2.4.2. Process Example Pt. 3: File Notes
While writing scope and content, concurrently record any necessary information in the file notes field.
1. File #1630 does not contain any content that would warrant a Sensitive label, so with all of the metadata fields and scope and content completed, we’re ready to create a pdf of our case file.⚓
*At this point, if you haven't yet started working on a case file you can begin to do so now. Once you have worked through your case file and written all of the metadata, scope and content, and any file notes, return to this point in the guide to learn how to make your file into a pdf and record the file in the tracker.
7.2.5. pdf Making
As mentioned in the Hopper and Terminal section, you will make pdfs using the “Hopper,” the Terminal, and the pdf-maker shell script.
Once you’ve determined the page range of your case file, you will copy these images from the HCMC server to your local machine in the “Hopper” directory.
Within your microfilm reel directory window, start by clicking on the first image file (of your case file) to select it. Next, scroll to the last image file, hold down the ‘Shift’ key, and click on that last image to select that range of files.
Now, with all of your file pages selected, COPY the images and paste them into your open “Hopper” directory window. DO NOT ‘CUT’ the images or they will be deleted from the server.
Now that the images are in the “Hopper,” rotate any incorrectly orientated pages (that you made note of in your text document as you worked through the case file). When asked if you would like to save your changes before closing, select “Save”.
Note: You must do image rotations on your local machine as such changes cannot be made to image files on the HCMC server.
Next, copy and paste the metadata (that you recorded in your text document) into your Terminal window with the pdf-maker shell script open. Follow the prompts in the script to complete all fields, pressing ‘Enter’ after each input. Note: For copy and pasting, the Terminal only accepts right clicking (not ctrl commands).
Once you’ve hit ‘Enter’ after the last field (the Metadata Author field), the script will convert the images in the “Hopper” into a pdf. This newly created pdf will now be located in your “casefile_conversions” directory. DO NOT CLOSE THE TERMINAL WINDOW.
Now you will copy your created pdf from your local machine to the HCMC server in the “RG117_C-3_PDFs” directory.
Note: The script will automatically name the pdf file; but for reference, the LOI filename convention is:
Navigate back to your Terminal window. Near the bottom of the window you will see instructions to: "find the pasteLoi.csv file in the same directory as this script and copy the line(s) and paste them in the Google Sheets file called 'Case Files (RG117 C-3) Tracker'" You may do this for each case file created, OR you can create a bunch of case files and then copy and paste them into your tracker.
Navigate to the Case File Tracker and select the correct row for your file. Remember, case files are listed sequentially by case file number.
Note: You may have to add more rows to the spreadsheet to fit your data in sequential order.
In order to have the data properly spaced across columns, you must select the first box in the row, under the column “File Number (Sequential).” Do not open this box by double-clicking. Now use ctrl + v to paste.
Tip #1 "pasteLOI.csv" must be closed while entering data in the terminal interface or permission will be denied. Tip #2 Before copy and pasting from your "pasteLOI.csv" makes sure that all the dates are visible (i.e. NO ####-##-##) by expanding those columns. Tip #3 After you have copy and pasted a bunch of rows, erase the data from your "pasteLOI.csv" and save the file.
The Casefile Tracker is set to “Automatic” (versus “Plain Text”), so when you paste in your line of data the spreadsheet will automatically remove the leading 0s (zeros) in front of the file numbers (e.g., case file number “00208” is transformed into “208”). This will happen in the pasteLOI.csv file as well. The removal of the leading zeros in the “File Number (Sequential)” fields of the Tracker is the desired outcome. The addition of zeros to bring case file numbers to five digits is necessary for the pdf-maker script to make file names, but in the Tracker please ensure that the zeros have been automatically removed.
For the “_xi” case files numbers, the spreadsheet will NOT automatically remove the leading zeroes. Please manually remove any of these zeroes yourself (e.g., change “01209_xi” to “1209_xi” in the “File Number (Sequential)” column).
Note: Do NOT manually remove the leading zeros in any other column, such as in the “Page Range” or “LOI pdf File Name” columns.
Now it’s time to fill out the “Scope and Content” column. Navigate back to your Metadata Notes document, select your scope and content paragraph, then copy and paste it into the corresponding column. This time, you must double-click in the box in order to paste successfully.
Next, you will follow the same process to enter any file notes (sensitive labels, notable documents, and snippets) into their respective columns.
Congratulations! You have successfully completed your first case file.
If you’ve started working on a new reel, please record such information in the Case File Reel Completion Tracker by keeping track of the date you started working on it, the date you completed it, etc. This will not only help us keep track of the status of all the reels but also give us a better estimate of how long it will take to complete everything.
7.3. Completed Case File Examples
7.3.1. Example #1
Page Range: 1229-1254
Start Date: 1942-03-28
Latest Date: 1946-06-25
Microfilm Reel #: C-9321
Case File: 01567
File Person’s Name: shimizu-fumiko
Citizenship Status: Canadian born
Sex: 1
Metadata Author: Lindy Marks
Scope and Content: He was born on 9 November 1876. He was a mill worker employed by B.C. Fir & Cedar Lumber Company Limited, Vancouver, BC. His family includes Tsuyu Ishihara (wife; nee Tsuyu Yoshioka; in Japan). His home address is listed as 344 Fourth Avenue West, Vancouver, BC. He was forcibly uprooted to Sandon, BC and New Denver, BC.
Scope and Content: She was born on 18 June 1917. She is also named in the file as Marjorie Hisa Wong, and her maiden name is Marjorie Hisa Kuwata. She was a housewife. Her family includes Kinu Kuwata (mother; nee Kinu Yoneda), Tokusaburo Kuwata (father), Charles Wong (husband), Geraldine Wong (daughter), and Russell Wong (son). The “Information from R.C.M.P.” form, under “Names of Children under 16”, also lists “1 - Chinese nationality – (not listed)”. She lived at 1724 Government Street, Victoria, BC and then in High River, AB.
Scope and Content: He was born on 09 March 1916. He was a fisherman. His family includes Yaye Nasu (mother; nee Yaye Nomura) and Oyokichi Nasu (father). He lived in Ucluelet, BC and was forcibly uprooted to Slocan, BC; Love’s Mushroom Farm Scarborough Junction, ON; 102 Centre Avenue, Toronto, ON; and 81 Montrose Avenue, Toronto, ON.
Scope and Content: He was born on 08 April 1914. He was a fisherman and a farmer, working on his and his brother’s berry farm. His family includes Tsuruyo Suto [possibly Tsuruyo Onotera] (mother), Tamotsu Onotera (father), Tatsuo Onotera (brother), Masa Onotera (wife), and Larry Yasuo Onotera (son). He lived on Rural Route #1, New Westminster, BC and at the Patricia Hotel, Vancouver, BC; he was forcibly uprooted to Kaslo, BC, Penticton, BC, and Greenwood, BC.
You may come across case files that are specific to companies/businesses or organizations with assets seized by the Office of the Custodian. These files are mostly included in later reels and may be mixed in with people files.
Business files are handled in a similar manner to people files, with some changes to the formatting of the metadata and scope and content.
For organization case files metadata:
You will not be filling out the “Citizenship Status” and “Sex” fields.
In the name field, format the name in all lowercase letters, separating words with hyphens.
Ignore any punctuation marks (apostrophes, hyphens) present in the name of the company/business. For any ampersands, replace with “and.” For e.g., “Gord’s Garage & Son” would be formatted as “gords-garage-and-son”.
Do not abbreviate any words.
E.g., “Powell Lumber and Fuel Company” would be written out as “powell-lumber-and-fuel-company.” You must include words like “company” and “limited.”
Write “organization” for the case file type field.
For entity case files scope and content, write according to the following guidelines in the order they appear:
Description of the company, if included in the file:
E.g., “Haney Box Company Limited was a box company that manufactured produce boxes for tomatoes, strawberries, and raspberries.”
Any alternate or previous names, if applicable and available
E.g., “Originally named The Nikko Company, the business was renamed to Import and Domestic Silk Company on 21 October 1940.”
Location of the entity, if it is included in the file.
E.g., “The Fernridge Lumber Company was located at Alouette Lake, Haney, BC.”
Important dates, if available (incorporated, liquidated, name changes):
E.g., “The No. 2 District Fishermen’s Association operated out of Port Essington, BC. It was incorporated on 22 January 1940.”
Other entities closely related to the entity to whom the file belongs. Note: this does not include creditors or debtors.
E.g., “It also incorporated the Skeena Japanese Fishermen’s Association, located at Prince Rupert, BC.”
People associated with the file and their position, if available. We are concerned primarily with the names of Japanese Canadians. Use your best judgement on how many names to include/pull from the file. In the interest of time, please do not include more than 15 names.
It would be preferable to type out a one-page list of ten clear, easy-to-read names than to struggle over five hard-to-read names that you need to read through several pages of documents to find.
If you come across lists of names of Japanese Canadian people associated with the file and you do not type out all of them, please make a note at the end of the scope and content that states: “The file includes (a) list(s) of Japanese Canadian people associated with the file.”
If you determine that a file meets the criteria for restriction in accordance with the risk matrix, please include all of the names of Japanese Canadians that you come across. This is the only way family members searching for documents pertaining to their relatives will be able to decide whether to request the file or not.
Examples of Completed Scope and Contents
The Camp and Mill Workers’ Federal Labor Union No. 31 Vancouver and Vicinity also owned and controlled The Daily People newspaper. People involved in the organization include Taneji Sada (president), Atsmu Kamino (1st vice-president), Ichiro Matsushita (2nd vice-president), Takaichi Umezuki (secretary), Kijuro Inouye (treasurer), and members of the union who are listed in the file. ⚓
The East Coast Troller’s Association was part of the Amalgamated Association of Fisherman of British Columbia. People associated with this file include Masahichi Yamashita (president), Mataichiro Doi (vice president), and Mitsujiro Noguchi (secretary of the Amalgamated Association of Fisherman of British Columbia). ⚓
7.5. Estate Case Files
You may also come across case files for the estates of Japanese Canadians who died prior to 1942.
Like other types of files, estate files are subject to their own naming convention. It looks like this:
In terms of metadata for estate files, we want to collect information regarding citizenship and sex, but the file type is now “estate.”
Note: When a file does not provide any information regarding citizenship status or sex, we will write “unknown” for the citizenship status, “0” in the sex field, and refer to the file person using they/them pronouns.
For estate case files, each scope and content will begin with the statement “This file pertains to the estate of __.” The rest of the scope and content will vary by file as there does not seem to be any consistency with regards to the type of information included. Include the following types of information if they appear in the file:
Date and location of death
Previous addresses
People associated with the file and their role/relationship to the file person if provided.
The types of people who should be included are family members, executors of the estate, and beneficiaries of the estate.
If none of the above information exists in the file, write a simple description of the file using what information does exist.
Examples:
This file pertains to the estate of Tsuya Nishimura. She died in 1936. People associated with this file include Jutaro Nishimura (father) and Shige Nishimura (mother).⚓
This file pertains to the estate of Ichitaro Amano. He died on 13 April 1926 in Vancouver, BC. People associated with this file include Mitsuru Amano (son and sole beneficiary), Tajiro Amano (brother), and Denzo Enjo (executor).⚓
This file pertains to the estate of Sankichi Tanaka. A document in the file indicates that he owned 1000 shares in Canada Mio Company Limited.⚓
7.6. Nikkei Volunteer Case File Work
There are some volunteers at the Nikkei National Museum that Lisa Uyeda and Lindsey Jacobson coordinate, and they are working on writing scope and content descriptions for case files. When the volunteers finish a batch that we have sent them either Lisa or Lindsey will be in contact to request that we send them further files to work on. We also transfer the data from the volunteer spreadsheet to the main case files spreadsheet. This is the process for how to do that.
7.6.1. Sending to Volunteers
These are the steps to prepare batches of case files and send to Nikkei for volunteer work:
You will create a new folder in this folder and title it Batch #, where # will be the number of the batch that you are creating. To create a new folder, navigate to the left hand side and click on the button near the top that says “New” then select “Folder.”
Now that you have created a new folder, navigate to the folder of one of the previous batches. Right-click on the spreadsheet that is in that folder and select “Make a copy.”
Now you should have a spreadsheet named “Copy…” Rename this spreadsheet to “Case Files (RG117 C-3) Tracker Volunteer Metadata Batch #” where # will be the number of the batch this is.
Delete any information that is in this copy of the spreadsheet. You want it to be blank except for the top matter setting out what the spreadsheet is and all of the column titles. Change column D row 1 to the correct batch number, and column D row 2 to the correct date.
Move your new spreadsheet to your new created folder by right-clicking and selecting “Move to”
Once in the dialogue box select your new folder
Now you need to determine which files to send the volunteers. In the Case Files (RG117 C-3) Tracker, locate case files that have no scope and content written for them. You will be sending 30 per batch
Fill out the column in the spreadsheet that indicates the date that the files were sent with today’s date
Once you know which files you will be sending, fill out the relevant sections of the volunteer spreadsheet in the folder you created with the metadata from these files. This will include the case file number and the pdf file name.
Now you will transfer copies of the PDFs to the folder you created. Have the folder open on one screen, and on the other have open the folder named “RG117_C-3_PDFs.” You need to drag and drop each PDF file into the new batch folder.
The easiest ways that I have found to do this utilize the search bar in the HCMC folder. Search either the name or case file number of the file you are looking for then drag and drop it into the folder in Google Drive.
*Isolation contingency*: You will need to download the pdfs using FileZilla SFTP client to your local computer and then upload them to Google Drive from there.
Repeat this process until all of the PDFs of the case files are in the Google Drive folder and you’re done!
Send an email to either Lisa or Lindsey to let them know that there are new files ready for the volunteers.
7.6.2. Receiving from Volunteers
Lindsey (or Lisa) will send an email to someone in the Victoria office letting us know that the volunteers have finished with the case files they have
This also means it’s time to send new batches! Follow the process above
In one tab or on one monitor, open the volunteer spreadsheet that has been completed, and in another tab or on the second monitor, open the Case Files (RG117 C-3) Tracker spreadsheet
In the volunteer spreadsheet, copy all of the text in the scope and content column for the first case file on the sheet
Paste this text into the scope and content column for the same case file number in the main case files spreadsheet
Repeat this process until all of the text has been transferred from the volunteer spreadsheet to the main case file spreadsheet
Fill in the column in the spreadsheet that indicates the date the scope and content was sent back by the volunteers with today’s date. Do this for each case file.
7.6.3. Volunteer Case File Completion Tracker
Please use this tracker for volunteer batch returns.
8. Risk Matrix Guide
If the file/transcript contains substantial amounts of any of these categories of content, modify the spreadsheet, word file or xml file you’re working on as detailed below. “Substantial” is your judgement of a combination of the frequency and severity of instances within the document. Our primary concern is detailed accounts of sensitive information about identifiable people not otherwise easily available.
Label
Description
Severity
illness
Details or graphic images of serious illness (mental or physical) or mortality of identifiable individual(s)
4
implicate
Defaming or implicating identifiable individual(s) who were not part of document creation
2
criminal
Details of potentially criminal activity, especially violence
2
youth
Serious anti-social activity or illness of youth under age of 18
3
stereotype
Egregious stereotyping (positive or negative) of a culture, group or person (beyond outdated language), especially vulnerable
1
cultural
Might be considered private by community for cultural reasons
1
dishonour
Might cause undue or disproportionate dishonour / embarrassment to family
1
details
Current personal identifying details (such as contact info)
4
You may apply as many of the labels as appropriate to any document.
Include no more than one instance of any label for any document.
Use of the “cultural” label will likely require a reference to community members.
We will use these to determine:
whether to include in database the complete document or only the metadata (possibly with names redacted) and link to original source of the document; or
whether to include a specific warning to that record in the output products (e.g. “researchers have found this document contains substantial stereotyping of cultures, groups or persons”).
8.1. When to add Sensitive information flags during workflow
For archival records (i.e. only metadata) that have ScopeContent metadata:
Read ScopeContent for references to sensitive material if reference is vague, take quick look at document edit XML ana attribute on the container of actual object (e.g. <item> that has a n="file" or n="item" and contains the <listObject>)
For archival records (i.e. only metadata) that don’t have ScopeContent metadata:
After you create ScopeContent edit XML ana attribute on the container of actual object (e.g. <item> that has a n="file" or n="item" and contains the <listObject>)
After you do audio check/proofing edit the Sensitive field in spreadsheet and then, in the XML version of the oral history, wrap the sensitive text in a <seg> element and use the same sensitive value(s) in the ana attribute.
See example for Leslie Barnwell (@xml:id='barn23' in oral_history_barn23_2019-02-28.xml).
For other full-text records (e.g. community documents)
We’ll need to specify a new task to edit XML ana attribute.
For court records
Project is ok with court records being included as-is.
8.2. Risk Matrix Mark-Up Examples
TINA Files
Case Files
Oral Histories
LOI Oral History Database oral_history_barn23_2019-02-28.xml
9. LOI Public Outputs Language Guide
This guide proposes inappropriate and appropriate language for Landscapes of Injustice public outputs. It pertains to text created by the collective [e.g. in museum panels, text for teachers, etc.], rather than language in primary source and archival document [which are part of a separate discussion led by the Archival Cluster. This document is meant to advance ongoing discussion, rather than as a final statement of approach.
Terminology
Inappropriate term
Appropriate term
Japanese (when referring to Canadians of Japanese ancestry)
Japanese Canadian
Nikkei
Canadian of Japanese descent
Jap
Japanese Canadian
Canadian born Japanese
Japanese Canadian
Enemy aliens (when referring to people with Japanese nationality status)
Japanese nationals
Rebels (for people detailed in POW camps)
Prisoners
Evacuation/Evacuees
Internment/Internees – for entire process/experience (also “Internment Era” for time period 1942-1949)
Forced uprooting - for process of displacement
Incarceration- for government administered sites, including BC and Ontario administered sites)
Protected zone
Restricted area
Repatriation
Exile
Relocation
Uprooting
Forced Uprooting
Dispersal
Forced dispersal
Sales
Forced sales
Dispossession- For broader process of property loss, including theft, neglect, and vandalism
[Sales by other Canadians during the same era—sometimes described/analyzed in contrast to the forced sales—can be called “free market sales”].
Liquidation
Forced sale.
Except in the case of the forcible sale of business assets by the Custodian of Enemy Property, in which case we will use forced liquidation.
Other Language Matters
Hyphenation
LOI proposes to use a hyphen in “Japanese Canadian” when the phrase is used adjectivally (e.g. Japanese-Canadian community). When used as a noun, however, no hyphen will be used (e.g. Japanese Canadians responded).
Japanese language terms
Use of transliterated Japanese language, where appropriate, is encouraged in LOI publications and public outputs. Whenever being used, including in names, these uses should be vetted by a competent Japanese language speaker to ensure accuracy.
Recommended temporal terminology
When referring to the period of time in which the internment took place, we recommend the use of 1940s in place of “wartime” or equivalents, because the internment era lasted until 1949.
Nikkei
There is some current discussion/debate within the community about the use of the term Nikkei. In most instances, Landscapes of Injustice publications and outputs we use the phrase “Japanese Canadian” instead. However the project has partner organizations that use the term, has used it in publications, and takes no formal position on this issue.
10. Isolation Workflow
Due to the covid19 pandemic, it has become necessary to carry on LOI digital database work from home to practice social isolation. This section is a guide to seetting up necessary apps for home work. It will be updated as requirements and needs change.
When it installs it will ask you to choose which components you would like. Leave all of the pre-checked ones selected. Select ‘desktop icon’ if you would like to have a desktop icon.
Decline the two other programs FileZilla asks you to install i.e. McAffee
Create a New Site in FileZilla
Select the option ‘File / Site Manager’
Click on the ‘New Site’ button; a new site will be added in the selection box
Name the new site ‘Landscapes’ (1)
Set the protocol to SFTP (2)
Set the host to nfs.hcmc.uvic.ca (3)
Set logon type to 'Ask for password' (4)
Set the user to be your netlink ID without the @uvic.ca part. The password will be your netlink ID password (5)
Click Ok
Finding the case files
When you first access the Landscapes site you will be put into home1t/[your netlink ID]
To navigate out of here, click on the very first yellow square at the top of the tree of folders
From this yellow square you can navigate to the case files by following this pathway: home1h/loi/dev/LAC/rg117/rg117_c-3/rg117_C-3_PDFs (rg117_C-3_PDFs hold all of the PDF files that have been created from case file images)
Opening the files
Double-click on the file you would like to open
The client will ask for your password and will then transfer a copy of the file to your local machine
At the bottom of the program there is a tab marked ‘Successful Transfers’
Clicking this tab will show you the location of the file on your local machine
Open a file explorer window, go to that location, and the file will be there, ready for you to start working on
10.1.1. Procedures for Case File Workers
Updated: 28 April 2020
For metadata enterers (no abstracts):
Using your ftp client, download a reel that has not been processed (please refer to the Case File Reel Completion Tracker and consult with your LOI colleagues on which reel to work on). Downloading the files will take a while so it is best to do it over night. Download the reel to a folder external to your Case File Processing directory as described in "Processing Case Files".
For Linux and Mac (Unix) users: place this modified (no pdf creation) shell script in same location as instructed in Processing Case Files (i.e. replace “rg117_CaseFiles_pdfMaker.sh” with "rg117_CaseFiles_pdfMaker-noImg2pdf.sh"). For Windows users, use this script (Note: Windows Defender may try to prevent you from running this script. Don't worry, it is safe, you may run it anyway).
Follow Processing Case Files instructions. (Note: this new script will not create a pdf so disregard pdf making step). Images for this step will be harvested from the images you downloaded and placed on your computer.
Note: some case files cross microfilm reels. If your reel begins with a case file that started on previous reel, ignore it and move to next case file. If your last case file crosses into the next reel, go to that reel, download the images to complete the case file, place them in your "hopper" along with the other images, and then execute the shell script. Metadata for case files that cross reels looks like this:
Data for the next reel inside square brackets.
For metadata enterers instructed to write Scope and Content
Same instructions as above but also write a Scope and Content abstract in the Case Files Tracker following the Scope and Content Style Guide.
Or, if instructed by Stewart or Gord, complete Scope and Content for a set of case files in the tracker that have other metadata already provided. Steps:
Download the indicated pdfs from the HCMC server in the “RG117_C-3_PDFs” directory.
10.2.1. Accessing the XML Files from LOI Production Site
Please see "Using the Subversion Repository" section of this documentation for instructions on downloading an svn client for all platforms.
Windows Terminal
Open a command window by navigating to the start menu of your computer and typing ‘cmd’ into the search bar
A terminal window will open. You will automatically be in C:\Users\[username]
You can move into your Documents folder if you wish
Mac Terminal
Click the Finder logo, located in the bottom toolbar of your screen (it looks like a two-toned smiling face).
On the left toolbar, click "Applications" (if that was the last folder you visited within the Finder, Finder will open to this folder automatically).
Scroll down and open the "Utilities" folder.
Double click "Terminal" to launch it.
Both Terminals
Make a new directory by typing ‘mkdir loi’ into the command line and then pressing the return key
Change from the home directory to the ‘loi’ directory by typing ‘cd loi’ followed by the return key
Check out the files by typing “svn checkout https://hcmc.uvic.ca/svn/landscapes/production/ .” (without the quotation marks) followed by the return key. Make sure to include the s in https and the space + period at the end
This will download a copy of the database to your ‘loi’ directory.
10.2.2. Accessing the Transcripts
Open a terminal window (make sure you are located where you want to be ("Documents" or somewhere relevant to the "loi" folder you already created, BUT not in it!
Make a new directory by typing ‘mkdir loiOH’ into the command line and pressing the return key
Navigate to this new directory by typing ‘cd loiOH’ into the command line and pressing the return key
Once in ‘loiOH’ check out the files by typing: “svn checkout https://hcmc.uvic.ca/svn/landscapes/oralHistoryDocs/originals/ . ” (without the quotation marks) and hitting return. Make sure to include the s in https and the space + period at the end)
To access the transcripts, navigate to the ‘loiOH’ folder on your local machine. This is where all the transcripts are
You will need to have access to the email address that you choose to give Oxygen because that is where the 31-day license key will be sent
Do not include the Fusion Connector
When it asks you what files to work with, keep all of the default selected and also select XML files
You are now ready to begin working on the oral history files. Please follow the procedures outlined in the XML Mark Up Steps guide
10.3. The Task Master
The Task Master is our tracker to track project production so that Stewart can generate realistic output goals.
Please fill out the first three columns with your details and hours worked on a specific task, and then, in the appropriate column for the work you did, provide a logical number of records or data completed for that task. Or fill out "Other Activities" or "Notes" field indicating what you spent time on.
Number of narrators contacted about their transcript.
"OH: Pre-Audio Check: Full/Partial"
Number of interviews that have completed this stage (see Pre-Audio Check)
OH: Audio Check
Number of interviews audio checked (See Audio Check).
OH: Final Check
Number of interviews fully checked (See Final Check).
OH: XML
Number of interviews marked up in XML transcript. (See XML Mark Up)
If you have any questions about any of these do not hesitate to reach out to any team member for advice.
10.4. Communication
The team has opted to use the Discord service for general discussions during work hours. This is an option that is recommended for efficient communication and support as we all work from home.
Please contact Natsuki Abe for a link to LOI's private group.
Appendix A
Appendix A.1 Elements
Appendix A.1.1 <TEI>
<TEI> (TEI document) contains a single TEI-conformant document, combining a single TEI header with one or more members of the model.resource class. Multiple <TEI> elements may be combined within a <TEI> (or <teiCorpus>) element. [4. Default Text Structure15.1. Varieties of Composite Text]
Major editions of the Guidelines have long been informally referred to by a name made up of the letter P (for Proposal) followed by a digit. The current release is one of the many releases of the fifth major edition of the Guidelines, known as P5. This attribute may be used to associate a TEI document with a specific release of the P5 Guidelines, in the absence of a more precise association provided by the source attribute on the associated <schemaSpec>.
This element is required. It is customary to specify the TEI namespace http://www.tei-c.org/ns/1.0 on it, for example: <TEI version="4.4.0" xml:lang="it" xmlns="http://www.tei-c.org/ns/1.0">.
Example
<TEI version="3.3.0" xmlns="http://www.tei-c.org/ns/1.0"><teiHeader><fileDesc><titleStmt><title>The shortest TEI Document Imaginable</title></titleStmt><publicationStmt><p>First published as part of TEI P2, this is the P5
version using a namespace.</p></publicationStmt><sourceDesc><p>No source: this is an original work.</p></sourceDesc></fileDesc></teiHeader><text><body><p>This is about the shortest TEI document imaginable.</p></body></text></TEI>
Example
<TEI version="2.9.1" xmlns="http://www.tei-c.org/ns/1.0"><teiHeader><fileDesc><titleStmt><title>A TEI Document containing four page images </title></titleStmt><publicationStmt><p>Unpublished demonstration file.</p></publicationStmt><sourceDesc><p>No source: this is an original work.</p></sourceDesc></fileDesc></teiHeader><facsimile><graphic url="page1.png"/><graphic url="page2.png"/><graphic url="page3.png"/><graphic url="page4.png"/></facsimile></TEI>
<ab> (anonymous block) contains any component-level unit of text, acting as a container for phrase or inter level elements analogous to, but without the same constraints as, a paragraph. [16.3. Blocks, Segments, and Anchors]
The <ab> element may be used at the encoder's discretion to mark any component-level elements in a text for which no other more specific appropriate markup is defined. Unlike paragraphs, <ab> may nest and may use the type and subtype attributes.
Example
<div type="book" n="Genesis"><div type="chapter" n="1"><ab>In the beginning God created the heaven and the earth.</ab><ab>And the earth was without form, and void; and
darkness was upon the face of the deep. And the
spirit of God moved upon the face of the waters.</ab><ab>And God said, Let there be light: and there was light.</ab><!-- ...--></div></div>
Schematron
<sch:report test="(ancestor::tei:l or ancestor::tei:lg) and not( ancestor::tei:floatingText
|parent::tei:figure |parent::tei:note )"> Abstract model violation: Lines may not contain higher-level divisions such as p or ab, unless ab is a child of figure or note, or is a descendant of floatingText.
</sch:report>
(suspension) the abbreviation provides the first letter(s) of the word or phrase, omitting the remainder.
contraction
(contraction) the abbreviation omits some letter(s) in the middle.
brevigraph
the abbreviation comprises a special symbol or mark.
superscription
(superscription) the abbreviation includes writing above the line.
acronym
(acronym) the abbreviation comprises the initial letters of the words of a phrase.
title
(title) the abbreviation is for a title of address (Dr, Ms, Mr, …)
organization
(organization) the abbreviation is for the name of an organization.
geographic
(geographic) the abbreviation is for a geographic name.
Note
The type attribute is provided for the sake of those who wish to classify abbreviations at their point of occurrence; this may be useful in some circumstances, though usually the same abbreviation will have the same type in all occurrences. As the sample values make clear, abbreviations may be classified by the method used to construct them, the method of writing them, or the referent of the term abbreviated; the typology used is up to the encoder and should be carefully planned to meet the needs of the expected use. For a typology of Middle English abbreviations, see 6.2.
This element is intended only for cases where no abstract is available in the original source. Any abstract already present in the source document should be encoded as a <div> within the <front>, as it should for a born-digital document.
Example
<profileDesc><abstract resp="#LB"><p>Good database design involves the acquisition and deployment of
skills which have a wider relevance to the educational process. From
a set of more or less instinctive rules of thumb a formal discipline
or "methodology" of database design has evolved. Applying that
methodology can be of great benefit to a very wide range of academic
subjects: it requires fundamental skills of abstraction and
generalisation and it provides a simple mechanism whereby complex
ideas and information structures can be represented and manipulated,
even without the use of a computer. </p></abstract></profileDesc>
<acquisition> (acquisition) contains any descriptive or other information concerning the process by which a manuscript or manuscript part or other object entered the holding institution. [10.8. History]
<addName> (additional name) contains an additional name component, such as a nickname, epithet, or alias, or any other descriptive phrase used within a personal name. [13.2.1. Personal Names]
<additional> (additional) groups additional information, combining bibliographic information about a manuscript or other object, or surrogate copies of it, with curatorial or administrative information. [10.9. Additional Information]
<additional><adminInfo><recordHist><p><!-- record history here --></p></recordHist><custodialHist><p><!-- custodial history here --></p></custodialHist></adminInfo><surrogates><p><!-- information about surrogates here --></p></surrogates><listBibl><bibl><!-- ... --></bibl><!-- full bibliography here --></listBibl></additional>
Addresses may be encoded either as a sequence of lines, or using any sequence of component elements from the model.addrPart class. Other non-postal forms of address, such as telephone numbers or email, should not be included within an <address> element directly but may be wrapped within an <addrLine> if they form part of the printed address in some source text.
Example
<address><addrLine>Computing Center, MC 135</addrLine><addrLine>P.O. Box 6998</addrLine><addrLine>Chicago, IL</addrLine><addrLine>60680 USA</addrLine></address>
<address><addrLine>Computing Center, MC 135</addrLine><addrLine>P.O. Box 6998</addrLine><addrLine>Chicago, IL 60680</addrLine><addrLine>USA</addrLine></address>
Example
<address><country key="FR"/><settlement type="city">Lyon</settlement><postCode>69002</postCode><district type="arrondissement">IIème</district><district type="quartier">Perrache</district><street><num>30</num>, Cours de Verdun</street></address>
<adminInfo> (administrative information) contains information about the present custody and availability of the manuscript or other object, and also about the record description itself. [10.9.1. Administrative Information]
<adminInfo><recordHist><source>Record created <date>1 Aug 2004</date></source></recordHist><availability><p>Until 2015 permission to photocopy some materials from this
collection has been limited at the request of the donor. Please ask repository staff for details
if you are interested in obtaining photocopies from Series 1:
Correspondence.</p></availability><custodialHist><p>Collection donated to the Manuscript Library by the Estate of
Edgar Holden in 1993. Donor number: 1993-034.</p></custodialHist></adminInfo>
<affiliation> (affiliation) contains an informal description of a person's present or past affiliation with some organization, for example an employer or sponsor. [15.2.2. The Participant Description]
<argument><p>Monte Video — Maldonado — Excursion
to R Polanco — Lazo and Bolas — Partridges —
Absence of Trees — Deer — Capybara, or River Hog —
Tucutuco — Molothrus, cuckoo-like habits — Tyrant
Flycatcher — Mocking-bird — Carrion Hawks —
Tubes formed by Lightning — House struck</p></argument>
As an alternative to using the scheme attribute a namespace prefix may be used. Where both scheme and a prefix are used, the prefix takes precedence.
Example
<p>The TEI defines several <soCalled>global</soCalled> attributes; their names include
<att>xml:id</att>, <att>rend</att>, <att>xml:lang</att>, <att>n</att>, <att>xml:space</att>,
and <att>xml:base</att>; <att scheme="XX">type</att> is not amongst them.</p>
<author> (author) in a bibliographic reference, contains the name(s) of an author, personal or corporate, of a work; for example in the same form as that provided by a recognized bibliographic name authority. [3.12.2.2. Titles, Authors, and Editors2.2.1. The Title Statement]
Particularly where cataloguing is likely to be based on the content of the header, it is advisable to use a generally recognized name authority file to supply the content for this element. The attributes key or ref may also be used to reference canonical information about the author(s) intended from any appropriate authority, such as a library catalogue or online resource.
In the case of a broadcast, use this element for the name of the company or network responsible for making the broadcast.
Where an author is unknown or unspecified, this element may contain text such as Unknown or Anonymous. When the appropriate TEI modules are in use, it may also contain detailed tagging of the names used for people, organizations or places, in particular where multiple names are given.
Example
<author>British Broadcasting Corporation</author><author>La Fayette, Marie Madeleine Pioche de la Vergne, comtesse de (1634–1693)</author><author>Anonymous</author><author>Bill and Melinda Gates Foundation</author><author><persName>Beaumont, Francis</persName> and
<persName>John Fletcher</persName></author><author><orgName key="BBC">British Broadcasting
Corporation</orgName>: Radio 3 Network
</author>
<authority> (release authority) supplies the name of a person or other agency responsible for making a work available, other than a publisher or distributor. [2.2.4. Publication, Distribution, Licensing, etc.]
<availability> (availability) supplies information about the availability of a text, for example any restrictions on its use or distribution, its copyright status, any licence applying to it, etc. [2.2.4. Publication, Distribution, Licensing, etc.]
<availability status="restricted"><p>Available for academic research purposes only.</p></availability><availability status="free"><p>In the public domain</p></availability><availability status="restricted"><p>Available under licence from the publishers.</p></availability>
Example
<availability><licence target="http://opensource.org/licenses/MIT"><p>The MIT License
applies to this document.</p><p>Copyright (C) 2011 by The University of Victoria</p><p>Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:</p><p>The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.</p><p>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.</p></licence></availability>
Contains phrase-level elements, together with any combination of elements from the model.biblPart class
Example
<bibl>Blain, Clements and Grundy: Feminist Companion to Literature in English (Yale,
1990)</bibl>
Example
<bibl><title level="a">The Interesting story of the Children in the Wood</title>. In
<author>Victor E Neuberg</author>, <title>The Penny Histories</title>.
<publisher>OUP</publisher><date>1968</date>.
</bibl>
Example
<bibl type="article" subtype="book_chapter"
xml:id="carlin_2003"><author><name><surname>Carlin</surname>
(<forename>Claire</forename>)</name></author>,
<title level="a">The Staging of Impotence : France’s last
congrès</title> dans
<bibl type="monogr"><title level="m">Theatrum mundi : studies in honor of Ronald W.
Tobin</title>, éd.
<editor><name><forename>Claire</forename><surname>Carlin</surname></name></editor> et
<editor><name><forename>Kathleen</forename><surname>Wine</surname></name></editor>,
<pubPlace>Charlottesville, Va.</pubPlace>,
<publisher>Rookwood Press</publisher>,
<date when="2003">2003</date>.
</bibl></bibl>
(A document index, only allowed on generated pages.) Document Index
loi:loiBornDigitalBoilerplate
(A boilerplate document not meant for standalone publication on the website. This includes documents like the site menu.) Boilerplate
loi:loiDataset
(A created or derived dataset.) Datasets
loi:loiDatasetCustodianCaseFile
Custodian Case Files
loi:loiDatasetCustodianCaseFileReel
Custodian Case File Reel
loi:loiDatasetCustodianCaseFileName
Custodian Case File Name Index
loi:loiDatasetNames
(A listing of names document) People
loi:loiDatasetNamesA
(A listing of names) Names: A
loi:loiDatasetNamesB
(A listing of names) Names: B
loi:loiDatasetNamesC
(A listing of names) Names: C
loi:loiDatasetNamesD
(A listing of names) Names: D
loi:loiDatasetNamesE
(A listing of names) Names: E
loi:loiDatasetNamesF
(A listing of names) Names: F
loi:loiDatasetNamesG
(A listing of names) Names: G
loi:loiDatasetNamesH
(A listing of names) Names: H
loi:loiDatasetNamesI
(A listing of names) Names: I
loi:loiDatasetNamesJ
(A listing of names) Names: J
loi:loiDatasetNamesK
(A listing of names) Names: K
loi:loiDatasetNamesL
(A listing of names) Names: L
loi:loiDatasetNamesM
(A listing of names) Names: M
loi:loiDatasetNamesN
(A listing of names) Names: N
loi:loiDatasetNamesO
(A listing of names) Names: O
loi:loiDatasetNamesP
(A listing of names) Names: P
loi:loiDatasetNamesQ
(A listing of names) Names: Q
loi:loiDatasetNamesR
(A listing of names) Names: R
loi:loiDatasetNamesS
(A listing of names) Names: S
loi:loiDatasetNamesT
(A listing of names) Names: T
loi:loiDatasetNamesU
(A listing of names) Names: U
loi:loiDatasetNamesV
(A listing of names) Names: V
loi:loiDatasetNamesW
(A listing of names) Names: W
loi:loiDatasetNamesX
(A listing of names) Names: X
loi:loiDatasetNamesY
(A listing of names) Names: Y
loi:loiDatasetNamesZ
(A listing of names) Names: Z
loi:loiDatasetTeam
(An LOI Team Member document) Team Members
loi:loiDatasetPlace
(A listing of names) Places
loi:loiDatasetOrg
(A orgs listing document) Organizations
loi:loiDatasetArchival
Archival Datasets
loi:loiDatasetArchivalFonds
Archival Dataset: Fonds
loi:loiDatasetArchivalSousfonds
Archival Dataset: Sous-fonds
loi:loiDatasetArchivalSeries
Archival Dataset: Series
loi:loiDatasetArchivalSubseries
Archival Dataset: Subseries
loi:loiDatasetArchivalFile
Archival Dataset: File
loi:loiDatasetArchivalObject
Archival Dataset: Object
loi:loiDatasetLegalCaseFile
Legal Case File
loi:loiDatasetTitle
Titles
loi:loiDatasetLot
Lots
loi:loiDatasetStory
Lot/Titles Stories
loi:loiPrimarySource
(A primary source document.) Primary Source
loi:loiPrimarySourceProtestLetter
(A letter protesting the sale of property or a government reply to protest letter.) Protest Letter
loi:loiPrimarySourceFishingVesselRequest
(A letter requesting information about seized Japanese-Canadian fishing vessels.) Fishing Vessel Request Letter
loi:loiPrimarySourceDirectory
Directory
loi:loiPrimarySourceOralHistory
Oral History
loi:loiPrimarySourceBoatLedger
Fishing Boat Ledger
loi:loiDatasetStreetIndex
Street Index
scheme
identifies the classification scheme within which the set of categories concerned is defined, for example by a <taxonomy> element, or by some other resource.
On this element, the global n attribute indicates the number or other value associated with the column which follows the point of insertion of this <cb> element. Encoders should adopt a clear and consistent policy as to whether the numbers associated with column breaks relate to the physical sequence number of the column in the whole text, or whether columns are numbered within the page. The <cb> element is placed at the head of the column to which it refers.
Example
Markup of an early English dictionary printed in two columns:
<pb/><cb n="1"/><entryFree><form>Well</form>, <sense>a Pit to hold Spring-Water</sense>:
<sense>In the Art of <hi rend="italic">War</hi>, a Depth the Miner
sinks into the Ground, to find out and disappoint the Enemies Mines,
or to prepare one</sense>.
</entryFree><entryFree>To <form>Welter</form>, <sense>to wallow</sense>, or
<sense>lie groveling</sense>.</entryFree><!-- remainder of column --><cb n="2"/><entryFree><form>Wey</form>, <sense>the greatest Measure for dry Things,
containing five Chaldron</sense>.
</entryFree><entryFree><form>Whale</form>, <sense>the greatest of
Sea-Fishes</sense>.
</entryFree>
<row><cell role="label">General conduct</cell><cell role="data">Not satisfactory, on account of his great unpunctuality
and inattention to duties</cell></row>
The who attribute may be used to point to any other element, but will typically specify a <respStmt> or <person> element elsewhere in the header, identifying the person responsible for the change and their role in making it.
It is recommended that changes be recorded with the most recent first. The status attribute may be used to indicate the status of a document following the change documented.
<profileDesc><creation><listChange><change xml:id="DRAFT1">First draft in pencil</change><change xml:id="DRAFT2"
notBefore="1880-12-09">First revision, mostly
using green ink</change><change xml:id="DRAFT3"
notBefore="1881-02-13">Final corrections as
supplied to printer.</change></listChange></creation></profileDesc>
Schematron
All change/@who pointers should point to a team member.
<sch:pattern>
<sch:rule context="tei:change[@who]">
<sch:let name="pointers"
value="tokenize(@who,'\s+')"/>
<sch:let name="errors"
value="$pointers[not(matches(.,'^team:'))]"/>
<sch:assert test="empty($errors)">ERROR: All change/@who should point to a team member. The pointer(s) <sch:value-of select="string-join($errors,', ')"/> do not.</sch:assert>
</sch:rule>
</sch:pattern>
Because the children of a <choice> element all represent alternative ways of encoding the same sequence, it is natural to think of them as mutually exclusive. However, there may be cases where a full representation of a text requires the alternative encodings to be considered as parallel.
Where the purpose of an encoding is to record multiple witnesses of a single work, rather than to identify multiple possible encoding decisions at a given point, the <app> element and associated elements discussed in section 12.1. The Apparatus Entry, Readings, and Witnesses should be preferred.
Example
An American encoding of Gulliver's Travels which retains the British spelling but also provides a version regularized to American spelling might be encoded as follows.
<p>Lastly, That, upon his solemn oath to observe all the above
articles, the said man-mountain shall have a daily allowance of
meat and drink sufficient for the support of <choice><sic>1724</sic><corr>1728</corr></choice> of our subjects,
with free access to our royal person, and other marks of our
<choice><orig>favour</orig><reg>favor</reg></choice>.</p>
<div type="letter"><p> perhaps you will favour me with a sight of it when convenient.</p><closer><salute>I remain, &c. &c.</salute><signed>H. Colburn</signed></closer></div>
Example
<div type="chapter"><p><!-- ... --> and his heart was going like mad and yes I said yes I will Yes.</p><closer><dateline><name type="place">Trieste-Zürich-Paris,</name><date>1914–1921</date></dateline></closer></div>
<correspAction> (correspondence action) contains a structured description of the place, the name of a person/organization and the date related to the sending/receiving of a message or any other action related to the correspondence. [2.4.6. Correspondence Description]
<correspDesc> (correspondence description) contains a description of the actions related to one act of correspondence. [2.4.6. Correspondence Description]
<correspDesc><correspAction type="sent"><persName>Carl Maria von Weber</persName><settlement>Dresden</settlement><date when="1817-06-23">23 June 1817</date></correspAction><correspAction type="received"><persName>Caroline Brandt</persName><settlement>Prag</settlement></correspAction><correspContext><ref type="prev"
target="http://www.weber-gesamtausgabe.de/A041209">Previous letter of
<persName>Carl Maria von Weber</persName>
to <persName>Caroline Brandt</persName>:
<date from="1817-06-19" to="1817-06-20">June 19/20, 1817</date></ref><ref type="next"
target="http://www.weber-gesamtausgabe.de/A041217">Next letter of
<persName>Carl Maria von Weber</persName> to
<persName>Caroline Brandt</persName>:
<date when="1817-06-27">June 27, 1817</date></ref></correspContext></correspDesc>
Given on the <date when="1977-06-12">Twelfth Day
of June in the Year of Our Lord One Thousand Nine Hundred and Seventy-seven of the Republic
the Two Hundredth and first and of the University the Eighty-Sixth.</date>
<dateline> (dateline) contains a brief description of the place, date, time, etc. of production of a letter, newspaper story, or other work, prefixed or suffixed to it as a kind of heading or trailer. [4.2.2. Openers and Closers]
<dateline>Walden, this 29. of August 1592</dateline>
Example
<div type="chapter"><p><!-- ... --> and his heart was going like mad and yes I said yes I will Yes.</p><closer><dateline><name type="place">Trieste-Zürich-Paris,</name><date>1914–1921</date></dateline></closer></div>
<desc> (description) contains a short description of the purpose, function, or use of its parent element, or when the parent is a documentation element, describes or defines the object being documented. [22.4.1. Description of Components]
(deprecation information) This element describes why or how its parent element is being deprecated, typically including recommendations for alternate encoding.
<dataSpec module="tei"
ident="teidata.point"
validUntil="2050-02-25"><desc type="deprecationInfo"
versionDate="2018-09-14"
xml:lang="en">Several standards bodies, including NIST in the USA,
strongly recommend against ending the representation of a number
with a decimal point. So instead of <q>3.</q> use either <q>3</q>
or <q>3.0</q>.</desc><!-- ... --></dataSpec>
When used in a specification element such as <elementSpec>, TEI convention requires that this be expressed as a finite clause, begining with an active verb.
Example
Example of a <desc> element inside a documentation element.
<dataSpec module="tei"
ident="teidata.point"><desc versionDate="2010-10-17"
xml:lang="en">defines the data type used to express a point in cartesian space.</desc><content><dataRef name="token"
restriction="(-?[0-9]+(\.[0-9]+)?,-?[0-9]+(\.[0-9]+)?)"/></content><!-- ... --></dataSpec>
Example
Example of a <desc> element in a non-documentation element.
A <desc> with a type of deprecationInfo should only occur when its parent element is being deprecated. Furthermore, it should always occur in an element that is being deprecated when <desc> is a valid child of that element.
<sch:rule context="tei:desc[ @type eq 'deprecationInfo']">
<sch:assert test="../@validUntil">Information about a
deprecation should only be present in a specification element
that is being deprecated: that is, only an element that has a
@validUntil attribute should have a child <desc
type="deprecationInfo">.</sch:assert>
</sch:rule>
<district> (district) contains the name of any kind of subdivision of a settlement, such as a parish, ward, or other administrative or geographic unit. [13.2.3. Place Names]
<body><div type="part"><head>Fallacies of Authority</head><p>The subject of which is Authority in various shapes, and the object, to repress all
exercise of the reasoning faculty.</p><div n="1" type="chapter"><head>The Nature of Authority</head><p>With reference to any proposed measures having for their object the greatest
happiness of the greatest number [...]</p><div n="1.1" type="section"><head>Analysis of Authority</head><p>What on any given occasion is the legitimate weight or influence to be attached to
authority [...] </p></div><div n="1.2" type="section"><head>Appeal to Authority, in What Cases Fallacious.</head><p>Reference to authority is open to the charge of fallacy when [...] </p></div></div></div></body>
Schematron
<sch:report test="(ancestor::tei:l or ancestor::tei:lg) and not(ancestor::tei:floatingText)"> Abstract model violation: Lines may not contain higher-level structural elements such as div, unless div is a descendant of floatingText.
</sch:report>
Schematron
<sch:report test="(ancestor::tei:p or ancestor::tei:ab) and not(ancestor::tei:floatingText)"> Abstract model violation: p and ab may not contain higher-level structural elements such as div, unless div is a descendant of floatingText.
</sch:report>
<divGen> (automatically generated text division) indicates the location at which a textual division generated automatically by a text-processing application is to appear. [3.9.2. Index Entries]
This element is intended primarily for use in document production or manipulation, rather than in the transcription of pre-existing materials; it makes it easier to specify the location of indices, tables of contents, etc., to be generated by text preparation or word processing software.
Example
One use for this element is to allow document preparation software to generate an index and insert it in the appropriate place in the output. The example below assumes that the indexName attribute on <index> elements in the text has been used to specify index entries for the two generated indexes, named NAMES and THINGS:
<docAuthor> (document author) contains the name of the author of the document, as given on the title page (often but not always contained in a byline). [4.6. Title Pages]
The document author's name often occurs within a byline, but the <docAuthor> element may be used whether the <byline> element is used or not. It should be used only for the author(s) of the entire document, not for author(s) of any subset or part of it. (Attributions of authorship of a subset or part of the document, for example of a chapter in a textbook or an article in a newspaper, may be encoded with <byline> without <docAuthor>.)
Example
<titlePage><docTitle><titlePart>Travels into Several Remote Nations of the World, in Four
Parts.</titlePart></docTitle><byline> By <docAuthor>Lemuel Gulliver</docAuthor>, First a Surgeon,
and then a Captain of several Ships</byline></titlePage>
For simple dates, the when attribute should give the Gregorian or proleptic Gregorian date in one of the formats specified in XML Schema Part 2: Datatypes Second Edition.
Cf. the general <date> element in the core tag set. This specialized element is provided for convenience in marking and processing the date of the documents, since it is likely to require specialized handling for many applications. It should be used only for the date of the entire document, not for any subset or part of it.
<encodingDesc><p>Basic encoding, capturing lexical information only. All
hyphenation, punctuation, and variant spellings normalized. No
formatting or layout information preserved.</p></encodingDesc>
<equipment><p>"Hi-8" 8 mm NTSC camcorder with integral directional
microphone and windshield and stereo digital sound
recording channel.
</p></equipment>
Example
<equipment><p>8-track analogue transfer mixed down to 19 cm/sec audio
tape for cassette mastering</p></equipment>
The content of this element should be the expanded abbreviation, usually (but not always) a complete word or phrase. The <ex> element provided by the transcr module may be used to mark up sequences of letters supplied within such an expansion.
If abbreviations are expanded silently, this practice should be documented in the <editorialDecl>, either with a <normalization> element or a <p>.
Example
The address is Southmoor
<choice><expan>Road</expan><abbr>Rd</abbr></choice>
<facsimile> contains a representation of some written source in the form of a set of images rather than as transcribed or encoded text. [11.1. Digital Facsimiles]
<sch:rule context="tei:facsimile//tei:line | tei:facsimile//tei:zone">
<sch:report test="child::text()[ normalize-space(.) ne '']"> A facsimile element represents a text with images, thus
transcribed text should not be present within it.
</sch:report>
</sch:rule>
The major source of information for those seeking to create a catalogue entry or bibliographic citation for an electronic file. As such, it provides a title and statements of responsibility together with details of the publication or distribution of the file, of any series to which it belongs, and detailed bibliographic notes for matters not addressed elsewhere in the header. It also contains a full bibliographic description for the source or sources from which the electronic text was derived.
Example
<fileDesc><titleStmt><title>The shortest possible TEI document</title></titleStmt><publicationStmt><p>Distributed as part of TEI P5</p></publicationStmt><sourceDesc><p>No print source exists: this is an original digital text</p></sourceDesc></fileDesc>
<foreign> (foreign) identifies a word or phrase as belonging to some language other than that of the surrounding text. [3.3.2.1. Foreign Words or Expressions]
The global xml:lang attribute should be supplied for this element to identify the language of the word or phrase marked. As elsewhere, its value should be a language tag as defined in 6.1. Language Identification.
This element is intended for use only where no other element is available to mark the phrase or words concerned. The global xml:lang attribute should be used in preference to this element where it is intended to mark the language of the whole of some text element.
The <distinct> element may be used to identify phrases belonging to sublanguages or registers not generally regarded as true languages.
Example
This is
heathen Greek to you still? Your <foreign xml:lang="la">lapis
philosophicus</foreign>?
The name g is short for gaiji, which is the Japanese term for a non-standardized character or glyph.
Example
<g ref="#ctlig">ct</g>
This example points to a <glyph> element with the identifier ctlig like the following:
<glyph xml:id="ctlig"><!-- here we describe the particular ct-ligature intended --></glyph>
Example
<g ref="#per-glyph">per</g>
The medieval brevigraph per could similarly be considered as an individual glyph, defined in a <glyph> element with the identifier per-glyph as follows:
<gap> (gap) indicates a point where material has been omitted in a transcription, whether for editorial reasons described in the TEI header, as part of sampling practice, or because the material is illegible, invisible, or inaudible. [3.5.3. Additions, Deletions, and Omissions]
(Restrictions on material of a sensitive nature.) This attribute flags records in our database that may contain sensitive, personal or defamatory information. These classes of ana identify the type and severity of the restriction applied.
Status
Optional
Datatype
1–∞ occurrences ofseparated by whitespace
Legal values are:
sens:illness
(Illness label - Severity 4.) Details or graphic images of serious illness (mental or physical) or mortality of identifiable individual(s).
sens:youth
(Youth label - Severity 3.) Details of serious anti-social activity or illness of youth under age of 18.
sens:implicate
(Implicate label - Severity 2.) Defaming or implicating identifiable individual(s) who were not part of document creation.
sens:criminal
(Criminal label - Severity 2.) Details of potentially serious or violent criminal activity, especially violence.
sens:stereotype
(Stereotype label - Severity 1.) Egregious stereotyping (positive or negative) of a culture, group or person (beyond outdated language), especially vulnerable individual(s)/group(s).
sens:cultural
(Cultural label - Severity 1.) Could be considered private by community for cultural reasons.
sens:dishonour
(Dishonour label - Severity 1.) Could cause undue or disproportionate dishonour / embarrassment to self or family.
sens:details
(Details label - Severity 4.) Current personal identifying details (such as contact info).
The <gap> tag simply signals the editors decision to omit or inability to transcribe a span of text. Other information, such as the interpretation that text was deliberately erased or covered, should be indicated using the relevant tags, such as <del> in the case of deliberate deletion.
<geo> (geographical coordinates) contains any expression of a set of geographic coordinates, representing a point, line, or area on the surface of the earth in some notation. [13.3.4.1. Varieties of Location]
Uses of <geo> can be associated with a coordinate system, defined by a <geoDecl> element supplied in the TEI header, using the decls attribute. If no such link is made, the assumption is that the content of each <geo> element will be a pair of numbers separated by whitespace, to be interpreted as latitude followed by longitude according to the World Geodetic System.
Example
<geoDecl xml:id="WGS" datum="WGS84">World Geodetic System</geoDecl><geoDecl xml:id="OS" datum="OSGB36">Ordnance Survey</geoDecl><!-- ... --><location><desc>A tombstone plus six lines of
Anglo-Saxon text, built into the west tower (on the south side
of the archway, at 8 ft. above the ground) of the
Church of St. Mary-le-Wigford in Lincoln.</desc><geo decls="#WGS">53.226658 -0.541254</geo><geo decls="#OS">SK 97481 70947</geo></location>
<p>The <gi>xhtml:li</gi> element is roughly analogous to the <gi>item</gi> element, as is the
<gi scheme="DBK">listItem</gi> element.</p>
This example shows the use of both a namespace prefix and the scheme attribute as alternative ways of indicating that the <gi> in question is not a TEI element name: in practice only one method should be adopted.
<glyph xml:id="rstroke"><localProp name="Name"
value="LATIN SMALL LETTER R WITH A FUNNY STROKE"/><localProp name="entity" value="rstroke"/><figure><graphic url="glyph-rstroke.png"/></figure></glyph>
The mimeType attribute should be used to supply the MIME media type of the image specified by the url attribute.
Within the body of a text, a <graphic> element indicates the presence of a graphic component in the source itself. Within the context of a <facsimile> or <sourceDoc> element, however, a <graphic> element provides an additional digital representation of some part of the source being encoded.
Example
<figure><graphic url="fig1.png"/><head>Figure One: The View from the Bridge</head><figDesc>A Whistleresque view showing four or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc></figure>
<head> (heading) contains any type of heading, for example the title of a section, or the heading of a list, glossary, manuscript description, etc. [4.2.1. Headings and Trailers]
The <head> element is used for headings at all levels; software which treats (e.g.) chapter headings, section headings, and list titles differently must determine the proper processing of a <head> element based on its structural position. A <head> occurring as the first element of a list is the title of that list; one occurring as the first element of a <div1> is the title of that chapter or section.
Example
The most common use for the <head> element is to mark the headings of sections. In older writings, the headings or incipits may be rather longer than usual in modern works. If a section has an explicit ending as well as a heading, it should be marked as a <trailer>, as in this example:
<div1 n="I" type="book"><head>In the name of Christ here begins the first book of the ecclesiastical history of
Georgius Florentinus, known as Gregory, Bishop of Tours.</head><div2 type="section"><head>In the name of Christ here begins Book I of the history.</head><p>Proposing as I do ...</p><p>From the Passion of our Lord until the death of Saint Martin four hundred and twelve
years passed.</p><trailer>Here ends the first Book, which covers five thousand, five hundred and ninety-six
years from the beginning of the world down to the death of Saint Martin.</trailer></div2></div1>
Example
When headings are not inline with the running text (see e.g. the heading "Secunda conclusio") they might however be encoded as if. The actual placement in the source document can be captured with the place attribute.
<div type="subsection"><head place="margin">Secunda conclusio</head><p><lb n="1251"/><hi rend="large">Potencia: habitus: et actus: recipiunt speciem ab obiectis<supplied>.</supplied></hi><lb n="1252"/>Probatur sic. Omne importans necessariam habitudinem ad proprium
[...]
</p></div>
Example
The <head> element is also used to mark headings of other units, such as lists:
With a few exceptions, connectives are equally
useful in all kinds of discourse: description, narration, exposition, argument. <list rend="bulleted"><head>Connectives</head><item>above</item><item>accordingly</item><item>across from</item><item>adjacent to</item><item>again</item><item><!-- ... --></item></list>
<history><origin><p>Written in Durham during the mid twelfth
century.</p></origin><provenance><p>Recorded in two medieval
catalogues of the books belonging to Durham Priory, made in 1391 and
1405.</p></provenance><provenance><p>Given to W. Olleyf by William Ebchester, Prior (1446-56)
and later belonged to Henry Dalton, Prior of Holy Island (Lindisfarne)
according to inscriptions on ff. 4v and 5.</p></provenance><acquisition><p>Presented to Trinity College in 1738 by
Thomas Gale and his son Roger.</p></acquisition></history>
<idno> should be used for labels which identify an object or concept in a formal cataloguing system such as a database or an RDF store, or in a distributed system such as the World Wide Web. Some suggested values for type on <idno> are ISBN, ISSN, DOI, and URI.
In the last case, the identifier includes a non-Unicode character which is defined elsewhere by means of a <glyph> or <char> element referenced here as #sym.
<incident> (A non-verbal moment in the interview.) Incident is used by LOI Oral History team to indicate any non-verbal moment of significance in the interview such as an interuption, a pause, or a laugh. It replaces more specific element use such as kinesic and vocal. [8.3.3. Vocal, Kinesic, Incident]
(Restrictions on material of a sensitive nature.) This attribute flags records in our database that may contain sensitive, personal or defamatory information. These classes of ana identify the type and severity of the restriction applied.
Status
Optional
Datatype
1–∞ occurrences ofseparated by whitespace
Legal values are:
sens:illness
(Details or graphic images of serious illness (mental or physical) or mortality of identifiable individual(s).) Illness label
sens:youth
(Details of serious anti-social activity or illness of youth under age of 18.) Youth label
sens:implicate
(Defaming or implicating identifiable individual(s) who were not part of document creation.) Implicate label
sens:criminal
(Details of potentially serious or violent criminal activity, especially violence.) Criminal label
sens:stereotype
(Egregious stereotyping (positive or negative) of a culture, group or person (beyond outdated language), especially vulnerable individual(s)/group(s).) Stereotype label
sens:cultural
(Could be considered private by community for cultural reasons.) Cultural label
sens:dishonour
(Could cause undue or disproportionate dishonour / embarrassment to self or family.) Dishonour label
sens:details
(Current personal identifying details (such as contact info).) Details label
Whatever string of characters is used to label a list item in the copy text may be used as the value of the global n attribute, but it is not required that numbering be recorded explicitly. In ordered lists, the n attribute on the <item> element is by definition synonymous with the use of the <label> element to record the enumerator of the list item. In glossary lists, however, the term being defined should be given with the <label> element, not n.
Example
<list rend="numbered"><head>Here begin the chapter headings of Book IV</head><item n="4.1">The death of Queen Clotild.</item><item n="4.2">How King Lothar wanted to appropriate one third of the Church revenues.</item><item n="4.3">The wives and children of Lothar.</item><item n="4.4">The Counts of the Bretons.</item><item n="4.5">Saint Gall the Bishop.</item><item n="4.6">The priest Cato.</item><item> ...</item></list>
identifies the controlled vocabulary within which the set of keywords concerned is defined, for example by a <taxonomy> element, or by some other resource.
Each individual keyword (including compound subject headings) should be supplied as a <term> element directly within the <keywords> element. An alternative usage, in which each <term> appears within an <item> inside a <list> is permitted for backwards compatibility, but is deprecated.
If no control list exists for the keywords used, then no value should be supplied for the scheme attribute.
Example
<keywords scheme="http://classificationweb.net"><term>Babbage, Charles</term><term>Mathematicians - Great Britain - Biography</term></keywords>
<l met="x/x/x/x/x/" real="/xx/x/x/x/">Shall I compare thee to a summer's day?</l>
Schematron
<sch:report test="ancestor::tei:l[not(.//tei:note//tei:l[. = current()])]"> Abstract model violation: Lines may not contain lines or lg elements.
</sch:report>
Labels are commonly used for the headwords in glossary lists; note the use of the global xml:lang attribute to set the default language of the glossary list to Middle English, and identify the glosses and headings as modern English or Latin:
Labels may also be used to record explicitly the numbers or letters which mark list items in ordered lists, as in this extract from Gibbon's Autobiography. In this usage the <label> element is synonymous with the n attribute on the <item> element:
I will add two facts, which have seldom occurred
in the composition of six, or at least of five quartos. <list rend="runon" type="ordered"><label>(1)</label><item>My first rough manuscript, without any intermediate copy, has been sent to the press.</item><label>(2) </label><item>Not a sheet has been seen by any human eyes, excepting those of the author and the
printer: the faults and the merits are exclusively my own.</item></list>
Example
Labels may also be used for other structured list items, as in this extract from the journal of Edward Gibbon:
<list type="gloss"><label>March 1757.</label><item>I wrote some critical observations upon Plautus.</item><label>March 8th.</label><item>I wrote a long dissertation upon some lines of Virgil.</item><label>June.</label><item>I saw Mademoiselle Curchod — <quote xml:lang="la">Omnia vincit amor, et nos cedamus
amori.</quote></item><label>August.</label><item>I went to Crassy, and staid two days.</item></list>
Note that the <label> might also appear within the <item> rather than as its sibling. Though syntactically valid, this usage is not recommended TEI practice.
Example
Labels may also be used to represent a label or heading attached to a paragraph or sequence of paragraphs not treated as a structural division, or to a group of verse lines. Note that, in this case, the <label> element appears within the <p> or <lg> element, rather than as a preceding sibling of it.
<p>[...]
<lb/>& n’entrer en mauuais & mal-heu-
<lb/>ré meſnage. Or des que le conſente-
<lb/>ment des parties y eſt le mariage eſt
<lb/> arreſté, quoy que de faict il ne ſoit
<label place="margin">Puiſſance maritale
entre les Romains.</label><lb/> conſommé. Depuis la conſomma-
<lb/>tion du mariage la femme eſt ſoubs
<lb/> la puiſſance du mary, s’il n’eſt eſcla-
<lb/>ue ou enfant de famille : car en ce
<lb/> cas, la femme, qui a eſpouſé vn en-
<lb/>fant de famille, eſt ſous la puiſſance
[...]</p>
In this example the text of the label appears in the right hand margin of the original source, next to the paragraph it describes, but approximately in the middle of it. If so desired the type attribute may be used to distinguish different categories of label.
(identifier) Supplies a language code constructed as defined in BCP 47 which is used to identify the language documented by this element, and which is referenced by the global xml:lang attribute.
By convention, <lb> elements should appear at the point in the text where a new line starts. The n attribute, if used, indicates the number or other value associated with the text between this point and the next <lb> element, typically the sequence number of the line within the page, or other appropriate unit. This element is intended to be used for marking actual line breaks on a manuscript or printed page, at the point where they occur; it should not be used to tag structural units such as lines of verse (for which the <l> element is available) except in circumstances where structural units cannot otherwise be marked.
The type attribute may be used to characterize the line break in any respect. The more specialized attributes break, ed, or edRef should be preferred when the intent is to indicate whether or not the line break is word-breaking, or to note the source from which it derives.
Example
This example shows typographical line breaks within metrical lines, where they occur at different places in different editions:
<l>Of Mans First Disobedience,<lb ed="1674"/> and<lb ed="1667"/> the Fruit</l><l>Of that Forbidden Tree, whose<lb ed="1667 1674"/> mortal tast</l><l>Brought Death into the World,<lb ed="1667"/> and all<lb ed="1674"/> our woe,</l>
Example
This example encodes typographical line breaks as a means of preserving the visual appearance of a title page. The break attribute is used to show that the line break does not (as elsewhere) mark the start of a new word.
<titlePart><lb/>With Additions, ne-<lb break="no"/>ver before Printed.
</titlePart>
contains verse lines or nested line groups only, possibly prefixed by a heading.
Example
<lg type="free"><l>Let me be my own fool</l><l>of my own making, the sum of it</l></lg><lg type="free"><l>is equivocal.</l><l>One says of the drunken farmer:</l></lg><lg type="free"><l>leave him lay off it. And this is</l><l>the explanation.</l></lg>
Schematron
<sch:assert test="count(descendant::tei:lg|descendant::tei:l|descendant::tei:gap) >
0">An lg element
must contain at least one child l, lg, or gap element.</sch:assert>
Schematron
<sch:report test="ancestor::tei:l[not(.//tei:note//tei:lg[. = current()])]"> Abstract model violation: Lines may not contain line groups.
</sch:report>
A <licence> element should be supplied for each licence agreement applicable to the text in question. The target attribute may be used to reference a full version of the licence. The when, notBefore, notAfter, from or to attributes may be used in combination to indicate the date or dates of applicability of the licence.
<availability><licence target="http://creativecommons.org/licenses/by/3.0/"
notBefore="2013-01-01"><p>The Creative Commons Attribution 3.0 Unported (CC BY 3.0) Licence
applies to this document.</p><p>The licence was added on January 1, 2013.</p></licence></availability>
(gloss) each list item glosses some term or concept, which is given by a <label> element preceding the list item.
index
(index) each list item is an entry in an index such as the alphabetical topical index at the back of a print volume.
instructions
(instructions) each list item is a step in a sequence of instructions, as in a recipe.
litany
(litany) each list item is one of a sequence of petitions, supplications or invocations, typically in a religious ritual.
syllogism
(syllogism) each list item is part of an argument consisting of two or more propositions and a final conclusion derived from them.
Note
Previous versions of these Guidelines recommended the use of type on <list> to encode the rendering or appearance of a list (whether it was bulleted, numbered, etc.). The current recommendation is to use the rend or style attributes for these aspects of a list, while using type for the more appropriate task of characterizing the nature of the content of a list.
The formal syntax of the element declarations allows <label> tags to be omitted from lists tagged <list type="gloss">; this is however a semantic error.
May contain an optional heading followed by a series of items, or a series of label and item pairs, the latter being optionally preceded by one or two specialized headings.
Example
<list rend="numbered"><item>a butcher</item><item>a baker</item><item>a candlestick maker, with
<list rend="bulleted"><item>rings on his fingers</item><item>bells on his toes</item></list></item></list>
Example
<list type="syllogism" rend="bulleted"><item>All Cretans are liars.</item><item>Epimenides is a Cretan.</item><item>ERGO Epimenides is a liar.</item></list>
Example
<list type="litany" rend="simple"><item>God save us from drought.</item><item>God save us from pestilence.</item><item>God save us from wickedness in high places.</item><item>Praise be to God.</item></list>
Example
The following example treats the short numbered clauses of Anglo-Saxon legal codes as lists of items. The text is from an ordinance of King Athelstan (924–939):
<div1 type="section"><head>Athelstan's Ordinance</head><list rend="numbered"><item n="1">Concerning thieves. First, that no thief is to be spared who is caught with
the stolen goods, [if he is] over twelve years and [if the value of the goods is] over
eightpence.
<list rend="numbered"><item n="1.1">And if anyone does spare one, he is to pay for the thief with his
wergild — and the thief is to be no nearer a settlement on that account — or to
clear himself by an oath of that amount.</item><item n="1.2">If, however, he [the thief] wishes to defend himself or to escape, he is
not to be spared [whether younger or older than twelve].</item><item n="1.3">If a thief is put into prison, he is to be in prison 40 days, and he may
then be redeemed with 120 shillings; and the kindred are to stand surety for him
that he will desist for ever.</item><item n="1.4">And if he steals after that, they are to pay for him with his wergild,
or to bring him back there.</item><item n="1.5">And if he steals after that, they are to pay for him with his wergild,
whether to the king or to him to whom it rightly belongs; and everyone of those who
supported him is to pay 120 shillings to the king as a fine.</item></list></item><item n="2">Concerning lordless men. And we pronounced about these lordless men, from whom
no justice can be obtained, that one should order their kindred to fetch back such a
person to justice and to find him a lord in public meeting.
<list rend="numbered"><item n="2.1">And if they then will not, or cannot, produce him on that appointed day,
he is then to be a fugitive afterwards, and he who encounters him is to strike him
down as a thief.</item><item n="2.2">And he who harbours him after that, is to pay for him with his wergild
or to clear himself by an oath of that amount.</item></list></item><item n="3">Concerning the refusal of justice. The lord who refuses justice and upholds
his guilty man, so that the king is appealed to, is to repay the value of the goods and
120 shillings to the king; and he who appeals to the king before he demands justice as
often as he ought, is to pay the same fine as the other would have done, if he had
refused him justice.
<list rend="numbered"><item n="3.1">And the lord who is an accessory to a theft by his slave, and it becomes
known about him, is to forfeit the slave and be liable to his wergild on the first
occasionp if he does it more often, he is to be liable to pay all that he owns.</item><item n="3.2">And likewise any of the king's treasurers or of our reeves, who has been
an accessory of thieves who have committed theft, is to liable to the same.</item></list></item><item n="4">Concerning treachery to a lord. And we have pronounced concerning treachery to
a lord, that he [who is accused] is to forfeit his life if he cannot deny it or is
afterwards convicted at the three-fold ordeal.</item></list></div1>
Note that nested lists have been used so the tagging mirrors the structure indicated by the two-level numbering of the clauses. The clauses could have been treated as a one-level list with irregular numbering, if desired.
Example
<p>These decrees, most blessed Pope Hadrian, we propounded in the public council ... and they
confirmed them in our hand in your stead with the sign of the Holy Cross, and afterwards
inscribed with a careful pen on the paper of this page, affixing thus the sign of the Holy
Cross.
<list rend="simple"><item>I, Eanbald, by the grace of God archbishop of the holy church of York, have
subscribed to the pious and catholic validity of this document with the sign of the Holy
Cross.</item><item>I, Ælfwold, king of the people across the Humber, consenting have subscribed with
the sign of the Holy Cross.</item><item>I, Tilberht, prelate of the church of Hexham, rejoicing have subscribed with the
sign of the Holy Cross.</item><item>I, Higbald, bishop of the church of Lindisfarne, obeying have subscribed with the
sign of the Holy Cross.</item><item>I, Ethelbert, bishop of Candida Casa, suppliant, have subscribed with thef sign of
the Holy Cross.</item><item>I, Ealdwulf, bishop of the church of Mayo, have subscribed with devout will.</item><item>I, Æthelwine, bishop, have subscribed through delegates.</item><item>I, Sicga, patrician, have subscribed with serene mind with the sign of the Holy
Cross.</item></list></p>
Schematron
Lists should only be empty in the special case of RADish files; those lists aren't really empty in any case--they must also include a processing instruction for including items from another RADish file.
<sch:pattern>
<sch:rule context="tei:list[not(exists(child::*))]">
<sch:assert test="processing-instruction('loi-include')">ERROR: Empty lists
can only occur in RADish files and must have loi-include processing instructions.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:rule context="tei:list[@type='gloss']">
<sch:assert test="tei:label">The content of a "gloss" list should include a sequence of one or more pairs of a label element followed by an item element</sch:assert>
</sch:rule>
<listEvent> (list of events) contains a list of descriptions, each of which provides information about an identifiable event. [13.3.1. Basic Principles]
<listEvent><head>Battles of the American Civil War: Kentucky</head><event xml:id="event01" when="1861-09-19"><label>Barbourville</label><desc>The Battle of Barbourville was one of the early engagements of
the American Civil War. It occurred September 19, 1861, in Knox
County, Kentucky during the campaign known as the Kentucky Confederate
Offensive. The battle is considered the first Confederate victory in
the commonwealth, and threw a scare into Federal commanders, who
rushed troops to central Kentucky in an effort to repel the invasion,
which was finally thwarted at the <ref target="#event02">Battle of
Camp Wildcat</ref> in October.</desc></event><event xml:id="event02" when="1861-10-21"><label>Camp Wild Cat</label><desc>The Battle of Camp Wildcat (also known as Wildcat Mountain and Camp
Wild Cat) was one of the early engagements of the American Civil
War. It occurred October 21, 1861, in northern Laurel County, Kentucky
during the campaign known as the Kentucky Confederate Offensive. The
battle is considered one of the very first Union victories, and marked
the first engagement of troops in the commonwealth of Kentucky.</desc></event><event xml:id="event03" from="1864-06-11"
to="1864-06-12"><label>Cynthiana</label><desc>The Battle of Cynthiana (or Kellar’s Bridge) was an engagement
during the American Civil War that was fought on June 11 and 12, 1864,
in Harrison County, Kentucky, near the town of Cynthiana. A part of
Confederate Brigadier General John Hunt Morgan's 1864 Raid into
Kentucky, the battle resulted in a victory by Union forces over the
raiders and saved the town from capture.</desc></event></listEvent>
<listObject> (list of objects) contains a list of descriptions, each of which provides information about an identifiable physical object. [13.3.5. Objects]
The type attribute may be used to distinguish different types of objects.
Example
<listObject><object xml:id="AlfredJewel"><objectIdentifier><country>United Kingdom</country><region>Oxfordshire</region><settlement>Oxford</settlement><institution>University of Oxford</institution><repository>Ashmolean Museum</repository><collection>English Treasures</collection><idno type="ashmolean">AN1836p.135.371</idno><idno type="wikipedia">https://en.wikipedia.org/wiki/Alfred_Jewel</idno><objectName>Alfred Jewel</objectName></objectIdentifier><physDesc><p> The Alfred Jewel is about 6.4 cm in length and is made of combination of filigreed <material>gold</material>
surrounding a polished teardrop shaped piece of transparent <material>quartz</material>. Underneath the rock crystal
is a cloisonné enamel image of a man with ecclesiastical symbols. The sides of the jewel holding the crystal in
place contain an openwork inscription saying "AELFRED MEC HEHT GEWYRCAN", meaning 'Alfred ordered me made'. </p></physDesc><history><origin>It is generally accepted that the Alfred Jewel dates from the <origDate>late 9th Century</origDate> and was
most likely made in <origPlace>England</origPlace>. </origin><provenance when="1693">The jewel was discovered in 1693 at Petherton Park, North Petherton in the English county of
Somerset, on land owned by Sir Thomas Wroth. North Petherton is about 8 miles away from Athelney, where King Alfred
founded a monastery. </provenance><provenance when="1698">A description of the Alfred Jewel was first published in 1698, in the Philosophical
Transactions of the Royal Society.</provenance><acquisition> It was bequeathed to Oxford University by Colonel Nathaniel Palmer (c. 1661-1718) and today is in the
Ashmolean Museum in Oxford. </acquisition></history></object></listObject>
<listOrg> (list of organizations) contains a list of elements, each of which provides information about an identifiable organization. [13.2.2. Organizational Names]
The type attribute may be used to distinguish lists of organizations of a particular type if convenient.
Example
<listOrg><head>Libyans</head><org><orgName>Adyrmachidae</orgName><desc>These people have, in most points, the same customs as the Egyptians, but
use the costume of the Libyans. Their women wear on each leg a ring made of
bronze [...]</desc></org><org><orgName>Nasamonians</orgName><desc>In summer they leave their flocks and herds upon the sea-shore, and go up
the country to a place called Augila, where they gather the dates from the
palms [...]</desc></org><org><orgName>Garamantians</orgName><desc>[...] avoid all society or intercourse with their fellow-men, have no
weapon of war, and do not know how to defend themselves. [...]</desc><!-- ... --></org></listOrg>
<listPlace> (list of places) contains a list of places, optionally followed by a list of relationships (other than containment) defined amongst them. [2.2.7. The Source Description13.3.4. Places]
<listPlace type="offshoreIslands"><place><placeName>La roche qui pleure</placeName></place><place><placeName>Ile aux cerfs</placeName></place></listPlace>
<listRelation> provides information about relationships identified amongst people, places, and organizations, either informally as prose or as formally expressed relation links. [13.3.2.3. Personal Relationships]
May contain a prose description organized as paragraphs, or a sequence of <relation> elements.
Example
<listPerson><person xml:id="pp1"><!-- data about person pp1 --></person><person xml:id="pp2"><!-- data about person pp1 --></person><!-- more person (pp3, pp4) elements here --><listRelation type="personal"><relation name="parent"
active="#pp1 #pp2" passive="#pp3 #pp4"/><relation name="spouse"
mutual="#pp1 #pp2"/></listRelation><listRelation type="social"><relation name="employer" active="#pp1"
passive="#pp3 #pp5 #pp6 #pp7"/></listRelation></listPerson>
The persons with identifiers pp1 and pp2 are the parents of pp3 and pp4; they are also married to each other; pp1 is the employer of pp3, pp5, pp6, and pp7.
Example
<listPerson><person xml:id="en_pp1"><!-- data about person en_pp1 --></person><person xml:id="en_pp2"><!-- data about person en_pp2 --></person><!-- more person (en_pp3, en_pp4) elements here --></listPerson><listPlace><place xml:id="en_pl1"><!-- data about place en_pl1 --></place><!-- more place (en_pl2, en_pl3) elements here --></listPlace><listRelation><relation name="residence"
active="#en_pp1 #en_pp2" passive="#en_pl1"/></listRelation>
The persons with identifiers en_pp1 and en_pp2 live in en_pl1.
Example
<listRelation><p>All speakers are members of the Ceruli family, born in Naples.</p></listRelation>
<location> (location) defines the location of a place as a set of geographical coordinates, in terms of other named geo-political entities, or as an address. [13.3.4. Places]
<place xml:id="BGbuilding" type="building"><placeName>Brasserie Georges</placeName><location><country key="FR"/><settlement type="city">Lyon</settlement><district type="arrondissement">IIème</district><district type="quartier">Perrache</district><placeName type="street"><num>30</num>, Cours de Verdun</placeName></location></place>
Example
<place type="imaginary"><placeName>Atlantis</placeName><location><offset>beyond</offset><placeName>The Pillars of <persName>Hercules</persName></placeName></location></place>
Suggested values for the type attribute include exact for exact equivalences, uppercase for uppercase equivalences, lowercase for lowercase equivalences, and simplified for simplified characters. The <g> elements contained by this element can point to either another <char> or <glyph>element or contain a character that is intended to be the target of this mapping.
<material> (material) contains a word or phrase describing the material of which the object being described is composed. [10.3.2. Material and Object Type]
sewing at the head or tail of the codex spine to strengthen the binding, often decorative
slipcase
removable protective cover for a set of one or more codices
support
the surface for writing
tie
a ribbon or string used to bind or close a codex or rolled scroll
Note
The sample values here are for descriptive bibliography. Other sets of sample values might include armrests, legs, tabletop, pan, and back for furniture; or wall, floor, window, column, ceiling, roof, stairs, chimney for architecture.
target
identifies one or more elements to which the metamark applies.
The attributes available for this element are not appropriate in all cases. For example, it makes no sense to specify the temporal duration of a graphic. Such errors are not currently detected.
The mimeType attribute must be used to specify the MIME media type of the resource specified by the url attribute.
Example
<figure><media mimeType="image/png" url="fig1.png"/><head>Figure One: The View from the Bridge</head><figDesc>A Whistleresque view showing four or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc></figure>
Example
<media mimeType="audio/wav"
url="dingDong.wav" dur="PT10S"><desc>Ten seconds of bellringing sound</desc></media>
Example
<media mimeType="video/mp4"
url="clip45.mp4" dur="PT45M" width="500px"><desc>A 45 minute video clip to be displayed in a window 500
px wide</desc></media>
<milestone> (milestone) marks a boundary point separating any kind of section of a text, typically but not necessarily indicating a point at which some part of a standard reference system changes, where the change is not represented by a structural element. [3.11.3. Milestone Elements]
For this element, the global n attribute indicates the new number or other value for the unit which changes at this milestone. The special value unnumbered should be used in passages which fall outside the normal numbering scheme, such as chapter or other headings, poem numbers or titles, etc.
The order in which <milestone> elements are given at a given point is not normally significant.
<msContents> (manuscript contents) describes the intellectual content of a manuscript, manuscript part, or other object either as a series of paragraphs or as a series of structured manuscript items. [10.6. Intellectual Content]
Unless it contains a simple prose description, this element should contain at least one of the elements <summary>, <msItem>, or <msItemStruct>. This constraint is not currently enforced by the schema.
Example
<msContents class="#sermons"><p>A collection of Lollard sermons</p></msContents>
Example
<msContents><msItem n="1"><locus>fols. 5r-7v</locus><title>An ABC</title><bibl><title>IMEV</title><biblScope>239</biblScope></bibl></msItem><msItem n="2"><locus>fols. 7v-8v</locus><title xml:lang="frm">Lenvoy de Chaucer a Scogan</title><bibl><title>IMEV</title><biblScope>3747</biblScope></bibl></msItem><msItem n="3"><locus>fol. 8v</locus><title>Truth</title><bibl><title>IMEV</title><biblScope>809</biblScope></bibl></msItem><msItem n="4"><locus>fols. 8v-10v</locus><title>Birds Praise of Love</title><bibl><title>IMEV</title><biblScope>1506</biblScope></bibl></msItem><msItem n="5"><locus>fols. 10v-11v</locus><title xml:lang="la">De amico ad amicam</title><title xml:lang="la">Responcio</title><bibl><title>IMEV</title><biblScope>16 & 19</biblScope></bibl></msItem><msItem n="6"><locus>fols. 14r-126v</locus><title>Troilus and Criseyde</title><note>Bk. 1:71-Bk. 5:1701, with additional losses due to mutilation throughout</note></msItem></msContents>
<msDesc> (manuscript description) contains a description of a single identifiable manuscript or other text-bearing object such as an early printed book. [10.1. Overview]
Although the <msDesc> has primarily been designed with a view to encoding manuscript descriptions, it may also be used for other objects such as early printed books, fascicles, epigraphs, or any text-bearing objects that require substantial description. If an object is not text-bearing or the reasons for describing the object is not primarily the textual content, the more general <object> may be more suitable.
Example
<msDesc><msIdentifier><settlement>Oxford</settlement><repository>Bodleian Library</repository><idno type="Bod">MS Poet. Rawl. D. 169.</idno></msIdentifier><msContents><msItem><author>Geoffrey Chaucer</author><title>The Canterbury Tales</title></msItem></msContents><physDesc><objectDesc><p>A parchment codex of 136 folios, measuring approx
28 by 19 inches, and containing 24 quires.</p><p>The pages are margined and ruled throughout.</p><p>Four hands have been identified in the manuscript: the first 44
folios being written in two cursive anglicana scripts, while the
remainder is for the most part in a mixed secretary hand.</p></objectDesc></physDesc></msDesc>
<msIdentifier> (manuscript identifier) contains the information required to identify the manuscript or similar object being described. [10.4. The Manuscript Identifier]
<sch:report test="not(parent::tei:msPart) and (local-name(*[1])='idno' or local-name(*[1])='altIdentifier'
or normalize-space(.)='')">An msIdentifier must contain either a repository or location.</sch:report>
<msItem> (manuscript item) describes an individual work or item within the intellectual content of a manuscript, manuscript part, or other object. [10.6.1. The msItem and msItemStruct Elements]
Proper nouns referring to people, places, and organizations may be tagged instead with <persName>, <placeName>, or <orgName>, when the TEI module for names and dates is included.
Example
<name type="person">Thomas Hoccleve</name><name type="place">Villingaholt</name><name type="org">Vetus Latina Institut</name><name type="person" ref="#HOC001">Occleve</name>
<nationality> (nationality) contains an informal description of a person's present or past nationality or citizenship. [15.2.2. The Participant Description]
In the following example, the translator has supplied a footnote containing an explanation of the term translated as "painterly":
And yet it is not only
in the great line of Italian renaissance art, but even in the
painterly <note place="bottom" type="gloss"
resp="#MDMH"><term xml:lang="de">Malerisch</term>. This word has, in the German, two
distinct meanings, one objective, a quality residing in the object,
the other subjective, a mode of apprehension and creation. To avoid
confusion, they have been distinguished in English as
<mentioned>picturesque</mentioned> and
<mentioned>painterly</mentioned> respectively.
</note> style of the
Dutch genre painters of the seventeenth century that drapery has this
psychological significance.
<!-- elsewhere in the document --><respStmt xml:id="MDMH"><resp>translation from German to English</resp><name>Hottinger, Marie Donald Mackie</name></respStmt>
For this example to be valid, the code MDMH must be defined elsewhere, for example by means of a responsibility statement in the associated TEI header.
Example
The global n attribute may be used to supply the symbol or number used to mark the note's point of attachment in the source text, as in the following example:
Mevorakh b. Saadya's mother, the matriarch of the
family during the second half of the eleventh century, <note n="126" anchored="true"> The
alleged mention of Judah Nagid's mother in a letter from 1071 is, in fact, a reference to
Judah's children; cf. above, nn. 111 and 54. </note> is well known from Geniza documents
published by Jacob Mann.
However, if notes are numbered in sequence and their numbering can be reconstructed automatically by processing software, it may well be considered unnecessary to record the note numbers.
<notesStmt> (notes statement) collects together any notes providing information about a text additional to that recorded in other parts of the bibliographic description. [2.2.6. The Notes Statement2.2. The File Description]
Detailed analyses of quantities and units of measure in historical documents may also use the feature structure mechanism described in chapter 18. Feature Structures. The <num> element is intended for use in simple applications.
Example
<p>I reached <num type="cardinal" value="21">twenty-one</num> on
my <num type="ordinal" value="21">twenty-first</num> birthday</p><p>Light travels at <num value="3E10">3×10<hi rend="sup">10</hi></num> cm per second.</p>
Schematron
<num> elements should only have a corresp attribute if it's being used as a statistics placeholder
<sch:pattern>
<sch:rule context="tei:num[@corresp]">
<sch:assert test="string-length(string(.)) = 0">ERROR: Nums with a corresp attribute must be empty.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<num> elements should only use the stats prefix for their @corresp.
<sch:pattern>
<sch:rule context="tei:num[@corresp]">
<sch:assert test="every $token in tokenize(@corresp,'\s+') satisfies starts-with($token,
'stats:')">ERROR: All num corresp pointers must start with the stats prefix.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
The stat prefix should only be used in nums
<sch:pattern>
<sch:rule context="tei:*[@*[matches(.,'stats:')]]">
<sch:assert test="self::tei:num and @corresp">ERROR: The stats: prefix should only be used
as a corresp value for num elements.</sch:assert>
</sch:rule>
</sch:pattern>
The <object> element is a recent addition to the TEI P5 Guidelines as of version 3.5.0 and as such may be more prone to further revision in the next few releases as its use develops. This may be particularly evident where its contents have been borrowed from <msDesc> and have yet to be generalized from their use in the context of manuscript descriptions.
The <object> element may be used for describing any object, text-bearing or not, though where the textuality of the object is the primary concern or a collection is mostly composed of manuscripts, encoders may prefer the <msDesc> element (a more specific form of <object>) which may be used not only to describe manuscripts but any form of text-bearing objects such as early printed books.
Example
<listObject><object xml:id="Alfred_Jewel"><objectIdentifier><country>United Kingdom</country><region>Oxfordshire</region><settlement>Oxford</settlement><institution>University of Oxford</institution><repository>Ashmolean Museum</repository><collection>English Treasures</collection><idno type="ashmolean">AN1836p.135.371</idno><idno type="wikipedia">https://en.wikipedia.org/wiki/Alfred_Jewel</idno><objectName>Alfred Jewel</objectName></objectIdentifier><physDesc><p> The Alfred Jewel is about 6.4 cm in length and is made of combination of filigreed <material>gold</material>
surrounding a polished teardrop shaped piece of transparent <material>quartz</material>. Underneath the rock
crystal is a cloisonné enamel image of a man with ecclesiastical symbols. The sides of the jewel holding the
crystal in place contain an openwork inscription saying "AELFRED MEC HEHT GEWYRCAN", meaning 'Alfred ordered
me made'. </p></physDesc><history><origin>It is generally accepted that the Alfred Jewel dates from the <origDate>late 9th Century</origDate> and
was most likely made in <origPlace>England</origPlace>. </origin><provenance when="1693">The jewel was discovered in 1693 at Petherton Park, North Petherton in the English
county of Somerset, on land owned by Sir Thomas Wroth. North Petherton is about 8 miles away from Athelney,
where King Alfred founded a monastery. </provenance><provenance when="1698">A description of the Alfred Jewel was first published in 1698, in the Philosophical
Transactions of the Royal Society.</provenance><acquisition> It was bequeathed to Oxford University by Colonel Nathaniel Palmer (c. 1661-1718) and today is in
the Ashmolean Museum in Oxford. </acquisition></history></object></listObject><!-- Elsewhere in document --><p> The <objectName ref="#MinsterLovellJewel">Minster Lovell Jewel</objectName> is probably the most similar to the
<objectName ref="#Alfred_Jewel">Alfred Jewel</objectName> and was found in <placeName ref="#MinsterLovell">Minster
Lovell</placeName> in <placeName ref="#Oxfordshire">Oxfordshire</placeName> and is kept at the <orgName ref="#AshmoleanMuseum">Ashmolean Museum</orgName>.
</p>
Example
<listObject><object xml:id="MaskOfTutankhamun"><objectIdentifier><objectName xml:lang="en">Mask of Tutankhamun</objectName><idno type="carter">256a</idno><idno type="JournalD'Entrée">60672</idno><idno type="exhibition">220</idno><institution>Museum of Egyptian Antiquities</institution><address><street>15 Meret Basha</street><district>Ismailia</district><settlement>Cairo</settlement><country>Egypt</country><location><geo>30.047778, 31.233333</geo></location></address></objectIdentifier><msContents><p>The back and shoulders of the mask is inscribed with a protective spell in Egyptian hieroglyphs formed of ten
vertical and horizontal lines. This spell first appeared on masks in the Middle Kingdom at least 500 years
before Tutankhamun, and comes from chapter 151 of the <title>Book of the Dead</title>.</p></msContents><physDesc><p> The mask of Tutankhamun is 54cm x 39.3cm x 49cm. It is constructed from two layers of high-karat gold that
varies in thickness from 1.5-3mm. It weighs approximately 10.23kg and x-ray crystallography shows that it is
composed of two alloys of gold with a lighter 18.4 karat shade being used for the face and neck while a heavier
22.5 karat gold was used for the rest of the mask.</p><p>In the mask Tutankhamun wears a nemes headcloth which has the royal insignia of a cobra (Wadjet) and vulture
(Nekhbet) on it. These are thought respectively to symbolize Tutankhamun's rule of both Lower Egypt and Upper
Egypt. His ears are pierced for earrings. The mask has rich inlays of coloured glass and gemstones, including
lapis lazuli surrounding the eye and eyebrows, quartz for the eyes, obsidian for the pupils. The broad collar is
made up of carnelian, feldspar, turquoise, amazonite, faience and other stones.</p></physDesc><history><origin><p>The mask of Tutankhamun was created in <origPlace>Egypt</origPlace> around <origDate when="-1323" type="circa">1323 BC</origDate>. It is a death mask of the 18th-dynasty ancient Egyptian Pharaoh Tutankhamun
who reigned 1332–1323 BC. </p></origin><provenance><p>The mask of Tutankhamun was found in his burial chamber at Theban Necropolis in the Valley of the Kings in
1922. On 28 October 1925 the excavation team led by English archaeologist Howard Carter opened the heavy
sarcophagus and three coffins and were the first people in around 3,250 years to see the mask of Tutankhamun.
Carter wrote in his diary: <quote> The pins removed, the lid was raised. The penultimate scene was disclosed –
a very neatly wrapped mummy of the young king, with golden mask of sad but tranquil expression, symbolizing
Osiris … the mask bears that god's attributes, but the likeness is that of Tut.Ankh.Amen – placid and
beautiful, with the same features as we find upon his statues and coffins. The mask has fallen slightly
back, thus its gaze is straight up to the heavens. </quote></p></provenance><acquisition> In December 1925, the mask was removed from the tomb, placed in a crate and transported 635
kilometres (395 mi) to the Egyptian Museum in Cairo, where it remains on public display. </acquisition></history><additional><adminInfo><custodialHist><custEvent when="1944">When it was discovered in 1925, the 2.5kg narrow gold beard was no longer attached to
the mask and was reattached to the chin by use of a wooden dowel in 1944.</custEvent><custEvent when="2014-08"> In August 2014 when the mask was removed from its display case for cleaning, the
beard fell off again. Those working in the museum unadvisedly used a quick-drying epoxy to attempt to fix
it, but left the beard off-centre. </custEvent><custEvent when="2015-01">The damage was noticed and repaired in January 2015 by a German-Egyptian team who
used beeswax, a material known to be used as adhesives by the ancient Egyptians.</custEvent></custodialHist></adminInfo></additional></object></listObject>
<objectIdentifier><country>United Kingdom</country><region>Oxfordshire</region><settlement>Oxford</settlement><institution>University of Oxford</institution><repository>Ashmolean Museum</repository><collection>English Treasures</collection><idno type="ashmolean">AN1836p.135.371</idno><idno type="wikipedia">https://en.wikipedia.org/wiki/Alfred_Jewel</idno><objectName>Alfred Jewel</objectName></objectIdentifier>
Example
<object xml:id="Excalibur-MultipleNames"><objectIdentifier><objectName type="main">Excalibur</objectName><objectName type="alt">Caliburn</objectName><objectName xml:lang="cy">Caledfwlch</objectName><objectName xml:lang="cnx">Calesvol</objectName><objectName xml:lang="br">Kaledvoulc'h</objectName><objectName xml:lang="la">Caliburnus</objectName><country>Wales</country></objectIdentifier><p>Excalibur is the name for the legendary sword of King Arthur, in Welsh it is called Caledfwlch,
in Cornish it is called Calesvol, in Breton it is called Kaledvoulc'h, and in Latin it is called Caliburnus.
In some versions Excalibur's blade was engraved with phrases on opposite sides which in translation read:
"Take me up" and "Cast me away" (or similar).</p></object>
indicates the classification system or taxonomy in use, for example by supplying the identifier of a <taxonomy> element, or pointing to some other resource.
The content of this element may be used as an alternative to the more formal specification made possible by its attributes; it may also be used to supplement the formal specification with commentary or clarification.
<opener> (opener) groups together dateline, byline, salutation, and similar phrases appearing as a preliminary group at the start of a division, especially of a letter. [4.2. Elements Common to All Divisions]
<opener><dateline>Walden, this 29. of August 1592</dateline></opener>
Example
<opener><dateline><name type="place">Great Marlborough Street</name><date>November 11, 1848</date></dateline><salute>My dear Sir,</salute></opener><p>I am sorry to say that absence from town and other circumstances have prevented me from
earlier enquiring...</p>
<org> (organization) provides information about an identifiable organization such as a business, a tribe, or any other grouping of people. [13.3.3. Organizational Data]
Values for this attribute may be locally defined by a project, using arbitrary keywords such as artist, employer, familyGroup, or politicalParty, each of which should be associated with a definition. Such local definitions will typically be provided by a <desc> for each <valItem> element in the schema specification of the project's customization.
<org xml:id="JAMs"><orgName>Justified Ancients of Mummu</orgName><desc>An underground anarchist collective spearheaded by
<persName>Hagbard Celine</persName>, who fight the Illuminati
from a golden submarine, the <name>Leif Ericson</name></desc><bibl><author>Robert Shea</author><author>Robert Anton Wilson</author><title>The Illuminatus! Trilogy</title></bibl></org>
About a year back, a question of considerable interest was agitated in the <orgName key="PAS1" type="voluntary"><placeName key="PEN">Pennsyla.</placeName> Abolition Society
</orgName> [...]
Schematron
The pattern for orgName ref is org:[a-z]{4}\d+
<sch:pattern>
<sch:rule context="tei:orgName[@ref]">
<sch:assert test="matches(@ref, '^org:[a-z]{4}\d+$')">The pattern for orgName @ref must start with "org:" followed by four letters and a number.</sch:assert>
</sch:rule>
</sch:pattern>
If all that is desired is to call attention to the original version in the copy text, <orig> may be used alone:
<l>But this will be a <orig>meere</orig> confusion</l><l>And hardly shall we all be <orig>vnderstoode</orig></l>
Example
More usually, an <orig> will be combined with a regularized form within a <choice> element:
<l>But this will be a <choice><orig>meere</orig><reg>mere</reg></choice> confusion</l><l>And hardly shall we all be <choice><orig>vnderstoode</orig><reg>understood</reg></choice></l>
<origin> (origin) contains any descriptive or other information concerning the origin of a manuscript, manuscript part, or other object. [10.8. History]
<origin notBefore="1802" notAfter="1845"
evidence="internal" resp="#AMH">Copied in <name type="origPlace">Derby</name>, probably from an
old Flemish original, between 1802 and 1845, according to <persName xml:id="AMH">Anne-Mette Hansen</persName>.
</origin>
<p>Hallgerd was outside. <q>There is blood on your axe,</q> she said. <q>What have you
done?</q></p><p><q>I have now arranged that you can be married a second time,</q> replied Thjostolf.
</p><p><q>Then you must mean that Thorvald is dead,</q> she said.
</p><p><q>Yes,</q> said Thjostolf. <q>And now you must think up some plan for me.</q></p>
Schematron
<sch:report test="(ancestor::tei:ab or ancestor::tei:p) and not( ancestor::tei:floatingText
|parent::tei:exemplum |parent::tei:item |parent::tei:note |parent::tei:q
|parent::tei:quote |parent::tei:remarks |parent::tei:said |parent::tei:sp
|parent::tei:stage |parent::tei:cell |parent::tei:figure )"> Abstract model violation: Paragraphs may not occur inside other paragraphs or ab elements.
</sch:report>
Schematron
<sch:report test="(ancestor::tei:l or ancestor::tei:lg) and not( ancestor::tei:floatingText
|parent::tei:figure |parent::tei:note )"> Abstract model violation: Lines may not contain higher-level structural elements such as div, p, or ab, unless p is a child of figure or note, or is a descendant of floatingText.
</sch:report>
A <pb> element should appear at the start of the page which it identifies. The global n attribute indicates the number or other value associated with this page. This will normally be the page number or signature printed on it, since the physical sequence number is implicit in the presence of the <pb> element itself.
The type attribute may be used to characterize the page break in any respect. The more specialized attributes break, ed, or edRef should be preferred when the intent is to indicate whether or not the page break is word-breaking, or to note the source from which it derives.
Example
Page numbers may vary in different editions of a text.
<p> ... <pb n="145" ed="ed2"/><!-- Page 145 in edition "ed2" starts here --> ... <pb n="283" ed="ed1"/><!-- Page 283 in edition "ed1" starts here--> ... </p>
Example
A page break may be associated with a facsimile image of the page it introduces by means of the facs attribute
<body><pb n="1" facs="page1.png"/><!-- page1.png contains an image of the page;
the text it contains is encoded here --><p><!-- ... --></p><pb n="2" facs="page2.png"/><!-- similarly, for page 2 --><p><!-- ... --></p></body>
<persName> (personal name) contains a proper noun or proper-noun phrase referring to a person, possibly including one or more of the person's forenames, surnames, honorifics, added names, etc. [13.2.1. Personal Names]
<persName><forename>Edward</forename><forename>George</forename><surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
<placeName>Knebworth</placeName></roleName></persName>
Schematron
The pattern for persName ref is either team:[a-z]{4}\d+ or prs:[a-z]{4}\d+
<sch:pattern>
<sch:rule context="tei:persName[@ref]">
<sch:assert test="matches(@ref, '^(team:|prs:)[a-z]{4}\d+$')">The pattern for persName @ref must start with "team:" or "prs:" followed by four letters and a number.</sch:assert>
</sch:rule>
</sch:pattern>
Values for this attribute may be locally defined by a project, using arbitrary keywords such as artist, employer, author, relative, or servant, each of which should be associated with a definition. Such local definitions will typically be provided by a <valList> element in the project schema specification.
sex
specifies the sex of the person.
Status
Optional
Datatype
1–∞ occurrences ofteidata.sexseparated by whitespace
Note
Values for this attribute may be defined locally by a project, or they may refer to an external standard.
Values for this attribute may be locally defined by a project, using arbitrary keywords such as infant, child, teen, adult, or senior, each of which should be associated with a definition. Such local definitions will typically be provided by a <valList> element in the project schema specification.
May contain either a prose description organized as paragraphs, or a sequence of more specific demographic elements drawn from the model.personPart class.
Example
<person sex="F" age="adult"><p>Female respondent, well-educated, born in Shropshire UK, 12 Jan 1950, of unknown occupation. Speaks French fluently. Socio-Economic
status B2.</p></person>
<physDesc> (physical description) contains a full physical description of a manuscript, manuscript part, or other object optionally subdivided using more specialized elements from the model.physDescPart class. [10.7. Physical Description]
<physDesc><objectDesc form="codex"><supportDesc material="perg"><support>Parchment.</support><extent>i + 55 leaves
<dimensions scope="all" type="leaf"
unit="inch"><height>7¼</height><width>5⅜</width></dimensions></extent></supportDesc><layoutDesc><layout columns="2">In double columns.</layout></layoutDesc></objectDesc><handDesc><p>Written in more than one hand.</p></handDesc><decoDesc><p>With a few coloured capitals.</p></decoDesc></physDesc>
<sch:pattern>
<sch:rule context="tei:placeName[@ref]">
<sch:assert test="matches(@ref, '^plc:[a-z]{4}\d+$')">The pattern for placeName @ref must start with "plc:" followed by four letters and a number.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:rule context="tei:place[@type]">
<sch:assert test="child::tei:placeName"> ERROR: a place element must have a placeName.
</sch:assert>
<sch:assert test="not(@type='settlement') or child::tei:location[child::tei:geo]"> ERROR: a settlement must include a location element with a geo child.
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:rule context="tei:place[@type]">
<sch:assert test="not(@type='settlement') or parent::tei:place[@type='area']"> ERROR: a settlement must be a child of an area.
</sch:assert>
<sch:assert test="@type='region' or parent::tei:place[@type]"> ERROR: This type of place must be nested inside a larger place.
</sch:assert>
<sch:assert test="matches(@xml:id, '^mp[A-Z]')"> ERROR: a Monument place id must start with mp + a capital letter.
</sch:assert>
<sch:assert test="not(@type='district') or parent::tei:place[@type='region']"> ERROR: a district must be a child of a region.
</sch:assert>
<sch:assert test="not(@type='area') or parent::tei:place[@type=('district', 'region')]"> ERROR: an area must be a child of a district or a region.
</sch:assert>
</sch:rule>
</sch:pattern>
<postBox> (postal box or post office box) contains a number or other identifier for some postal delivery point other than a street address. [3.6.2. Addresses]
<postCode> (postal code) contains a numerical or alphanumeric code used as part of a postal address to simplify sorting or delivery of mail. [3.6.2. Addresses]
<profileDesc> (text-profile description) provides a detailed description of non-bibliographic aspects of a text, specifically the languages and sublanguages used, the situation in which it was produced, the participants and their setting. [2.4. The Profile Description2.1.1. The TEI Header and Its Components]
Although the content model permits it, it is rarely meaningful to supply multiple occurrences for any of the child elements of <profileDesc> unless these are documenting multiple texts.
<sch:pattern>
<sch:rule context="tei:profileDesc">
<sch:assert test="tei:textClass">ERROR: All documents must include a profileDesc with a textClass element child.</sch:assert>
</sch:rule>
</sch:pattern>
Where a publication statement contains several members of the model.publicationStmtPart.agency or model.publicationStmtPart.detail classes rather than one or more paragraphs or anonymous blocks, care should be taken to ensure that the repeated elements are presented in a meaningful order. It is a conformance requirement that elements supplying information about publication place, address, identifier, availability, and date be given following the name of the publisher, distributor, or authority concerned, and preferably in that order.
Example
<publicationStmt><publisher>C. Muquardt </publisher><pubPlace>Bruxelles & Leipzig</pubPlace><date when="1846"/></publicationStmt>
Example
<publicationStmt><publisher>Chadwyck Healey</publisher><pubPlace>Cambridge</pubPlace><availability><p>Available under licence only</p></availability><date when="1992">1992</date></publicationStmt>
Example
<publicationStmt><publisher>Zea Books</publisher><pubPlace>Lincoln, NE</pubPlace><date>2017</date><availability><p>This is an open access work licensed under a Creative Commons Attribution 4.0 International license.</p></availability><ptr target="http://digitalcommons.unl.edu/zeabook/55"/></publicationStmt>
<q> (quoted) contains material which is distinguished from the surrounding text using quotation marks or a similar method, for any one of a variety of reasons including, but not limited to: direct speech or thought, technical terms or jargon, authorial distance, quotations from elsewhere, and passages that are mentioned but not used. [3.3.3. Quotation]
May be used to indicate that a passage is distinguished from the surrounding text for reasons concerning which no claim is made. When used in this manner, <q> may be thought of as syntactic sugar for <hi> with a value of rend that indicates the use of such mechanisms as quotation marks.
Example
It is spelled <q>Tübingen</q> — to enter the
letter <q>u</q> with an umlaut hold down the <q>option</q> key and press
<q>0 0 f c</q>
<quote> (quotation) contains a phrase or passage attributed by the narrator or author to some agency external to the text. [3.3.3. Quotation4.3.1. Grouped Texts]
If a bibliographic citation is supplied for the source of a quotation, the two may be grouped using the <cit> element.
Example
Lexicography has shown little sign of being affected by the
work of followers of J.R. Firth, probably best summarized in his
slogan, <quote>You shall know a word by the company it
keeps</quote><ref>(Firth, 1957)</ref>
The dur attribute is used to indicate the original duration of the recording.
Example
<recording type="audio" dur="P30M"><equipment><p>Recorded on a Sony TR444 walkman by unknown participants; remastered
to digital tape at <placeName>Borehamwood Studios</placeName> by
<orgName>Transcription Services Inc</orgName>.</p></equipment></recording>
Example
<recording type="audio" dur="P10M"><equipment><p>Recorded from FM Radio to digital tape</p></equipment><broadcast><bibl><title>Interview on foreign policy</title><author>BBC Radio 5</author><respStmt><resp>interviewer</resp><name>Robin Day</name></respStmt><respStmt><resp>interviewee</resp><name>Margaret Thatcher</name></respStmt><series><title>The World Tonight</title></series><note>First broadcast on
<date when="1989-11-27">27 Nov 89</date></note></bibl></broadcast></recording>
<recordingStmt><recording type="audio" dur="P30M"><respStmt><resp>Location recording by</resp><name>Sound Services Ltd.</name></respStmt><equipment><p>Multiple close microphones mixed down to stereo Digital
Audio Tape, standard play, 44.1 KHz sampling frequency</p></equipment><date>12 Jan 1987</date></recording></recordingStmt>
Example
<recordingStmt><p>Three
distinct recordings made by hidden microphone in early February
2001.</p></recordingStmt>
If all that is desired is to call attention to the fact that the copy text has been regularized, <reg> may be used alone:
<q>Please <reg>knock</reg> if an <reg>answer</reg> is <reg>required</reg></q>
Example
It is also possible to identify the individual responsible for the regularization, and, using the <choice> and <orig> elements, to provide both the original and regularized readings:
<q>Please <choice><reg resp="#LB">knock</reg><orig>cnk</orig></choice> if an <choice><reg>answer</reg><orig>nsr</orig></choice> is <choice><reg>required</reg><orig>reqd</orig></choice></q>
<region> (region) contains the name of an administrative unit such as a state, province, or county, larger than a settlement, but smaller than a country. [13.2.3. Place Names]
<relatedItem> contains or references some other bibliographic item which is related to the present one in some specified manner, for example as a constituent or alternative version of it. [3.12.2.7. Related Items]
If the target attribute is used to reference the related bibliographic item, the element must be empty.
Example
<biblStruct><monogr><author>Shirley, James</author><title type="main">The gentlemen of Venice</title><imprint><pubPlace>New York</pubPlace><publisher>Readex Microprint</publisher><date>1953</date></imprint><extent>1 microprint card, 23 x 15 cm.</extent></monogr><series><title>Three centuries of drama: English, 1642–1700</title></series><relatedItem type="otherForm"><biblStruct><monogr><author>Shirley, James</author><title type="main">The gentlemen of Venice</title><title type="sub">a tragi-comedie presented at the private house in Salisbury
Court by Her Majesties servants</title><imprint><pubPlace>London</pubPlace><publisher>H. Moseley</publisher><date>1655</date></imprint><extent>78 p.</extent></monogr></biblStruct></relatedItem></biblStruct>
Schematron
<sch:report test="@target and count( child::* ) > 0">If the @target attribute on <sch:name/> is used, the
relatedItem element must be empty</sch:report>
<sch:assert test="@target or child::*">A relatedItem element should have either a 'target' attribute
or a child element to indicate the related bibliographic item</sch:assert>
<relation> (relationship) describes any kind of relationship or linkage amongst a specified group of places, events, persons, objects or other items. [13.3.2.3. Personal Relationships]
Only one of the attributes active and mutual may be supplied; the attribute passive may be supplied only if the attribute active is supplied. Not all of these constraints can be enforced in all schema languages.
This example records a relationship, defined by the SAWS ontology, between a passage of text identified by a CTS URN, and a variant passage of text in the Perseus Digital Library, and assigns the identification of the relationship to a particular editor (all using resolvable URIs).
Schematron
<sch:assert test="@ref or @key or @name">One of the attributes 'name', 'ref' or 'key' must be supplied</sch:assert>
Schematron
<sch:report test="@active and @mutual">Only one of the attributes @active and @mutual may be supplied</sch:report>
Schematron
<sch:report test="@passive and not(@active)">the attribute 'passive' may be supplied only if the attribute 'active' is supplied</sch:report>
<repository> (repository) contains the name of a repository within which manuscripts or other objects are stored, possibly forming part of an institution. [10.4. The Manuscript Identifier]
(A person, family, or organization responsible for creating a work that is primarily textual in content, regardless of media type (e.g., printed text, spoken word, electronic text, tactile text) or genre (e.g., poems, novels, screenplays, blogs). Use also for persons, etc., creating a new work by paraphrasing, rewriting, or adapting works by another creator such that the modification has substantially changed the nature and content of the original or changed the medium of expression.) Author
resp:edt
(A person, family, or organization contributing to a resource by revising or elucidating the content, e.g., adding an introduction, notes, or other critical matter. An editor may also prepare a resource for production, publication, or distribution. For major revisions, adaptations, etc., that substantially change the nature and content of the original work, resulting in a new work, see author) Editor
resp:cre
(A person or organization responsible for the intellectual or artistic content of a resource.) Creator
resp:col
(A curator who brings together items from various sources that are then arranged, described, and cataloged as a collection. A collector is neither the creator of the material nor a person to whom manuscripts in the collection may have been addressed.) Collector
resp:ive
(A person, family or organization responsible for creating or contributing to a resource by responding to an interviewer, usually a reporter, pollster, or some other information gathering agent.) Interviewee
resp:ivr
(A person, family, or organization responsible for creating or contributing to a resource by acting as an interviewer, reporter, pollster, or some other information gathering agent.) Interviewer
resp:mda
(A team member responsibile for authoring and researching parts of a metadata record, outside of the context of the holding institution.) Metadata Author
resp:mdc
(A person or organization primarily responsible for compiling and maintaining the original description of a metadata set.) Metadata Contact
resp:mrk
(A person or organization performing the coding of SGML, HTML, or XML markup of metadata, text, etc.) Markup Editor
resp:oth
(A role that has no equivalent. CONSULT WITH TECHNICAL TEAM BEFORE USING.) Other
resp:pfr
(A person who corrects printed matter.) Proofreader
resp:prg
(A person, family, or organization responsible for creating a computer program.) Programmer
resp:res
(A person or organization responsibile for performing research.) Researcher
resp:trc
(A person, family, or organization contributing to a resource by changing it from one system of notation to another.) Transcriber
resp:trl
(A person or organization who renders a text from one language into another, or from an older form of a language into the modern form.) Translator
The attribute ref, inherited from the class att.canonical may be used to indicate the kind of responsibility in a normalized form by referring directly to a standardized list of responsibility types, such as that maintained by a naming authority, for example the list maintained at http://www.loc.gov/marc/relators/relacode.html for bibliographic usage.
A resp in a respStmt shouldn't contain a persName; right now, we flag these as errors in the schematron, but this should be made more explicit once we're finished.
<sch:pattern>
<sch:rule context="tei:respStmt/tei:resp">
<sch:assert test="not(tei:persName)">ERROR: Responsibility statements should not include the person's name in the <resp>; the the <persName> element should be a child of <respStmt> with the resp giving a statement of responsibility (i.e. Transcribed by).</sch:assert>
</sch:rule>
</sch:pattern>
<respStmt> (statement of responsibility) supplies a statement of responsibility for the intellectual content of a text, edition, recording, or series, where the specialized elements for authors, editors, etc. do not suffice or do not apply. May also be used to encode information about individuals or organizations which have played a role in the production or distribution of a bibliographic work. [3.12.2.2. Titles, Authors, and Editors2.2.1. The Title Statement2.2.2. The Edition Statement2.2.5. The Series Statement]
<respStmt><resp>transcribed from original ms</resp><persName>Claus Huitfeldt</persName></respStmt>
Example
<respStmt><resp>converted to XML encoding</resp><name>Alan Morrison</name></respStmt>
Schematron
A name in a respStmt should not include the word "and" or have an ampersand; those should be split into multiple respStmts.
<sch:pattern>
<sch:rule context="tei:respStmt/tei:persName | tei:respStmt/tei:orgName">
<sch:let name="text"
value="string-join(descendant::text(),'')"/>
<sch:assert test="not(matches($text,'\s+(and|&)\s+'))">ERROR: Do not combine multiple names into
one respStmt. Split these into multiple respStmts if more than one person applies to this resp.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
A name in a respStmt should not include the word "and" or have an ampersand; those should be split into multiple respStmts.
<sch:pattern>
<sch:rule context="tei:respStmt/tei:persName | tei:respStmt/tei:orgName">
<sch:assert test="@ref">ERROR: persName/orgName in a respStmt must have a ref pointing to the
responsible person/org.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
A name in a respStmt should not include the word "and" or have an ampersand; those should be split into multiple respStmts.
<sch:pattern>
<sch:rule context="tei:respStmt/tei:persName | tei:respStmt/tei:orgName">
<sch:let name="text"
value="string-join(descendant::text(),'')"/>
<sch:assert test="not(matches($text,','))">ERROR: Names in respStmts should be regularized (i.e. FORENAME SURNAME not SURNAME, FORENAME).</sch:assert>
</sch:rule>
</sch:pattern>
If present on this element, the status attribute should indicate the current status of the document. The same attribute may appear on any <change> to record the status at the time of that change. Conventionally <change> elements should be given in reverse date order, with the most recent change at the start of the list.
<roleName> (role name) contains a name component which indicates that the referent has a particular role or position in society, such as an official title or rank. [13.2.1. Personal Names]
A <roleName> may be distinguished from an <addName> by virtue of the fact that, like a title, it typically exists independently of its holder.
Example
<persName><forename>William</forename><surname>Poulteny</surname><roleName>Earl of Bath</roleName></persName>
Example
<p>The <roleName role="solicitor_general">S.G.</roleName> is the only national public official,
including the Supreme Court justices, required by statute to be “learned in the law.”</p>
Example
<p><persName ref="#NJF"><roleName role="solicitor_general">Solicitor General</roleName> Noel J. Francisco</persName>,
representing the administration, asserted in rebuttal that there was nothing to disavow (...)
<persName ref="#NJF">Francisco</persName> had violated the scrupulous standard of candor about the facts and
the law that <roleName role="solicitor_general">S.G.s</roleName>, in Republican and Democratic administrations
alike, have repeatedly said they must honor.
</p>
<q>My dear <rs type="person">Mr. Bennet</rs>, </q> said <rs type="person">his lady</rs>
to him one day,
<q>have you heard that <rs type="place">Netherfield Park</rs> is let at
last?</q>
<salute> (salutation) contains a salutation or greeting prefixed to a foreword, dedicatory epistle, or other division of a text, or the salutation in the closing of a letter, preface, etc. [4.2.2. Openers and Closers]
This element records all information about systematic inclusion or omission of portions of the text, whether a reflection of sampling procedures in the pure sense or of systematic omission of material deemed either too difficult to transcribe or not of sufficient interest.
Example
<samplingDecl><p>Samples of up to 2000 words taken at random from the beginning, middle, or end of each
text identified as relevant by respondents.</p></samplingDecl>
(Restrictions on material of a sensitive nature.) This attribute flags records in our database that may contain sensitive, personal or defamatory information. These classes of ana identify the type and severity of the restriction applied.
Status
Optional
Datatype
1–∞ occurrences ofseparated by whitespace
Legal values are:
sens:illness
(Details or graphic images of serious illness (mental or physical) or mortality of identifiable individual(s).) Illness label
sens:youth
(Details of serious anti-social activity or illness of youth under age of 18.) Youth label
sens:implicate
(Defaming or implicating identifiable individual(s) who were not part of document creation.) Implicate label
sens:criminal
(Details of potentially serious or violent criminal activity, especially violence.) Criminal label
sens:stereotype
(Egregious stereotyping (positive or negative) of a culture, group or person (beyond outdated language), especially vulnerable individual(s)/group(s).) Stereotype label
sens:cultural
(Could be considered private by community for cultural reasons.) Cultural label
sens:dishonour
(Could cause undue or disproportionate dishonour / embarrassment to self or family.) Dishonour label
sens:details
(Current personal identifying details (such as contact info).) Details label
The <seg> element may be used at the encoder's discretion to mark any segments of the text of interest for processing. One use of the element is to mark text features for which no appropriate markup is otherwise defined. Another use is to provide an identifier for some segment which is to be pointed at by some other element—i.e. to provide a target, or a part of a target, for a <ptr> or other similar element.
Example
<seg>When are you leaving?</seg><seg>Tomorrow.</seg>
Example
<s><seg rend="caps" type="initial-cap">So father's only</seg> glory was the ballfield.
</s>
Example
<seg type="preamble"><seg>Sigmund, <seg type="patronym">the son of Volsung</seg>, was a king in Frankish country.</seg><seg>Sinfiotli was the eldest of his sons ...</seg><seg>Borghild, Sigmund's wife, had a brother ... </seg></seg>
Schematron
A seg in the about pages must have type snippet
<sch:pattern>
<sch:rule context="tei:seg[ancestor::tei:TEI[matches(@xml:id,'^loi.+_captions$')]]">
<sch:assert test="@type='snippet'">The seg in a caption document must have the type 'snippet'</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
A snippet seg must only be in caption docs
<sch:pattern>
<sch:rule context="tei:seg[@type='snippet']">
<sch:assert test="ancestor::tei:TEI[matches(@xml:id,'^loi.+_captions$')]"> ERROR: A snippet seg should only be in the caption document
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
A snippet seg must only be in caption docs
<sch:pattern>
<sch:rule context="tei:seg[@type='snippet'][ancestor::tei:TEI[matches(@xml:id,'^loi.+_captions$')]]">
<sch:assert test="ancestor::tei:div[matches(@xml:id,'_about$')]"> ERROR: Snippet segs should only be in the about div.
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
A snippet seg must only be in caption docs
<sch:pattern>
<sch:rule context="tei:div[matches(@xml:id,'_about')][ancestor::tei:TEI[matches(@xml:id,'^loi.+_captions$')]]">
<sch:assert test="count(tei:seg[@type='snippet']) lt 2"> ERROR: Each about div should only have ONE snippet.
</sch:assert>
</sch:rule>
</sch:pattern>
<settingDesc> (setting description) describes the setting or settings within which a language interaction takes place, or other places otherwise referred to in a text, edition, or metadata. [15.2. Contextual Information2.4. The Profile Description]
May contain a prose description organized as paragraphs, or a series of <setting> elements. If used to record not settings of language interactions, but other places mentioned in the text, then <place> optionally grouped by <listPlace> inside <standOff> should be preferred.
Example
<settingDesc><p>Texts recorded in the
Canadian Parliament building in Ottawa, between April and November 1988 </p></settingDesc>
<settlement> (settlement) contains the name of a settlement such as a city, town, or village identified as a single geo-political or administrative unit. [13.2.3. Place Names]
<signed> (signature) contains the closing salutation, etc., appended to a foreword, dedicatory epistle, or other division of a text. [4.2.2. Openers and Closers]
<sourceDesc> (source description) describes the source(s) from which an electronic text was derived or generated, typically a bibliographic description in the case of a digitized text, or a phrase such as "born digital" for a text which has no previous existence. [2.2.7. The Source Description]
<sourceDesc><bibl><title level="a">The Interesting story of the Children in the Wood</title>. In
<author>Victor E Neuberg</author>, <title>The Penny Histories</title>.
<publisher>OUP</publisher><date>1968</date>. </bibl></sourceDesc>
Example
<sourceDesc><p>Born digital: no previous source exists.</p></sourceDesc>
Where there is confusion between <trait> and <state> the more general purpose element <state> should be used even for unchanging characteristics. If you wish to distinguish between characteristics that are generally perceived to be time-bound states and those assumed to be fixed traits, then <trait> is available for the more static of these. The <state> element encodes characteristics which are sometimes assumed to change, often at specific times or over a date range, whereas the <trait> elements are used to record characteristics, such as eye-colour, which are less subject to change. Traits are typically, but not necessarily, independent of the volition or action of the holder.
<street> contains a full street address including any name or number identifying a building as well as the name of the street or route on which it is located. [3.6.2. Addresses]
The order and presentation of house names and numbers and street names, etc., may vary considerably in different countries. The encoding should reflect the order which is appropriate in the country concerned.
<summary> contains an overview of the available information concerning some aspect of an item or object (for example, its intellectual content, history, layout, typography etc.) as a complement or alternative to the more detailed information carried by more specific elements. [10.6. Intellectual Content]
<summary>This item consists of three books with a prologue and an epilogue.
</summary>
Example
<typeDesc><summary>Uses a mixture of Roman and Black Letter types.</summary><typeNote>Antiqua typeface, showing influence of Jenson's Venetian
fonts.</typeNote><typeNote>The black letter face is a variant of Schwabacher.</typeNote></typeDesc>
<supplied> (supplied) signifies text supplied by the transcriber or editor for any reason; for example because the original cannot be read due to physical damage, or because of an obvious omission by the author or scribe. [11.3.3.1. Damage, Illegibility, and Supplied Text]
<surface> defines a written surface as a two-dimensional coordinate space, optionally grouping one or more graphic representations of that space, zones of interest within that space, and transcriptions of the writing within them. [11.1. Digital Facsimiles11.2.2. Embedded Transcription]
The <surface> element represents any two-dimensional space on some physical surface forming part of the source material, such as a piece of paper, a face of a monument, a billboard, a scroll, a leaf etc.
The coordinate space defined by this element may be thought of as a grid lrx - ulx units wide and uly - lry units high.
The <surface> element may contain graphic representations or transcriptions of written zones, or both. The coordinate values used by every <zone> element contained by this element are to be understood with reference to the same grid.
Where it is useful or meaningful to do so, any grouping of multiple <surface> elements may be indicated using the <surfaceGrp> element.
In LOI, we require <profileDesc> since it is necessary for specifying a document type. We also make <revisionDesc> mandatory.
Example
<teiHeader><fileDesc><titleStmt><title>Shakespeare: the first folio (1623) in electronic form</title><author>Shakespeare, William (1564–1616)</author><respStmt><resp>Originally prepared by</resp><name>Trevor Howard-Hill</name></respStmt><respStmt><resp>Revised and edited by</resp><name>Christine Avern-Carr</name></respStmt></titleStmt><publicationStmt><distributor>Oxford Text Archive</distributor><address><addrLine>13 Banbury Road, Oxford OX2 6NN, UK</addrLine></address><idno type="OTA">119</idno><availability><p>Freely available on a non-commercial basis.</p></availability><date when="1968">1968</date></publicationStmt><sourceDesc><bibl>The first folio of Shakespeare, prepared by Charlton Hinman (The Norton Facsimile,
1968)</bibl></sourceDesc></fileDesc><encodingDesc><projectDesc><p>Originally prepared for use in the production of a series of old-spelling
concordances in 1968, this text was extensively checked and revised for use during the
editing of the new Oxford Shakespeare (Wells and Taylor, 1989).</p></projectDesc><editorialDecl><correction><p>Turned letters are silently corrected.</p></correction><normalization><p>Original spelling and typography is retained, except that long s and ligatured
forms are not encoded.</p></normalization></editorialDecl><refsDecl xml:id="ASLREF"><cRefPattern matchPattern="(\S+) ([^.]+)\.(.*)"
replacementPattern="#xpath(//div1[@n='$1']/div2/[@n='$2']//lb[@n='$3'])"><p>A reference is created by assembling the following, in the reverse order as that
listed here: <list><item>the <att>n</att> value of the preceding <gi>lb</gi></item><item>a period</item><item>the <att>n</att> value of the ancestor <gi>div2</gi></item><item>a space</item><item>the <att>n</att> value of the parent <gi>div1</gi></item></list></p></cRefPattern></refsDecl></encodingDesc><revisionDesc><list><item><date when="1989-04-12">12 Apr 89</date> Last checked by CAC</item><item><date when="1989-03-01">1 Mar 89</date> LB made new file</item></list></revisionDesc></teiHeader>
<text> (text) contains a single text of any kind, whether unitary or composite, for example a poem or drama, a collection of essays, a novel, a dictionary, or a corpus sample. [4. Default Text Structure15.1. Varieties of Composite Text]
This element should not be used to represent a text which is inserted at an arbitrary point within the structure of another, for example as in an embedded or quoted narrative; the <floatingText> is provided for this purpose.
Example
<text><front><docTitle><titlePart>Autumn Haze</titlePart></docTitle></front><body><l>Is it a dragonfly or a maple leaf</l><l>That settles softly down upon the water?</l></body></text>
Example
The body of a text may be replaced by a group of nested texts, as in the following schematic:
<text><front><!-- front matter for the whole group --></front><group><text><!-- first text --></text><text><!-- second text --></text></group></text>
<textClass> (text classification) groups information which describes the nature or topic of a text in terms of a standard classification scheme, thesaurus, etc. [2.4.3. The Text Classification]
All <textClass> elements must include, at minimum, one <catRef> child; it may also include <keywords>, but only for the oral histories.
Example
<taxonomy><category xml:id="acprose"><catDesc>Academic prose</catDesc></category><!-- other categories here --></taxonomy><!-- ... --><textClass><catRef target="#acprose"/><classCode scheme="http://www.udcc.org">001.9</classCode><keywords scheme="http://authorities.loc.gov"><list><item>End of the world</item><item>History - philosophy</item></list></keywords></textClass>
Schematron
We should use only use the <keywords> element if it's an oral history.
<sch:rule context="tei:textClass/tei:keywords">
<sch:assert test="if (not(empty($docTypes))) then $docTypes[contains(@target,'OralHistory')]
else true()">ERROR: Element <sch:name/> not allowed here. <sch:name/> should only be used in Oral History documents.</sch:assert>
</sch:rule>
<timeline> (timeline) provides a set of ordered points in time which can be linked to elements of a spoken text to create a temporal alignment of that text. [16.4.2. Placing Synchronous Events in Time]
If this attribute is not supplied, the implication is that the time of origin is not known. If it is supplied, it must point either to one of the <when> elements in its content, or to another <timeline> element.
unit
specifies the unit of time corresponding to the interval value of the timeline or of its constituent points in time.
The value irregular indicates uncertainty about all the intervals in the timeline; the value regular indicates that all the intervals are evenly spaced, but the size of the intervals is not known; numeric values indicate evenly spaced values of the size specified. If individual points in time in the timeline are given different values for the interval attribute, those values locally override the value given in the timeline.
(alternate) alternate title, often in another language, by which the work is also known
short
abbreviated form of title
desc
(descriptive) descriptive paraphrase of the work functioning as a title
Note
This attribute is provided for convenience in analysing titles and processing them according to their type; where such specialized processing is not necessary, there is no need for such analysis, and the entire title, including subtitles and any parallel titles, may be enclosed within a single <title> element.
level
indicates the bibliographic level for a title, that is, whether it identifies an article, book, journal, series, or unpublished material.
(analytic) the title applies to an analytic item, such as an article, poem, or other work published as part of a larger item.
m
(monographic) the title applies to a monograph such as a book or other item considered to be a distinct publication, including single volumes of multi-volume works
j
(journal) the title applies to any serial or periodical publication such as a journal, magazine, or newspaper
s
(series) the title applies to a series of otherwise distinct publications such as a collection
u
(unpublished) the title applies to any unpublished material (including theses and dissertations unless published by a commercial press)
Note
The level of a title is sometimes implied by its context: for example, a title appearing directly within an <analytic> element is ipso facto of level ‘a’, and one appearing within a <series> element of level ‘s’. For this reason, the level attribute is not required in contexts where its value can be unambiguously inferred. Where it is supplied in such contexts, its value should not contradict the value implied by its parent element.
The attributes key and ref, inherited from the class att.canonical may be used to indicate the canonical form for the title; the former, by supplying (for example) the identifier of a record in some external library system; the latter by pointing to an XML element somewhere containing the canonical form of the title.
Example
<title>Information Technology and the Research Process: Proceedings of
a conference held at Cranfield Institute of Technology, UK,
18–21 July 1989</title>
Example
<title>Hardy's Tess of the D'Urbervilles: a machine readable
edition</title>
Example
<title type="full"><title type="main">Synthèse</title><title type="sub">an international journal for
epistemology, methodology and history of
science</title></title>
Schematron
All titles much have some meaningful content
<sch:pattern>
<sch:rule context="tei:title">
<sch:let name="text"
value="string-join(descendant::text(),'')"/>
<sch:assert test="$text ne ''">ERROR: Titles must have meaningful content.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Titles shouldn't start or end with spaces
<sch:pattern>
<sch:rule context="tei:title">
<sch:let name="text"
value="string-join(descendant::text(),'')"/>
<sch:assert test="not(matches($text,'^\s|\s$'))">ERROR: Titles shouldn't begin or end with spaces.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Titles shouldn't have a child element other than a text node
<sch:pattern>
<sch:rule context="tei:title[not(@type='generated')]">
<sch:assert test="not(*[not(self::tei:foreign)])">ERROR: Titles shouldn't have any children other than a <foreign> or a text node.</sch:assert>
</sch:rule>
</sch:pattern>
<titleStmt><title>Capgrave's Life of St. John Norbert: a machine-readable transcription</title><respStmt><resp>compiled by</resp><name>P.J. Lucas</name></respStmt></titleStmt>
<trait> (trait) contains a description of some status or quality attributed to a person, place, or organization typically, but not necessarily, independent of the volition or action of the holder and usually not at some specific time or for a specific date range. [13.3.1. Basic Principles13.3.2.1. Personal Characteristics]
Where there is confusion between <trait> and <state> the more general purpose element <state> should be used even for unchanging characteristics. If you wish to distinguish between characteristics that are generally perceived to be time-bound states and those assumed to be fixed traits, then <trait> is available for the more static of these. The <state> element encodes characteristics which are sometimes assumed to change, often at specific times or over a date range, whereas the <trait> elements are used to record characteristics, such as eye-colour, which are less subject to change. Traits are typically, but not necessarily, independent of the volition or action of the holder.
Although individual transcriptions may consistently use <u> elements for turns or other units, and although in most cases a <u> will be delimited by pause or change of speaker, <u> is not required to represent a turn or any communicative event, nor to be bounded by pauses or change of speaker. At a minimum, a <u> is some phonetic production by a given speaker.
Example
<u who="#spkr1">if did you set</u><u trans="latching" who="#spkr2">well Joe and I set it between us</u><list type="speakers"><item xml:id="spkr1"/><item xml:id="spkr2"/></list>
Schematron
Utterances must have an who identifying a speaker with either a team member or a person prefix.
<sch:pattern>
<sch:rule context="tei:u">
<sch:assert test="matches(@who, '^(team:|prs:)[a-z]{4}\d+$')">Utterances must have an @who identifying a speaker with either "team:" or "prs:" followed by the persons id.</sch:assert>
</sch:rule>
</sch:pattern>
The same element is used for all cases of uncertainty in the transcription of element content, whether for written or spoken material. For other aspects of certainty, uncertainty, and reliability of tagging and transcription, see chapter 21. Certainty, Precision, and Responsibility.
identifies the reference point for determining the time of the current <when> element, which is obtained by adding the interval to the time of the reference point.
This attribute should point to another <when> element in the same <timeline>. If no value is supplied, and the absolute attribute is also unspecified, then the reference point is understood to be the origin of the enclosing <timeline> tag.
On this element, the global xml:id attribute must be supplied to specify an identifier for this point in time. The value used may be chosen freely provided that it is unique within the document and is a syntactically valid name. There is no requirement for values containing numbers to be in sequence.
element when
{
att.global.attributes,
attribute absolute { text }?,
attribute unit { "d" | "h" | "min" | "s" | "ms" }?,
attribute interval { text }?,
attribute since { text }?,
empty
}⚓
Appendix A.2 Model classes
Appendix A.2.1 model.addrPart
model.addrPartgroups elements such as names or postal codes which may appear as part of a postal address. [3.6.2. Addresses]
model.emphLikegroups phrase-level elements which are typographically distinct and to which a specific function can be attributed. [3.3. Highlighting and Quotation]
Elements in this class are typically used to hold groups of links or of abstract interpretations, or by provide indications of certainty etc. It may find be convenient to localize all metadata elements, for example to contain them within the same divison as the elements that they relate to; or to locate them all to a division of their own. They may however appear at any point in a TEI text.
model.hiLikegroups phrase-level elements which are typographically distinct but to which no specific function can be attributed. [3.3. Highlighting and Quotation]
model.limitedPhrasegroups phrase-level elements excluding those elements primarily intended for transcription of existing sources. [1.3. The TEI Class System]
model.measureLikegroups elements which denote a number, a quantity, a measurement, or similar piece of text that conveys some numerical meaning. [3.6.3. Numbers and Measures]
model.pPart.editorialgroups phrase-level elements for simple editorial interventions that may be useful both in transcribing and in authoring. [3.5. Simple Editorial Changes]
model.pPart.transcriptionalgroups phrase-level elements used for editorial transcription of pre-existing source materials. [3.5. Simple Editorial Changes]
model.persStateLikegroups elements describing changeable characteristics of a person which have a definite duration, for example occupation, residence, or name.
This class of elements can occur within paragraphs, list items, lines of verse, etc.
Appendix A.2.61 model.phrase.xml
model.phrase.xmlgroups phrase-level elements used to encode XML constructs such as element names, attribute names, and attribute values [22. Documentation Elements]
The ‘agency’ child elements, while not required, are required if one of the ‘detail’ child elements is to be used. It is not valid to have a ‘detail’ child element without a preceding ‘agency’ child element.
The principles on which segmentation is carried out, and any special codes or attribute values used, should be defined explicitly in the <segmentation> element of the <encodingDesc> within the associated TEI header.
Appendix A.2.73 model.settingPart
model.settingPartgroups elements used to describe the setting of a linguistic interaction.
model.titlepagePartgroups elements which can occur as direct constituents of a title page, such as <docTitle>, <docAuthor>, <docImprint>, or <epigraph>. [4.6. Title Pages]
att.anchoring (anchoring) provides attributes for use on annotations, e.g. notes and groups of notes describing the existence and position of an anchor for annotations.
In modern texts, notes are usually anchored by means of explicit footnote or endnote symbols. An explicit indication of the phrase or line annotated may however be used instead (e.g. ‘page 218, lines 3–4’). The anchored attribute indicates whether any explicit location is given, whether by symbol or by prose cross-reference. The value true indicates that such an explicit location is indicated in the copy text; the value false indicates that the copy text does not indicate a specific place of attachment for the note. If the specific symbols used in the copy text at the location the note is anchored are to be recorded, use the n attribute.
targetEnd
(target end) points to the end of the span to which the note is attached, if the note is not embedded in the text at that point.
This attribute is retained for backwards compatibility; it may be removed at a subsequent release of the Guidelines. The recommended way of pointing to a span of elements is by means of the range function of XPointer, as further described in 16.2.4.6. range().
Example
<p>(...) tamen reuerendos dominos archiepiscopum et canonicos Leopolienses
necnon episcopum in duplicibus Quatuortemporibus<anchor xml:id="A55234"/> totaliter expediui...</p><!-- elsewhere in the document --><noteGrp targetEnd="#A55234"><note xml:lang="en"> Quatuor Tempora, so called dry fast days.
</note><note xml:lang="pl"> Quatuor Tempora, tzw. Suche dni postne.
</note></noteGrp>
In the following example from Hamlet, speeches (<sp>) in the body of the play are linked to <castItem> elements in the <castList> using the who attribute.
For transcribed speech, this will typically identify a participant or participant group; in other contexts, it will point to any identified <person> element.
In the following example from Mary Pix's The False Friend, speeches (<sp>) in the body of the play are linked to <castItem> elements in the <castList> using the toWhom attribute, which is used to specify who the speech is directed to. Additionally, the <stage> includes toWhom to indicate the directionality of the action.
<castItem type="role"><role xml:id="emil">Emilius.</role></castItem><castItem type="role"><role xml:id="lov">Lovisa</role></castItem><castItem type="role"><role xml:id="serv">A servant</role></castItem><!-- ... --><sp who="#emil"
toWhom="#lov"><speaker>Emil.</speaker><l n="1">My love!</l></sp><sp who="#lov"
toWhom="#emil"><speaker>Lov.</speaker><l n="2">I have no Witness of my Noble Birth</l><stage who="emil"
toWhom="#serv">Pointing to her Woman.</stage><l>But that poor helpless wretch——</l></sp>
Note
To indicate the recipient of written correspondence, use the elements used in section 2.4.6. Correspondence Description, rather than a toWhom attribute.
Appendix A.3.4 att.breaking
att.breakingprovides attributes to indicate whether or not the element concerned is considered to mark the end of an orthographic token in the same way as whitespace. [3.11.3. Milestone Elements]
indicates whether or not the element bearing this attribute should be considered to mark the end of an orthographic token in the same way as whitespace.
the element bearing this attribute is considered to mark the end of any adjacent orthographic token irrespective of the presence of any adjacent whitespace
no
the element bearing this attribute is considered not to mark the end of any adjacent orthographic token irrespective of the presence of any adjacent whitespace
maybe
the encoding does not take any position on this issue.
In the following lines from the Dream of the Rood, linebreaks occur in the middle of the words lāðost and reord-berendum.
<ab> ...eƿesa tome iu icƿæs ȝeƿorden ƿita heardoſt .
leodum la<lb break="no"/> ðost ærþan ichim lifes
ƿeȝ rihtne ȝerymde reord be<lb break="no"/>
rendum hƿæt me þaȝeƿeorðode ƿuldres ealdor ofer...
</ab>
Appendix A.3.5 att.cReferencing
att.cReferencingprovides attributes that may be used to supply a canonical reference as a means of identifying the target of a pointer.
(canonical reference) specifies the destination of the pointer by supplying a canonical reference expressed using the scheme defined in a <refsDecl> element in the TEI header
The value of cRef should be constructed so that when the algorithm for the resolution of canonical references (described in section 16.2.5. Canonical References) is applied to it the result is a valid URI reference to the intended target.
The <refsDecl> to use may be indicated with the decls attribute.
Currently these Guidelines only provide for a single canonical reference to be encoded on any given <ptr> element.
Appendix A.3.6 att.canonical
att.canonicalprovides attributes that can be used to associate a representation such as a name or title with canonical information about the object being named or referenced. [13.1.1. Linking Names and Their Referents]
<author><name key="Hugo, Victor (1802-1885)"
ref="http://www.idref.fr/026927608">Victor Hugo</name></author>
Note
The value may be a unique identifier from a database, or any other externally-defined string identifying the referent.
No particular syntax is proposed for the values of the key attribute, since its form will depend entirely on practice within a given project. For the same reason, this attribute is not recommended in data interchange, since there is no way of ensuring that the values used by one project are distinct from those used by another. In such a situation, a preferable approach for magic tokens which follows standard practice on the Web is to use a ref attribute whose value is a tag URI as defined in RFC 4151.
ref
(reference) provides an explicit means of locating a full definition or identity for the entity being named by means of one or more URIs.
The value must point directly to one or more XML elements or other resources by means of one or more URIs, separated by whitespace. If more than one is supplied the implication is that the name identifies several distinct entities.
Appendix A.3.7 att.coordinated
att.coordinatedprovides attributes that can be used to position their parent element within a two dimensional coordinate system.
identifies a two dimensional area by means of a series of pairs of numbers, each of which gives the x,y coordinates of a point on a line enclosing the area.
Status
Optional
Datatype
3–∞ occurrences ofteidata.pointseparated by whitespace
Appendix A.3.8 att.datable
att.datableprovides attributes for normalization of elements that contain dates, times, or datable events. [3.6.4. Dates and Times13.4. Dates]
<sch:rule context="tei:*[@calendar]">
<sch:assert test="string-length( normalize-space(.) ) gt 0"> @calendar indicates one or more
systems or calendars to which the date represented by the content of this element belongs,
but this <sch:name/> element has no textual content.</sch:assert>
</sch:rule>
He was born on <date calendar="#gregorian">Feb. 22, 1732</date> (<date calendar="#julian"
when="1732-02-22">Feb. 11, 1731/32,
O.S.</date>).
He was born on <date calendar="#gregorian #julian"
when="1732-02-22">Feb. 22, 1732
(Feb. 11, 1731/32, O.S.)</date>.
Note
Note that the calendar attribute (unlike datingMethod defined in att.datable.custom) defines the calendar system of the date in the original material defined by the parent element, not the calendar to which the date is normalized.
period
supplies pointers to one or more definitions of named periods of time (typically <category>s or <calendar>s) within which the datable item is understood to have occurred.
This ‘superclass’ provides attributes that can be used to provide normalized values of temporal information. By default, the attributes from the att.datable.w3c class are provided. If the module for names & dates is loaded, this class also provides attributes from the att.datable.iso and att.datable.custom classes. In general, the possible values of attributes restricted to the W3C datatypes form a subset of those values available via the ISO 8601 standard. However, the greater expressiveness of the ISO datatypes may not be needed, and there exists much greater software support for the W3C datatypes.
Appendix A.3.9 att.datable.custom
att.datable.customprovides attributes for normalization of elements that contain datable events to a custom dating system (i.e. other than the Gregorian used by W3 and ISO). [13.4. Dates]
supplies the value of a date or time in some custom standard form.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
The following are examples of custom date or time formats that are not valid ISO or W3C format normalizations, normalized to a different dating system
<p>Alhazen died in Cairo on the
<date when="1040-03-06"
when-custom="431-06-12"> 12th day of Jumada t-Tania, 430 AH
</date>.</p><p>The current world will end at the
<date when="2012-12-21"
when-custom="13.0.0.0.0">end of B'ak'tun 13</date>.</p><p>The Battle of Meggidu
(<date when-custom="Thutmose_III:23">23rd year of reign of Thutmose III</date>).</p><p>Esidorus bixit in pace annos LXX plus minus sub
<date when-custom="Ind:4-10-11">die XI mensis Octobris indictione IIII</date></p>
Not all custom date formulations will have Gregorian equivalents.The when-custom attribute and other custom dating are not constrained to a datatype by the TEI, but individual projects are recommended to regularize and document their dating formats.
notBefore-custom
specifies the earliest possible date for the event in some custom standard form.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
notAfter-custom
specifies the latest possible date for the event in some custom standard form.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
from-custom
indicates the starting point of the period in some custom standard form.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
<event xml:id="FIRE1"
datingMethod="#julian"
from-custom="1666-09-02"
to-custom="1666-09-05"><head>The Great Fire of London</head><p>The Great Fire of London burned through a large part
of the city of London.</p></event>
to-custom
indicates the ending point of the period in some custom standard form.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
datingPoint
supplies a pointer to some location defining a named point in time with reference to which the datable item is understood to have occurred
Contayning the Originall, Antiquity, Increaſe, Moderne
eſtate, and deſcription of that Citie, written in the yeare
<date when-custom="1598"
calendar="#julian"
datingMethod="#julian">1598</date>. by Iohn Stow
Citizen of London.
In this example, the calendar attribute points to a <calendar> element for the Julian calendar, specifying that the text content of the <date> element is a Julian date, and the datingMethod attribute also points to the Julian calendar to indicate that the content of the when-custom attribute value is Julian too.
In this example, a date is given in a Mediaeval text measured ‘from the creation of the world’, which is normalized (in when) to the Gregorian date, but is also normalized (in when-custom) to a machine-actionable, numeric version of the date from the Creation.
Note
Note that the datingMethod attribute (unlike calendar defined in att.datable) defines the calendar or dating system to which the date described by the parent element is normalized (i.e. in the when-custom or other X-custom attributes), not the calendar of the original date in the element.
Appendix A.3.10 att.datable.iso
att.datable.isoprovides attributes for normalization of elements that contain datable events using the ISO 8601:2004 standard. [3.6.4. Dates and Times13.4. Dates]
The following are examples of ISO date, time, and date & time formats that are not valid W3C format normalizations.
<date when-iso="1996-09-24T07:25+00">Sept. 24th, 1996 at 3:25 in the morning</date><date when-iso="1996-09-24T03:25-04">Sept. 24th, 1996 at 3:25 in the morning</date><time when-iso="1999-01-04T20:42-05">4 Jan 1999 at 8:42 pm</time><time when-iso="1999-W01-1T20,70-05">4 Jan 1999 at 8:42 pm</time><date when-iso="2006-05-18T10:03">a few minutes after ten in the morning on Thu 18 May</date><time when-iso="03:00">3 A.M.</time><time when-iso="14">around two</time><time when-iso="15,5">half past three</time>
All of the examples of the when attribute in the att.datable.w3c class are also valid with respect to this attribute.
He likes to be punctual. I said <q><time when-iso="12">around noon</time></q>, and he showed up at <time when-iso="12:00:00">12 O'clock</time> on the dot.
The second occurence of <time> could have been encoded with the when attribute, as 12:00:00 is a valid time with respect to the W3C XML Schema Part 2: Datatypes Second Edition specification. The first occurence could not.
notBefore-iso
specifies the earliest possible date for the event in standard form, e.g. yyyy-mm-dd.
The value of these attributes should be a normalized representation of the date, time, or combined date & time intended, in any of the standard formats specified by ISO 8601:2004, using the Gregorian calendar.
If both when-iso and dur-iso are specified, the values should be interpreted as indicating a span of time by its starting time (or date) and duration. That is,
<date when-iso="2007-06-01" dur-iso="P8D"/>
indicates the same time period as
<date when-iso="2007-06-01/P8D"/>
In providing a ‘regularized’ form, no claim is made that the form in the source text is incorrect; the regularized form is simply that chosen as the main form for purposes of unifying variant forms under a single heading.
Appendix A.3.11 att.datable.w3c
att.datable.w3cprovides attributes for normalization of elements that contain datable events conforming to the W3C XML Schema Part 2: Datatypes Second Edition. [3.6.4. Dates and Times13.4. Dates]
Examples of W3C date, time, and date & time formats.
<p><date when="1945-10-24">24 Oct 45</date><date when="1996-09-24T07:25:00Z">September 24th, 1996 at 3:25 in the morning</date><time when="1999-01-04T20:42:00-05:00">Jan 4 1999 at 8 pm</time><time when="14:12:38">fourteen twelve and 38 seconds</time><date when="1962-10">October of 1962</date><date when="--06-12">June 12th</date><date when="---01">the first of the month</date><date when="--08">August</date><date when="2006">MMVI</date><date when="0056">AD 56</date><date when="-0056">56 BC</date></p>
This list begins in
the year 1632, more precisely on Trinity Sunday, i.e. the Sunday after
Pentecost, in that year the
<date calendar="#julian"
when="1632-06-06">27th of May (old style)</date>.
<sch:rule context="tei:*[@when]">
<sch:report test="@notBefore|@notAfter|@from|@to"
role="nonfatal">The @when attribute cannot be used with any other att.datable.w3c attributes.</sch:report>
</sch:rule>
Schematron
<sch:rule context="tei:*[@from]">
<sch:report test="@notBefore"
role="nonfatal">The @from and @notBefore attributes cannot be used together.</sch:report>
</sch:rule>
Schematron
<sch:rule context="tei:*[@to]">
<sch:report test="@notAfter"
role="nonfatal">The @to and @notAfter attributes cannot be used together.</sch:report>
</sch:rule>
Example
<date from="1863-05-28" to="1863-06-01">28 May through 1 June 1863</date>
Note
The value of these attributes should be a normalized representation of the date, time, or combined date & time intended, in any of the standard formats specified by XML Schema Part 2: Datatypes Second Edition, using the Gregorian calendar.
The most commonly-encountered format for the date portion of a temporal attribute is yyyy-mm-dd, but yyyy, --mm, ---dd, yyyy-mm, or --mm-dd may also be used. For the time part, the form hh:mm:ss is used.
Note that this format does not currently permit use of the value 0000 to represent the year 1 BCE; instead the value -0001 should be used.
Appendix A.3.12 att.datcat
att.datcatprovides attributes that are used to align XML elements or attributes with the appropriate Data Categories (DCs) defined by an external taxonomy, in this way establishing the identity of information containers and values, and providing means of interpreting them. [9.5.2. Lexical View18.3. Other Atomic Feature Values]
provides a pointer to a definition of, and/or general information about, (a) an information container (element or attribute) or (b) a value of an information container (element content or attribute value), by referencing an external taxonomy or ontology. If valueDatcat is present in the immediate context, this attribute takes on role (a), while valueDatcat performs role (b).
provides a definition of, and/or general information about a value of an information container (element content or attribute value), by reference to an external taxonomy or ontology. Used especially where a contrast with datcat is needed.
provides a definition of, and/or general information about, information structure of an object referenced or modeled by the containing element, by reference to an external taxonomy or ontology. This attribute has the characteristics of the datcat attribute, except that it addresses not its containing element, but an object that is being referenced or modeled by its containing element.
The example below presents the TEI encoding of the name-value pair<part of speech, common noun>, where the name (key) ‘part of speech’ is abbreviated as ‘POS’, and the value, ‘common noun’ is symbolized by ‘NN’. The entire name-value pair is encoded by means of the element <f>. In TEI XML, that element acts as the container, labeled with the name attribute. Its contents may be complex or simple. In the case at hand, the content is the symbol ‘NN’.The datcat attribute relates the feature name (i.e., the key) to the data category ‘part of speech’, while the attribute valueDatcat relates the feature value to the data category common noun. Both these data categories should be defined in an external and preferably open reference taxonomy or ontology.
‘NN’ is the symbol for common noun used e.g. in the CLAWS-7 tagset defined by the University Centre for Computer Corpus Research on Language at the University of Lancaster. The very same data category used for tagging an early version of the British National Corpus, and coming from the BNC Basic (C5) tagset, uses the symbol ‘NN0’ (rather than ‘NN’). Making these values semantically interoperable would be extremely difficult without a human expert if they were not anchored in a single point of an established reference taxonomy of morphosyntactic data categories. In the case at hand, the string ‘http://hdl.handle.net/11459/CCR_C-1256_7ec6083c-23d4-224d-6f94-eecbe6861545’ is both a persistent identifier of the data category in question, as well as a pointer to a shared definition of common noun.While the symbols ‘NN’, ‘NN0’, and many others (often coming from languages other than English) are implicitly members of the container category ‘part of speech’, it is sometimes useful not to rely on such an implicit relationship but rather use an explicit identifier for that data category, to distinguish it from other morphosyntactic data categories, such as gender, tense, etc. For that purpose, the above example uses the datcat attribute to reference a definition of part of speech. The reference taxonomy in this example is the CLARIN Concept Registry.If the feature structure markup exemplified above is to be repeated many times in a single document, it is much more efficient to gather the persistent identifiers in a single place and to only reference them, implicitly or directly, from feature structure markup. The following example is much more concise than the one above and relies on the concepts of feature structure declaration and feature value library, discussed in chapter [[undefined FS]].
The assumption here is that the relevant feature values are collected in a place that the annotation document in question has access to — preferably, a single document per linguistic resource, for example an <fsdDecl> that is XIncluded as a sibling of <text> or a child of <encodingDesc>; a <taxonomy> available resource-wide (e.g., in a shared header) is also an option.The example below presents an <fvLib> element that collects the relevant feature values (most of them omitted). At the same time, this example shows one way of encoding a tagset, i.e., an established inventory of values of (in the case at hand) morphosyntactic categories.
Note that these Guidelines do not prescribe a specific choice between datcat and valueDatcat in such cases. The former is the generic way of referencing a data category, whereas the latter is more specific, in that it references a data category that represents a value. The choice between them comes into play where a single element — or a tight element complex, such as the <f>/<symbol> complex illustrated above — make it necessary or useful to distinguish between the container data category and its value.
Example
In the context of dictionaries designed with semantic interoperability in mind, the following example ensures that the <pos> element is interpreted as the same information container as in the case of the example of <f name="POS"> above.
Efficiency of this type of interoperable markup demands that the references to the particular data categories should best be provided in a single place within the dictionary (or a single place within the project), rather than being repeated inside every entry. For the container elements, this can be achieved at the level of <tagUsage>, although here, the valueDatcat attribute should be used, because it is not the <tagUsage> element that is associated with the relevant data category, but rather the element <pos> (or <case>, etc.) that is described by <tagUsage>:
<tagsDecl partial="true"><!-- ... --><namespace name="http://www.tei-c.org/ns/1.0"><tagUsage gi="pos"
targetDatcat="http://hdl.handle.net/11459/CCR_C-396_5a972b93-2294-ab5c-a541-7c344c5f26c3">Contains the part of speech.</tagUsage><tagUsage gi="case"
targetDatcat="http://hdl.handle.net/11459/CCR_C-1840_9f4e319c-f233-6c90-9117-7270e215f039">Contains information about the grammatical case that the described form is inflected for.</tagUsage><!-- ... --></namespace></tagsDecl>
Another possibility is to shorten the URIs by means of the <prefixDef> mechanism, as illustrated below:
This mechanism creates implications that are not always wanted, among others, in the case at hand, suggesting that the identifiers ‘pos’ and ‘adj’ belong to a namespace associated with the CLARIN Concept Repository (CCR), whereas that is solely a shorthand mechanism whose scope is the current resource. Documenting this clearly in the header of the dictionary is therefore advised.Yet another possibility is to associate the information about the relationship between a TEI markup element and the data category that it is intended to model already at the level of modeling the dictionary resource, that is, at the level of the ODD, in <equiv> element that is a child of <elementSpec> or <attDef>.
Example
The targetDatcat attribute is designed to be used in, e.g., feature structure declarations, and is analogous to the targetLang attribute of the att.pointing class, in that it describes the object that is being referenced, rather than the referencing object.
Above, the <fDecl> uses targetDatcat, because if it were to use datcat, it would be asserting that it is an instance of the container data category part of speech, whereas it is not — it models a container (<f>) that encodes a part of speech. Note also that it is the <f> that is modeled above, not its values, which are used as direct references to data categories; hence the use of datcat in the <symbol> element.
Note
The TEI Abstract Model can be expressed as a hierarchy of attribute-value matrices (AVMs) of various types and of various levels of complexity, nested or grouped in various ways. At the most abstract level, an AVM consists of an information container and the value (contents) of that container.
A simple example of an XML serialization of such structures is, on the one hand, the opening and closing tags that delimit and name the container, and, on the other, the content enclosed by the two tags that constitues the value. An analogous example is an attribute name and the value of that attribute.
In a TEI XML example of two equivalent serializations expressing the name-value pair <part-of-speech,common-noun>, namely <pos>commonNoun</pos> and pos="common-noun", one would classify the element <pos> and the attribute pos as containers (mapping onto the first member of the relevant name-value pair), while the character data content of <pos> or the value of pos would be seen as mapping onto the second member of the pair.
The att.datcat class provides means of addressing the containers and their values, while at the same time providing a way to interpret them in the context of external taxonomies or ontologies. Aligning e.g. both the <pos> element and the pos attribute with the same value of an external reference point (i.e., an entry in an agreed taxonomy) affirms the identity of the concept serialised by both the element container and the attribute container, and optionally provides a definition of that concept (in the case at hand, the concept part of speech).
The value of the att.datcat attributes should be a PID (persistent identifier) that points to a specific — and, ideally, shared — taxonomy or ontology. Among the resources that can, to a lesser or greater extent, be used as inventories of (more or less) standardized linguistic categories are the GOLD ontology, CLARIN CCR, OLiA, or TermWeb's DatCatInfo, and also the Universal Dependencies inventory, on the assumption that its URIs are going to persist. It is imaginable that a project may choose to address a local taxonomy store instead, but this risks losing the advantage of interchangeability with other projects.
Historically, datcat and valueDatcat originate from the (the now obsolete) ISO 12620:2009 standard, describing the data model and procedures for a Data Category Registry (DCR). The current version of that standard, ISO 12620-1, does not standardize the serialization of pointers, merely mentioning the TEI att.datcat as an example.
Note that no constraint prevents the occurrence of a combination of att.datcat attributes: the <fDecl> element, which is a natural bearer of the targetDatcat attribute, is an instance of a specific modeling element, and, in principle, could be semantically fixed by an appropriate reference taxonomy of modeling devices.
Appendix A.3.13 att.declarable
att.declarableprovides attributes for those elements in the TEI header which may be independently selected by means of the special purpose decls attribute. [15.3. Associating Contextual Information with a Text]
This element is selected if its parent is selected
false
This element can only be selected explicitly, unless it is the only one of its kind, in which case it is selected if its parent is selected.[Default]
Note
The rules governing the association of declarable elements with individual parts of a TEI text are fully defined in chapter 15.3. Associating Contextual Information with a Text. Only one element of a particular type may have a default attribute with a value of true.
Appendix A.3.14 att.declaring
att.declaringprovides attributes for elements which may be independently associated with a particular declarable element within the header, thus overriding the inherited default for that element. [15.3. Associating Contextual Information with a Text]
(declarations) identifies one or more declarable elements within the header, which are understood to apply to the element bearing this attribute and its content.
This ‘superclass’ provides attributes that can be used to provide normalized values of temporal information. By default, the attributes from the att.duration.w3c class are provided. If the module for names & dates is loaded, this class also provides attributes from the att.duration.iso class. In general, the possible values of attributes restricted to the W3C datatypes form a subset of those values available via the ISO 8601 standard. However, the greater expressiveness of the ISO datatypes is rarely needed, and there exists much greater software support for the W3C datatypes.
If both when and dur or dur-iso are specified, the values should be interpreted as indicating a span of time by its starting time (or date) and duration. In order to represent a time range by a duration and its ending time the when-iso attribute must be used.
In providing a ‘regularized’ form, no claim is made that the form in the source text is incorrect; the regularized form is simply that chosen as the main form for purposes of unifying variant forms under a single heading.
If both when and dur are specified, the values should be interpreted as indicating a span of time by its starting time (or date) and duration. In order to represent a time range by a duration and its ending time the when-iso attribute must be used.
In providing a ‘regularized’ form, no claim is made that the form in the source text is incorrect; the regularized form is simply that chosen as the main form for purposes of unifying variant forms under a single heading.
The members of this attribute class are typically used to represent any kind of editorial intervention in a text, for example a correction or interpretation, or to date or localize manuscripts etc.
Each pointer on the source (if present) corresponding to a witness or witness group should reference a bibliographic citation such as a <witness>, <msDesc>, or <bibl> element, or another external bibliographic citation, documenting the source concerned.
Appendix A.3.22 att.edition
att.editionprovides attributes identifying the source edition from which some encoded feature derives.
(edition) supplies a sigil or other arbitrary identifier for the source edition in which the associated feature (for example, a page, column, or line break) occurs at this point in the text.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
edRef
(edition reference) provides a pointer to the source edition in which the associated feature (for example, a page, column, or line break) occurs at this point in the text.
<l>Of Mans First Disobedience,<lb ed="1674"/> and<lb ed="1667"/> the Fruit</l><l>Of that Forbidden Tree, whose<lb ed="1667 1674"/> mortal tast</l><l>Brought Death into the World,<lb ed="1667"/> and all<lb ed="1674"/> our woe,</l>
Example
<listBibl><bibl xml:id="stapledon1937"><author>Olaf Stapledon</author>,
<title>Starmaker</title>, <publisher>Methuen</publisher>, <date>1937</date></bibl><bibl xml:id="stapledon1968"><author>Olaf Stapledon</author>,
<title>Starmaker</title>, <publisher>Dover</publisher>, <date>1968</date></bibl></listBibl><!-- ... --><p>Looking into the future aeons from the supreme moment of
the cosmos, I saw the populations still with all their
strength maintaining the<pb n="411" edRef="#stapledon1968"/>essentials of their ancient culture,
still living their personal lives in zest and endless
novelty of action, … I saw myself still
preserving, though with increasing difficulty, my lucid
con-<pb n="291" edRef="#stapledon1937"/>sciousness;</p>
Appendix A.3.23 att.fragmentable
att.fragmentableprovides attributes for representing fragmentation of a structural element, typically as a consequence of some overlapping hierarchy.
specifies whether or not its parent element is fragmented in some way, typically by some other overlapping structure: for example a speech which is divided between two or more verse stanzas, a paragraph which is split across a page division, a verse line which is divided between two speakers.
The value of this attribute is always understood to be a single token, even if it contains space or other punctuation characters, and need not be composed of numbers only. It is typically used to specify the numbering of chapters, sections, list items, etc.; it may also be used in the specification of a standard reference system for the text.
xml:lang
(language) indicates the language of the element content using a ‘tag’ generated according to BCP 47.
<p> … The consequences of
this rapid depopulation were the loss of the last
<foreign xml:lang="rap">ariki</foreign> or chief
(Routledge 1920:205,210) and their connections to
ancestral territorial organization.</p>
Note
The xml:lang value will be inherited from the immediately enclosing element, or from its parent, and so on up the document hierarchy. It is generally good practice to specify xml:lang at the highest appropriate level, noticing that a different default may be needed for the <teiHeader> from that needed for the associated resource element or elements, and that a single TEI document may contain texts in many languages.
Only attributes with free text values (rare in these guidelines) will be in the scope of xml:lang.
The value used must conform with BCP 47. If the value is a private use code (i.e., starts with x- or contains -x-), a <language> element with a matching value for its ident attribute should be supplied in the TEI header to document this value. Such documentation may also optionally be supplied for non-private-use codes, though these must remain consistent with their (IETF)Internet Engineering Task Force definitions.
xml:base
provides a base URI reference with which applications can resolve relative URI references into absolute URI references.
<div type="bibl"><head>Selections from <title level="m">The Collected Letters of Robert Southey. Part 1: 1791-1797</title></head><listBibl xml:base="https://romantic-circles.org/sites/default/files/imported/editions/southey_letters/XML/"><bibl><ref target="letterEEd.26.3.xml"><title>Robert Southey to Grosvenor Charles Bedford</title>, <date when="1792-04-03">3 April 1792</date>.
</ref></bibl><bibl><ref target="letterEEd.26.57.xml"><title>Robert Southey to Anna Seward</title>, <date when="1793-09-18">18 September 1793</date>.
</ref></bibl><bibl><ref target="letterEEd.26.85.xml"><title>Robert Southey to Robert Lovell</title>, <date from="1794-04-05"
to="1794-04-06">5-6 April, 1794</date>.
</ref></bibl></listBibl></div>
xml:space
signals an intention about how white space should be managed by applications.
When multiple values are given, they may reflect either multiple divergent interpretations of an ambiguous text, or multiple mutually consistent interpretations of the same passage in different contexts.
Appendix A.3.26 att.global.change
att.global.changeprovides attributes allowing its member elements to specify one or more states or revision campaigns with which they are associated.
points to one or more <change> elements documenting a state or revision campaign to which the element bearing this attribute and its children have been assigned by the encoder.
att.global.facsprovides attributes used to express correspondence between an element and all or part of a facsimile image or surface. [11.1. Digital Facsimiles]
<group><text xml:id="t1-g1-t1"
xml:lang="mi"><body xml:id="t1-g1-t1-body1"><div type="chapter"><head>He Whakamaramatanga mo te Ture Hoko, Riihi hoki, i nga Whenua Maori, 1876.</head><p>…</p></div></body></text><text xml:id="t1-g1-t2"
xml:lang="en"><body xml:id="t1-g1-t2-body1"
corresp="#t1-g1-t1-body1"><div type="chapter"><head>An Act to regulate the Sale, Letting, and Disposal of Native Lands, 1876.</head><p>…</p></div></body></text></group>
In this example a <group> contains two <text>s, each containing the same document in a different language. The correspondence is indicated using corresp. The language is indicated using xml:lang, whose value is inherited; both the tag with the corresp and the tag pointed to by the corresp inherit the value from their immediate parent.
<!-- In a placeography called "places.xml" --><place xml:id="LOND1"
corresp="people.xml#LOND2 people.xml#GENI1"><placeName>London</placeName><desc>The city of London...</desc></place><!-- In a literary personography called "people.xml" --><person xml:id="LOND2"
corresp="places.xml#LOND1 #GENI1"><persName type="lit">London</persName><note><p>Allegorical character representing the city of <placeName ref="places.xml#LOND1">London</placeName>.</p></note></person><person xml:id="GENI1"
corresp="places.xml#LOND1 #LOND2"><persName type="lit">London’s Genius</persName><note><p>Personification of London’s genius. Appears as an
allegorical character in mayoral shows.
</p></note></person>
In this example, a <place> element containing information about the city of London is linked with two <person> elements in a literary personography. This correspondence represents a slightly looser relationship than the one in the preceding example; there is no sense in which an allegorical character could be substituted for the physical city, or vice versa, but there is obviously a correspondence between them.
synch
(synchronous) points to elements that are synchronous with the current element.
selects one or more alternants; if one alternant is selected, the ambiguity or uncertainty is marked as resolved. If more than one alternant is selected, the degree of ambiguity or uncertainty is marked as reduced by the number of alternants not selected.
(rendition) indicates how the element in question was rendered or presented in the source text.
Status
Optional
Datatype
1–∞ occurrences ofteidata.wordseparated by whitespace
<head rend="align(center) case(allcaps)"><lb/>To The <lb/>Duchesse <lb/>of <lb/>Newcastle,
<lb/>On Her <lb/><hi rend="case(mixed)">New Blazing-World</hi>.
</head>
Note
These Guidelines make no binding recommendations for the values of the rend attribute; the characteristics of visual presentation vary too much from text to text and the decision to record or ignore individual characteristics varies too much from project to project. Some potentially useful conventions are noted from time to time at appropriate points in the Guidelines. The values of the rend attribute are a set of sequence-indeterminate individual tokens separated by whitespace.
style
contains an expression in some formal style definition language which defines the rendering or presentation used for this element in the source text
<head style="text-align: center; font-variant: small-caps"><lb/>To The <lb/>Duchesse <lb/>of <lb/>Newcastle, <lb/>On Her
<lb/><hi style="font-variant: normal">New Blazing-World</hi>.
</head>
Note
Unlike the attribute values of rend, which uses whitespace as a separator, the style attribute may contain whitespace. This attribute is intended for recording inline stylistic information concerning the source, not any particular output.
The formal language in which values for this attribute are expressed may be specified using the <styleDefDecl> element in the TEI header.
If style and rendition are both present on an element, then style overrides or complements rendition. style should not be used in conjunction with rend, because the latter does not employ a formal style definition language.
rendition
points to a description of the rendering or presentation used for this element in the source text.
The rendition attribute is used in a very similar way to the class attribute defined for XHTML but with the important distinction that its function is to describe the appearance of the source text, not necessarily to determine how that text should be presented on screen or paper.
If rendition is used to refer to a style definition in a formal language like CSS, it is recommended that it not be used in conjunction with rend. Where both rendition and rend are supplied, the latter is understood to override or complement the former.
Each URI provided should indicate a <rendition> element defining the intended rendition in terms of some appropriate style language, as indicated by the scheme attribute.
To reduce the ambiguity of a resp pointing directly to a person or organization, we recommend that resp be used to point not to an agent (<person> or <org>) but to a <respStmt>, <author>, <editor> or similar element which clarifies the exact role played by the agent. Pointing to multiple <respStmt>s allows the encoder to specify clearly each of the roles played in part of a TEI file (creating, transcribing, encoding, editing, proofing etc.).
Example
Blessed are the
<choice><sic>cheesemakers</sic><corr resp="#editor" cert="high">peacemakers</corr></choice>: for they shall be called the children of God.
Example
<!-- in the <text> ... --><lg><!-- ... --><l>Punkes, Panders, baſe extortionizing
sla<choice><sic>n</sic><corr resp="#JENS1_transcriber">u</corr></choice>es,</l><!-- ... --></lg><!-- in the <teiHeader> ... --><!-- ... --><respStmt xml:id="JENS1_transcriber"><resp when="2014">Transcriber</resp><name>Janelle Jenstad</name></respStmt>
<sch:rule context="tei:*[@source]">
<sch:let name="srcs"
value="tokenize( normalize-space(@source),' ')"/>
<sch:report test="( self::tei:classRef | self::tei:dataRef | self::tei:elementRef |
self::tei:macroRef | self::tei:moduleRef | self::tei:schemaSpec )
and $srcs[2]"> When used on a schema description element (like
<sch:value-of select="name(.)"/>), the @source attribute
should have only 1 value. (This one has <sch:value-of select="count($srcs)"/>.)
</sch:report>
</sch:rule>
Note
The source attribute points to an external source. When used on an element describing a schema component (<classRef>, <dataRef>, <elementRef>, <macroRef>, <moduleRef>, or <schemaSpec>), it identifies the source from which declarations for the components should be obtained.
On other elements it provides a pointer to the bibliographical source from which a quotation or citation is drawn.
In either case, the location may be provided using any form of URI, for example an absolute URI, a relative URI, a private scheme URI of the form tei:x.y.z, where x.y.z indicates the version number, e.g. tei:4.3.2 for TEI P5 release 4.3.2 or (as a special case) tei:current for whatever is the latest release, or a private scheme URI that is expanded to an absolute URI as documented in a <prefixDef>.
When used on elements describing schema components, source should have only one value; when used on other elements multiple values are permitted.
Example
<p><!-- ... --> As Willard McCarty (<bibl xml:id="mcc_2012">2012, p.2</bibl>) tells us, <quote source="#mcc_2012">‘Collaboration’ is a problematic and should be a contested
term.</quote><!-- ... --></p>
Example
<p><!-- ... --><quote source="#chicago_15_ed">Grammatical theories are in flux, and the more we learn, the
less we seem to know.</quote><!-- ... --></p><!-- ... --><bibl xml:id="chicago_15_ed"><title level="m">The Chicago Manual of Style</title>,
<edition>15th edition</edition>. <pubPlace>Chicago</pubPlace>: <publisher>University of
Chicago Press</publisher> (<date>2003</date>), <biblScope unit="page">p.147</biblScope>.
</bibl>
Example
<elementRef key="p" source="tei:2.0.1"/>
Include in the schema an element named <p> available from the TEI P5 2.0.1 release.
Example
<schemaSpec ident="myODD"
source="mycompiledODD.xml"><!-- further declarations specifying the components required --></schemaSpec>
Create a schema using components taken from the file mycompiledODD.xml.
Appendix A.3.32 att.internetMedia
att.internetMediaprovides attributes for specifying the type of a computer resource using a standard taxonomy.
This attribute class provides an attribute for describing a computer resource, typically available over the internet, using a value taken from a standard taxonomy. At present only a single taxonomy is supported, the Multipurpose Internet Mail Extensions (MIME) Media Type system. This typology of media types is defined by the Internet Engineering Task Force in RFC 2046. The list of types is maintained by the Internet Assigned Numbers Authority (IANA). The mimeType attribute must have a value taken from this list.
If the milestone marks the beginning of a piece of text not present in the reference edition, the special value absent may be used as the value of unit. The normal interpretation is that the reference edition does not contain the text which follows, until the next <milestone> tag for the edition in question is encountered.
In addition to the values suggested, other terms may be appropriate (e.g. Stephanus for the Stephanus numbers in Plato).
The type attribute may be used to characterize the unit boundary in any respect other than simply identifying the type of unit, for example as word-breaking or not.
att.msExcerpt (manuscript excerpt) provides attributes used to describe excerpts from a manuscript placed in a description thereof. [10.6. Intellectual Content]
In the case of an incipit, indicates whether the incipit as given is defective, i.e. the first words of the text as preserved, as opposed to the first words of the work itself. In the case of an explicit, indicates whether the explicit as given is defective, i.e. the final words of the text as preserved, as opposed to what the closing words would have been had the text of the work been whole.
may be used to specify further information about the entity referenced by this name in the form of a set of whitespace-separated values, for example the occupation of a person, or the status of a place.
(reference to the canonical name) provides a means of locating the canonical form (nym) of the names associated with the object named by the element bearing it.
The value must point directly to one or more XML elements by means of one or more URIs, separated by whitespace. If more than one is supplied, the implication is that the name is associated with several distinct canonical names.
Appendix A.3.39 att.notated
att.notatedprovides attributes to indicate any specialised notation used for element content.
att.personal (attributes for components of names usually, but not necessarily, personal names) common attributes for those elements which form part of a name usually, but not necessarily, a personal name. [13.2.1. Personal Names]
to the right, e.g. to the right of a vertical line of text, or to the right of a figure
below
below the line
left
to the left, e.g. to the left of a vertical line of text, or to the left of a figure
end
at the end of e.g. chapter or volume.
inline
within the body of the text.
inspace
in a predefined space, for example left by an earlier scribe.
<add place="margin">[An addition written in the margin]</add><add place="bottom opposite">[An addition written at the
foot of the current page and also on the facing page]</add>
<sch:rule context="tei:*[not(self::tei:schemaSpec)][@targetLang]">
<sch:assert test="@target">@targetLang should only be used on <sch:name/> if @target is specified.</sch:assert>
</sch:rule>
In the example above, the <linkGrp> combines pointers at parallel fragments of the Universal Declaration of Human Rights: one of them is in Polish, the other in Swahili.
Note
The value must conform to BCP 47. If the value is a private use code (i.e., starts with x- or contains -x-), a <language> element with a matching value for its ident attribute should be supplied in the TEI header to document this value. Such documentation may also optionally be supplied for non-private-use codes, though these must remain consistent with their (IETF)Internet Engineering Task Force definitions.
target
specifies the destination of the reference by supplying one or more URI References
One or more syntactically valid URI references, separated by whitespace. Because whitespace is used to separate URIs, no whitespace is permitted inside a single URI. If a whitespace character is required in a URI, it should be escaped with the normal mechanism, e.g. TEI%20Consortium.
evaluate
(evaluate) specifies the intended meaning when the target of a pointer is itself a pointer.
if the element pointed to is itself a pointer, then the target of that pointer will be taken, and so on, until an element is found which is not a pointer.
one
if the element pointed to is itself a pointer, then its target (whether a pointer or not) is taken as the target of this pointer.
none
no further evaluation of targets is carried out beyond that needed to find the element specified in the pointer's target.
Note
If no value is given, the application program is responsible for deciding (possibly on the basis of user input) how far to trace a chain of pointers.
Appendix A.3.43 att.ranging
att.rangingprovides attributes for describing numerical ranges.
specifies the degree of statistical confidence (between zero and one) that a value falls within the range specified by min and max, or the proportion of observed values that fall within that range.
The MS. was lost in transmission by mail from <del rend="overstrike"><gap reason="illegible"
extent="one or two letters" atLeast="1" atMost="2" unit="chars"/></del> Philadelphia to the Graphic office, New York.
Example
Americares has been supporting the health sector in Eastern
Europe since 1986, and since 1992 has provided <measure atLeast="120000000" unit="USD"
commodity="currency">more than
$120m</measure> in aid to Ukrainians.
Appendix A.3.44 att.resourced
att.resourcedprovides attributes by which a resource (such as an externally held media file) may be located.
<sch:pattern>
<sch:rule context="tei:*[@url]">
<sch:assert test="not(matches(@url,'\s'))">ERROR: @url on element <sch:name/> should not have a space character.</sch:assert>
</sch:rule>
</sch:pattern>
Attribute values will often vary depending on the type of element to which they are attached. For example, a <cl>, may take values such as coordinate, subject, adverbial etc. For a <phr>, such values as subject, predicate etc. may be more appropriate. Such constraints will typically be implemented by a project-defined customization.
Appendix A.3.46 att.sortable
att.sortableprovides attributes for elements in lists or groups that are sortable, but whose sorting key cannot be derived mechanically from the element content. [9.1. Dictionary Body and Overall Structure]
David's other principal backer, Josiah
ha-Kohen <index indexName="NAMES"><term sortKey="Azarya_Josiah_Kohen">Josiah ha-Kohen b. Azarya</term></index> b. Azarya, son of one of the last gaons of Sura was David's own first
cousin.
Note
The sort key is used to determine the sequence and grouping of entries in an index. It provides a sequence of characters which, when sorted with the other values, will produced the desired order; specifics of sort key construction are application-dependent
Dictionary order often differs from the collation sequence of machine-readable character sets; in English-language dictionaries, an entry for 4-H will often appear alphabetized under ‘fourh’, and McCoy may be alphabetized under ‘maccoy’, while A1, A4, and A5 may all appear in numeric order ‘alphabetized’ between ‘a-’ and ‘AA’. The sort key is required if the orthography of the dictionary entry does not suffice to determine its location.
The @spanTo attribute must point to an element following the current element
<sch:rule context="tei:*[@spanTo]">
<sch:assert test="id(substring(@spanTo,2)) and following::*[@xml:id=substring(current()/@spanTo,2)]">The element indicated by @spanTo (<sch:value-of select="@spanTo"/>) must follow the current element <sch:name/>
</sch:assert>
</sch:rule>
Note
The span is defined as running in document order from the start of the content of the pointing element to the end of the content of the element pointed to by the spanTo attribute (if any). If no value is supplied for the attribute, the assumption is that the span is coextensive with the pointing element. If no content is present, the assumption is that the starting point of the span is immediately following the element itself.
When this attribute is specified on a row, its value is the default for all cells in this row. When specified on a cell, its value overrides any default specified by the role attribute of the parent <row> element.
rows
(rows) indicates the number of rows occupied by this cell or row.
A value greater than one indicates that this cell spans several rows. Where several cells span multiple rows, it may be more convenient to use nested tables.
cols
(columns) indicates the number of columns occupied by this cell or row.
A value greater than one indicates that this cell or row spans several columns. Where an initial cell spans an entire row, it may be better treated as a heading.
Appendix A.3.49 att.timed
att.timedprovides attributes common to those elements which have a duration in time, expressed either absolutely or by reference to an alignment map. [8.3.5. Temporal Information]
The versionDate attribute can be used to determine whether a translation might need to be revisited, by comparing the modification date on the containing file with the versionDate value on the translation. If the file has changed, changelogs can be checked to see whether the source text has been modified since the translation was made.
<div type="verse"><head>Night in Tarras</head><lg type="stanza"><l>At evening tramping on the hot white road</l><l>…</l></lg><lg type="stanza"><l>A wind sprang up from nowhere as the sky</l><l>…</l></lg></div>
Note
The type attribute is present on a number of elements, not all of which are members of att.typed, usually because these elements restrict the possible values for the attribute in a specific way.
subtype
(subtype) provides a sub-categorization of the element, if needed
The subtype attribute may be used to provide any sub-classification for the element additional to that provided by its type attribute.
Schematron
<sch:rule context="tei:*[@subtype]">
<sch:assert test="@type">The <sch:name/> element should not be categorized in detail with @subtype unless also categorized in general with @type</sch:assert>
</sch:rule>
Note
When appropriate, values from an established typology should be used. Alternatively a typology may be defined in the associated TEI header. If values are to be taken from a project-specific list, this should be defined using the <valList> element in the project-specific schema description, as described in 23.3.1.3. Modification of Attribute and Attribute Value Lists .
Appendix A.3.52 att.written
att.writtenprovides attributes to indicate the hand in which the content of an element was written in the source being transcribed. [1.3.1. Attribute Classes]
macro.limitedContent (paragraph content) defines the content of prose elements that are not used for transcription of extant materials. [1.3. The TEI Class System]
macro.phraseSeq.limited (limited phrase sequence) defines a sequence of character data and those phrase-level elements that are not typically used for transcribing extant documents. [1.4.1. Standard Content Models]
macro.specialPara ('special' paragraph content) defines the content model of elements such as notes or list items, which either contain a series of component-level elements or else have the same structure as a paragraph, containing a series of phrase-level and inter-level elements. [1.3. The TEI Class System]
Certainty may be expressed by one of the predefined symbolic values high, medium, or low. The value unknown should be used in cases where the encoder does not wish to assert an opinion about the matter.
Appendix A.5.2 teidata.count
teidata.countdefines the range of attribute values used for a non-negative integer value used as a count.
<time dur-iso="PT0,75H">three-quarters of an hour</time>
Example
<date dur-iso="P1,5D">a day and a half</date>
Example
<date dur-iso="P14D">a fortnight</date>
Example
<time dur-iso="PT0.02S">20 ms</time>
Note
A duration is expressed as a sequence of number-letter pairs, preceded by the letter P; the letter gives the unit and may be Y (year), M (month), D (day), H (hour), M (minute), or S (second), in that order. The numbers are all unsigned integers, except for the last, which may have a decimal component (using either . or , as the decimal point; the latter is preferred). If any number is 0, then that number-letter pair may be omitted. If any of the H (hour), M (minute), or S (second) number-letter pairs are present, then the separator T must precede the first ‘time’ number-letter pair.
For complete details, see ISO 8601 Data elements and interchange formats — Information interchange — Representation of dates and times.
Appendix A.5.4 teidata.duration.w3c
teidata.duration.w3cdefines the range of attribute values available for representation of a duration in time using W3C datatypes.
A duration is expressed as a sequence of number-letter pairs, preceded by the letter P; the letter gives the unit and may be Y (year), M (month), D (day), H (hour), M (minute), or S (second), in that order. The numbers are all unsigned integers, except for the S number, which may have a decimal component (using . as the decimal point). If any number is 0, then that number-letter pair may be omitted. If any of the H (hour), M (minute), or S (second) number-letter pairs are present, then the separator T must precede the first ‘time’ number-letter pair.
Attributes using this datatype must contain a single ‘word’ which contains only letters, digits, punctuation characters, or symbols: thus it cannot include whitespace.
Typically, the list of documented possibilities will be provided (or exemplified) by a value list in the associated attribute specification, expressed with a <valList> element.
Appendix A.5.6 teidata.gender
teidata.genderdefines the range of attribute values used to represent the gender of a person, persona, or character.
Any value greater than zero or any one of the values regular, irregular, unknown.
Appendix A.5.8 teidata.language
teidata.languagedefines the range of attribute values used to identify a particular combination of human language and writing system. [6.1. Language Identification]
The values for this attribute are language ‘tags’ as defined in BCP 47. Currently BCP 47 comprises RFC 5646 and RFC 4647; over time, other IETF documents may succeed these as the best current practice.
A ‘language tag’, per BCP 47, is assembled from a sequence of components or subtags separated by the hyphen character (-, U+002D). The tag is made of the following subtags, in the following order. Every subtag except the first is optional. If present, each occurs only once, except the fourth and fifth components (variant and extension), which are repeatable.
language
The IANA-registered code for the language. This is almost always the same as the ISO 639 2-letter language code if there is one. The list of available registered language subtags can be found at http://www.iana.org/assignments/language-subtag-registry. It is recommended that this code be written in lower case.
script
The ISO 15924 code for the script. These codes consist of 4 letters, and it is recommended they be written with an initial capital, the other three letters in lower case. The canonical list of codes is maintained by the Unicode Consortium, and is available at http://unicode.org/iso15924/iso15924-codes.html. The IETF recommends this code be omitted unless it is necessary to make a distinction you need.
region
Either an ISO 3166 country code or a UN M.49 region code that is registered with IANA (not all such codes are registered, e.g. UN codes for economic groupings or codes for countries for which there is already an ISO 3166 2-letter code are not registered). The former consist of 2 letters, and it is recommended they be written in upper case; the list of codes can be searched or browsed at https://www.iso.org/obp/ui/#search/code/. The latter consist of 3 digits; the list of codes can be found at http://unstats.un.org/unsd/methods/m49/m49.htm.
variant
An IANA-registered variation. These codes ‘are used to indicate additional, well-recognized variations that define a language or its dialects that are not covered by other available subtags’.
extension
An extension has the format of a single letter followed by a hyphen followed by additional subtags. These exist to allow for future extension to BCP 47, but as of this writing no such extensions are in use.
private use
An extension that uses the initial subtag of the single letter x (i.e., starts with x-) has no meaning except as negotiated among the parties involved. These should be used with great care, since they interfere with the interoperability that use of RFC 4646 is intended to promote. In order for a document that makes use of these subtags to be TEI-conformant, a corresponding <language> element must be present in the TEI header.
There are two exceptions to the above format. First, there are language tags in the IANA registry that do not match the above syntax, but are present because they have been ‘grandfathered’ from previous specifications.
Second, an entire language tag can consist of only a private use subtag. These tags start with x-, and do not need to follow any further rules established by the IETF and endorsed by these Guidelines. Like all language tags that make use of private use subtags, the language in question must be documented in a corresponding <language> element in the TEI header.
Examples include
sn
Shona
zh-TW
Taiwanese
zh-Hant-HK
Chinese written in traditional script as used in Hong Kong
Attributes using this datatype must contain a single word which follows the rules defining a legal XML name (see https://www.w3.org/TR/REC-xml/#dt-name): for example they cannot include whitespace or begin with digits.
Appendix A.5.10 teidata.namespace
teidata.namespacedefines the range of attribute values used to indicate XML namespaces as defined by the W3C Namespaces in XML Technical Recommendation.
Any numeric value, represented as a decimal number, in floating point format, or as a ratio.
To represent a floating point number, expressed in scientific notation, ‘E notation’, a variant of ‘exponential notation’, may be used. In this format, the value is expressed as two numbers separated by the letter E. The first number, the significand (sometimes called the mantissa) is given in decimal format, while the second is an integer. The value is obtained by multiplying the mantissa by 10 the number of times indicated by the integer. Thus the value represented in decimal notation as 1000.0 might be represented in scientific notation as 10E3.
A value expressed as a ratio is represented by two integer values separated by a solidus (/) character. Thus, the value represented in decimal notation as 0.5 might be represented as a ratio by the string 1/2.
Appendix A.5.12 teidata.outputMeasurement
teidata.outputMeasurementdefines a range of values for use in specifying the size of an object that is intended for display.
<figure><head>The TEI Logo</head><figDesc>Stylized yellow angle brackets with the letters <mentioned>TEI</mentioned> in
between and <mentioned>text encoding initiative</mentioned> underneath, all on a white
background.</figDesc><graphic height="600px" width="600px"
url="http://www.tei-c.org/logos/TEI-600.jpg"/></figure>
Note
These values map directly onto the values used by XSL-FO and CSS. For definitions of the units see those specifications; at the time of this writing the most complete list is in the CSS3 working draft.
Appendix A.5.13 teidata.pattern
teidata.patterndefines attribute values which are expressed as a regular expression.
A regular expression, often called a pattern, is an expression that describes a set of strings. They are usually used to give a concise description of a set, without having to list all elements. For example, the set containing the three strings Handel, Händel, and Haendel can be described by the pattern H(ä|ae?)ndel (or alternatively, it is said that the pattern H(ä|ae?)ndelmatches each of the three strings)
This TEI datatype is mapped to the XSD token datatype, and may therefore contain any string of characters. However, it is recommended that the value used conform to the particular flavour of regular expression syntax supported by XSD Schema.
Appendix A.5.14 teidata.point
teidata.pointdefines the data type used to express a point in cartesian space.
A point is defined by two numeric values, which should be expressed as decimal numbers. Neither number can end in a decimal point. E.g., both 0.0,84.2 and 0,84 are allowed, but 0.,84. is not.
Appendix A.5.15 teidata.pointer
teidata.pointerdefines the range of attribute values used to provide a single URI, absolute or relative, pointing to some other resource, either within the current document or elsewhere.
The range of syntactically valid values is defined by RFC 3986Uniform Resource Identifier (URI): Generic Syntax. Note that the values themselves are encoded using RFC 3987Internationalized Resource Identifiers (IRIs) mapping to URIs. For example, https://secure.wikimedia.org/wikipedia/en/wiki/% is encoded as https://secure.wikimedia.org/wikipedia/en/wiki/%25 while http://موقع.وزارة-الاتصالات.مصر/ is encoded as http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/
Appendix A.5.16 teidata.probCert
teidata.probCertdefines a range of attribute values which can be expressed either as a numeric probability or as a coded certainty value.
Values for attributes using this datatype may be defined locally by a project, or they may refer to an external standard.
Appendix A.5.20 teidata.temporal.iso
teidata.temporal.isodefines the range of attribute values expressing a temporal expression such as a date, a time, or a combination of them, that conform to the international standard Data elements and interchange formats – Information interchange – Representation of dates and times.
If it is likely that the value used is to be compared with another, then a time zone indicator should always be included, and only the dateTime representation should be used.
For all representations for which ISO 8601:2004 describes both a basic and an extended format, these Guidelines recommend use of the extended format.
Appendix A.5.21 teidata.temporal.w3c
teidata.temporal.w3cdefines the range of attribute values expressing a temporal expression such as a date, a time, or a combination of them, that conform to the W3C XML Schema Part 2: Datatypes Second Edition specification.
If it is likely that the value used is to be compared with another, then a time zone indicator should always be included, and only the dateTime representation should be used.
Appendix A.5.22 teidata.temporal.working
teidata.temporal.workingdefines the range of values, conforming to the W3C XML Schema Part 2: Datatypes Second Edition specification, expressing a date or a date and a time within the working life of the document.
If it is likely that the value used is to be compared with another, then a time zone indicator should always be included, and only the dateTime representation should be used.
The earliest time expressable with this datatype is 01 January 1970 (the Unix Epoch), which could be written as either 1970-01-01 or 1970-01-01T00:00:00Z.
Appendix A.5.23 teidata.text
teidata.textdefines the range of attribute values used to express some kind of identifying string as a single sequence of Unicode characters possibly including whitespace.
The possible values of this datatype are 1 or true, or 0 or false.
This datatype applies only for cases where uncertainty is inappropriate; if the attribute concerned may have a value other than true or false, e.g. unknown, or inapplicable, it should have the extended version of this datatype: teidata.xTruthValue.
Appendix A.5.25 teidata.unboundedCount
teidata.unboundedCountdefines the range of values used for a counting number or the string unbounded for infinity.
The value of this attribute follows the pattern specified by the Unicode consortium for its version number (http://unicode.org/versions/). A version number contains digits and fullstop characters only. The first number supplied identifies the major version number. A second and third number, for minor and sub-minor version numbers, may also be supplied.
Appendix A.5.27 teidata.versionNumber
teidata.versionNumberdefines the range of attribute values used for version numbers.
Attributes using this datatype must contain a single ‘word’ which contains only letters, digits, punctuation characters, or symbols: thus it cannot include whitespace.
Appendix A.5.29 teidata.xTruthValue
teidata.xTruthValue (extended truth value) defines the range of attribute values used to express a truth value which may be unknown.
Any XPath expression using the syntax defined in 6.2..
When writing programs that evaluate XPath expressions, programmers should be mindful of the possibility of malicious code injection attacks. For further information about XPath injection attacks, see the article at OWASP.
Appendix A.6 Constraints
Schematron
All @xml:ids at the root of any document must match the document filename.
<sch:pattern>
<sch:rule context="/tei:TEI | /tei:item[not(ancestor::tei:*)]">
<sch:assert test="@xml:id and matches($docUri,concat('[/\\]', $docId,'\.xm[l_]$'))">ERROR: Document xml:id (<sch:value-of select="$docId"/>) must match the document file name (<sch:value-of select="$docUri"/>).</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
All local pointers must be resolvable.
<sch:pattern>
<sch:rule context="tei:*[@*[matches(.,'(^|\s+)#')]]">
<sch:let name="localRefs"
value="for $a in @*[matches(.,'(^|\s+)#')] return tokenize($a,'\s+')[starts-with(.,'#')]"/>
<sch:let name="errors"
value="for $r in $localRefs return if ($docIds = substring-after($r,'#'))
then () else $r"/>
<sch:assert test="empty($errors)">ERROR: Bad pointer(s): <sch:value-of select="string-join($errors,', ')"/>
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
No linking elements inside other linking elements.
<sch:pattern>
<sch:rule context="tei:placeName[not(parent::tei:place)][@ref] | tei:orgName[not(parent::tei:org)][@ref]
| tei:persName[not(parent::tei:person)][@ref] | tei:ref">
<sch:assert role="error"
test="not(descendant::tei:*[local-name()=('placeName','persName','orgName')][@ref]
or tei:ref)">A persName, placeName, orgName with an @ref or a ref element cannot have a child that is also a linking element.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Objects should only be on terminal nodes.
<sch:rule context="tei:item[tei:list]/tei:listObject">
<sch:assert test="not(../tei:list/descendant::tei:listObject)">ERROR: items that have descendant objects cannot have a child object.</sch:assert>
</sch:rule>
Schematron
Objects should have at most 1 URI
<sch:rule context="tei:objectIdentifier">
<sch:assert test="count(tei:idno[@type='URI']) lt 2">ERROR: Objects should only point to a single URI</sch:assert>
</sch:rule>
Schematron
All object elements must have an id.
<sch:pattern>
<sch:rule context="tei:object">
<sch:assert role="error" test="@xml:id">ERROR: object element must have a @xml:id.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
All person, orgs, and places in an ography file must have an id.
<sch:pattern>
<sch:rule context="tei:body/tei:listPerson/tei:person | tei:body/tei:listOrg/tei:org
| tei:body/tei:listPlace/tei:place">
<sch:let name="isOgraphy"
value="matches($docId,'ography(_[a-z])?$')"/>
<sch:assert test="if ($isOgraphy) then (matches(@xml:id,'^[a-z]{4}\d+')) else true()">ERROR: All ography content (person, org, place) must have an @xml:id that is 4 lowercase letters and a digit.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
These are global variables that can be used throughout the schematron constraints.
All xml:lang attributes must be one of a sepcified set of values
<sch:pattern>
<sch:rule context="tei:*[@xml:lang]">
<sch:assert test="@xml:lang = ('en', 'ja-Latn', 'ja')">ERROR: All xml:langs must be either en, ja-Latn, or ja</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:rule context="tei:TEI[starts-with(@xml:id, 'monument_')]/descendant::tei:residence[@type='original']">
<sch:assert role="error"
test="not(matches(., ',?\s+B\.?C\.?\s*$'))"> ERROR: Do not include ", BC" in any original residence.
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:rule context="tei:person[child::tei:idno[@type='custodian']]">
<sch:assert role="error"
test="descendant-or-self::*[@source]">ERROR: a person with a custodian id MUST have a @source attribute, or a descendant element with a @source attribute.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:rule context="tei:listRelation/tei:relation">
<sch:let name="persId"
value="ancestor::tei:person/@xml:id"/>
<sch:assert role="error"
test="@passive = 'prs:' || $persId"> ERROR: the @passive attribute of a relation element should point
to the id of the person element which contains it:
<sch:value-of select="'prs:' || $persId"/>
</sch:assert>
<sch:assert role="error"
test="not(@active = @passive)"> ERROR: A same person pointer cannot appear in both @active and @passive.
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:pattern>
<sch:let name="apos" value="''''"/>
<sch:rule context="tei:person/tei:residence | tei:person/tei:note/tei:p">
<sch:assert role="error"
test="not(contains(., $apos))">ERROR: do not use straight apostrophes. Use the curly apostrophe ʼ instead.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
<sch:rule context="tei:surname">
<sch:assert test="not(normalize-space(.) = '')"> ERROR: Surnames may not be blank or empty.
</sch:assert>
</sch:rule>
Schematron
<sch:pattern>
<sch:rule context="tei:person[not(@corresp) and (not(@xml:id) or not(matches(@xml:id,
'^(m_)?[a-z]{4,4}(\d+)?$')))]">
<sch:assert test="@xml:id and matches(@xml:id, '^(m_)?[a-z]{4,4}\d+$')"> ERROR: person elements must have a unique xml:id. If you are creating a
new record for the Monument project (not appearing in LOI), please type
m_ plus the first four letters of the id you need, and the next available
id will be shown.
</sch:assert>
</sch:rule>
<sch:rule context="tei:person[matches(@xml:id, '^m_[a-z]{4,4}$')]">
<sch:let name="letters"
value="xs:string(@xml:id)"/>
<sch:let name="maxId"
value="max((0, for $i in //tei:person[@xml:id][matches(xs:string(@xml:id),
'^' || $letters || '\d+$')]/@xml:id return xs:integer(substring($i,
7))))"/>
<sch:let name="nextId"
value="$letters || xs:string($maxId + 1)"/>
<sch:assert test="not(matches(@xml:id, '^m_[a-z]{4,4}$'))"> NOTE: <sch:value-of select="$nextId"/> is the next available id for the letter prefix <sch:value-of select="$letters"/>.
</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Dating elements in Oral Histories should have dating attributes
<sch:pattern>
<sch:rule context="tei:body[$docTypes[contains(@target,'OralHistory')]]">
<sch:assert test="tei:annotationBlock | tei:timeline | tei:div[count(child::tei:*) =
1]/tei:gap">ERROR: The body of oral history documents should either be timeline and annotationBlock (if it has a transcription) or a div with a gap element if there is no transcription available yet.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Dating elements in Oral Histories should have dating attributes
<sch:pattern>
<sch:rule context="tei:date[ancestor::tei:teiHeader][$docTypes[contains(@target,'OralHistory')]]">
<sch:assert test="@when or @notBefore or @notAfter or @to or @from">ERROR: Date elements in oral history metadata must have dating attributes (one or more of @when, @to, @from, @notBefore, @notAfter).</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Rules to ban literal quotation marks, square brackets, and literal ellipses from utterances
<sch:pattern>
<sch:rule context="tei:*[text()][ancestor-or-self::tei:u]">
<sch:let name="errors"
value="for $t in text() return if (matches($t,'\[|\]')) then $t else ()"/>
<sch:assert test="empty($errors)">ERROR: No square brackets.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Rules to ban literal quotation marks, square brackets, and literal ellipses from utterances
<sch:pattern>
<sch:rule context="tei:*[text()][ancestor-or-self::tei:u]">
<sch:let name="errors"
value="for $t in text() return if (matches($t,'…')) then $t else ()"/>
<sch:assert test="empty($errors)">ERROR: No literal ellipsis characters allowed in transcription.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Rules to ban literal quotation marks, square brackets, and literal ellipses from utterances
<sch:pattern>
<sch:rule context="tei:*[text()][ancestor-or-self::tei:u]">
<sch:let name="errors"
value="for $t in text() return if (matches($t, '“|”|"')) then $t else ()"/>
<sch:assert role="error"
test="empty($errors)">ERROR: No double quotes inside a u tag.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Next/Prev doc pointers should only exist in oral histories.
<sch:pattern>
<sch:rule context="tei:text[@next or @prev]">
<sch:assert test="$docTypes[contains(@target,'OralHistory')]">ERROR: Only oral histories should specify @next/@prev pointers on text elements.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
next/prev pointers should be single valued and only point to docs.
<sch:pattern>
<sch:rule context="tei:text[@next or @prev]">
<sch:let name="atts"
value="(@next, @prev)"/>
<sch:assert test="every $att in $atts satisfies matches($att,'^doc:oral_history_[^\s]+$')">ERROR: next/prev pointers should point to a single oral history
with the doc prefix.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Elements in the spoken module should only be used in Oral History documents.
<sch:pattern>
<sch:rule context="tei:annotationBlock | tei:equipment | tei:incident | tei:recording
| tei:recordingStmt | tei:u">
<sch:assert test="$docTypes[contains(@target,'OralHistory')]">ERROR: Element <sch:name/> not allowed here. <sch:name/> should only be used in Oral History documents.</sch:assert>
</sch:rule>
</sch:pattern>
Schematron
Oral histories should not contain information about its parts in the title.
<sch:pattern>
<sch:rule context="tei:titleStmt/tei:title[$docTypes[contains(@target,'OralHistory')]]">
<sch:assert test="not(matches(string(.), '\(\s*\d+\s*|\s*\d+\s*\)'))">ERROR: Do not put part information e.g. "(1 of 2)" in the title of an oral history. Use @nex/@prev to properly put the documents in sequence.</sch:assert>
</sch:rule>
</sch:pattern>
Note: Windows uses "\", Mac and Linux use, "/".
products/diagnostics.html
products/ids.html
Transcription
Note: You can snap a window by clicking its title bar and dragging it to the edge of a screen and holding it, letting go after the blue snap-preview animation appears. Drag and hold to the top of a screen to make the window full screen. Drag and hold to either the right or left side of a screen to make a window half screen (vertically).
From this first page, we can note in our text document the starting page of the file (“0952 - ”), the case file number (“01630”), and the reel number (“C-9322”).Note: Confirm that this initial handwritten case file number matches those listed on the documents following it.
From the first page of this form, we can note the file person’s name (“nogami-sankichi”) and their sex (“1”), which we can use to assume which pronoun template to use.Note: The version of this initial Office of the Custodian form may vary from file to file depending on the age of the file person and how much property they owned. The one in the example above is the longer three-page form; you may also see a one-page form instead. 
Note: Some file pages will be incorrectly oriented. As you work through a file, make note of which page numbers need to be rotated in your Metadata Notes document. See pdf Making.
Note: For copy and pasting, the Terminal only accepts right clicking (not ctrl commands).
oral_history_barn23_2019-02-28.xml 
