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.

Sign up for GitHub

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

Jump to bottom

Code Table Request - right gonad width #6189

Closed
4 tasks
dustymc opened this issue Apr 25, 2023 · 44 comments
Closed
4 tasks

Code Table Request - right gonad width #6189

dustymc opened this issue Apr 25, 2023 · 44 comments
Labels
Accessibility Issue is related to Arctos accessibility. CodeTableCleanup Our bad data leads to more bad data. Fix it! Priority - Wildfire Potential ignore this at everyone's peril, may smolder for now ...
Milestone
Needs Discussion

Comments

@dustymc
Copy link
Contributor

dustymc commented Apr 25, 2023 •
edited
Loading

Current

This will be removed, not fixed.

Old Stuff

disregard everything below here

Instructions

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.

(from https://docs.google.com/spreadsheets/d/1yc6ZE1voZp44S-0qEzc_w1yatxynWkXcpbWDzNmY8TA/edit#gid=0)

Attribute right gonad width is defined as "Length measurement of the left gonad."

Probably just nobody reads definitions, but ????????

Data: temp_rgw.csv.zip


 guid_prefix | count 
-------------+-------
 UCSC:Mamm   |     1
 MSB:Bird    |     1
 MVZ:Mamm    |    18
 UNR:Mamm    |     1
 MMNH:Bird   |     1
 UAM:Mamm    |     1
 CHAS:Bird   |    22
 UMNH:Bird   |     3
 UWBM:Mamm   |    59
 MVZ:Herp    |    40
 DMNS:Mamm   |    22
 OWU:Bird    |     7
 MLZ:Bird    |     3
 UCM:Bird    |    47

@ebraker
@mkoo
@amgunderson
@atrox10
@cjconroy
@wellerjes
@jebrad
@jrpletch
@acdoll
@jrdemboski
@kderieg322079
@catherpes
@droberts49

Help?

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

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

_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)

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

_Attribute units If numberical values should be accompanied by units, provide a link to the appropriate units table.

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

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.

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.

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

  • 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.
@dustymc dustymc added this to the Needs Discussion milestone Apr 25, 2023
@catherpes
Copy link

catherpes commented Apr 25, 2023 via email

@acdoll
Copy link

acdoll commented Apr 25, 2023

Probably just nobody reads definitions, but ????????

Some things just seem self-explanatory, but I guess not! What needs to happen here? Just review by Code Table Committee and then update of definition?

@Jegelewicz
Copy link
Member

Seems like a copy-pasta problem and I agree - also seems like the term is self-explanatory and changing the definition should be NBD.

@dustymc
Copy link
Contributor Author

dustymc commented Apr 25, 2023

What needs to happen here?

I think we just need a definition (which references this Issue, which contains data, which should be plenty of history given what probably happened).

@Jegelewicz
Copy link
Member

Width measurement of the right gonad.

@Jegelewicz

This comment was marked as off-topic.

Sign in to view
@dustymc dustymc mentioned this issue Apr 26, 2023
Closed
@dustymc
Copy link
Contributor Author

dustymc commented Apr 26, 2023

Width measurement of the right gonad.

I'm tempted to check my boxes because that's about as good as anything else, but there seems to be some focus on this sort of thing and surely we can do better!? Some of those things are kinda squishy, I'm not sure there's a clear "here be the width" dotted-line-or-something, etc. etc. Surely there's some functional definition which might let me know if these values are compatible with some other similarly-labeled values?? If not, then do we really need this - would we lose anything by dumping some arbitrary apparently-undefinable thing into some topic-appropriate junkyard?

Alternatively, maybe vague handwavey definitions are OK or preferable (in which case we need updated documentation and maybe-easier cleanup) and all the details belong in method.

tl;dr: Can this be made Research Grade?

@Jegelewicz
Copy link
Member

functional definition which might let me know if these values are compatible with some other similarly-labeled values??

Shouldn't that really be happening in METHOD? I have been struggling between these things and the antler stuff - if we make them SUPER specific (including the "how"), then why have a method? And then we will have 20 or 50 different "gonad width" things, each varying by the "how". Do we need length and width for gonads, or could we get by with gonad measurement and let the rest (length, left, etc.) reside in method? Where is the line between the thing thing and the how we got the thing?

@campmlc
Copy link

campmlc commented Apr 26, 2023 via email

@dustymc
Copy link
Contributor Author

dustymc commented Apr 26, 2023

Shouldn't that really be happening in METHOD?

See: "Alternatively..." - maybe.

If so, do we really need ear from crown [ link ] and ear from notch [ link ] - and are there other things which might be condensed?

right, left etc in remarks?

We clearly need better documentation, anyway - 'measured the right whatever.....' sounds like method to me.

Usually the method

#6191 (comment) suggests that there is no "usually." (And we have 30 THINGS and one method in the length-types....)

@campmlc
Copy link

campmlc commented Apr 26, 2023 via email

@campmlc
Copy link

campmlc commented Apr 26, 2023

@jldunnum

@catherpes
Copy link

catherpes commented Apr 26, 2023 via email

@dustymc
Copy link
Contributor Author

dustymc commented Apr 26, 2023

"right testis: 4 x 2 mm, left testis 3 x 1 mm"

That is functionally something else; it's free-text.

  • gonad=4 mm method=right testis thisaway
  • gonad=2 mm method=right testis thataway
  • ...

is structurally defensible, but that does seem like it's probably on the wrong side of the line, wherever that line really is.

currently as open text into "reproductive data" at MSB

Who cares? Answer that and you'll know what you should be doing. If only people who like reading text and have already found the record have an interest, then that's defensible. If anyone might ever want to find things with a left testis between 4 and 5 mm wide, then we need something more than free text (or my 'everything's a gonad' model which deals with mm just fine, but not 'wide' nor 'left'). Usually we end up guessing and hoping with that sort of thing, but there's an active grant and maybe we can find a defensible answer.

@bryansmclean

@dustymc
Copy link
Contributor Author

dustymc commented Apr 26, 2023 •
edited
Loading

entering length and width attributes in separate fields takes TIME

Not to drag this too far off course, but #6171 is going to mean a near-full rebuild of a crazy-complex form intended to do everything for everyone. I don't know what's realistic, but perhaps a few more-specialized and much simpler forms (eg that could have the 4 traits you need as simple 'enter number here' fields with metadata hard-coded into the form) or WHATEVER could be both more sustainable and more usable than the current data entry UI. It's always a bit of a chicken-and-egg thing (must spend months building complex thing to know complex thing is too complex to use) and everyone always has some sort of resource limitations, but the shape of some UI shouldn't be driving what data are collected. (And neither should "we've always done it that way!") Anyway, probably a decent time to file an issue if you have radical ideas regarding how data entry could or should work.

@Jegelewicz
Copy link
Member

And maybe also off-topic, but here we are again placing part names somewhere else? If we recorded

part= gonad

we could add

descended
length
right

and any number of other things about the gonad - the gonad disposition could be - discarded and it could still carry these attributes.....

@campmlc
Copy link

campmlc commented Apr 26, 2023 via email

@dustymc
Copy link
Contributor Author

dustymc commented Apr 26, 2023

not in the model

Sure it is, both the part and the individual/record can carry "traits." @Jegelewicz 's part plus a bunch of attributes approach fits just fine, and maybe that's truly what we should be doing. (I suspect it's not for the sake of simplicity, but the model is clearly capable and there is some extra clarity in that approach.)

"observation" is no longer an allowed disposition.

"We don't have it" disposition values are fine, we have a few of them. (And I suspect some other things are not being understood.)

@bryansmclean
Copy link

bryansmclean commented Apr 26, 2023 •
edited
Loading

Chiming in here with some thoughts relevant to #5532.

There are several instances where potentially proposed attributes correspond to features/parts with L and R qualifiers (testis, uterus, embryo, placental scar). I would strongly argue in defense of NOT moving any of this information to free text.

But, it does seem there is a fine line between the efficiency of enumerating all attributes at the record level vs. moving them to the part level. I imagine that most of the attributes that most of us want to capture with increased precision dont actually have endless qualifiers - usually L/R and length/width/etc/etc just about do it. So maybe the former option (record level) works?

@mkoo mkoo mentioned this issue Apr 26, 2023
Closed
@campmlc
Copy link

campmlc commented Apr 27, 2023 via email

@bryansmclean
Copy link

bryansmclean commented Apr 28, 2023 •
edited
Loading

Maybe... Is there an example of where something similar is already implemented that will help me/us think about it more clearly (sorry, foggy Friday morning here, in more ways that one).

@cjconroy
Copy link

The few MVZ mammals that have right length and right width was just a random use of those fields. We may have picked right only because we had to pick either left or right as there is no side-free option. Our standard is to just put that info in reproductive remarks. Some burden should be placed on users to download data and split measures. One would hope that a user who is interested in thousands of testes measures would be savvy enough to split the values by the x, or whatever character(s) separates the two values.
Testes are pretty much nearly the same in my experience and I don't record which side I measure. Differentiating left and right would be useful for some study of bilateral asymmetry, but if that was the case, I assume that researcher would want to collect their own data with great precision.
We don't parse out left or right ear from notch, or hind foot with claw for the same reason - they are basically the same size. So why do it for testes? Maybe someone knows the history.

@dustymc
Copy link
Contributor Author

dustymc commented Apr 28, 2023

I think the left/right bits might make more sense for birds, but I can't find nor remember details of that conversation - @ewommack @ccicero ??

burden should be placed on users

I'd be surprised if many can pay that price, but if that's the direction this is going then maybe we should be considering many fewer attributes, so that those users at least don't have to sort through quite so many "fields." (Perhaps a dozen or more attributes could be considered components of 'reproductive data.')

FWIW here are most-used values.


arctosprod@arctos>> select attribute_value,count(*) from attributes where attribute_type ='reproductive data' group by attribute_value having count(*)> 500  order by count(*);
                                 attribute_value                                  | count 
----------------------------------------------------------------------------------+-------
 vagina closed; nipples small; not lactating; not pregnant; placental scars: none |   508
 testis 9mm                                                                       |   520
 T=6x4                                                                            |   523
 testis drawn on tag                                                              |   531
 with calf                                                                        |   551
 testis 3mm                                                                       |   565
 no placental scars                                                               |   566
 swollenVagina                                                                    |   573
 testes minute                                                                    |   573
 testes drawn on tag                                                              |   575
 enlargedNipples; swollenVagina                                                   |   596
 testis 4mm                                                                       |   611
 testis 10mm                                                                      |   631
 unknown                                                                          |   646
 CSN, No PLSC                                                                     |   664
 NO EMBRYOS                                                                       |   673
 testis 2mm                                                                       |   674
 testis 1mm                                                                       |   707
 T<1                                                                              |   707
 T=1x1                                                                            |   709
 brood patch                                                                      |   709
 testis 5mm                                                                       |   709
 T=4x3                                                                            |   712
 testis 8mm                                                                       |   732
 no embs                                                                          |   740
 t.e.                                                                             |   740
 testis 6mm                                                                       |   786
 testes large                                                                     |   796
 T=1                                                                              |   809
 V:I                                                                              |   812
 T=2x1                                                                            |   817
 testes fully enlarged                                                            |   832
 non-reproductive                                                                 |   833
 T=5x3                                                                            |   838
 ova minute                                                                       |   843
 No PLSC                                                                          |   847
 testis 7mm                                                                       |   860
 closed, small, non-lactating                                                     |   895
 No embryos                                                                       |   931
 o.s.                                                                             |   942
 no scars                                                                         |  1041
 T=4x2                                                                            |  1073
 t.s.                                                                             |  1149
 nulliparous                                                                      |  1193
 vagina imperforate                                                               |  1202
 testes 1/4 enlarged                                                              |  1412
 immature                                                                         |  1487
 lactating                                                                        |  1584
 CSN                                                                              |  1611
 non-scrotal                                                                      |  1722
 enlargedNipples                                                                  |  1736
 no embryos                                                                       |  1905
 not recorded                                                                     |  2005
 ovaries minute                                                                   |  2211
 T=3x2                                                                            |  2381
 gonads not found                                                                 |  2539
 pregnant                                                                         |  2822
 no plsc                                                                          |  2924
 nonscrotal                                                                       |  8878
 scrotal                                                                          |  9813
(60 rows)

@ewommack
Copy link

I think the left/right bits might make more sense for birds, but I can't find nor remember details of that conversation -

Birds it is traditional to measure the left testis, and I bet that is because the ovary is generally only on the left for most birds as well. Check on the left side, find something, measure it.

I try and measure both whenever I can. In birds they often are different in size (left generally just slightly bigger). If I check both sides then I also do it for females, and I'll find those odd ones that have two ovaries.

At the UWYMV we are like @cjconroy and put everything in reproductive data. If we were really consistent in which we measured, maybe I would use the different attributes.

Perhaps it makes a difference in the aggregator data?

@Jegelewicz
Copy link
Member

Perhaps it makes a difference in the aggregator data?

This stuff isn't even separated in the aggregator data as we send it - all attributes get lumped together.

https://arctos.database.museum/guid/MSB:Mamm:10199 at GBIF:

image

@ewommack
Copy link

ewommack commented May 1, 2023

all attributes get lumped together.

Would having the data in parts attributes rather than record attributes make a difference? I don't see any part attributes the above list.

@dustymc
Copy link
Contributor Author

dustymc commented May 1, 2023

We should never let an exchange standard dictate how we record data, but GUM does handle attributes defensibly, see eg http://labs.gbif.org:7003/?entityId=https%3A%2F%2Farctos.database.museum%2Fguid%2FMSB%3AHost%3A152

Screenshot 2023-05-01 at 1 33 02 PM

@campmlc
Copy link

campmlc commented May 1, 2023 via email

@dustymc
Copy link
Contributor Author

dustymc commented May 1, 2023

Do they have a way to record determination method?

yes

@ewommack
Copy link

ewommack commented May 1, 2023

So if we put the testis size info in the parts attribute data would it come out in a funny place in an aggregator's data, look the same, or do something really cool compared to our long list of record attributes we currently have?

@campmlc
Copy link

campmlc commented May 1, 2023 via email

@campmlc
Copy link

campmlc commented May 1, 2023

Putting these data in part attributes when we don't have parts would require a complete overhaul of all of our data capture workflows, which currently capture these in record attributes. I think that would cause an even greater uproar than merging identifiers.

@dustymc
Copy link
Contributor Author

dustymc commented May 1, 2023

@ewommack unclear. If you mean now, not a clue. If you mean in GUM then assertions can apply to parts, but IDK what the UI might look like (or if the whole idea will ever see nonexperimental status for that matter). https://github.com/gbif/model-material/issues is the place to ask.

@campmlc yes usability (and resources and etc.) has to be considered, parts is arguably more correct, I'm not sure that I can see an actual functional distinction, and if we have to choose between "slightly imperfect but usable" and "stuffed into some wildly inappropriate text field because resources allow nothing else" then I'll always choose the former.

@campmlc
Copy link

campmlc commented May 1, 2023 via email

@Jegelewicz
Copy link
Member

Part attributes is the answer - but I know people don't want/need the extra work. I'm just saying it will probably happen someday....

But we have not got one iota closer to resolving this issue. which is simply change the definition for this term from

Length measurement of the left gonad.

to

Width measurement of the right gonad.

@campmlc
Copy link

campmlc commented May 1, 2023

I personally would prefer to have left and right be optional and put in methods, keeping "gonad length" and "gonad width" as the attribute values. That way we can use these for data where right/left is not specified and migrate the large amount of legacy data on testes measurements from the open text field "reproductive data" to these attributes. But if these proposed attributes are only to be used for new data, then that is not a relevant concern. @bryansmclean @jldunnum
If we aren't making that change - then I support:

Change the definition for this term from

Length measurement of the left gonad.

to

Width measurement of the right gonad.

@dustymc
Copy link
Contributor Author

dustymc commented May 1, 2023

@campmlc I'm not sure if you're responding to what you quoted, doesn't really make sense from here??

Yes parts are physical, the model is public you don't need to take my word for it.

If someone's measuring a part I'd like to think it exists. (And if the part was kept it then someone might want to record measurements with it and that could lead to identical data in two places which is never good, but I think that's all theoretical and so can be ignored at the moment.)

don't think you are considering the impacts

Pretty sure I am, which is why I'm saying (again) that the maybe-imperfect record attribute approach still looks right from here. Are you advocating something else? I think this is where we're not communicating, but ?????????

MaterialSample is part of an exchange standard, parts are data-carrying objects in Arctos, there's no switch to be made???

left and right be optional and put in methods

I'd like to avoid a bunch of ways to doing the same thing if at all possible. It looks to me like mammals doesn't really need the direction, but if birds does then the attribute will need to exist and it would be useful to find some common ground (or, failing that, perhaps guiding documentation, eg how to respond when a mammal collection inevitably asks for a bird-thing in a year). I think Beth is saying that birds can live without the direction too (#6189 (comment)), and if that's the case then migrating this to 'gonad' seems like a reasonable place to start.

Here's what I think are all related attributes and their collection contacts - can we set up a Zoom to resolve this?

create table temp_lra as
select
    guid_prefix,
    concat_ws(':',guid_prefix,cat_num) as guid,
    attribute_type,
    attribute_value,
    attribute_units,
    getPreferredAgentName(determined_by_agent_id) determiner,
    attribute_remark,
    determination_method,
    determined_date
from
    attributes
    inner join cataloged_item on attributes.collection_object_id=cataloged_item.collection_object_id
    inner join collection on cataloged_item.collection_id=collection.collection_id
where
    attribute_type  in (
        'right gonad width',
        'right gonad length',
        'middle toe length',
        'left gonad width',
        'left gonad length'
    )
;


arctosprod@arctos>>  select guid_prefix,attribute_type,count(*) from temp_lra group by guid_prefix,attribute_type order by attribute_type,guid_prefix;
 guid_prefix |   attribute_type   | count 
-------------+--------------------+-------
 CHAS:Bird   | left gonad length  |    28
 CHAS:Teach  | left gonad length  |     1
 CRCM:Bird   | left gonad length  |  5239
 DMNS:Bird   | left gonad length  |     1
 DMNS:Mamm   | left gonad length  |     4
 MLZ:Bird    | left gonad length  |   136
 MSB:Mamm    | left gonad length  |     2
 MVZ:Herp    | left gonad length  |   153
 OWU:Bird    | left gonad length  |     5
 UCM:Bird    | left gonad length  |    50
 UCSC:Mamm   | left gonad length  |     4
 UMNH:Bird   | left gonad length  |     5
 UMZM:Bird   | left gonad length  |     1
 UNR:Mamm    | left gonad length  |     2
 UTEP:Bird   | left gonad length  |     2
 UWBM:Mamm   | left gonad length  |    60
 UWYMV:Mamm  | left gonad length  |     1
 CHAS:Bird   | left gonad width   |    27
 CRCM:Bird   | left gonad width   |  5066
 DMNS:Mamm   | left gonad width   |     6
 MLZ:Bird    | left gonad width   |   136
 MVZ:Herp    | left gonad width   |    62
 MVZ:Mamm    | left gonad width   |     1
 OWU:Bird    | left gonad width   |     4
 UCM:Bird    | left gonad width   |    49
 UCSC:Mamm   | left gonad width   |     4
 UMNH:Bird   | left gonad width   |     2
 UMZM:Bird   | left gonad width   |     1
 UNR:Mamm    | left gonad width   |     2
 UTEP:Bird   | left gonad width   |     1
 UWBM:Mamm   | left gonad width   |    60
 UWYMV:Mamm  | left gonad width   |     1
 UTEP:Bird   | middle toe length  |    10
 CHAS:Bird   | right gonad length |    21
 CHAS:Teach  | right gonad length |     1
 DMNS:Mamm   | right gonad length |    23
 MLZ:Bird    | right gonad length |     3
 MMNH:Bird   | right gonad length |     1
 MVZ:Herp    | right gonad length |   177
 MVZ:Mamm    | right gonad length |    22
 OWU:Bird    | right gonad length |     7
 UAM:Mamm    | right gonad length |     1
 UCM:Bird    | right gonad length |    47
 UCSC:Mamm   | right gonad length |     1
 UMNH:Mamm   | right gonad length |     1
 UNR:Mamm    | right gonad length |     1
 UTEP:Bird   | right gonad length |     1
 UWBM:Mamm   | right gonad length |    59
 CHAS:Bird   | right gonad width  |    22
 DMNS:Mamm   | right gonad width  |    21
 MLZ:Bird    | right gonad width  |     3
 MMNH:Bird   | right gonad width  |     1
 MVZ:Herp    | right gonad width  |    40
 MVZ:Mamm    | right gonad width  |    21
 OWU:Bird    | right gonad width  |     7
 UAM:Mamm    | right gonad width  |     1
 UCM:Bird    | right gonad width  |    47
 UCSC:Mamm   | right gonad width  |     1
 UMNH:Bird   | right gonad width  |     3
 UNR:Mamm    | right gonad width  |     1
 UWBM:Mamm   | right gonad width  |    59
(61 rows)

temp_lra.csv.zip

@ebraker
@mkoo
@campmlc
@amgunderson
@atrox10
@mvzhuang
@cjconroy
@wellerjes
@jebrad
@jrpletch
@AdrienneRaniszewski
@acdoll
@jldunnum
@jrdemboski
@jessicatir
@ewommack
@kderieg322079
@adhornsby
@droberts49

@campmlc
Copy link

campmlc commented May 1, 2023 via email

@dustymc
Copy link
Contributor Author

dustymc commented May 2, 2023

I think the RANGES consensus was that 'gonad' (including this) should go away for mammals - the useful assertions are more precise (testis) or less precise (repro data).

Suggest we adjust the definition to include something about 'not recommended for mammals,' update, and migrate individual collections by request.

@dustymc dustymc added CodeTableCleanup Our bad data leads to more bad data. Fix it! Accessibility Issue is related to Arctos accessibility. Priority - Wildfire Potential ignore this at everyone's peril, may smolder for now ... labels Aug 30, 2023
@mkoo mkoo mentioned this issue Mar 7, 2024
Closed
8 tasks
@mkoo
Copy link
Member

mkoo commented Mar 7, 2024

AWG Issues meeting on 3/7 confirmed we will not be implementing this request. Instead please see ArctosDB/code-table-work#63, ArctosDB/code-table-work#14, #7503

I missed the 61 records that need to be updated now so will keep open while we update these. (well really 60 rows since I dont know what middle toe length is doing here!)

@dustymc dustymc mentioned this issue Mar 8, 2024
Closed
@dustymc
Copy link
Contributor Author

dustymc commented Mar 8, 2024

Initial comment edited, this has turned into a migration

Data:

temp_rgw.csv.zip

summary


 guid_prefix | count 
-------------+-------
 UCSC:Mamm   |     1
 MVZ:Mamm    |    21
 UNR:Mamm    |     1
 MMNH:Bird   |     2
 CHAS:Bird   |    32
 MVZ:Herp    |    40
 DMNS:Bird   |     5
 DMNS:Mamm   |    21
 CHAS:Mamm   |     1
 CHAS:Teach  |     8
 UAM:Mamm    |     1
 UMZM:Bird   |    19
 UMNH:Bird   |     8
 UWBM:Mamm   |    82
 OWU:Bird    |     7
 MLZ:Bird    |     9
 UMZM:Mamm   |    16
 UCM:Bird    |    47
 UMNH:Mamm   |     1

users

@jrdemboski
@amgunderson
@barke042
@adhornsby
@mkoo
@cjconroy
@atrox10
@jebrad
@acdoll
@ebraker
@droberts49
@kderieg322079
@wellerjes
@jrpletch

@wellerjes
Copy link

CHAS specimens fixed

@Jegelewicz
Copy link
Member

@jebrad for UWBM:Mamm

  1. searched for all UWBM:Mamm with right gonad width attribute and used the view attribute tool to download the right gonad width attributes
  2. used the downloaded attributes to make an upload of gonad width attributes with "was right gonad width" added to attribute_method
  3. loaded new gonad width attributes
  4. used the bulk unload attribute tool to remove right gonad width attributes
  5. removed right gonad width from UWBM:Mamm

file -
UWBM_Mamm right gonad width.xlsx

@dustymc
Copy link
Contributor Author

dustymc commented Sep 6, 2024

merge-->#7504

@dustymc dustymc closed this as completed Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Accessibility Issue is related to Arctos accessibility. CodeTableCleanup Our bad data leads to more bad data. Fix it! Priority - Wildfire Potential ignore this at everyone's peril, may smolder for now ...
Projects
None yet
Milestone
Needs Discussion
Development

No branches or pull requests
10 participants
@mkoo @dustymc @Jegelewicz @cjconroy @bryansmclean @acdoll @campmlc @ewommack @catherpes @wellerjes