in, e.g, https://github.com/samvera-labs/houndstooth/blob/main/examples/UCSD.yaml we have definitions like:
properties: # add to spec?
"agent:contributor": # I think the quotes here are causing problems - which might be the colon in the property names is an issue...
display_label: "Contributor"
definition: "A person or organization responsible for making contributions to the resource."
usage_guidelines: # I think the formatting of this list is wrong, and I need to either put everything in quotes, or turn it into a list of key/value pairs
General: "Use as the broadest possible role, i.e. when lacking specific information on an agent's role, or the role is unclear or unknown. If a more specific role is available, prefer that, e.g. editor, compiler, illustrator."
RDCP: "Use for institutions, centers in addition to individuals that contribute to a resource (e.g. SIO, CAICE)"
"DLDP/SCA": "null"
Music: "null"
CLR: "null"
it's not clear to me in this case what "General", "RDCP", etc... represent, in terms of M3 abstractions. in other cases we have:
usage_guidelines:
default: "Record in lastname, firstname order."
Geospatial: "some other value"
where it's more clear that "Geospatial" is a class. but i'm still concerned that these examples involve a matching step after parsing to decide which parts of a property definition apply to which objects.
i'd propose an alternative:
properties: # add to spec?
agent_contributor:
display_label: "Contributor"
available_on:
- General
definition: "A person or organization responsible for making contributions to the resource."
usage_guidelines: "Use as the broadest possible role, i.e. when lacking specific information on an agent's role, or the role is unclear or unknown. If a more specific role is available, prefer that, e.g. editor, compiler, illustrator."
"agent:contributor:geospatial":
<<: *agent_contributor
available_on:
- Geospatial
usage_guidelines: "some other value"
this gives a general solution for any case where a given property needs to be overridden per class. and avoids introducing a separate abstraction for applying these overrides. on the implementation side, it has the benefit that you can use base YAML parsing to determine what properties apply to which classes. once you've done this, you can apply them wholesale without the need to filter contextually.