Add Attachment as a class on resource_type.

[mlhale7]

What does this Pull Request do?

This PR makes resource_type available for Attachments.

How should this be tested?

Check formatting of M3 and ensure that this fully addresses the issues mentioned https://assaydepot.slack.com/archives/C0396LSM06P/p1687362113688979

Interested parties

@markpbaggett

[markpbaggett]

What's the expectation for resource_type on Attachments? Right now, we don't add this. For works, the value might be something like text or still image. If this gets added here, what would a value of Attachment be?

[mlhale7]

@markpbaggett For works I was thinking the value for resource_type would simply be "Text"? The migrated MODS file would be text (which looking at migration spreadsheets seems to make up most of the attachments). My impression from the Slack conversation was that this is a required field. Kirk wrote "seemed like it just needed to be there to pass a check or something, we weren’t filling it out." I'm unsure exactly how it's utilized to make a better suggestion.

[markpbaggett]

Okay, I remember now. I talked to Kirk and refreshed myself some more with the problem. The m3 is misleading, so I'm adding this for context and also to point out we may have to do something in addition.

The current problem relates to PDF works and PDF splitting. On a Pdf, the work has a fileset attached directly to it that is the intermediate fileset. In this work type, there is no attachment. Using the intermediate file, it is split into 1-n attachments with an attached fileset. For some reason (it's not clear why), an error happens due to resource_type not being present on these programmatically generated attachments. This addition allows the programmatically generated attachment to get this value, but it doesn't appear right now that this is needed elsewere. For this reason, the m3 still says not required and we're not describing this on other attachments elsewhere. If we did have this problem, we'd need to prescribe values for all other attachments related to fileset. If we find out this is an issue, we need to:

1. update the m3 to make it no longer optional
2. make sure a value always get written for all works and attachments in migration utils
3. make sure we have a document that describes the correct value for all attachments that informs migration utils

Again, I don't think we need to do anything now, but pointing this out in case the issue grows in complexity.

[mlhale7]

Thanks @markpbaggett - this is very helpful context to have documented here.