Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code Table Request - agent attribute - verification status #7328

Closed
2 of 8 tasks
dustymc opened this issue Jan 24, 2024 · 3 comments
Closed
2 of 8 tasks

Code Table Request - agent attribute - verification status #7328

dustymc opened this issue Jan 24, 2024 · 3 comments

Comments

@dustymc
Copy link
Contributor

dustymc commented Jan 24, 2024

Goal

In preparation for #7318, set up the environment in which to record "status."

Context

This is a new value for a new code table for a new structure.

Table

Nothing to link yet, will be #7327

Proposed Value

'status' was proposed in #6813 (comment), but seems a bit cryptic. 'verification status' is familiar, but I'm not sure it's quite right. HELP!

Proposed Definition

Indication of data quality or completeness.

(Seems pretty waffly - HELP!!)

Attribute controlled values

This will be controlled by a trigger, there will not be a code table. (Such can be added if this sort of thing turns out to be more common than anticipated). Initially-allowed values will be

  • verified
  • accepted
  • unverified

and meanings and UI handling is described in #6813 (comment)

Priority

Will happen when necessary, please HELP!

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

@mkoo

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.
@Jegelewicz
Copy link
Member

Seems pretty waffly

Maybe because the three options need definitions?

verified - The agent is known to the verifier and managed as such. Data associated with the agent can be reasonably relied upon and edits should only be made when the editor is positive they apply to the agent. While verified agents may not carry disambiguating information that could be detected by automation, they are actively managed by another Arctos Agent.

accepted - The agent is not actively managed but holds data that make it unique such as an ORCiD, Wikidata identifier, or Library of Congress number.

unverified - The agent does not hold any data that allows disambiguation by automation and is not managed. Please improve this Agent by adding disambiguating data!

@ekrimmel
Copy link

Take or leave my thoughts on this...

"verified" and "accepted" are basically synonyms in English, which could lead to user confusion by default (i.e. the user needs to read the code table definition enough times to internalize the difference between these statuses; status values are not intuitively different). Something like this might be more intuitive?

One field to deal with a human decision:

verified - The agent is known to the verifier and managed as such. Data associated with the agent can be reasonably relied upon and edits should only be made when the editor is positive they apply to the agent. While verified agents may not carry disambiguating information that could be detected by automation, they are actively managed by another Arctos Agent.

unverified - The agent does not hold any data that allows disambiguation by automation and is not managed and agent data may not be reliable. Please improve this agent by adding disambiguating data!

Another field to deal with a programmatic assessment:

disambiguated - The agent is not actively managed but holds data that make it unique such as an ORCiD, Wikidata identifier, or Library of Congress number. The agent is associated with a unique identifier issued by ORCID, Wikidata, or Library of Congress. [expand this list to include the identifiers Arctos is looking for, if this value is getting assigned programmatically]

not disambiguated - The agent is not associated with a unique identifier issued by ORCID, Wikidata, or Library of Congress. [expand this list to include the identifiers Arctos is looking for, if this value is getting assigned programmatically]

Both or either of the above could also be boolean vs. code tables.

@Jegelewicz
Copy link
Member

That's pretty sweet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants