Open Jegelewicz opened 1 year ago
I will need to adjust code if this proceeds so I'm not checking all the boxes yet, but this seems correct and viable to me.
MAYBE "UAMENTO object tracking whatever" would be a better agent, but I can't see any strong functional implications and it should be easy to adjust so whatever.
UAMENTO object tracking whatever
barcodes across Arctos should be unique, so I'm not sure that matters? But maybe @DerekSikes would care.
Please do not remove barcode as a unique identifier value. We need this and are currently entering several thousand records with it to able to track parent child relationships between collection objects.
barcode as a unique identifier value
There is no such constraint, are you talking about some other object type?
Data:
Summary:
guid_prefix | numrecs
-------------+---------
BYU:Edu | 2
DMNS:Inv | 2
JSNM:Egg | 803
JSNM:Herb | 1068
JSNM:Paleo | 2521
MSB:Herp | 30
MSB:Host | 3
MSB:Para | 21
UAMb:Herb | 2
UAM:Ento | 236917
UAM:Herb | 72
UTEP:Herb | 1
Users:
@campmlc @DerekSikes @mvzhuang @jtgiermakowski @acdoll @genevieve-anderegg @msbparasites @StefanieBond @sharpphyl
Given that barcodes are now unique to institutions, would agents for the various institutions would need to be created? Or would it matter?
I don't believe these data are maintained or consistent, and we have radically different tools than we did when this was created. I would prefer to remove this (including data) and finding a UI solution.
Also I don't know how https://github.com/ArctosDB/arctos/issues/6014#issuecomment-1535315447 is related, that needs clarification.
I would prefer to remove this (including data) and finding a UI solution.
I think that has been proposed but I can't find the issue. It was to expose the barcode on the public page. Just the barcode, not the path and it shouldn't be clickable. I can file an issue if this seems remotely possible.
Also, I don't think those JSNM things are Arctos barcodes. However, they could be changed to identifier with an appropriate issued by.
Instructions
This is a template to facilitate communication with the Arctos Code Table Committee. Submit a separate request for each relevant value. This form is appropriate for exploring how data may best be stored, for adding vocabulary, or for updating existing definitions.
Reviewing documentation before proceeding will result in a more enjoyable experience.
Initial Request
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.
Attempting to lower the number of generic types of identifier. @DerekSikes I'm counting on you to demonstrate that this is workable.
Proposed Value: Proposed new value. This should be clear and compatible with similar values in the relevant table and across Arctos.
Remove barcode [ link ] and replace existing identifiers with other identifier issued by Arctos Object Tracking (I have not yet created this agent)
Proposed Definition: Clear, complete, non-collection-type-specific functional definition of the value. Avoid discipline-specific terminology if possible, include parenthetically if unavoidable.
Context: Describe why this new value is necessary and existing values are not.
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.
Collection type: Some code tables contain collection-type-specific values.
collection_cde
may be found from https://arctos.database.museum/home.cfmPriority: 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.
Available for Public View: Most data are by default publicly available. Describe any necessary access restrictions.
Project: Add the issue to the Code Table Management Project.
Discussion: 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.
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).
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.
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.
Make changes 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.