Further object revisions wlpotter

[wlpotter]

FYI @kirschbombe These are additional revisions based on the ones made in #52.

Some of these were uncovered in creating 'real data' exemplars (I will make a separate pull request for adding the exemplars).

A few outstanding issues:

1. Events vs attested dates vs associated dates. How many options do we allow? What will the user flows look like for adding events vs associated dates? Linking attestations to their corresponding events?
   1. More specifically, should we structure events similarly to other data where it is an object with array fields based on top-level event types ("production"; "ownership"; "use"; "custodianship")
2. Textual artifact contents. I've still just left these as 'note', 'features', and 'toc'. There may be more granular detail we'd want to grab about sub-items.

I'll make more specific comments and annotations on the files themselves of the changes I've made for discussion

[wlpotter]

In airtable we distinguish script and hand notes. It may be worth having the two fields: the script note for comments about how the script is used; the hand about specific characteristics of this particular instantiation of the 'ideal' script type.

[wlpotter]

I've removed the value constraint for 'columns' and 'number_of_lines' so we can capture cases where there's a range (e.g., "16-20")

[wlpotter]

These are all in the context of an "events" field, FYI. I think I mostly just reordered the sub-fields.

[wlpotter]

Events deserve their own discussion. I think we'll need to weigh their usefulness and expressiveness as research data points against how difficult it might be to implement for users inputting data about manuscripts.

One option for restructuring this field, which would make it more like 'paratexts' or 'related_objects' would be to have top-level event types:

{
  "events":
    {
      "production": [array of event objects],
      "ownership": [array of event objects],
      "use": [array of event objects],
      "custodianship": [array of event objects]
    }
}

[wlpotter]

I've updated paratexts here in keeping with how we are structuring 'object_relationships' so that there are named top-level paratexts types. We can decide separately what these top-level types might be, but I think that 'colophon' and 'inscriptions' are sufficiently generic to start with.

[wlpotter]

Another field we should have from airtable -- which can also be used like we do currently when checking data on stage by batch number

[wlpotter]

I realized that we are having RAs grab this data but we didn't have anywhere in the JSON to put it...We just had the rubric paratext, which is sometimes more info than we want for the title.

[wlpotter]

This is like the 'title from RA' field in our Airtable form. I don't know if we will need this or if we will require users to create an authority record? I like the idea of having a less committal option for titling things (this would be, for example, where we'd put 'unidentified')

[wlpotter]

again, on events, see under 'codicological unit'

[wlpotter]

I added this list of top-level types to demonstrate, and based on what we are getting in Airtable. More than happy to add, edit, or delete.

[wlpotter]

Note that the list is "rubric", "prologue", "incipit", "explicit", "subscription", and "marginalia". The paratexts field ends on line 554