Inheritance rules documentation

[snehagunduraoUL]

Summary

We need to understand how are inheritance rules are setup and working within the DAMS system. At the time we made these decisions, we failed to document them outside of the system.

This spreadsheet documents how we think the inheritance rules are set up.

Please indicate on the spreadsheet where there are differences between what is on the spreadsheet and what is in the code. Or if what is on the spreadsheet is not at all reflective of the rules as they are written in the DAMS, please document how the inheritance rules are defined in the DAMS.

[bkiahstroud]

Related: UCSCLibrary/dams_project_mgmt#514

[bkiahstroud]

Documentation can be found here and here

[rschwab]

@rmjaffe I've consolidated all the information we have about inheritance here: Inheritance Documentation. The 2nd tab shows with color coding which fields currently don't match the data dictionary.

There are two fields which should inherit but currently do not: accessRights and description. Sneha is currently investigating the first one.

There are several fields which do inherit but should not according to the dictionary: boxFolder, coordinates, physicalDescription, physicalFormat, resourceType, staffNote, and titleAlternative. If these need to be addressed, please let me know and I'll create a ticket so it can get worked into the priorities.

We've seen that in the code inheritance is separate from Bulkrax, but I understand it is related in a workflow/thematic kind of way. Given this, would you want this documentation rolled into the Bulkrax documentation, or kept separate?

[rmjaffe]

@rschwab Thank you for alerting me to this.

• accessRights: accessRights should inherit, whether it's handed down from collection to the constituent works or from a parent work to its child works.
• description: This one is trickier and I'm guessing I know why it is set to not inherit. When the DAMS team last talked about this eons ago, we'd decided that while we wanted any child works not having descriptions of their own to inherit descriptions from their parent work, we did not want works to inherit descriptions from the collection. So while most of the inheritance rules can be applied without being sensitive to the nature of the hierarchical relationship (collection-works or parent work-child works), description is the outlier. We can talk more, but if it's too much break the rules to provide for this exception, we can probably come up with a satisfactory workaround, for example, in a collection-level description instead of saying "This collection includes photographs ..." we include the formal name of so that the context of the descriptive statement isn't lost when it appears as inherited value in a work record.

As far as the other fields which do inherit but should not (boxFolder, coordinates, physicalDescription, physicalFormat, resourceType, staffNote, and titleAlternative), yes we should update the settings on those as values placed in those properties are generally specific to the object whether its a collection, a parent work or a child work.

Documentation: I'm thinking it makes better sense to document the inheritance rules as part of the data dictionary vs. the Bulkrax documentation. Does that sound reasonable?

[rschwab]

Sounds good to me. I've begun updating the Data Dictionary with a new tab.

I'm going to mark this ticket closed and break the discussion out into the constituent issues. UCSCLibrary/ucsc-library-digital-collections#406 for access rights UCSCLibrary/ucsc-library-digital-collections#368 for description UCSCLibrary/ucsc-library-digital-collections#369 for the others that should not inherit.