SD and I met to discuss two issues: some data oddities that I wasn't sure how to handle, and the re-shuffling of the recorder report dates.

#1: Data Oddities

We've made the following changes to the value lists (respites, crimes, outcomes):

• Added "Stealing" as a crime in the "Miscellaneous" group
• Removed "PledBelly" from the list of allowable respites (it's actually a judge's respite)
• Decided that the list of judge's respites (the judge_respite family of elements) would be "Respited-Judge", "Belly-Q", and "Belly-NQ"
• Added "NoRR" as a respite_normalized
• Added "SelfTL" and "SelfTR" as outcomes in the "Transport" group
• Added "PrisonRemission" and "Whipped" as outcomes in the "EarlyRelease" group

#2: Recorder's Report Dates

We also discussed a better way to handle rec_rep_start_date, rec_rep_end_date, and rec_rep_pub_date. These currently cover multiple trial_files within the same case, but, given that the dates may change for trials within one case, we've decided to move the dates to within the trial_file element. This will result in more redundant data but will also give SD the flexibility to enter date oddities. Specifically, these changes will be made:

• Removing the rec_rep_head element
• Renaming rec_rep_start_date and rec_rep_end_date to trial_file_start_date and trial_file_end_date, and moving them to within trial_file
• Renaming rec_rep_pub_date to respite_rr_date and moving it to within the first respite element. This is being done because, as SD explained, sometimes a respite resulting from a trial may not be published in the 'original' recorder's report, but be delayed and be published in a later report, even though the trial dates may match those of the original recorder's report. So, blanketing each trial_file within the recorder's report with the same publication date doesn't allow for that flexibility.
• Removal of rec_rep_notes, which, according to SD, is no longer needed.