Open WaigePilson opened 7 months ago
Open to discussion on this! I've been running into this frequently as I import legacy data, and I'm wondering if other folks would find this useful. Perhaps there's a better solution already possible? Or there is a better solution I am not thinking of as an Arctos newbie?
@ronaldeng @KatherineLAnderson @Nicole-Ridgwell-NMMNHS @Jegelewicz
@WaigePilson for that use geology remarks [ link ].
@Jegelewicz my issue is that then when I export data these names will be in "geology remarks" rather than associated with "lithostratigraphic formation". Is this an absolute no-go?
In these cases, I think the recommendation would be to add this as a "geology remark" or to leave off the unit entirely (since I don't have an attribute_value to add). However, I would prefer a way to store this verbatim data in the lithostratigraphic formation (or member or group) attribute to make exported data cleaner.
I think this is a good thing to discuss. Basically you are wanting this data parsed out from the rest of geology remarks so that you can report it specifically as lithostratigraphy? I think this may be a good solution, but I want to make sure if we do this you'll actually be able to get the kind of data exports you are looking for. Currently I think the only way to download a locality attribute remark is through "download locality attributes" on locality search, and that may or may not be a format that works for you.
If we decide that this is good solution, I suggest "other" or "verbatim" as the term.
"Not actually a taxon-like-thing" as a value in taxonomy-like data does not sound like something that should happen. I also don't understand why you'd want to mix those things, so maybe I'm just lost....
If we're comparing to taxonomy, I think what they're trying to do here is somewhat equivalent of unidentifiable {string}.
I'm re-categorizing and not transferring this, it needs much more resolution before becoming a code table request (still looks like an inappropriate NULL to me??).
I don't think this is meant to be a null value, just a workaround for recording some kind of verbatim value that can't/shouldn't be added into a lithostratigraphy code table, but they still want it parsed out as lithostratigraphy.
@dustymc I would say this is similar to the "unknown" value in the part_names code table. An example of how this would be used: I have a locality A1348 which I have recorded as being from the Boundary Shale Formation, but I cannot find any references to that formation online (there's one MSc thesis which mentions it from the 1980s but that is it). Currently, without a "Verbatim" or "Other" value available under lithostratigraphic_formation I instead have entered a geology remarks of "Boundary Shale Formation", but I have another geology remarks already containing some description of the geologic section at this locality.
While this is an okay solution, it seems like it would be neater in terms of data management to have this remark of "Boundary Shale Formation" tied to the attribute lithostratigraphic formation rather than in the wastebasket of geology remarks along with any number of other remarks.
As for needing more discussion, I agree! I am hoping we can talk about it at a code table meeting at some point but we haven't had time at any of the ones I've been to recently.
"unknown" value in the part_names code table
"I've got this thing in my hand, it's clearly a 'thing to which I might stick a barcode' and so it's clearly a part, and it's a part of something I want to catalog if I say it is (a purely administrative decision) but I don't know what to call it." I think that's all justified (or unavoidable), but I also don't think it's much like what's being requested here.
cannot find any references to that formation online
Our (working!) definition of formation is https://docs.google.com/spreadsheets/d/1-QC9L8jbOzaG7vstp5iHyx8ivlyvr3BrtiCY_GBimAg/edit?gid=0#gid=0. I think it's pretty clear that not published in the expected places ===> not a formation. I think it would be a mistake to mix any sort of informal data in with that; doing so would (to some extent, no hills I'm willing to die on around here...) make the rest of the data that much less useful. Mixing or confounding concepts kinda always finds a way to be the opposite of "neater in terms of data management."
another geology remarks
They're free, use as many as you need! (FWIW I think that's probably the 'proper' thing to do here, when it's apparently not clear what anyone's talking about. In slightly different circumstances I'd recommend https://arctos.database.museum/info/ctDocumentation.cfm?table=ctlocality_attribute_type#informal_lithostratigraphy instead.)
Initial Request
Goal
Enable a way to store verbatim lithostratigraphic units in the appropriate locality attribute without having to enter an approved lithostratigraphic unit from one of the code tables.
Context
You are required to enter a value (attribute_value) when recording a locality attribute. For lithostratigraphic units, this means that you are required to enter a valid formation, member, or group from the code tables. However, there are occasions where we don't know the formation or at least aren't able to use one of the code table values for it, but we do have some verbatim text from the researcher. For instance, I have a locality referring to the Bruxellion Formation in Brabant but a quick google search is not providing a reliable source or reference, or as another example I have a locality reportedly from the Boundary Shale Formation in Washington but I cannot find a unit matching that description in geolex. Perhaps these are mistakes or misspellings, or they might be esoteric or no longer used unit names, or they might be valid unit names which are just harder to track down valid references for.
In these cases, I think the recommendation would be to add this as a "geology remark" or to leave off the unit entirely (since I don't have an attribute_value to add). However, I would prefer a way to store this verbatim data in the lithostratigraphic formation (or member or group) attribute to make exported data cleaner.
Table
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctlithostratigraphic_formation https://arctos.database.museum/info/ctDocumentation.cfm?table=ctlithostratigraphic_member https://arctos.database.museum/info/ctDocumentation.cfm?table=ctlithostratigraphic_group
Proposed Value
unknownverbatim formation verbatim member verbatim group
Proposed Definition
Lithostratigraphic unit is unknown or is not a recognized term, add comments in attribute remarks.
Helpful Actions
[x] Add the issue to the Code Table Management Project.
[x] 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 @KatherineLAnderson @ronaldeng @Nicole-Ridgwell-NMMNHS
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._
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.
[ ] 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.