Define the list of feature fields and value constraints for each feature field

[wlpotter]

We are currently planning to include several places where feature information may be entered. For example, we could include a feature field both under the 'decorations' object array and under the paratext object array (e.g., for dated colophons).

We need first a list of all the data field locations where we will allow users to specify features. We will then revise this list of fields. Then, we can decide for each what individual value constraints -- so that one cannot, for instance, call a paratext 'decoration, anthropomorphic' as we have a separate field for decorations/ornamentations. This process will likely be iterative.

Note that in serialization for SMDL frontend and data sharing we will collapse this list into an overall features list for manuscript records. However, dividing the features into separate fields allows the more granular querying we want from the SDP.

Note also that the list of fields and their values is subject to our revisions to the overall list of available features, which is still in progress.

[wlpotter]

Current features fields:

N.b., I am referring to field locations via JSONPath

MS Object

As of https://github.com/UCLALibrary/sinai_metadata/commit/6e7a2a8035448d69d460a4083d47379aa524c191

• binding: $.binding.features ; array of cv terms
  • note: we have discussed removing this field already. We don't have binding-specific features. Would we want to note if there are binding decorations though?
• condition: $.condition.features ; array of cv terms
  • note: we have discussed removing this field already. Would we ever have a condition feature? We had discussed maybe 'fragment' being considered a feature rather than a term under 'form'?
• collation: $.collation.features ; array of cv terms
  • currently using it for signatures, though I don't know if that's on our list of features (yet)? Would this be where we'd mark 'catchwords' as well?

Codicological Units

As of https://github.com/UCLALibrary/sinai_metadata/commit/cebf5d940c5d9118d3f23f22fb7331f2c3fa84af

• support: $.support[*].features ; array of cv terms
  • not sure what would be included here?
• condition: $.condition.features ; array of cv terms
  • note: we have discussed removing this field already. Would we ever have a condition feature? We had discussed maybe 'fragment' being considered a feature rather than a term under 'form'?
• page layout: $.page_layout[*].features
  • not sure what would be included here? There are two ways of thinking about the value constraints. On the one hand, we are constraining so that the features only apply to the context field; or they can all be treated as features of the object as a whole regardless of where they are defined, but the constraints help narrow the list down for the user. So, for instance, if someone notices headpieces or tables when looking at the page layout. The latter seems a bit too imprecise, but we should discuss.
• collation: $.collation.features ; array of cv terms
  • currently using it for signatures, though I don't know if that's on our list of features (yet)? Would this be where we'd mark 'catchwords' as well?
• decorations: $.decorations[*].features ; array of cv terms
• paratexts: $.paratexts[*].features ; array of cv terms
  • colophon and dated would be used here. Colophon could be redundant if we give the paratext types.

Textual Artifact

As of https://github.com/UCLALibrary/sinai_metadata/commit/c6061134d40e5cd8dc39eadaaa82c163fe93575a

• condition: $.condition.features ; array of cv terms
  • note: we have discussed removing this field already. Would we ever have a condition feature? We had discussed maybe 'fragment' being considered a feature rather than a term under 'form'? If so, would we even define this for the text? (or codicological unit even?)
• contents: $.contents.features ; array of cv terms
  • maybe 'tables' could go here? Though a table could potentially be treated as its own text. Marginalia might fit, though it would probably be a paratext type/feature of a paratext?
• features of toc items: $.contents.toc[*].features ; array of cv terms
  • the form which this field will take is far from finalized, so we might not use features here.
• paratexts in toc items: $contents.toc[*].paratexts[*].features ; array of cv terms
  • the form which this field will take is far from finalized, so we might not use features here.

---

Potential additions

• we're missing a general features field for the ms object: $.features.
• features for writing and hands, such as 'garshuni'? We'd discussed including that as a feature, but need to raise with advisory board.
• should textual artifacts have a decoration field with features? (This gets beyond this issue, but I'm not sure where we should define decorations -- especially illustrations related to the text)

[wlpotter]

A few thoughts from this:

1. As with notes, this work turned up a lot of similarities across object types. This is not surprising, but we should start to think about what data can appear anywhere and what needs to be restricted to specific object types.
2. Now that we are going to have several controlled vocabularies, I wonder if 'feature' is too general? I think we, on the one hand, want to have a way to serialize out a list of facets for SMDL browse and search. These we can keep calling features. At the same time, I wonder if all of them have to be called features in the data portal? If we are getting more granular with our lists, then couldn't we also get more granular with our terminology? So we can define 'decoration/ornamentation features' separately from 'paratext types', and so forth. This might be the work to do instead of/in parallel with the work of defining the value constraints: what are the broad categories of features that we have? (This can also be extensible, e.g. we can define 'binding features' at a later point).