Revise Codicological Unit JSON Sample Records

[wlpotter]

This issue gathers together lingering questions and notes for discussing additional revisions for the ms object JSON sample. The version of these files referenced below are:

• Sample 1: https://github.com/UCLALibrary/sinai_metadata/blob/cebf5d940c5d9118d3f23f22fb7331f2c3fa84af/data-model/SDP-sample-records/codicological-unit_sample1.json
• Sample 2: https://github.com/UCLALibrary/sinai_metadata/blob/8c9f16345e4bfafebacf32bf08a70eb69b7cc63c/data-model/SDP-sample-records/codicological-unit_sample2.json

Notes and Questions

Sample 1

1. line 5. Foliation Regex Pattern. to decide still for foliation. Handling of non-paginated/foliated fly-leaves; handling of duplicated page markings (e.g., '3bis', '3ter' or '3a', '3b', etc. I'm hesitant to use apostrophes/tics as these have escape character issues). Note to self: SMDL image labels currently use a, b, etc.: "f. 003ar"
2. line 6: End-leaves in Extent? include pastedowns and end leaves here? These could be III + 152 ff. + III for 3 front- and 3 end-leaves? Do we treat pastedowns as leaves as well? This may only matter for the ms object if we end up treating end-leaves as their own codicological units.
3. lines 8-12: Allowing multiple supports. I'd be inclined to move towards an array to capture multiple supports where applicable. We could even add a 'range' field to specify which folios are made from which material. For exporting to SMDL, etc. we could merge these and call it ‘mixed’. The only reason not to would be if we want to make a hard distinction that different material = different codicological units. But I don’t think that’s true, and at least not something we’d want to commit ourselves to.
4. line 18: Short Code for Languages. using the lower case for the languages to be machine-friendly, and would hyphenate something like christian-palestinian-aramaic. Don't want to use ISO since they don't have CPA.
5. lines 19-20: Use IDs for Script and Writing System?. should these actually be writing system and script IDs? They would display with the label in the admin panel
6. line 45: Display/canonical date. would we also want/need to specify a ‘display’ date in some way? Or would it always be the date associated with ‘production’ events? What if we have multiple dates associated with production event(s)?
7. line 51: Source Field in Event. we could also restrict the sources field to just point towards paratextual evidence for an event.
8. lines 41-52: Requiring acquisition event? should we (always) include event for acquisition? This gets more into what fields are required, even when we have no data (or little data) for them, and which are optional. However, we do know that at least the ms object will always have an acquisition event for when it came into the Sinai collection (which may be co-terminal with the production date if it was produced there and never left)
9. line 53: IIIF Data for Paratexts, and Deocrations. paratexts — and decorations I think — could also eventually include IIIF content statue URIs and even could make use of the annotations module down the line.
10. lines 53-86: Additional field options for paratexts.
    • writing and hands info. I think we would if we want to treat these as 'mini records’. maybe it implicitly inherits from the text and we only define if it is at variance?
    • condition info. This is especially useful if an ownership note is crossed out by a later (owner’s) hand. This info could (for now) just go in the general notes field.
    • label? Do we need this field? Do we need it in ‘events’ or in ‘decorations’ as well?
    • a references field for paratexts as well? Would we have bibliography just looking at paratextual material (either now or in future?)
11. line 64: Attested vs Associated. I've started distinguishing 'associated' (which goes with events and the objects more abstractly) from 'attested' (which implies we have some, usually paratextual, evidence directly from the ms)
12. line 93: Use of Locus field in Deocrations. I think locus fits here. When we use range we mean the range of the ms for which our data is applicable (e.g., this range of folios has the designated page layout). Locus instead gives where in the ms the feature under discussion could be found (e.g., here, the geometric decoration is on f. 114r). The same is already used for paratexts. Need to figure out, still, how to handle 'throughout' info.
13. line 93: Locus field for 'Throughout'. what do we put for the locus if it’s 'throughout' but not necessarily on the each page? I’m not sure we want to lock ourselves into having to describe each and every instance? We could allow ‘throughout’ as a separate field (maybe a boolean), in which case we’d have the extent be the range within which the feature is ‘throughout’?

So we’d have:

...
"throughout": true,
"locus": "ff. 1-114"
...

or, if it not throughout, we could have:

...
"throughout": false,
"locus": "f. 114v"
...

14. lines 90-95: Additional fields for Decorations. we can include in this field things like attested entities, e.g. if it's an illustration of an identified saint. Should we give decorations IDs, or allow them to have IDs if they are more than just 'decorations'?
15. GENERAL: check the plurality of field names (do we use “note” or “notes”, e.g.). Related: ordering of certain common fields (is it ‘note’ ‘features’ or ‘features’ note’?)

Sample 2

1. line 41: Prefer attested entities in paratext to associated entities in events. We may have already discussed this, but I'm inclined to use 'paratexts' as the primary field. We can assume persons, places, works, dates, etc. attested in paratexts are also associated with events for which the paratext is a source. (This is assuming that we use paratexts in the source field for events, which I think we should). This lets a researcher browse/search by event or by paratext. In cases where we have paratextual sources for an event and indirect evidence, e.g. the paleographic dating of Kamil, we can include additional dates, persons, places, works, etc. as 'associated' in the event field.
   • Note: The two events we know did occur for each and every object is that they were produced and eventually acquired by the monastery. We may not know any of the details of those events, but they are prerequisites to their inclusion in the project. This of course changes for disjecta membra. And also it may not be true that we want to call codicological units or textual artifacts 'acquired'. What of the parts, too, that got rebound and altered while at the monastery? Events, I believe, require a bit more discussion and thought. I am again inclined to use them sparingly if we don’t have direct paratextual evidence to link to.
2. lines 42-49: Example of event without a paratext. I'm including this event separately (from a paratext) since we don't have direct evidence of its production date(s). But this is still a tricky issue as we want to be sure we aren't reduplicating. I think we change to 'attested entities' in paratexts and keep 'associated' as part of events?
3. line 51: Event source points to paratext ID. this field would be the Ark IDs for any paratexts that provide evidence for a given event. I used $ARKID$ as a stand-in for any of these IDs, so I didn't have one to specify.

[wlpotter]

Deprecated by #49