LEMDO

Following up after 2020-06-15 mtg with MH and RM about design:

I've changed my way of thinking a bit about the LEMDO anthology.
I think we need five Jenkins builds:

1. lemdo-dev on Jenkins where we can see everything, regardless of status (roughest of rough drafts all the way to done).
2. A lemdo anthology on Jenkins where we can see what we are going to push to the public site (lemdo.uvic.ca).
3. And the three anthologies on Jenkins: DRE, QME, ISE

Then we push LEMDO, DRE, QME, and ISE to lemdo.uvic.ca, lemdo.uvic.ca/dre, lemdo.uvic.ca/qme, and lemdo.uvic.ca/ise (unless we can secure dre.uvic.ca, qme.uvic.ca, or ise.uvic.ca for these projects).

I have an idea for the menus for LEMDO-dev. I think it should have all the menus for the live site + a menu for "Drafts". Basically, we can publish everything but the stuff under that menu (which will be governed by docTypes).

Other possible top-level menu items are:
About Anthologies All Texts How To Documentation

After the team mtg, met with MH, TEH, and JJ and came up with a plan for encoding the QME performances. Since performances must be understood as equal to the text (and textual artifacts), we are encoding the performances using a `<facsimile>` element, with `<surface>`s representing individual scenes; these surfaces will then be keyed to a timeline, at which divs can point using `@corresp`.

I'm going to test out this method with FV and report back.

After reading through Hinman to determine how TLNs are actually counted, JJ and I realized that we should be using the terminology turnover and turnunder for what we've called hungwords in the past; this is a more granular way of describing where precisely these things exist in relation to the preceding/following lines. To encode these, we will use:


<seg type="turnover|turnunder">(word</seg>


The last thing to figure out is how we should encode the bracket that usually precedes the turned word; we may want to regularize these at some future point so we might decide to tag the preceding bracket with a pc element so that we remove it from indexers et cetera.

Met with JJ to discuss glyph encoding and came up with a fairly robust course of action for encoding. While most glyphs are fairly simple (long S) there are instances of combining characters (y + (e|u|t) above) and we assume there will be similarly difficult glyphs.

We divided the problem into four parts:

1. How to encode in the charDecl

   • JT will discuss with MH and SA about the best strategy, based off of some of the work MH + SA have done for LOI.

2. How to encode in the text itself (i.e. what should the @xml:id of the glyph be)

   • We think yUAbove, yTAbove et cetera would suffice and is easily readable by encoders etc

3. What to put in the glyph tag

   • There are a few options: 1) Nothing; 2) the literal character [which is what we've been doing so far, but may not suffice for characters in future]; 3) a normalized version of the string (i.e. yu); 4) A regularized version of what the character represents (thou).
   • JJ and JT think (4) is the best approach as it will help for future searching and indexing; it is basically a short form of using choice and friends.

4. How to process and render:

   • This will come later, but basically, if we decide to use a regularized string, we can either replace the string with its regularized format (or make that an option) or display the character as best we can with the full-featured font that we use.

To do: JT will discuss some of the various encoding solutions with MH and SA; once decisions are made, JT will implement.

Fall 2019 LEMDO Project Plan

Team: RAs at UVic (Ashley Howard, Kate LeBere, Chris Horne); RA at UNR (Sarah Johnson); Programmer (Joey Takeda); Director (Janelle Jenstad)

Project Title: Remediation and Documentation

Outcomes

1. Some ISE editions will be fully remediated and available on LEMDO (by RAs).
2. One DRE edition will be fully remediated and available on LEMDO (by JJ).
3. One QME edition will be fully remediated and available on LEMDO so that we can resolve performance notes encoding and video embedding for the LEMDO platform (by JT). 

Objectives

1. Clean up six editions.
2. Clean up the metadata for all the files in those five editions.
3. Get the digital surrogates for those five editions (and metadata for the digital surrogates) into UVic ContentDM.
4. Republish those six editions on LEMDO.
5. Finish the documentation for all the parts of the edition.

Deliverables

See Asana LEMDO-Tech space for details.

Tasks

See Asana LEMDO-Tech space for details.

Texts

1. JJ does 1HW
2. JT does FV
3. AH does AYL
4. CH does H5
5. KLB does Oth
6. SJ does TBA

Process

1. We all remediate one or more OS texts. Pick a facsimile from the ones available, document the choice in the metadata, and make sure the Library adds each one to ContentDM.
2. JJ and AH finish the documentation for OS texts.
3. We all remediate one or more M texts.
4. JJ and AH finish the documentation for M texts.
5. We all remediate an annotation file.
6. JJ, AH, and JT finish the documentation for annotations.
7. We all remediate a collation file.
8. JJ, AH, and JT finish the documentation for collations.
9. We all remediate one or more critical paratext files (secondary). This task will entail cleaning up bibliographies and adding entries to BIBL1.
10. JJ, AH, and JT finish the documentation for critical paratexts.
11. We all remediate one or more supplementary texts (hybrid primary/secondary).
12. JJ, AH, and JT finish the documentation for supplementary texts.

Necessary Information

Types and Origins of Texts to Be Remediated

1. OS: Old-spelling transcriptions of primary texts (from IML or EEBO-TCP)
2. M: Modern-spelling texts of primary texts (from IML)
3. Critical paratexts (from xWiki or from the old ISE, QME, and DRE sites)
4. Annotations (XML files written in an IML-XML hybrid)
5. Collations (XML files written in an IML-XML hybrid)
6. Supplementary materials (from xWiki or from the old ISE, QME, and DRE sites. These texts were treated as critical paratexts in the ISE Platform; LEMDO treats them as primary texts.)
7. Title pages from QME (already in good TEI; need LEMDO teiHeader)

Remediation Processes

There are four ways in which we convert texts for LEMDO.

1. IML to LEMDO TEI-XML: OS and M texts.

IML files are stored as .txt files.

JT and/or MH run multiple conversion/cleanup cycles to produce rough LEMDO TEI.

RAs clean up the TEI and check the accuracy of the transcription simultaneously.

1. EEBO-TCP TEI-XML P5 texts to LEMDO TEI-XML: OS texts only.

We get EEBO-TCP files from GitHub. They are already encoded in TEI P5.

JT runs a conversion process that produces relatively good LEMDO TEI.

RAs clean up the TEI and check the accuracy of the transcription simultaneously.

xWiki custom HTML to LEMDO TEI: Secondary texts, About pages, Paratextual materials

RAs clean up the files, with varying amounts of copyediting and checking. Generally, the editor of the edition and/or the Anthology Lead will be involved with checking.

RAs encode the files using the LEMDO tagset for born-digital files.

RAs clean up the files, with varying amounts of copyediting and checking. Generally, the editor of the edition and/or the Anthology Lead will be involved with checking.

Some texts were programmatically converted. 

We might have to copy and paste the text into our own XML files. 

1. XML to TEI-XML conversion: Annotations and Collations

These files are stored as .xml files. They are encoded in a boutique IML-XML language.

JT does a conversion that embeds pointers to these annotations and collations (about 60% successful with the best texts).

RAs check the pointers. 

RAs manually add pointers for annotations and collations that could not be resolved programmatically.

RAs clean up the encoding of the annotations/collations.

Got myself set up in the office and met with JJ and KL to discuss the broad plan for fall and, more immediately, the plan for the team meeting tomorrow. Also discussed layout issues with PS and came up with a tentative plan for the complicated annotation/collation display: readability is a primary concern here since the annotations can range from two words to large paragraphs and block quotations. He's going to look into technical implications and see if our plan is feasible.  

Chatted with PS about the LEMDO site design, which is looking great. Discussed some of the odd features that crop up in EM drama and some of the workarounds we might need to do in terms of popups etc. Things are coming along nicely.

Met with JJ and MH to talk about the LEMDO infrastructure, including build jobs, shared resources, and the potential for ODD chaining. Will do some more research into ODD chaining and think about cost/benefit.

Met with JJ and MH to discuss LEMDO framework, plugin, and the anthology overall.

For the LEMDO anthology, we will include everything, even if it is in draft et cetera, and will provide a "two-step" link as per MoEML (i.e. click to view draft, and very obvious THIS IS A DRAFT watermark background). Projects can decide whether or not they want to have that link available on their site or they can hide it using CSS simply (i.e. #showDraftLink {display:none;}). People can still find that page if they know how to construct the URL, or they can even view on the LEMDO site. We may decide to split the LEMDO listing so that you can choose between peer-reviewed, already anthologized, not peer-reviewed, and not yet anthologized documents. 

Met with JT to thrash out plans for processing ODDs.