Code Table Request - New Catalog Record Attribute: cause of death

[Jegelewicz]

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

there are attributes for our deer collection that we would like to record but that I don't see; namely cause of death,

cause of death - this has traditionally ended up in collecting event remark (a lot of herpetological records include "DOR" or "dead on road"). Would you want a list of choices to select from or just a free text description?

we are needing to categorize hunter harvest, dead on road, euthanized, disease, vehicle, depredation, and predation as causes of mortality.

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

cause of death

• record attribute mortality cause
• code table ctmortality_cause WITHOUT collection-specific filtering

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

The method by which the cataloged organism died.

Context: Describe why this new value is necessary and existing values are not.

If I have missed that we are somehow recording this consistently elsewhere, please let me know. The code table ctkill_method exists, but I cannot figure out where/how it is being used.

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.

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type

with categorical values in a new code table - ctcause_of_death (or can/should we use the table above?)

hunter harvest - Killed by humans for food or to control a population. euthanized - Humanely put to death. disease – Death caused by disease condition. vehicle – Killed by a motor vehicle. depredation – Killed by humans to mitigate damage to crops, landscaping, or other property. predation – Killed by predator species.

_Collection type: Some code tables contain collection-type-specific values. collection_cde may be found from https://arctos.database.museum/home.cfm_

Bird Herp Mamm Amph Rept Host Teach

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.

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

• [x] 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
• [x] 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
• [x] 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.

@ArctosDB/arctos-code-table-administrators @hkevans

[dustymc]

ctkill_method exists, but I cannot figure out where/how it is being used

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

[Jegelewicz]

This feels like in some ideal world it would all be methods/attributes of 'collecting' specimen-events or similar

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.

[ewommack]

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.

[Jegelewicz]

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?

In all cases, you record more than one attribute - date/times are available as well, so you can even record the sequence of events.

[Jegelewicz]

But, given the above, I think leaving this as a catalog record attribute makes sense until people are willing to record a "death" event.

[dustymc]

death is a multi-factor state.

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

• born
• hit by car
• hunted
• euthanized

and adding all of those up can be left to the reader.

found to have a disease?

That's https://github.com/ArctosDB/arctos/issues/5688

[Jegelewicz]

de-deathed

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.

[dustymc]

de-killed

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"??

lightweight

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

Change ctkill_method to ctlife_event?

Ugh, I was hoping to avoid a new table, but yea, I think so depending on how some stuff ^^up yonder works out.

[Jegelewicz]

extended to buses - "painted"??

Isn't that condition report [ link ]?

[Jegelewicz]

HMMMM - but this would disallow the use of the terms for "cause of death" in a code table, right?

attribute = life event value - death remark - hunter

not what we are after really?

[ewommack]

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? I wonder how the Zoo databases handle this info.

[dustymc]

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 https://github.com/ArctosDB/arctos/issues/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.

[Jegelewicz]

Maybe pretend I didn't go there...

Can do

See also - https://github.com/ArctosDB/arctos/issues/6110

[Jegelewicz]

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

[hkevans]

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.orghttp://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 #4203https://github.com/ArctosDB/arctos/issues/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 GitHubhttps://github.com/ArctosDB/arctos/issues/6115#issuecomment-1504004456, or unsubscribehttps://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.

[dustymc]

two things

Seems excessive, especially in light of @hkevans comments.

I think I still like 'life event'

• born
• weaned
• vehicle encounter
• euthanized

and MAYBE (if someone shows up with data) that could be extended to 'scavenged,' but definitely not to things that happen to teapots.

Yay?

[campmlc]

How zoos handle this: from ZIMS

Plus they have another table that shows all the medical history comments and events.

[Jegelewicz]

'life event'

born
weaned
vehicle encounter
euthanized

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. vehicle – Killed by a motor vehicle. predation – Killed by predator species.

[dustymc]

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 ?

And I like 'event' (euthanized, weaned) better than 'result' (dead, ???????) because I think it's more extensible (eg maybe to things like rearing insects).

[campmlc]

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 https://github.com/ArctosDB/arctos/issues/6115#issuecomment-1504078291, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBG4FXHZ2RKYED3NE3DXAXANTANCNFSM6AAAAAAW2OSZGM . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

[dustymc]

infected with some cestode larvae

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.

[hkevans]

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 @hkevanshttps://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 GitHubhttps://github.com/ArctosDB/arctos/issues/6115#issuecomment-1504078291, or unsubscribehttps://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.

[Jegelewicz]

@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. euthanized - Humanely put to death. disease – Experienced a disease condition. vehicle encounter – Made contact with a motor vehicle. depredation – Killed by humans to mitigate damage to crops, landscaping, or other property. predation – Completely or partially eaten by predator species.

[Jegelewicz]

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.

[dustymc]

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

[Jegelewicz]

Just reading through this again and I think we need to clarify.

@dustymc you signed off on this:

New attribute = cause of death
Definition = The method by which the cataloged organism died.

categorical, values controlled by ctkill_method

Add the following values to ctkill_method

hunter harvest - Killed by humans for food or to control a population.
euthanized - Humanely put to death.
disease – Experienced a disease condition.
vehicle encounter – Made contact with a motor vehicle.
depredation – Killed by humans to mitigate damage to crops, landscaping, or other property.
predation – Completely or partially eaten by predator species.

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?

New attribute = life event
Definition = a lightweight way to say there is information about when/what happened to the cataloged item (no locality involved).

Change ctkill_method to ctlife_event.

categorical, values controlled by ctlife_event

Add the following values to ctlife_event

hunter harvest - Killed by humans for food or to control a population.
euthanized - Humanely put to death.
disease – Experienced a disease condition.
vehicle encounter – Made contact with a motor vehicle.
depredation – Killed by humans to mitigate damage to crops, landscaping, or other property.
predation – Completely or partially eaten by predator species.

Right?

[dustymc]

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!?

[campmlc]

And can use for date of birth for captive animals?

[hkevans]

Life event with categories as defined would work for my purposes.

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.orghttp://ncwildlife.org/

@.**@*.**@*.**@.

From: dustymc @.> Sent: Wednesday, May 17, 2023 7:45 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 verified. Report suspicious emails with the Report Message button located on your Outlook menu bar on the Home tab.

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!?

— Reply to this email directly, view it on GitHubhttps://github.com/ArctosDB/arctos/issues/6115#issuecomment-1552220337, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AVW242Z3ZA76GL325ZHSEJDXGVPIHANCNFSM6AAAAAAW2OSZGM. 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.

[ccicero]

@Jegelewicz At the Code Table meeting 18 May 2023 we talked about using the existing attribute ctkill_method to enter source of mortality. Change code table term to 'source of mortality' with values:

collision depredation disease euthanized hunter harvested incidental predation

And then use method to be more specific, e.g., how it was euthanized (chloroform, pentobarbital, etc.). Can also use 'detected' for more specific pathology details.

For collision, enter what you know (vehicle, airplane, window, wind turbine, etc.) in method.

Incidental: examples of bycatch or unintentional capture mortality (e.g., found dead in trap).

[ccicero]

Current values in ctkill_method are:

chloroform cyanide frozen

These are not being used so get rid of them for now. They can go into method for a particular source of mortality, as appropriate.

[Jegelewicz]

@ArctosDB/arctos-code-table-administrators I thought we had moved on to making this attribute about life events but the request above is still focused on death. Can we expand this as proposed in https://github.com/ArctosDB/arctos/issues/6115#issuecomment-1552208650? Which would also accommodate https://github.com/ArctosDB/arctos/issues/6110.

New attribute = life event
Definition = a lightweight way to say there is information about when/what happened to the cataloged item (no locality involved).

Change ctkill_method to ctlife_event.

categorical, values controlled by ctlife_event

Add the following values to ctlife_event

hunter harvest - Killed by humans for food or to control a population.
euthanized - Humanely put to death.
disease – Experienced a disease condition.
vehicle encounter – Made contact with a motor vehicle.
depredation – Killed by humans to mitigate damage to crops, landscaping, or other property.
predation – Completely or partially eaten by predator species.

[dustymc]

@ArctosDB/arctos-code-table-administrators thought the expansion to 'life event' was too - sloppy? broad? Something like that, I think...

Under that viewpoint, non-mortality events would be in a separate code table under a separate attribute.

(I'm not sure how I feel about that, especially in light of the recent 'fewer attributes, more metadata' enlightenment, but I guess for at least a few minutes I couldn't see any fatal flaws...)

[Jegelewicz]

I don't really care either way, but we are still going to need to address #6110 and - I'd be happy to have a life event attribute with a value of "death" with a date, then the "cause of death" described in a different attribute = source of mortality.

[campmlc]

I don't really care either way, but we are still going to need to address #6110 and - I'd be happy to have a life event attribute with a value of "death" with a date, then the "cause of death" described in a different attribute = source of mortality.

I agree with this. Then we can also have life event = birth or hatch date as well as date of death, for zoo animals.

[dustymc]

I'd be happy to have a life event attribute with a value of "death" with a date, then the "cause of death" described in a different attribute = source of mortality.

... and all of that sort of bleeding over into https://arctos.database.museum/info/ctDocumentation.cfm?table=ctexamined_detected - eg you might know it was hit by a car because pathology, and maybe you can even attribute it wandering out into the road to some detected disease. I'm not yet sure if that's a bug or a feature, but it keeps showing up in this arrangement.

[Jegelewicz]

I am going to need this soon and it has been around for way too long given that an incoming collection is attempting to enter data using it.

We discussed this a bit at Arctos Tea today as well because this is something that will be more and more useful. @kderieg322079 discussed how researchers have asked whether chemicals used in euthanizing an animal would be found in the tissues post-mortem.

I would like to move on with what @ArctosDB/arctos-code-table-administrators recommended:

Change code table term to 'source of mortality' with values:

collision
depredation
disease
euthanized
hunter harvested
incidental
predation

And then use method to be more specific, e.g., how it was euthanized (chloroform, pentobarbital, etc.). Can also use 'detected' for more specific pathology details.

Note that I have new data that include the following:

metodoSacrificio

Encontrado muerto Desconocido Inyeccion de anestesia CO2 Roxicaina en spray Lidocaina Chloretone Anestesia topica llega muerto Lidocaína al 2% Roxicaina Anestecia topica

which will need translation, but could definitely be used with this attribute/methods

Can we get this going?

[campmlc]

I support this, but I prefer cause of death as simpler and clearer term. Also, do we have the option of encumbering this attribute?

On Tue, Aug 1, 2023, 5:20 PM Teresa Mayfield-Meyer @.***> wrote:

• [EXTERNAL]*

I am going to need this soon and it has been around for way too long given that an incoming collection is attempting to enter data using it.

We discussed this a bit at Arctos Tea today as well because this is something that will be more and more useful. @kderieg322079 https://github.com/kderieg322079 discussed how researchers have asked whether chemicals use din euthanizing an animal would be found in the tissues post-mortem.

I would like to move on with what @ArctosDB/arctos-code-table-administrators https://github.com/orgs/ArctosDB/teams/arctos-code-table-administrators recommended:

Change code table term to 'source of mortality' with values:

collision depredation disease euthanized hunter harvested incidental predation

And then use method to be more specific, e.g., how it was euthanized (chloroform, pentobarbital, etc.). Can also use 'detected' for more specific pathology details.

Note that I have new data that include the following: metodoSacrificio

Encontrado muerto Desconocido Inyeccion de anestesia CO2 Roxicaina en spray Lidocaina Chloretone Anestesia topica llega muerto Lidocaína al 2% Roxicaina Anestecia topica

which will need translation, but could definitely be used with this attribute/methods

Can we get this going?

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/6115#issuecomment-1661231383, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBD4KWP2ZQVFAKYZVGDXTGFLPANCNFSM6AAAAAAW2OSZGM . You are receiving this because you are on a team that was mentioned.Message ID: @.***>

[ewommack]

As long as Collection Method in event remains the same I can't see a problem. You'll have a ton of discrepancy between collections, but if it helps a collection keep their notes together go for it.

I can't see using it a ton when I'm talking about collected animals. They are all technically "euthanized", but there are many different methods of euthanasia. Most IACUCs now are actually requesting two when you are collecting - a primary and a back-up that you have to go through after the primary to guarantee the poor animal does not wake up later in a bag in a freezer. My primary may be chemical based, and my back-up is physical. Or I may have two different physical methods.

[dustymc]

Collection Method in event

For the sake of clarity: It's not, but https://github.com/ArctosDB/arctos/issues/6218 will add that option.

many different methods

That is precisely why attributes have method, and why it can't be categorical. If your complex 37-step euthanasia ritual might help some far-future user (eg, one wielding tech that you can't now imagine) understand something, then you should explain it (or maybe point to the publication - perhaps whatever your IACIC approved - which explains it).

[ewommack]

Collection Method in event

For the sake of clarity: It's not, but https://github.com/ArctosDB/arctos/issues/6218 will add that option.

We're going to replace record_event_collecting_method with a record attribute instead? I'm confused by that comment.

Otherwise my above comments stands, and as long as we have a free text in event for method of acquisition I'm fine with adding a record attribute for cause of death.

[Jegelewicz]

replace record_event_collecting_method with a record attribute instead?

Not with a record attribute, with a collecting event attribute

[ewommack]

So the field will go away?

[Jegelewicz]

So the field will go away?

That remains to be determined (see the discussion about habitat, which is quite similar here), but for the purposes of normalization, I think we should pick one or the other.

[dustymc]

 create table temp_ce as select collecting_method,count(*) from specimen_event group by collecting_method order by collecting_method;
SELECT 7850

temp_ce.csv

[Jegelewicz]

@ebraker thinks is event attribute "mortality source" with code table.

[Jegelewicz]

stuff dead in a trap or while being banded, etc. would be incidental with the rest in method

This is about HOW IT DIED - Make a new issue and also for the code table.

[Jegelewicz]

@ebraker @Nicole-Ridgwell-NMMNHS @dustymc @ccicero

I know that we decided to move this to event attributes, but it is giving me heartburn! Things often don't die during the collecting event (where we are planning to put this). Instead they were already dead or they are killed shortly after collection. Placing this IN the event is just rubbing me the wrong way. I think of most catalog records as a proxy for an organism, and that it would make sense to have this as a record attribute with the date of mortality in determined date?

I think there is a different thing we may want in the event and it looks like dwc:vitality - https://dwc.tdwg.org/terms/#dwc:vitality An indication of whether a dwc:Organism was alive or dead at the time of collection or observation.

Someone talk me down....

[dustymc]

record attribute

I can't see what else could deal with an hour-long event in which you band 3 birds and oopsie the 4th. It'll be a bit redundant when you're just collecting with the mist net, but I can't see how to avoid that without losing functionality (or scattering data by eg introducing event-level AND record-level options).

[ebraker]

I still think this belongs in collecting_event. Most things found dead are presumed to have died same day or within a day or two (otherwise they would likely be in bad shape, not museum quality) and collect_date serves as a near-proxy of death date in these cases. This resolution is probably fine for many applications other than amplifying DNA/RNA from salvaged tissues.

Placing this info in collecting_event also allows for finer resolution if needed.

Whatever we do, habitat, collecting_method and mortaity_source need to be in the same place. I don't think that place is record_event. Record_attribute is OK, but collecting_event makes the most sense and allows flexibility and likely accommodates the majority of use cases.