Code Table Request - Informal lithostratigraphy code table

KatherineLAnderson commented 1 year ago

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.

We need a new locality attribute type and associated code table for informal lithostratigraphy, akin to the informal chronostratigraphy code table.

Context

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

For lithostratigraphic units that are unranked and/or not formally defined, but consistently used in the literature. This data has been previously entered in remarks by other collections. Controlled vocabulary will ensure data entry is consistent, easing searchability.

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=ctlocality_attribute_type

Proposed Value

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

informal lithostratigraphy

Proposed Definition

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

lithostratigraphic units that are unranked and/or not formally defined, but consistently used in the literature

Collection type

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

ES

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)

categorical (controlled vocabulary)

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.

Table values for UWBM VP here: UWBM_VP_informallithostratigraphy.csv

Attribute units

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

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.

priority high. necessary for ongoing data migration.

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.

yes.

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.

As discussed with @WaigePilson @Jegelewicz @Nicole-Ridgwell-NMMNHS @dustymc in Issue #6541

@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
[x] 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
[x] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
[x] 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.

dustymc commented 1 year ago

I still don't quite understand this.

There's "formal" chronostratigraphy (it gets printed on the chart that everyone uses, anyway) so 'informal' potentially makes some level of sense.

I think there's not formal lithostratigraphy, so I'm not sure how there could be informal.

The example data suggest these are subsections of controlled things (eg formation) - right?

And I presume there's no information beyond "A" or "B" or whatever "working name" some (also unknowable?!) person might have tacked on?

I don't see how that adds up to needing a controlled vocabulary. What could I do with that which I can't do with these data in remarks-or-whatever?

KatherineLAnderson commented 1 year ago

I don't see how that adds up to needing a controlled vocabulary. What could I do with that which I can't do with these data in remarks-or-whatever?

Spell it correctly and format it consistently.

WaigePilson commented 1 year ago

100% agree with Katie's reply that this new table would allow us to have correct and consistent spelling and searchability. Putting this vocabulary in Remarks would make it essentially unsearchable.

I think there's not formal lithostratigraphy, so I'm not sure how there could be informal.

The only other solution here would be to add all of these units to the existing lithostratigraphy tables. I don't have a strong opinion; I understand Katie's point that these units don't always fit nicely into the category of "bed" or "member" because they are so informal (i.e., in the published literature but not on Geolex), but I also understand that since there is no governing body determining what a "formal" unit is there is some wiggle room here. So adding these to existing lithostratigraphy tables or creating a new informal lithostratigraphy table, either option sounds good to me!

dustymc commented 1 year ago

From the demo data...

... the value here (unless we're going all Department of Redundancy Department on this thing) would be "A."

That also suggests that there might be an infinite number of these things (if whatever lead to A is Authority-worthy then that same process can produce a and a' and ...) which isn't very compatible with code tables. About how many of these things would you actually have?

And of course from that if I can create these by writing something on some ledger-or-whatever, then "Blacks Fork A" doesn't necessarily mean only one thing (I can see no mechanism to prevent homonyms), and maybe no two spellings are meant to be the same?

don't always fit nicely into the category of "bed" or "member"

Again from the demo data, it seems they all have parents - are there multiple children of whatever the most specific "formal" determination might be? (Or maybe I'm reading that wrong - it's Whatever Formation and also whatever this is, which I think might include finer-than-formal differences that'll never be named and new large-scale yet-to-be-defined THINGS, and anything else under the sun???)

Is there some way I could recognize these data? If I give the same label-or-whatever to a thousand *ologists would they all treat "Blacks Fork A" as what we're trying to create, or would some of them consider it remarks (or verbatim locality or whatever)? I think the latter, and if that's true then this just looks like denormalization - an arbitrary thing which results in one kind of data being stored in more than one place (which always means that nobody can find all of it).

@Nicole-Ridgwell-NMMNHS help?

Sorry, I'm really not trying to be difficult, I'm just struggling to understand this!

KatherineLAnderson commented 1 year ago

I'll try to answer some of @dustymc Dusty's Q's. Would love Nicole's thoughts and any other ES collections that this might be useful for.

About how many of these things would you actually have?

Technically, you could have an infinite number.

And of course from that if I can create these by writing something on some ledger-or-whatever, then "Blacks Fork A" doesn't necessarily mean only one thing (I can see no mechanism to prevent homonyms), and maybe no two spellings are meant to be the same?

Because these appear in the published literature, they are known entities and standardized, but unnamed (hence the "A", "B", etc) and/or unranked (e.g., they're subdivisions of the Blacks Fork member of the Bridger formation, but not formally designated/defined as "beds" in the literature).

don't always fit nicely into the category of "bed" or "member"

Again from the demo data, it seems they all have parents - are there multiple children of whatever the most specific "formal" determination might be? (Or maybe I'm reading that wrong - it's Whatever Formation and also whatever this is, which I think might include finer-than-formal differences that'll never be named and new large-scale yet-to-be-defined THINGS, and anything else under the sun???)

In short, the answer here is yes. There can be unranked units between the formal designations (e.g., between "formation" and "member") and unranked units more specific than a formal designation (e.g., more specific than member which is the most specific "formal" entity). There can be unnamed units in any of the formal ranks and in between.

Is there some way I could recognize these data? If I give the same label-or-whatever to a thousand *ologists would they all treat "Blacks Fork A" as what we're trying to create, or would some of them consider it remarks (or verbatim locality or whatever)? I think the latter, and if that's true then this just looks like denormalization - an arbitrary thing which results in one kind of data being stored in more than one place (which always means that nobody can find all of it).

The important thing here is that they're used consistently in the literature so at least a handful of *ologists (e.g., the nerds who study the Bridger formation) agree they are all referring to the same thing using that designation. These are not random field/verbatim determinations that one person used one time. (We have plenty of those that will go into remarks or other identifiers.)

Sorry, I'm really not trying to be difficult, I'm just struggling to understand this!

It is hard to understand, so no worries. We are attempting to impose order on a chaotic system. My goal is to make the data standardized and searchable, but I also can understand over-normalization being a concern.

dustymc commented 1 year ago

consistently used in the literature

Thanks, I think that finally soaked through. I'd still like to hear from @Nicole-Ridgwell-NMMNHS (and anyone else willing to chime in, always!) but "published" I think makes this make (enough) sense for me.