Code Table Request - MERGE? - carapace-stuff

[dustymc]

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.

Can we merge

curved carapace length [ link ]: carapace length measured across curved surface

and

straight carapace length [ link ]: carapace length measured as straight line across curved surface

(I have no idea what that definition means....)

into

carapace length [ link ]: Length of carapace, straight or curved not specified.

(which needs a better definition, that one is horrible, method has always been available!)

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.

temp_carapace.csv.zip

 guid_prefix | count 
-------------+-------
 ALMNH:Paleo |     1
 APSU:Herp   |     2
 ASNHC:Herp  |    12
 BYU:Herp    |     1
 LINGU:Herp  |     1
 MSB:Herp    |    82
 MVZ:Herp    |    16
 NMMNH:Paleo |     1
 UCM:Herp    |    18
 UTEP:Herp   |     1
 UWBM:Herp   |    16
 UWYMV:Herp  |     3

@ebraker
@byuherpetology
@Nicole-Ridgwell-NMMNHS
@mkoo
@ewommack
@gradyjt
@aklompma
@atrox10
@mvzhuang
@makaylaeasley
@jtgiermakowski

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

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

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.

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.

[mkoo]

are we consistently merging methods and values? because now these are separate methods of measuring a curvy object (eg roughly difference between arc vs a radius measurement for two points). I agree the two could have better descriptions but that's a separate issue

My point is they are not the same so I am going to reject this request. Please close to acknowledge @dustymc Thanks!

[Jegelewicz]

@mkoo I disagree. These are both measuring carapace length - one uses the curvy method and one the straight - that stuff should be in method.

[dustymc]

are we consistently merging methods and values?

Probably not, and there's probably some gray area. Documenting "sameness" would be a useful outcome of this, whatever that turns out to be.

This seems like #6307 and #6308 to me - it's a bunch of ways of saying the same thing, and method exists to specify how things are being said.

[mkoo]

but we arent consistent with methods... is it already filled with stuff like 'calipers', 'shoestring' etc? Anyway that's ok if we can distinguish. I can be persuaded on this but wanted to address the confusion in the initial issue about the difference

[dustymc]

arent consistent with methods

That's my big takeaway from the RANGES meetings - EVERYTHING seems to have some limitations when expressed as a 'fact' (eg, without method, determiner, date), we should do a lot better (maybe starting with expanding and clarifying https://handbook.arctosdb.org/documentation/attributes.html#method).

'calipers', 'shoestring'

Yes, along with how and where the device was applied. (Did you squeeze the calipers until you heard a crunch, or so delicately that the moss growing on the carapace was included? Did you include or not include that thing that gets sometimes-included and seems to exist for lots of measurements? Etc., etc., etc. - let a future user know in some detail what they can and can't get from these data!)

[campmlc]

EVERYTHING seems to have some limitations when expressed as a 'fact' (eg, without method, determiner, date), we should do a lot better (maybe starting with expanding and clarifying https://handbook.arctosdb.org/documentation/attributes.html#method).

Absolutely agree. We should just make metadata part of the model for all fields.

[mkoo]

ok looking into a bunch of MVZ examples-- what am I even complaining about?-- no methods and no distinction between the two!

OK if RANGES is going into the direction of methods to parse out values then I suppose it could work BUT I was thnking of the example of exemplar specimens with BOTH values where it would be desirable to have in separate columns. See https://arctos.database.museum/guid/ASNHC:Herp:14893, https://arctos.database.museum/guid/MSB:Herp:99472, https://arctos.database.museum/guid/MSB:Herp:99473, etc

(even if we keep the two CT values, best practices would not exempt from filling in methods)

[dustymc]

exemplar specimens with BOTH values

Options include:

1. Turn on attributedetail, get it from the JSON
2. Use the attribute download/viewer to get it as separate rows
3. Maybe - although I can't quite see how, method is just important - tell me something clever to squish into a cell for Feature Request - attributes and search results options #6111

[campmlc]

Any way for users to choose what metadata fields to squish into a cell for option 3?

…

On Mon, Jun 5, 2023 at 1:29 PM dustymc ***@***.***> wrote: * [EXTERNAL]* exemplar specimens with BOTH values Options include: 1. Turn on attributedetail, get it from the JSON 2. Use the attribute download/viewer to get it as separate rows 3. Maybe - although I can't quite see how, method is just important - tell me something clever to squish into a cell for #6111 <#6111> — Reply to this email directly, view it on GitHub <#6329 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBB7WBPR2ISBGAC5QFDXJYXPVANCNFSM6AAAAAAYMH2S5I> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[mkoo]

exemplar specimens with BOTH values

Options include:

1. Turn on attributedetail, get it from the JSON

that's where user will have to get it now... so it's # 2 that's the issue

2. Use the attribute download/viewer to get it as separate rows

with additional parsing by method but that's what it looks like all traits people are using will have to do if RANGES says parse in methods, which is ok of course..... but there's sorta two levels of Methods here-- what you're measuring (curved, straight) and how. Methods are generally the "How" part. What we're really trying to wrap around is the What part-- is it simply 'length'? what kind of carapace length? This isnt in Futres at all

3. Maybe - although I can't quite see how, method is just important - tell me something clever to squish into a cell for [Feature Request -  attributes and search results options #6111](https://github.com/ArctosDB/arctos/issues/6111)

155 records with carapace anything not sure if it's worth flat table tweaking but yeah we may need to think about how we see methods in our exports

[dustymc]

2 that's the issue

In case it's not clear, this exists now. (And #6061 might allow someone to find it...)

sorta two levels of Methods

I think they're completely intertwined (along with units, eg PG can't carry enough precision to be very useful if you're measuring musk turtles in lightyears). I'm sure there's lots of overlap for some users using some methods on flattish and/or bitey turtles, for example - it's all important!

not sure if it's worth flat table tweaking

Great, I'd prefer (at least sometimes...) not to add anything without a compelling use case, it's not difficult to add later, just needs some CPU time to catch up.