Code Table Request - new agent identifier/address: pronoun

[Jegelewicz]

Goal

Describe what you're trying to accomplish. This is the only necessary step to start this process. The Committee is available to assist with all other steps. Please clearly indicate any uncertainty or desired guidance if you proceed beyond this step.

Add pronouns when they are known.

Context

Describe why this new value is necessary and existing values are not.

See lengthy discussion at #2452 with conclusion in #2452 (comment)

DUI committee would like to suggest a new private data field be added to the Agents Edit Page under Addresses and Identifiers: pronouns.
The field is maintained as private so only curatorial access can view it.
Field will be free-text.
Having the start and end dates for the pronoun field will add curatorial function to the info entered, as well as can add in remarks where the pronoun was referenced from for people who have died.

In description text for the field we can add some suggested pronouns (e.g. afab = assigned female at birth, amab = assigned male at birth, she/her/herself, they/them, he/him/himself), but allowing it to be free text will allow flexibility for different identified pronouns, as well as limit creation of a code table.

Table

Code Tables are http://arctos.database.museum/info/ctDocumentation.cfm. Link to the specific table or value. This may involve multiple tables and will control datatype for Attributes. OtherID requests require BaseURL (and example) or explanation. Please ask for assistance if unsure.

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

Proposed Value

Proposed new value. This should be clear and compatible with similar values in the relevant table and across Arctos.

pronoun

Proposed Definition

Clear, complete, non-collection-type-specific functional definition of the value. Avoid discipline-specific terminology if possible, include parenthetically if unavoidable.

The preferred pronoun(s) that the agent has indicated they use. Most agents probably will not have a preferred pronoun, since they are not present for us to ask what they prefer (e.g. afab = assigned female at birth, amab = assigned male at birth, she/her/herself, they/them, he/him/himself).

Collection type

Some code tables contain collection-type-specific values. collection_cde may be found from https://arctos.database.museum/home.cfm

N/A

Attribute Extras

Attribute data type

If the request is for an attribute, what values will be allowed?
free-text, categorical, or number+units depending upon the attribute (TBA)

free-text and maintained as private so only curatorial access can view it

Attribute controlled values

If the values are categorical (to be controlled by a code table), add a link to the appropriate code table. If a new table or set of values is needed, please elaborate.

N/A

Attribute units

if numerical values should be accompanied by units, provide a link to the appropriate units table.

N/A

Part preservation attribute affect on "tissueness"

if a new part preservation is requested, please add the affect it would have on "tissueness": No Influence, Allows, or Denies

N/A

Priority

Please describe the urgency and/or choose a priority-label to the right. You should expect a response within two working days, and may utilize Arctos Contacts if you feel response is lacking.

Example Data

Requests with clarifying sample data are generally much easier to understand and prioritize. Please attach or link to any representative data, in any form or format, which might help clarify the request.

Available for Public View

Most data are by default publicly available. Describe any necessary access restrictions.

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 @ArctosDB/diversity-and-inclusion @AJLinn

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.

• 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.

1. Can a suitable solution be found here? If not, proceed to (2)
2. Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
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. URLs should be included as text, separated by spaced pipes. Do not include HTML in definitions.

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.

1. 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.
2. 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.

[dustymc]

I do not understand why this isn't https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_name_type. It's clearly not an address!

private so only curatorial access can view it.

I also (still) don't understand this, and don't think we can safely accommodate it. The simple and leak-proof approach is to just record what the person wants us to record, and not record anything they might not want exposed. Securely maintaining confidential information here seems like it would require something we don't have (eg, something somewhere between encryption and a security team).

[AJLinn]

I do not understand why this isn't https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_name_type.

We would be happy to include it under the names type but we don't have the ability to include start date / end date / remarks under the name types. For trans individuals it might be important to indicate the dates when they collected / published under certain other names or pronouns. If you can add the date functionality to name types (which in my view would be preferred) then great, we can add this as a name type. The committee was trying to work within the structures available.

It's clearly not an address!

No, it's an identifier.

The simple and leak-proof approach is to just record what the person wants us to record, and not record anything they might not want exposed.

Again, in the spirit of trying to have clear and complete agent profiles our goal is to document the collecting and publishing history of individuals without creating duplicate entries for single individuals. However, we didn't want to be the ones to "out" individuals should they not want this information transparently public. We have many examples of non-public information that doesn't go into the public page.