Create new specimen event & specimen from collection event

[DerekSikes]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Sometimes we revisit a site & collect new specimens there - it's easy to go to the locality record in Arctos and click "create new collection event" which we can then edit with the new date etc.

However, there is no equivalent button to allow one to create a new specimen event/ specimen from the new collection event. This would be a nice feature.

Describe what you're trying to accomplish An clear and concise overview of the goals; why are you asking for this?

Describe the solution you'd like How might we accomplish your goals?

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

I make the new collection event & copy the CE ID #. Find an old specimen with similar data, clone it, make edits, & then replace the collection event with the new one by searching on the CE ID #. Not very elegant.

Additional context Add any other context or screenshots about the feature request here.

Priority Please assign a priority-label. low

[dustymc]

Collecting events are stand-alone data objects - Arctos can be viewed as a collecting event management tool, and everything else as metadata of those objects.

Specimen events are not independent; they're the intersection of collecting events and specimens, and can't exist without both of those data objects. On the surface, what you ask isn't possible - but we can probably fake it with interfaces if you'll let me know a bit more about how you see this working. Could this just be more options on the "pull" from data entry?

Or ??????

[DerekSikes]

I envision a button that when clicked creates both a specimen event and specimen record that are children of the collection event. All fields that need filling out or links made (eg accession, etc) would need to be satisfied before the record would 'save'

as an aside -

I have yet to find any value in specimen events (wishing instead that all specimens were direct children of collection events) and I and my entomology colleagues still think that collection method belongs in collection event.

-Derek

On Wed, Jul 22, 2020 at 6:36 AM dustymc notifications@github.com wrote:

Collecting events are stand-alone data objects - Arctos can be viewed as a collecting event management tool, and everything else as metadata of those objects.

Specimen events are not independent; they're the intersection of collecting events and specimens, and can't exist without both of those data objects. On the surface, what you ask isn't possible - but we can probably fake it with interfaces if you'll let me know a bit more about how you see this working. Could this just be more options on the "pull" from data entry?

[image: Screen Shot 2020-07-22 at 7 34 17 AM] https://user-images.githubusercontent.com/5720791/88189326-cb7ee480-cbed-11ea-8a2d-b166385c44c1.png

[image: Screen Shot 2020-07-22 at 7 34 25 AM] https://user-images.githubusercontent.com/5720791/88189346-d0dc2f00-cbed-11ea-8ba6-bc1b1a652534.png

Or ??????

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662490852, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFNUMYO6I7MUXFPXG6TXYDR432QTANCNFSM4PEETKAQ .

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum 1962 Yukon Drive Fairbanks, AK 99775-6960

dssikes@alaska.edu

phone: 907-474-6278 FAX: 907-474-5469

University of Alaska Museum - search 400,276 digitized arthropod records http://arctos.database.museum/uam_ento_all http://www.uaf.edu/museum/collections/ento/ +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

[dustymc]

button that when clicked

Is that just "clone this record to data entry" sprinkled around, or something different? (Maybe "clone, but pick what to clone"?)

find any value in specimen events

• beetle ---> collecting method==beetle trap
• phoretic, parasite, etc ---> collecting method==XZY Mesh Screen er sumthin

is the unavoidable use case - no matter how good you are at recording temporospatial data, those should probably share the place-time stack but have dissimilar data in between the place-time and the specimen.

Specimen-event also allows multiple place-time stacks, which are useful for everything from alternate opinions on spatial data to recording mark-recapture or captivity events.

still think that collection method belongs in collection event.

You might not if you were collecting plasmodium from mosquitoes using some noteworthy method (and also cared about the host).

That said, http://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_event_attr_type facilitates putting just about anything "in the event" (and http://arctos.database.museum/info/ctDocumentation.cfm?table=ctlocality_attribute_type in the locality if you don't care about the time/verbatim components). You can very much arrange those parts of the model to suit your tastes, and simply don't use the things that don't meet your needs.

[Jegelewicz]

button that when clicked

Is that just "clone this record to data entry" sprinkled around, or something different? (Maybe "clone, but pick what to clone"?)

I created 140 some-odd localities last week. When you create a locality, you can create a collecting event that uses that locality using "Add Collecting Event". Once you have created the collection event, could we then have the option to "Create a catalog record using this event" that would just take you to the data entry form that has the event pre-filled with the one you just created? I think that is what is proposed?

collection method belongs in collection event.

It seems correct, but that means that you would have two separate events for specimens that were "trapped" and "hand collected" during the same time at the same place. Which is probably valid.

That said, http://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_event_attr_type facilitates putting just about anything "in the event" (and http://arctos.database.museum/info/ctDocumentation.cfm?table=ctlocality_attribute_type in the locality if you don't care about the time/verbatim components). You can very much arrange those parts of the model to suit your tastes, and simply don't use the things that don't meet your needs.

@dustymc you might be making the argument for collecting method to just be an event attribute....

[dustymc]

Create a catalog record using this event" that would just take you to the data entry form that has the event pre-filled with the one you just created? I think that is what is proposed?

That's possible, but I'm not sure it's less work than just pasting the eventID into the pick box - you'd still have to pick the collection and such, so I think it'd be at least as many clicks if not a couple more.

might be making the argument for collecting method to just be an event attribute

That would be fatal for hosts and parasites, or any other co-collected situation. You could put them in two events, which is twice as much work for inevitably-divergent data, yay nobody, or attach two methods to the event which is lossy from the perspective of any specimen.

[DerekSikes]

I suppose this would be of little value given the current structure.

& regarding collection event & method - 'fatal for hosts & parasites' - I disagree. If a host is caught in a pitfall trap and that host has parasites, the parasites were also caught in a pitfall trap. How you get the parasites off the host is part of specimen preparation, not specimen collection. We don't have any good tracking of specimen preparation steps and methods.

-Derek

On Wed, Jul 22, 2020 at 9:35 AM dustymc notifications@github.com wrote:

Create a catalog record using this event" that would just take you to the data entry form that has the event pre-filled with the one you just created? I think that is what is proposed?

That's possible, but I'm not sure it's less work than just pasting the eventID into the pick box - you'd still have to pick the collection and such, so I think it'd be at least as many clicks if not a couple more.

might be making the argument for collecting method to just be an event attribute

That would be fatal for hosts and parasites, or any other co-collected situation. You could put them in two events, which is twice as much work for inevitably-divergent data, yay nobody, or attach two methods to the event which is lossy from the perspective of any specimen.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662587837, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFNUM27BE5R5FNEOBJ3CCTR44POHANCNFSM4PEETKAQ .

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum 1962 Yukon Drive Fairbanks, AK 99775-6960

dssikes@alaska.edu

phone: 907-474-6278 FAX: 907-474-5469

University of Alaska Museum - search 400,276 digitized arthropod records http://arctos.database.museum/uam_ento_all http://www.uaf.edu/museum/collections/ento/ +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

[dustymc]

disagree

I might be convinced, but I don't think I'm there just yet! These are the same sort of thing:

• collecting_method
• collecting_source
• habitat

@campmlc

We don't have any good tracking of specimen preparation steps and methods.

Should fit in part attributes, although I'm not sure I'd want to try without some UI improvements. Put together some demo data and file an Issue!

[campmlc]

I disagree with using different collecting event for parasite and host in order to apply different collecting methods. Saying that a cataloged tapeworm method of collection is "pitfall trap" or even worse, "mist net" doesn't make sense- no evidence yet of flying tapeworms - and really doesn't provide useful data from the parasitology perspective. I rely on shared collecting events as a standard method to link and find parasites and hosts.

But I do agree that adding more specific info on collection and preparation methods would be a good extension of the data. What I would like to see would be the ability to use consistent collection methods for parasitologists, as there are too many ways to say the same thing. Some examples:

visual exam of gastrointestinal tract vs visual exam of GI tract vs "GI tract preserved in 70% ethanol and subsequently dissected after fixation" vs " collected from fluid-preserved specimen" Or combed from study skin vs "field-collected by combing pelage of freshly killed host" Or "by hand" or "field collected" Or "blood smear on slide" vs "blood (frozen) subsequently screened for Plasmodium DNA" etc.

I also agree with Derek that we need to make the existing tools easier to use - especially by integrating the multiple steps that are required for a single, simple action. It is not obvious without training what steps anyone would need to take to clone a locality or event and use that to create a new specimen record, and the process is labyrinthine, to say the least. Having UI improvements that ask the user up front what they need to do and provide guided steps through multiple prompts woud be preferable. If you clone a locality, and then clone the event, the option of adding a new record to the bulkloader at the same time seems reasonable, perhaps with prompts for "what collection" and "what accession"? Otherwise, the user must know in advance to exit Locality or Event and go back to Data Entry. We have a lot of examples of this kind of missing guidance in the UI- where users just have to magically know in advance what the next step is and where to find the appropiate tools for a process, rather than being prompted.

On Wed, Jul 22, 2020 at 1:02 PM dustymc notifications@github.com wrote:

• [EXTERNAL]*

disagree

I might be convinced, but I don't think I'm there just yet! These are the same sort of thing:

• collecting_method
• collecting_source
• habitat

@campmlc https://github.com/campmlc

We don't have any good tracking of specimen preparation steps and methods.

Should fit in part attributes, although I'm not sure I'd want to try without some UI improvements. Put together some demo data and file an Issue!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662630417, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBGREJDGDDEUR276ABDR44ZUFANCNFSM4PEETKAQ .

[jldunnum]

Regardless of what additional data we can include for preparation of parasites I absolutely agree that parasite and host should be in single shared collecting event.

---

Jonathan L. Dunnum Ph.D. Senior Collection Manager Division of Mammals, Museum of Southwestern Biology University of New Mexico Albuquerque, NM 87131 (505) 277-9262 Fax (505) 277-1351

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 notifications@github.com Sent: Wednesday, July 22, 2020 1:35 PM To: ArctosDB/arctos arctos@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [ArctosDB/arctos] Create new specimen event & specimen from collection event (#2949)

[EXTERNAL]

I disagree with using different collecting event for parasite and host in order to apply different collecting methods. Saying that a cataloged tapeworm method of collection is "pitfall trap" or even worse, "mist net" doesn't make sense- no evidence yet of flying tapeworms - and really doesn't provide useful data from the parasitology perspective. I rely on shared collecting events as a standard method to link and find parasites and hosts.

But I do agree that adding more specific info on collection and preparation methods would be a good extension of the data. What I would like to see would be the ability to use consistent collection methods for parasitologists, as there are too many ways to say the same thing. Some examples:

visual exam of gastrointestinal tract vs visual exam of GI tract vs "GI tract preserved in 70% ethanol and subsequently dissected after fixation" vs " collected from fluid-preserved specimen" Or combed from study skin vs "field-collected by combing pelage of freshly killed host" Or "by hand" or "field collected" Or "blood smear on slide" vs "blood (frozen) subsequently screened for Plasmodium DNA" etc.

I also agree with Derek that we need to make the existing tools easier to use - especially by integrating the multiple steps that are required for a single, simple action. It is not obvious without training what steps anyone would need to take to clone a locality or event and use that to create a new specimen record, and the process is labyrinthine, to say the least. Having UI improvements that ask the user up front what they need to do and provide guided steps through multiple prompts woud be preferable. If you clone a locality, and then clone the event, the option of adding a new record to the bulkloader at the same time seems reasonable, perhaps with prompts for "what collection" and "what accession"? Otherwise, the user must know in advance to exit Locality or Event and go back to Data Entry. We have a lot of examples of this kind of missing guidance in the UI- where users just have to magically know in advance what the next step is and where to find the appropiate tools for a process, rather than being prompted.

On Wed, Jul 22, 2020 at 1:02 PM dustymc notifications@github.com wrote:

• [EXTERNAL]*

disagree

I might be convinced, but I don't think I'm there just yet! These are the same sort of thing:

• collecting_method
• collecting_source
• habitat

@campmlc https://github.com/campmlc

We don't have any good tracking of specimen preparation steps and methods.

Should fit in part attributes, although I'm not sure I'd want to try without some UI improvements. Put together some demo data and file an Issue!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662630417, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBGREJDGDDEUR276ABDR44ZUFANCNFSM4PEETKAQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ArctosDB/arctos/issues/2949#issuecomment-662653785, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AED2PAYM6BMH45RHOHINQADR445ONANCNFSM4PEETKAQ.

[dustymc]

flying tapeworms

I don't think that's quite what's being suggested.

consistent collection methods

That's been bouncing around for years - new Issue.

existing tools easier to use

Big-picture, sure, always.

More focused, if people are doing that stuff it's fair to expect they have some training! Folks without training can just use the data entry screen, but things like typos will result in multiple events. Some sort of stepwise process to enter very specific kinds of data is just a custom data entry screen - there's been an API capable of supporting that for ~15 years.

[campmlc]

there's been an API capable of supporting that for ~15 years.

Yes, but it is apparent that none of us trained museum professionals also happen to be trained in UI/API development. Since I lack those skills, that capability is useless to me as an operator. I can, however, suggest what would be helpful to me as an operator to navigate the system, and hopefully we can find someone with the technical skills to implement some of our suggestions.

On Wed, Jul 22, 2020 at 2:09 PM dustymc notifications@github.com wrote:

• [EXTERNAL]*

flying tapeworms

I don't think that's quite what's being suggested.

consistent collection methods

That's been bouncing around for years - new Issue.

existing tools easier to use

Big-picture, sure, always.

More focused, if people are doing that stuff it's fair to expect they have some training! Folks without training can just use the data entry screen, but things like typos will result in multiple events. Some sort of stepwise process to enter very specific kinds of data is just a custom data entry screen - there's been an API capable of supporting that for ~15 years.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662670205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAEVRWBI6MVQHTQSJTR45BOLANCNFSM4PEETKAQ .

[DerekSikes]

re: flying tapeworms. - the question is how were the specimens extracted from the wild? What would someone do who wanted to get more? If tapeworm taxon x are only caught inside birds caught in mist nets then mist nets are how one catches those tapeworms.

& the problem with the current structure is that usually many many specimens are caught with the same method. A single flight intercept trap can catch thousands of specimens over a single 2 week-long collection event. As it stands now that would become thousands of different text strings all saying 'flight intercept trap' - one in each specimen event for each specimen caught in that one collection event. Nothing at all stops someone from misspelling that single collection method 'flight intercept trap' a thousand different ways.

One trap that generates multiple specimens = one collection event for multiple specimens. The collection method is part of what holds those specimens together, they were all caught at the same place, time & with the same method.

-Derek

On Wed, Jul 22, 2020 at 12:09 PM dustymc notifications@github.com wrote:

flying tapeworms

I don't think that's quite what's being suggested.

consistent collection methods

That's been bouncing around for years - new Issue.

existing tools easier to use

Big-picture, sure, always.

More focused, if people are doing that stuff it's fair to expect they have some training! Folks without training can just use the data entry screen, but things like typos will result in multiple events. Some sort of stepwise process to enter very specific kinds of data is just a custom data entry screen - there's been an API capable of supporting that for ~15 years.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662670205, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFNUM2WQVWLF5REVAPWHELR45BOLANCNFSM4PEETKAQ .

--

+++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum 1962 Yukon Drive Fairbanks, AK 99775-6960

dssikes@alaska.edu

phone: 907-474-6278 FAX: 907-474-5469

University of Alaska Museum - search 400,276 digitized arthropod records http://arctos.database.museum/uam_ento_all http://www.uaf.edu/museum/collections/ento/ +++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological Society and / or sign up for the email listserv "Alaska Entomological Network" at http://www.akentsoc.org/contact_us

[Jegelewicz]

See #2866

[Jegelewicz]

I really do think that method of collection should be a "collecting event" attribute. The tapeworms WERE "wild caught" by means of a pitfall trap. A second even should apply to those tapeworms detailing the method of extraction from the host.

[campmlc]

But a second event detailing the method of GI extraction would not be shared with the host. It is critical that we have collecting events shared between parasites and hosts. This is why collecting method has been put in specimen events. I don't see why this is a problem.

On Wed, Jul 22, 2020 at 3:31 PM Teresa Mayfield-Meyer < notifications@github.com> wrote:

• [EXTERNAL]*

I really do think that method of collection should be a "collecting event" attribute. The tapeworms WERE "wild caught" by means of a pitfall trap. A second even should apply to those tapeworms detailing the method of extraction from the host.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662707993, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBHOQ52K25COJX6H4FTR45LELANCNFSM4PEETKAQ .

[dustymc]

If tapeworm taxon x are only caught inside birds caught in mist nets

Yep, there's some science to be had in there - bats with parasites might behave differently etc., how ya gonna know without some data?!

A second even

We don't have to go that far, and I don't think its an either-or situation.

• collecting_event.thing==thing-stuff that covers everything in the collecting event
• specimen_event.thing==thing-stuff that applies to an individual at an event, but not every result of the event.

Nothing at all stops someone from misspelling that single collection method 'flight intercept trap' a thousand different ways.

That's precisely what https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_event_att_att does.

This is why collecting method has been put in specimen events. I don't see why this is a problem.

I agree, but I'm also coming around to the idea that we're giving up data by not having a corresponding event attribute.

[campmlc]

Happy to have an event attribute or a second event even - given the parasites are frequently not even removed from the host and "collected" as separate objects until after the initial host/parasite collection. But we need a "collecting event identifier" like we need an "organism ID" - some uber number that links everything from a specific place/time/set of organisms.

Derek's point brings up the question of why we don't have "specimen event IDs" that can be shared between records? See the specimens in collecting event ID11620032. All the parasites should have been assigned a common specimen event - same place, time, and same person doing georeferencing and assigning the place/time, but that is not currently possible.

On Wed, Jul 22, 2020 at 4:05 PM dustymc notifications@github.com wrote:

• [EXTERNAL]*

If tapeworm taxon x are only caught inside birds caught in mist nets

Yep, there's some science to be had in there - bats with parasites might behave differently etc., how ya gonna know without some data?!

A second even

We don't have to go that far, and I don't think its an either-or situation.

• collecting_event.thing==thing-stuff that covers everything in the collecting event
• specimen_event.thing==thing-stuff that applies to an individual at an event, but not every result of the event.

Nothing at all stops someone from misspelling that single collection method 'flight intercept trap' a thousand different ways.

That's precisely what https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_event_att_att does.

This is why collecting method has been put in specimen events. I don't see why this is a problem.

I agree, but I'm also coming around to the idea that we're giving up data by not having a corresponding event attribute.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662720920, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBG3PD6IVWGOADQOQGLR45PBLANCNFSM4PEETKAQ .

[dustymc]

we need a "collecting event identifier"

We have one. You can use event_attributes to make more if you can't make them unique, or are somehow forced to avoid the "real" identifier.

All the parasites should have been assigned a common specimen event - same place, time, and same person doing georeferencing and assigning the place/time, but that is not currently possible.

No, it's very deliberately not - that's not what specimen-event is or does.

We could give specimen events identifiers as well, but they cannot cannot exist independently of specimens - I'm not sure what it could do.

[campmlc]

On a similar subject, Catalog Item Results -> Manage -> Collecting Events does not work; and have to use Specimen Events instead to update Collecting Events. None of this makes sense to me. This is worth a committee to look over and discuss options, as we should have a group of people all on the same page of how these are to be used who can write documentation for others. I use these tools constantly but am still confused by them and by what tools can and cannot be used in different circumstances for different purposes.

On Wed, Jul 22, 2020 at 4:18 PM dustymc notifications@github.com wrote:

• [EXTERNAL]*

we need a "collecting event identifier"

We have one. You can use event_attributes to make more if you can't make them unique, or are somehow forced to avoid the "real" identifier.

All the parasites should have been assigned a common specimen event - same place, time, and same person doing georeferencing and assigning the place/time, but that is not currently possible.

No, it's very deliberately not - that's not what specimen-event is or does.

We could give specimen events identifiers as well, but they cannot cannot exist independently of specimens - I'm not sure what it could do.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/2949#issuecomment-662725760, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAA6ZBIID2NZPESS5TR45QT5ANCNFSM4PEETKAQ .

[dustymc]

committee

Oh yes please. https://github.com/ArctosDB/arctos/issues/2916.

[dustymc]

Tabling - I'm not sure what could be done to better address this, please feel very free to reopen and clarify.