Replies: 32 comments
-
Other stuff from attributes: brood patch [ link ] |
Beta Was this translation helpful? Give feedback.
-
I think a dedicated repro table gets back to the original request (prior to RANGES), and is more attractive as a one-stop for data entry. We have a few additional straggler attributes that Im still working on requests for, Ill try and add them to this thread once I do that. |
Beta Was this translation helpful? Give feedback.
-
This may be the last consideration. Which of the above (or which categories of things above) do you mean? |
Beta Was this translation helpful? Give feedback.
-
Placental scars for example - it really needs numbers (and maybe direction) - it's not clear to me how it might work as a categorical, which might mean
And perhaps someone should propose merging some of the free-text stuff - eg gonad [ link ] (what a useful definition....) and brood patch [ link ] are also free-text repro-related attributes, do we really need all three? If not they could be merged, if so the definitions could be updated to make that clear. |
Beta Was this translation helpful? Give feedback.
-
This should be a case of number+units. And yes direction too. #6588 on the other hand is to capture instances where placental scars were observed, but no count taken. Could just include "placental scarring" and "not placental scarring" in your proposed repro table to fix this |
Beta Was this translation helpful? Give feedback.
-
A question from today's meeting - should we add "repro: " to all reproductive attributes to cluster them together in the UI? |
Beta Was this translation helpful? Give feedback.
-
https://docs.google.com/document/d/1HUXzIXs2qcG-BiCIJ33IXeW6lmOnT1U1U5Xvl7ZbtXo/edit - discussed, individual attributes are better, killing this. |
Beta Was this translation helpful? Give feedback.
-
A thought on organizing growing lists of attributes, and easing the data entry process with that growing list (after yesterday's code table meeting): Could the prefix include a sex modifier? e.g. repro:female:placental scars |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Also starting a thread for existing attributes that need to receive repro: prefix. repro:reproductive data |
Beta Was this translation helpful? Give feedback.
-
Are pregnancy, not pregnancy, lactation and not lactation the proper terms? Seems like these could be the present condition or a prior condition. Pregnant and lactating would be correct for the condition at time of examination.
…______________________________________________________________
Jonathan L. Dunnum Ph.D. (he, him, his)
Senior Collection Manager
Division of Mammals, Museum of Southwestern Biology
University of New Mexico
Albuquerque, NM 87131
(505) 277-9262
Fax (505) 277-1351
Chair, Systematic Collections Committee, American Society of Mammalogists
Latin American Fellowship Committee, ASM
MSB Mammals website: http://www.msb.unm.edu/mammals/index.html
Facebook: http://www.facebook.com/MSBDivisionofMammals
Shipping Address:
Museum of Southwestern Biology
Division of Mammals
University of New Mexico
CERIA Bldg 83, Room 204
Albuquerque, NM 87131
From: ***@***.***>
Sent: Friday, August 18, 2023 7:49 AM
To: ***@***.***>
Cc: ***@***.***>
Subject: Re: [ArctosDB/arctos] repro stuff - RANGES and beyond (Issue ArctosDB/arctos#6599)
[EXTERNAL]
* reproductive (from ArctosDB/arctos#6569<#6569>
New repro: requests
* repro:vaginal perforation ArctosDB/arctos#6594<https://github.com/ArctosDB/arctos/issues/6594>
* repro:parity ArctosDB/arctos#6593<https://github.com/ArctosDB/arctos/issues/6593>
* nipple enlarged - ArctosDB/arctos#6595<https://github.com/ArctosDB/arctos/issues/6595>
* not nipple enlarged - ArctosDB/arctos#6595<https://github.com/ArctosDB/arctos/issues/6595>
* not vaginal perforation - ArctosDB/arctos#6594<https://github.com/ArctosDB/arctos/issues/6594>
* nulliparous, ArctosDB/arctos#6593<https://github.com/ArctosDB/arctos/issues/6593>
* primiparous, ArctosDB/arctos#6593<https://github.com/ArctosDB/arctos/issues/6593>
* multiparous, ArctosDB/arctos#6593<https://github.com/ArctosDB/arctos/issues/6593>
* pregnancy ArctosDB/arctos#6409<https://github.com/ArctosDB/arctos/issues/6409>
* not pregnancy. ArctosDB/arctos#6409<https://github.com/ArctosDB/arctos/issues/6409>
* placental scar (hard to fit this here) - ArctosDB/arctos#6592<https://github.com/ArctosDB/arctos/issues/6592>
* lactation ArctosDB/arctos#6408<https://github.com/ArctosDB/arctos/issues/6408>
* not lactation ArctosDB/arctos#6408<https://github.com/ArctosDB/arctos/issues/6408>
* testis width (no fit?) ArctosDB/arctos#6407<#6407>
* embryo count (?) ArctosDB/arctos#6412<https://github.com/ArctosDB/arctos/issues/6412>
* testis length (?) ArctosDB/code-table-work#2<ArctosDB/code-table-work#2>
—
Reply to this email directly, view it on GitHub<#6599 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AED2PA37QCTGBSAJCPHTZLTXV5XEXANCNFSM6AAAAAA3DDSG5Y>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Good points and I am ok with this change (and will edit the post above) |
Beta Was this translation helpful? Give feedback.
-
Postpartum? |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
pregnancy and (multi)parity are possible simultaneously, which would mean youd select the same attribute twice with different values under the scheme we have now. i know this isnt a roadblock, just pointing it out.
For parsing traits from messy fields in which they currently get dumped (dwc:dynamicProps), pregnant=Y might be preferable to pregnant/non(or not) pregnant. The bot idea scares me a little because you are adding traits that arent actually recorded, but inferred. Its easy enough in my opinion to assume pregnancy if an embryo count is there. |
Beta Was this translation helpful? Give feedback.
-
It probably should, but I also think we have to get away from the viewpoint that any of this is anything like "facts" and metadata can be ignored. (We keep circling around to the idea that even the most straightforward things become ambiguous under close scrutiny if there's no metadata involved!) Part of that metadata involves the Agent making the assertion, which for a bot would be something like https://arctos.database.museum/agent/21344957 - a specific type of an Agent with a 'it's a script, this thing isn't capable of making independent assertions, it's just helped you find something and now you need to go check upstream data to determine if that's all lies or not" remark. (And #5310 clearly needs to consider more than GUIDs - "reciprocal_relationship_bot" maybe hints at something, but https://arctos.database.museum/agent/21344957 is completely unambiguous - same as MVZ:Mamm:27928 vs http://arctos.database.museum/guid/MVZ:Mamm:27928. We can and should fully participate in the Extended Specimen Network!) |
Beta Was this translation helpful? Give feedback.
-
The addition of directions and methods (left, length) makes "method" easy to ignore. So much of the legacy data will not include a determiner, either because we really don't know who recorded the trait or we know, but we don't know the person well enough to create an unambiguous agent. For these reasons I think we have mostly ignored "metadata" in attributes but I think it is time to get more serious about using method and determiner and using them well? Could we build some sort of "method builder" tool that helps create standardized methods? Pick one each of anatomical direction, measurement type (length etc), and then free text for anything else you want to add. Creates a standard format for method and eliminates "L" vs "left" and so on as well as the need for 6 attributes for every measurement. |
Beta Was this translation helpful? Give feedback.
-
I am circling back to this so we maintain momentum for reaching consensus. @cjconroy raises the point of lumping pregnancy (Y/N) in with parity. This seems to make sense, except that the categories for parity can be past or present tense. e.g. primiparous can mean "pregnant for the first time" or "having been pregnant for the first time". [https://en.wiktionary.org/wiki/primiparous]. Pregnant is always in the present tense. What say you @jldunnum @ewommack? |
Beta Was this translation helpful? Give feedback.
-
I kinda think its different in that pregnancy is a definitive observation based on the presence of embryos. Parity data is somewhat subjective because there is a lot of room for error. Just because you didn't see scars doesn't mean it definitively hasn't been pregnant before. Often quite hard to see scars on a very pregnant animal for example.
I guess my thought is that we will likely continue to just enter the straightforward data (i.e. embryos, scars, perforated vagina, etc.) and users can take those data and interpret them as they will. It also means adding data entry; you will now have "pregnant" plus "primiparous" or "multiparous".
…______________________________________________________________
Jonathan L. Dunnum Ph.D. (he, him, his)
Senior Collection Manager
Division of Mammals, Museum of Southwestern Biology
University of New Mexico
Albuquerque, NM 87131
(505) 277-9262
Fax (505) 277-1351
Chair, Systematic Collections Committee, American Society of Mammalogists
Latin American Fellowship Committee, ASM
MSB Mammals website: http://www.msb.unm.edu/mammals/index.html
Facebook: http://www.facebook.com/MSBDivisionofMammals
Shipping Address:
Museum of Southwestern Biology
Division of Mammals
University of New Mexico
CERIA Bldg 83, Room 204
Albuquerque, NM 87131
________________________________
From: bryansmclean ***@***.***>
Sent: Wednesday, August 23, 2023 11:52 AM
To: ArctosDB/arctos ***@***.***>
Cc: Jonathan Dunnum ***@***.***>; Mention ***@***.***>
Subject: Re: [ArctosDB/arctos] repro stuff - RANGES and beyond (Issue ArctosDB/arctos#6599)
[EXTERNAL]
I am circling back to this so we maintain momentum for reaching consensus. @cjconroy<https://github.com/cjconroy> raises the point of lumping pregnancy (Y/N) in with parity. This seems to make sense, except that the categories for parity can be past or present tense. e.g. primiparous can mean "pregnant for the first time" or "having been pregnant for the first time". [https://en.wiktionary.org/wiki/primiparous]. Pregnant is always in the present tense. What say you @jldunnum<https://github.com/jldunnum> @ewommack<https://github.com/ewommack>?
—
Reply to this email directly, view it on GitHub<#6599 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AED2PAZDXOHKIKRBUPOC66DXWY7PPANCNFSM6AAAAAA3DDSG5Y>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
NO! There are about a brazillion ways that could be inferred (some of them maybe even accurate); method is critical.
Withholding method doesn't leave a lot of options! |
Beta Was this translation helpful? Give feedback.
-
Philosophically I totally agree with the need to be specific with method (and other attribute metadata). Will be critical in our larger data universe to make more and more digital attributes usable. However, I'll come back to my assertion that the suite of mammal measurements we are talking about in this thread is relatively small and highly standardized. There simply aren't that many ways that mammalogists infer pregnancy in dead mammals. Ear from crown and ear from notch are problematic as discussed, but are outliers. For the sake of progress for the community and RANGES, can we move ahead as planned? I would like to see more comprehensive attribute metadata tracking but would also argue we should apply this to cases where more interesting and variable metadata actually exist (eg pathogen/viral screening/detection). |
Beta Was this translation helpful? Give feedback.
-
Any additional thoughts on moving forward with these requests? What can RANGES do to help clarify or coordinate? |
Beta Was this translation helpful? Give feedback.
-
I am unclear as to the agreed-upon plan and it seems like there is still uncertainty? #6599 (comment) Before we add or change any of these, I want to make sure that you guys are sure about what you want and that I understand it! |
Beta Was this translation helpful? Give feedback.
-
I agree with Jon to keep pregnancy as a separate attribute from parity. @cjconroy raises a good point about the continuity of these two traits re:female reproductive status, but I do think that parity is much more nuanced to infer while pregnancy is often directly observed by mammalogists doing necropsies. @cjconroy how do you feel about this issue? |
Beta Was this translation helpful? Give feedback.
-
As far as I can see, these reference the same one issue (which we can work to clear up ASAP). The second link you posted doesnt seem to point to an actual issue, but something we agreed to previously. I can post as a separate issue if needed. |
Beta Was this translation helpful? Give feedback.
-
I'm still very unclear on the big picture.
Totally possible that I'm the only one lost on any of that, but if I'm not then maybe some sort of a (brief) roadmap document would be useful? |
Beta Was this translation helpful? Give feedback.
-
I will chime in with a response to #3, which seems easiest to answer right now. YES - establishing a repro: prefix is what we all decided. This seems scalable in that different (future) projects can utilize the prefix, or bin other attributes of interest by other prefixes. |
Beta Was this translation helpful? Give feedback.
-
I think we have decided to leave off prefixes. Tentatively closing. |
Beta Was this translation helpful? Give feedback.
-
Discussed again in Code Table meeting today, with potential path forward if we can clear up communication. @bryansmclean can we schedule a meeting to discuss? |
Beta Was this translation helpful? Give feedback.
-
I'm not using the template because this is exploratory, not a proposal. Someone will need to refile if it becomes more.
Should have have a 'reproductive {class?? state?? something...}' attribute with values....
...?
Seems like a mostly-manageable code table, would provide convenient one-ish-stop shopping for anyone looking for categorical repro stuff.
Some of the above probably won't actually fit.
Somehow grouping these things would probably make the data more accessible to researchers, and harder to get lost in for enter-ers.
I can't quite see how to form a 'number+units repro stuff" attribute, so we may be stuck with ~dozens of '.. length'-type things - I'm not sure how, or if, that should influence this.
Some of this could instead be values in https://arctos.database.museum/info/ctDocumentation.cfm?table=ctexamined_detected - eg "pregnancy" --> "[not] detected".
These could also be implemented as proposed, each individual attributes, many with their own code tables.
See also #6179
@bryansmclean @Jegelewicz
Beta Was this translation helpful? Give feedback.
All reactions