arctos
arctos copied to clipboard
ArctosDB
reproductive category
Proposal: Instead of creating many very specific code tables, can we have one 'category' code table with...
https://github.com/ArctosDB/arctos/issues/6594
vagina perforated closed unplugged closed plugged
https://github.com/ArctosDB/arctos/issues/6593
nulliparous primiparous multiparous parous
lactating not lactating
nipples enlarged
pregnant not pregnant
etc
@ccicero @mkoo @ebraker @Jegelewicz
So this would be "reproductive category" or "reproductive status", and we could include all of the above as controlled vocabulary options, as well as potentially other terms related to other taxa - e.g. birds ("laying"), reptiles (gravid) etc? @bryansmclean
Hi all, sorry for delay in responding. From what I can tell, this potential solution leaves off the trait terms, and only preserves their values. The terms are necessary for the community to harvest specific traits for research and biodiversity monitoring. The only way this might work is to prepend values with the trait terms (e.g., lactation::not lactating)
For example, the recent plan to map testis attributes to more general "gonad" attributes still allows the trait term to be tracked confidently, as long as we can assume that the term "gonad" is a synonym of "testis", which is safe. Does this proposal do that? Im happy to discuss on a call if needed.
Would it be possible to discuss at the next code table meeting next Thursday March 4 at 4pm your time, or perhaps during the prior issues meeting? @Jegelewicz @ccicero @dustymc
March 4
I'm not available at that time, but that shouldn't matter.
terms are necessary for the community to harvest specific traits
I don't know what this means; some example data (and questions that might be asked of it) would be really useful.
Im actually dodging proposals and defenses, and one just got scheduled for this Thursday. I will need to switch to another AWG issues meeting. @campmlc or @Jegelewicz would you pick one and let me know which works best??
March 4
I'm not available at that time, but that shouldn't matter.
terms are necessary for the community to harvest specific traits
I don't know what this means; some example data (and questions that might be asked of it) would be really useful.
@dustymc I was saying that this proposed change seems to lose the entity itself (for example, "lactation" or "lactation status"). Could become problematic if very standardized values arent used, which we know occurs. For example, when reviewing a repro trait data field, which trait should one match "enlarged" or "descended" or "not" back to? As a data user, I would think one would prefer to retain the specific attribute terms such that this reads, e.g., "nipple enlargement: enlarged", "testes position: descended", or "lactation status: not".
Next week Thursday April 4 at 2pm MDT/4pm EDT is the code table meeting, so that would be the best time to meet. Does that work? My understanding of this is that there would be one code table with controlled vocabulary - so they would be picked from a standardized drop down. So that could include all the terms below and more. You would be able to search on the reproductive status attribute attribute for any of these terms, and get a download with values in a single column in the attribute download or concatenated as JSON in the main flat search page. It wouldn't overload Arctos with so many attributes causing performance and interface issues- because they will be discoverable from one or a few attributes with a single code table. All of these terms would be parsable and searchable. If I understand correctly, this is similar to the "examined for" and "detected" attributes that share a code table for many different values. @dustymc But let's meet to go over and look at some examples?
ArctosDB/code-table-work#43
vagina perforated closed unplugged closed plugged
ArctosDB/code-table-work#49
nulliparous primiparous multiparous parous
lactating not lactating
nipples enlarged
pregnant not pregnant
etc
One attribute = reproductive description with a code table of possible options
vagina perforated vagina not perforated vagina closed vagina not closed vagina plugged vagina not plugged nulliparous primiparous multiparous parous lactating no lactating yes nipples enlarged nipples not enlarged pregnant no pregnant yes scrotal non-scrotal non-scrotal inguinal non-scrotal abdominal
@jldunnum @bryansmclean joined the CT committee today-- tentatively agreement on this method but the list needs to be reviewed, edited, confirmed by the RANGES folks before our next meeting. We discussed the pros/cons for this and might be useful to include future UI twaeks for data entry (once this is settled)
Im trying to re-do a master list of attributes and then the categories of this particular attribute we are discussing on this thread. I think a prefix of some kind would really help within this attribute to organize very different values by general trait type. Did we discuss this and is it possible? Prefixes could follow the, e.g., ranges list of traits but wouldnt have to.
e.g., vaginal perforation: perforated ... parity: parous ... lactation: no ... pregnancy: yes ... testis position: scrotal
I was really making an effort to remove punctuation from code table terms. If we do this, we cannot keep trying to do that.
Is there a functional reason for not using punctuation? We already have it in the examined/detected code tables, e.g. "detected" = "virus:Orthohantavirus". If we remove punctuation, how will those code table values be changed?
I was really making an effort to remove punctuation from code table terms. If we do this, we cannot keep trying to do that.
Is there an alternative way we can make the long list of repro values more "ordered"? Open to suggestions.
Agreed! We did that based on discussions with the Arctos Working Group!
Jonathan L. Dunnum Ph.D. (he, him, his) Senior Collection Manager Division of Mammals, Museum of Southwestern Biology Research Assistant Professor (LAT) Department of 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: Mariel Campbell @.> Sent: Tuesday, April 23, 2024 10:00 AM To: ArctosDB/arctos @.> Cc: Jonathan Dunnum @.>; Mention @.> Subject: Re: [ArctosDB/arctos] reproductive category (Issue ArctosDB/arctos#7364)
[EXTERNAL]
Is there a functional reason for not using punctuation? We already have it in the examined/detected code tables, e.g. "detected" = "virus:Orthohantavirus". If we remove punctuation, how will those code table values be changed?
— Reply to this email directly, view it on GitHubhttps://github.com/ArctosDB/arctos/issues/7364#issuecomment-2072814478, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AED2PAYXIMVGH7BDRPNNZSTY62AQLAVCNFSM6AAAAABCVVIHLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZSHAYTINBXHA. You are receiving this because you were mentioned.Message ID: @.***>
Im trying to re-do a master list of attributes and then the categories of this particular attribute we are discussing on this thread. I think a prefix of some kind would really help within this attribute to organize very different values by general trait type. Did we discuss this and is it possible? Prefixes could follow the, e.g., ranges list of traits but wouldnt have to.
e.g., vaginal perforation: perforated ... parity: parous ... lactation: no ... pregnancy: yes ... testis position: scrotal
I would like to get this draft attribute list posted here so that we can all move forward entering/bulkloading traits. Is some kind of prefix or punctuation possible?
Is there a functional reason for not using punctuation?
The use of punctuation can cause issues when transferring data to other formats as the punctuation can signal some sort of break in the data (commas are a particular problem for CSV). From my perspective, it also indicates that our term means more than one thing (not normal). I am by no means an expert, but we just keep doing things and we have yet to develop any rules for code tables - Formatting Rules for CT Terms was started and quickly forgotten as we run around putting out fires and thinking narrowly about the most pressing issue.
Prefixes seem like they belong in code table metadata. To be used internally for sorting and broader searches. The list proposed here sorts together:
lactating no lactating yes nipples enlarged nipples not enlarged parous parous multiparous parous nulliparous parous primiparous pregnant no pregnant yes testes abdominal testes inguinal testes not scrotal testes scrotal vagina closed vagina not closed vagina not perforated vagina not plugged vagina perforated vagina plugged
Sorry - I am not an expert - just trying to make this work - see new list.
No worries just trying to understand. Why are we using scrotal as the main term as opposed to testes or gonad? Scrotal or abdominal are modifiers of the testes. We use nipples and vagina so seems like we should use testes.
"testes scrotal", testes abdominal, testes inguinal
@Jegelewicz is trying to consolidate all the various issues, which is a bit confusing. Do we have an updated list as requested by RANGES? Is the request for testes scrotal, testes nonscrotal, or for testes abdominal, testes inguinal? Ditto for vagina perforated vs not vs vagina open, vagina closed? @bryansmclean can you review this list and add/edit as needed so we can all assess?
The following brings it more in line with proposed ranges trait terms (which are now prefixes below). This covers all of the categorial traits we have talked about
lactation no lactation yes
nipple size enlarged nipple size not enlarged
parity multiparous parity nulliparous parity primiparous parity parous
pregnancy no pregnancy yes
testis position non-scrotal testis position non-scrotal abdominal testis position non-scrotal inguinal testis position scrotal
vaginal perforation closed vaginal perforation not closed vaginal perforation not plugged vaginal perforation plugged
@bryansmclean do you really need the " not" values? From a data entry perspective and from UI and download, it seems simpler wording would be much better from a functional perspective. For example, we record "vagina open" and vagina closed" in the field. To do data entry, a student will have to scroll through a drop-down with extra verbiage and confusingly similar terms separated only by a "not". This is a recipe for error. For Arctos data entry and display purposes, could we use the shorter, clearer, simpler two-word terms and put the more complex definition in the documentation?
Im sure this can be tweaked - which ones are you eyeing as error-prone besides the vaginal perforation values?
Any way to convert all the choices into just two words? For examples, could the testes position values be simplified? For example: "testes scrotal, testes non scrotal, testes abdominal, testes inguinal" ?
Nipples enlarged Nipples small
Vagina open Vagina closed Vagina plugged
Lactating yes Lactating no
Pregnant yes Pregnant no
Note I changed the initial noun to an adjective, because using the noun is confusing. Does pregnancy test mean right now, or anytime? Also, how are you defining parity nulliparous vs primiparous etc? Again, I'm just thinking here about what we displaying via the interface for entry and download.