Code Table Request - add new encumbrance action

AJLinn commented 1 year ago

Initial Request

Goal

Add a new value to the encumbrance_action code table: mask user contributed comments

Context

Managers of cultural collections sometimes are provided culturally sensitive information about objects that culture bearers want recorded but not made broadly available to the public. I would like the ability to record that information in the attribute "user contributed comments" but also to have the option to encumber that field if requested by members of a community or family, or for some legal reason should not be made broadly available.

Table

https://arctos.database.museum/info/ctDocumentation.cfm?table=CTENCUMBRANCE_ACTION

Proposed Value

mask user contributed comments

Proposed Definition

Mask the attribute [user contributed comments]([ link ])

Collection type

EH (others might find this useful as well?)

Priority

Priority: high, I have information that was just provided to me that I'd like to associate with the catalog record but will temporarily hold in the access remarks, which is not ideal.

Example Data

A user has provided me with a story associated with the possible place of collection of an object but he needs to follow up with a few other people and there might be legal ramifications. I'd like to add this possible new location of collection but I don't want to make it publicly visible, while also including some of the details of our conversation.

Other examples might include stories about the ceremonial use of an object that should be associated with that piece, but not made broadly available because of intellectual or cultural property implications.

Available for Public View

the encumbrance action would be publicly viewable, but the action itself is to remove data from public view.

Helpful Actions

[ ] Add the issue to the Code Table Management Project.
[ ] Please reach out to anyone who might be affected by this change. Leave a comment or add this to the Committee agenda if you believe more focused conversation is necessary.

@ArctosDB/arctos-code-table-administrators

Approval

All of the following must be checked before this may proceed.

_The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example._

[x] Code Table Administrator[1] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
[ ] Code Table Administrator[2] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
[ ] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
[ ] DBA - Appropriate code or handlers are in place as necessary. (ID_References, Media Relationships, Encumbrances, etc. require particular attention)

Rejection

If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.

Can a suitable solution be found here? If not, proceed to (2)
Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
Take the discussion to a monthly Arctos Working Group meeting for final resolution.

Implementation

Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.

[ ] Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.
[ ] Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition.

Close this Issue.

DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.

Special Exemptions

In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.

Adding an existing term to additional collection types may proceed immediately and without discussion, but doing so may also subject users to future cleanup efforts. If time allows, please review the term and definition as part of this step.
The Committee may grant special access on particular tables to particular users. This should be exercised with great caution only after several smooth test cases, and generally limited to "taxonomy-like" data such as International Commission on Stratigraphy terminology.

Nicole-Ridgwell-NMMNHS commented 1 year ago

This seems like an appropriate encumbrance to me.

dustymc commented 1 year ago

I don't think https://github.com/ArctosDB/arctos/discussions/6742 has to stop this, but if we can cast some illumination on a more-sustainable pathway, or stop digging the hole we're in, I think we should. I don't have any solid idea of where that might go, but one idea is to restrict access to certain types of Attributes. Could all https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type#user_contributed_comments be restricted, or could this be a different type? If so: Is that a horrible idea, possibly with reference to https://github.com/ArctosDB/arctos/discussions/6179?

campmlc commented 1 year ago

I like the idea of attribute types? I haven't been able to follow all this discussion, but it is interesting and relevant for natural history as well as cultural collections. We may need to encumber "detected" attribute values for pathogens or toxins, for example. Having the ability to flag any attribute for encumbrance on an individual record or bulk record level could work, but is the suggestion here to create specific attribute types to assign attributes for encumbrance, avoiding having to create specific encumbrances for each one? @jldunnum

AJLinn commented 1 year ago

With the flurry of code table requests in the last day that seem to being acted upon, any suggestions on moving forward on this one? This remains a "priority high - needed for work" status and no discussion for two weeks. Is there a reason why we can't have the ability to encumber any attribute based on the ethics and decision-making authority of a collection manager?

Could all https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type#user_contributed_comments be restricted, or could this be a different type

Definitely no, as this is a way to differential information collected by curatorial staff vs. that supplied to us by collaborators or community visitors to our collections. This information might or might not be appropriate to be shared, but we make those decisions in partnership with the individual providing the information.

Jegelewicz commented 1 year ago

@AJLinn this request is really more than a simple code table request and encumbering information is becoming a sore spot in Arctos performance. We really need an overall policy for encumbering data and a better way to handle it so that it isn't the thing killing search requests. The request for an Encumbrance Working Group has been on the Working Group Agenda for months - but nobody has stepped up to organize. It seems that we just don't have the bandwidth to tackle this issue right now.

@ArctosDB/arctos-working-group-officers

campmlc commented 1 year ago

I would be interested in participating in an encumbrance working group/committee but can't organize it, apologies.

Nicole-Ridgwell-NMMNHS commented 1 year ago

@AJLinn for the specific example described above, since it regards the collection of the object, could a possible (temporary?) solution be to include the information in an an encumbered locality/event?

Jegelewicz commented 6 months ago

After a discussion with @DellaCHall last week, we wonder if we should have some attributes that are just automatically private? This would relive the managers from always reviewing encumbrances and maybe simplify the encumbrance action list?

Possible attributes to make private include:

value - does anyone want to advertise the monetary value of collection objects? user contributed comments - just adding this because of this issue, would they ever be public? Maybe we need a public and a "curatorial" version? NAGPRA category - Are these ever public? part location - does anyone want to advertise the exact location of their birds of paradise? curatorial remarks - a new thing to use instead of collection object remarks for information not meant to be public

ewommack commented 6 months ago

Ah, like the idea of how we have curatorial remarks for Agents now, which are always private. Sounds like a potentially good idea. Perhaps we could have a private verbatim locality attribute to help with locality information encumbrances too?

dustymc commented 6 months ago

have some attributes that are just automatically private?

https://github.com/ArctosDB/arctos/issues/3536#issuecomment-2093153164

ArctosDB / arctos