The REED London project team has developed a set of encoding guidelines and principles that form our methodology when working through the many records in our collections. It is important to track the encoding work we do because it has evolved over many years, and the process is an iterative one, leading to ever more questions and opportunities to capture information through tagging.

REED London relies on the TEI Consortium Guidelines from which we have developed a custom schema to support our research-centric encoding.

REED London's editorial intent is complicated by the fact that we are remediating the editorial work undertaken by editors before us who consulted the archival documents in situ, then decided which excerpts applied to their editorial mandate, and then transcribed those excerpts so as to be replicable in printed form. We have now further interpreted that work so as to make it navigable in a screen environment. We regret any errors in transforming and formatting that information.

Our encoding is both structural and semantic, describing the transcribed texts as well as the information within them. Not all of the tagging is viewable in the LEAF-Writer reading mode (e.g., tags that indicate expansions, or in which margin a note was placed, are documented in the TEI code but not visible by default).

If you are interested in considering or adopting our structural encoding approach you can see our template here. 

A word about terminology: we refer to a 'document' as being the source material from which the records are excerpted. Because the original editors distinguished these documents by year-range, we have continued that practice. For example, a document could be "Baker's Company Court Minutes 1560-1." However, a letter or diary entry would also be considered a document, such as "Letter of John Chamberlain to Mistress Alice Carleton, February 18, 1612/13." Within that document is a 'record-set' -- which refers to the gathering of all excerpted information within a document. Within a record-set are a series of 'records' -- the discrete excerpts that apply to a dated entry, focused financial transaction, or the like. Records refer to performance or performance business events.

Below you will find our decisions about how to tag and manage entities. This is a living document and so expect that these decisions will continue to evolve over time. We will endeavour to indicate when a new decision is added.

Diane K. Jakacki & Rachel Milio

July 2, 2024

 

People

Tag the first time a person’s name appears in each record; therefore, a person who is named multiple times in a record-set should be tagged once in each of the records within the set.

Names are tagged whether they are explicit or implicit (e.g., by honorific); also if they are tagged by just first or last name.

Everyone who is named in a record that we can disambiguate with a high degree of certainty gets a CWRC/RLO entity URI. These identifiers are resolved against existing authorities (e.g., Wikidata, VIAF); where possible, they are also cross-walked with the Map of Early Modern London. Anyone who has/had an existing REED identifier is also cross-walked.

For people we discover who do not yet have a CWRC URI, continue the process as has been established.

Person Occupations

A person may have one or more occupations, but this information aligns with understanding of their life, rather than what they are doing in a particular record. Therefore, this information should be attached to the entity, and not included as an attribute in the persName tag.

Person Roles

A person is involved in the ‘event’ described in a record in a particular way; therefore we capture that involvement as a @role within a persName tag

Person Affiliations

A person is connected to one or more organizations – sometimes explicitly referred to within a record. However, we will attach this information to the entity rather than the record.

Where a person is listed as being affiliated with an organization, and the organization is important in the context of the record, they are tagged as discrete, e.g.:

<persName>Phylyp Gunter</persName> <orgName>skinner</orgName>

We currently don’t have a way to capture familial relationships (e.g., parents, children, spouses, etc.). This information should be captured in a footnote as well as any extra information that is contextual (e.g., a short essay about an event and the people who participated).

 

Person Birth, Death, Floruit Dates

These are captured in the entity form, and should not be included as attributes in the persName tag.

Places

Tag first time a place name appears in each record; therefore, a place that is named multiple times in a ‘record set’ would be tagged once in each of the records within the set.

Places are tagged whether they are explicit or implicit (e.g., ‘the bridge’, ‘the City’)

Every place that is named in a record that we can disambiguate with a high degree of certainty gets a CWRC/RLO entity URI. These identifiers are resolved against existing authorities (e.g., Wikidata); where possible, they are also cross-walked with MoEML (MoEML has already added some of our place entities to their list). Places with an existing REED identifier are also cross-walked.

Places beyond (greater) London are not given a RLO/CWRC entity (e.g., York, Exeter). Places beyond London should be tagged with a Wikidata or Geonames URI.

Place Types

Using the LINCS vocabulary terms; add to the placeName tag as a @type attribute.

 

Place Roles

A place is involved in the ‘event’ described in a record in a particular way; therefore we capture that involvement as a @role within a placeName tag

Organizations

Every organization that is identified in a record (or the document source for the record) that we can disambiguate with a high degree of certainty gets a CWRC/RLO entity URI. These identifiers are resolved against existing authorities (e.g., Wikidata)

  • we don’t currently capture parishes or wards as organizations (although we do capture officers of those organizations as having affiliations)
  • we don’t currently capture @role for organizations … we assume that these have a performance related role because they have been gathered for REED.

Objects

We have not to date captured objects in any intentional way. Going forward we will capture objects connected to performance (e.g., costumes, properties, musical instruments, ‘sets’)

Objects are tagged each time they are mentioned in a record because there might be multiple references to different instances of object within the same record

We will not capture objects that are not related to performance.

 

Costs/payments/fines/quantities

Use the measure tag for prices and units. There is value in capturing the amount of a thing (cost, number), but not in providing a larger argument for how that amount has value. If some other researcher wants to use our records to do that research they are welcome to do so, with our deepest encouragement.