Code Table Request - New Catalog Record Attribute: cause of death #6115
Comments
Jegelewicz
added
Priority-High (Needed for work)
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_code_tables will answer that - it's not, and I think it should be expanded for this. This feels like in some ideal world it would all be methods/attributes of 'collecting' specimen-events or similar, but reality exists and we've used record attributes in similar ways, this seems reasonable. I'm checking the box to support a new attribute type 'cause of death' which uses ctkill_method for values. Additions to that table need their own issues (I think, maybe I'm being too paranoid on the procedure thing, those all look reasonable to me). |
That was my gut reaction and perhaps it is where this belongs? I don't want to rush into creating a catalog record attribute if the data would be more useful in the event. |
|
I can see a couple confounding factors. What happens when you have an animal that was hit by a car, still alive, and then you euthanized it? Or an animal with a disease that was euthanized in a hospital? Or an animal that was hunted, and then found to have a disease? You are probably going to have a number of animals where the point of their death is a multi-factor state. For basic collecting info (salvage, shot, net, trap) I put that info in Collecting Method in the Event fields. |
In all cases, you record more than one attribute - date/times are available as well, so you can even record the sequence of events. |
|
But, given the above, I think leaving this as a catalog record attribute makes sense until people are willing to record a "death" event. |
Ain't that the truth! So, maybe this needs de-deathed, which might also accommodate rearing events and experimental parasite infections and whatever. "life event" or something maybe (and does that encompass some other Issues??)
and adding all of those up can be left to the reader.
That's #5688 |
or at least de-killed? I like the idea of life event - a lightweight way to say there is information about when/what happened to something (no locality involved). Change ctkill_method to ctlife_event? I can request the death stuff - because there is data waiting on that - life stuff can come when someone has data. |
Ish? Probably should be made distinct from hacking up carcasses (that's part-stuff) and such, but maybe it could extend some sort postmortem activities (in which case it probably needs a better name)??? Is "scavenged" in here? Could/should this be extended to buses - "painted"??
Yes, and that should be made clear from the documentation - this, wherever it wanders, can't be a replacement for Events. (But it might come to include 'verbatim preservation date' which seems like a pretty decent trade.)
Ugh, I was hoping to avoid a new table, but yea, I think so depending on how some stuff ^^up yonder works out. |
Isn't that condition report [ link ]? |
|
HMMMM - but this would disallow the use of the terms for "cause of death" in a code table, right? attribute = life event not what we are after really? |
Good question. I bet it will differ depending on what type of collection is being handled. I like "Life Event", because a lot of the things you cover are things that can happen during the life of an animal. When you broaden out to objects, where does life end? Other types of things that might occur during a Life Event -> offspring, migration, dispersal, surgery, recovery (from an injury or disease). All of those would be interesting to know, but they might also involve becoming more like a medical chart. Is that where museum data will be going? |
That's parts, which is probably blurry when talking about buses. Maybe pretend I didn't go there... IDK what the scope of this is (maybe don't need to) and I'm not sure what to call it, but I think having a few (<dozens) of big-picture thingee-event-terms in a CT is a worthy goal, especially if it leads to something more useful than eg #4203 (a million ways of saying 'something about roads wasn't particularly healthy').
Like condition report, I suspect - I don't think they'd have a lot of interest in searching (so don't need finite categories) and do have lots of 'method' details, but I don't actually know. |
Can do See also - #6110 |
|
Maybe we could use two things cause of death life event life events could be things like birth, weaning, etc. but cause of death would be an explanation for the life event that is "death". |
|
To give some context here, as a management agency using Arctos, we want to collect both disease status (CWD positive or negative, which is another thread), and cause of death because, as pointed out, we don’t 100% know what ultimately kills an animal in all cases. However, in future, we will be interested in looking at these factors together. Are CWD positive deer more likely to be hit by a vehicle, for example? So wherever these land, we just want to make sure we have a way to capture the various mortality events – in so much as we can make that determination. And we do have some very definitive categories at play here – hunter harvest, depredation, e.g.
Heather K. Evans, Ph.D.
Conservation Geneticist
NC Wildlife Resources Commission
Mailing Address: 11 West Jones Street
Raleigh, North Carolina 27601
Office: 919-707-9285
Mobile: 984-480-6408
ncwildlife.org<http://ncwildlife.org/>
***@***.******@***.******@***.******@***.***
From: dustymc ***@***.***>
Sent: Tuesday, April 11, 2023 3:53 PM
To: ArctosDB/arctos ***@***.***>
Cc: Evans, Heather K ***@***.***>; Mention ***@***.***>
Subject: [External] Re: [ArctosDB/arctos] Code Table Request - New Catalog Record Attribute: cause of death (Issue #6115)
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
condition report
That's parts, which is probably blurry when talking about buses. Maybe pretend I didn't go there...
IDK what the scope of this is (maybe don't need to) and I'm not sure what to call it, but I think having a few (<dozens) of big-picture thingee-event-terms in a CT is a worthy goal, especially if it leads to something more useful than eg #4203<#4203> (a million ways of saying 'something about roads wasn't particularly healthy').
how the Zoo databases handle this info
Like condition report, I suspect - I don't think they'd have a lot of interest in searching (so don't need finite categories) and do have lots of 'method' details, but I don't actually know.
—
Reply to this email directly, view it on GitHub<#6115 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVW2424NSR6QWNQYGAPT2RTXAWZATANCNFSM6AAAAAAW2OSZGM>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
…________________________________
Email correspondence to and from this sender is subject to the N.C. Public Records Law and may be disclosed to third parties.
|
Seems excessive, especially in light of @hkevans comments. I think I still like 'life event'
and MAYBE (if someone shows up with data) that could be extended to 'scavenged,' but definitely not to things that happen to teapots. Yay? |
|
How zoos handle this: from ZIMS Plus they have another table that shows all the medical history comments and events. |
BUT at least for these - there is not a guarantee of death. Any of these might result in injury or pathology or death, so we are sorta mixing two things? Note the definitions requested by @hkevans. A "vehicle encounter" might not cause the death of an individual although it might be an interesting fact someone would want to know if it didn't. How do we distinguish them in the code table? disease – Death caused by disease condition. |
Right, "we don’t 100% know what ultimately kills an animal in all cases." I don't think we want to play overpoliticized coroner here, we just want to record what's known. Maybe the poor deer was smited by the universe itself right before the Peterbilt came along, who knows, we just know it was found all mangled up near the highway. Am I interpreting that correctly @hkevans ? And I like 'event' (euthanized, weaned) better than 'result' (dead, ???????) because I think it's more extensible (eg maybe to things like rearing insects). |
|
I like event - can also apply to wild caught animals brought into
captivity, infected with some cestode larvae, euthanized, examined for
pathology, etc; plus the larvae have events being used to infect something
else. We have a lot of Rausch data like this.
…On Tue, Apr 11, 2023 at 2:56 PM dustymc ***@***.***> wrote:
* [EXTERNAL]*
not a guarantee of death
Right, "we don’t 100% know what ultimately kills an animal in all cases."
I don't think we want to play overpoliticized coroner here, we just want to
record what's known. Maybe the poor deer was smited by the universe itself
right before the Peterbilt came along, who knows, we just know it was found
all mangled up near the highway. Am I interpreting that correctly @hkevans
<https://github.com/hkevans> ?
And I like 'event' (euthanized, weaned) better than 'result' (dead,
???????) because I think it's more extensible (eg maybe to things like
rearing insects).
—
Reply to this email directly, view it on GitHub
<#6115 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBG4FXHZ2RKYED3NE3DXAXANTANCNFSM6AAAAAAW2OSZGM>
.
You are receiving this because you are on a team that was mentioned.Message
ID: ***@***.***>
|
Or just exposed; the 'event' doesn't necessarily have to lead to a 'result' (or state or whatever that is), and we won't necessarily know about it if it does. |
|
Yes, but the event is a collection of a dead deer. So we would want to note that, and then maybe we could remark somehow on what we conjecture to be the cause of death? Are we 100% right all the time? Maybe not, but in some cases, we are 100% percent sure (hunter harvest) and in the other cases we’re pretty sure (vehicle) - and if you ask my biologists, they will argue with you that they are very very sure. Is there a way to build in a remark for “likely cause of death” that goes along with the event?
Heather K. Evans, Ph.D.
Conservation Geneticist
NC Wildlife Resources Commission
11 W. Jones St.
Raleigh, NC 27601
Office: 919-707-9285
Mobile:984-480-6408
ncwildlife.org
On Apr 11, 2023, at 4:55 PM, dustymc ***@***.***> wrote:
CAUTION: External email. Do not click links or open attachments unless you verify. Send all suspicious email as an attachment to Report ***@***.***>
not a guarantee of death
Right, "we don’t 100% know what ultimately kills an animal in all cases." I don't think we want to play overpoliticized coroner here, we just want to record what's known. Maybe the poor deer was smited by the universe itself right before the Peterbilt came along, who knows, we just know it was found all mangled up near the highway. Am I interpreting that correctly @hkevans<https://github.com/hkevans> ?
And I like 'event' (euthanized, weaned) better than 'result' (dead, ???????) because I think it's more extensible (eg maybe to things like rearing insects).
—
Reply to this email directly, view it on GitHub<#6115 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AVW242ZXA34WKLDEPK3BDZDXAXANTANCNFSM6AAAAAAW2OSZGM>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
…________________________________
Email correspondence to and from this sender is subject to the N.C. Public Records Law and may be disclosed to third parties.
|
|
@hkevans all attributes include a remark - so you could definitely add that. I just don't want you to feel like you have to add something as a remark when it could be conveyed through the attribute itself, which is what was originally requested. If using the remark to indicate "death" works, then we will need to adjust definitions for the terms. hunter harvest - Killed by humans for food or to control a population. |
|
I know this is crazy - but this is where I can see begin and end dates working for attributes...but then maybe we are just turning attributes into events. |
|
I'm trying to be as general as possible to hopefully make this work for as large and diverse an audience as possible. (And sometimes that's not productive, but I think it might be here. I could be wrong, I'm not morally opposed to a simpler 'cause of death' or whatever approach, but I do suspect we'll find a bunch of overlap when the lepidopterists or experimental parasitologists inevitably show up.) For some zoo/tagged/whatever thing with 50 events, maybe there'd be no clear ultimate cause of death and I need to spend days reviewing the details to really understand the situation. For a deer, I think this would almost always be one conclusive 'event' - it was found beside the road or harvested. (All attributes have method and remarks so that can be expanded/clarified/whatever as necessary.) I don't see much ambiguity in that, interpreting this as 'likely cause of death' seems perfectly reasonable, at least for a deer with one such determination (and I suspect the people interested in that are going to filter out the zoo cobras with 50 events in a bunch of ways). |
|
Just reading through this again and I think we need to clarify. @dustymc you signed off on this: BUT then there is all the discussion about "life event" and everyone seems to be good with that. If we do that, the proposal would be? Right? |
|
Yes. If we can generalize then this can be used for (much) more than death - which I think is more in line with the original request anyway. ("It seems to have been struck by a car, we don't know if that killed it or not" - fine with 'life events' but completely incompatible with 'cause of death.') I'm still fine with the thing I signed off on too, but the seems like the revision does all that and more, and who doesn't like free functionality!? |
|
At AWG we agreed to add this term, but we did not agree to the code table for it. Should it have a code table or remain free text? @ArctosDB/arctos-code-table-administrators @dustymc @wellerjes |
|
I think it's a new code table, but I don't know if if needs collection partitioning or not. |
I'd be fine with free text. There's a million ways to die, right? But I guess if we have "other" and a code table that works as well. |
mwahahaha That requires a mad scientist laugh. |
|
The original request was looking to get at things like roadkill vs harvest and would have needed a CT/categorical value set - IDK if that's still current or not, but #4203 (900 ways to spell DOR) makes me think there's some value in the idea.
Seems reasonable when/if we find something that can't be categorized and still have something to say about it. |
|
OK - I think a code table makes sense, otherwise we should just keep putting this in remarks somewhere? Adding other as suggested to the original request gets us: hunter harvest - Killed by humans for food or to control a population. Any additions to this list? Changes to the definitions? |
|
I'd like to add "collision," which could include vehicles, or we could keep these as separate categories. Window strikes into buildings are probably my biggest source of salvaged birds. collision - killed by impact, including static structures (window strikes) or by moving objects, such as cars and wind turbines Also, does it make sense to add "collected"? It might be worth pulling out from "euthanized" to make the distinction from a wildlife rehab or wildlife "dispatch" situation (sheriff, state DNRs, etc.) to indicate that an organism was specifically targeted for scientific research. I think an "unknown" value would also be useful. |
|
I sorta think the terms should come in as issues with use cases/discussion/data - this already seems to be turning into a recipe for needing to change a lot of stuff.... Can we limit this issue to the table? From some comments above, I'll propose
|
|
Ahhhh - I always assumed we needed values to create a code table... |
Looking back through this issue, will check a box for this. |
|
I agree with @ebraker's definition of collision. If we are going with code table definitions, there needs to be something like "incidental" to cover unintentional deaths, i.e., an owl eating a mouse that had eaten rodenticide. I'm also happy to go with a free text field! |
|
@wellerjes please see #6115 (comment) - are you OK with the proposed attribute type (and can you find someone to check a box if so)? We can address attribute values in separate issues. See also #6115 (comment) for my current understanding of the need for controlled/categorical values, and please let me know if that's changed. |
|
I support and checked a box. We may also need something free text at some point, or use media, for long free text descriptions e.g. necropsy reports. But this is a good start. |
|
I was going to add, but I feel like everyone is talking about cause of death and the request is: mortality cause - The method by which the cataloged organism died. Is that what we are all agreeing to? |
|
Is there a reason not to just be clear and use "cause of death"? Are we just hoping the euphemism flies under the radar? |
Agree with attribute type and @campmlc has checked the box.
"other" will work. Thanks! |
|
@dustymc I think this is ready, but the code table needs to be created. |
|
As #6115 (comment)? I thought we were starting over.... |
|
wrong tab.... |
|
@dustymc I don't want to create the term without a table to associate it with or we will immediately have people using it as free text. The table doesn't need any values, it just needs to exist? |
|
Sorry, I think I checked my box when we were considering recycling a table, please don't do anything until I (re)check all the boxes. |
|
Done. To add values, file a code table request To add to a collection, click collection settings from https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type or manage collection |
Initial Request
See discussion in https://github.com/ArctosDB/data-migration/issues/889#issuecomment-1503495144 (including the initial request in comments in the same issue).
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.
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_cdemay be found from https://arctos.database.museum/home.cfmPriority: 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.
yes
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.
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).
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.
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.
@ArctosDB/arctos-code-table-administrators @hkevans
The text was updated successfully, but these errors were encountered: