IPM module

[Jegelewicz]

From @ebraker
I think there is real opportunity to flesh out an IPM module for managing IPM tasks - either a separate table that can link to containers, media, taxonomy(?), and charts(?), or if kept as an environmental parameter, a series of linked code tables.

A checklist of common pest species with a count field is probably easiest when dealing with traps (e.g., we maintain 28 sticky monitors that pick up dozens of bugs each that are checked monthly, so typing in names could quickly become cumbersome), though perhaps the check boxes could magically relate to taxonomy.

common museum pests:

Common	Scientific
Webbing Clothes Moth	Tineola bisselliella
Casemaking Clothes Moth	Tinea pellionella
Brown-dotted Clothes Moth	Niditinea fuscella
unknown Clothes Moth	Tineidae
Angoumois Grain Moth	Sitotroga cerealella
Indian Meal Moth	Plodia sp.
unknown Grain Moth	Pyralidae
Museum Beetle	Anthrenus museorum
Vodka Beetle	Attagenus smirnovi
Black Carpet Beetle	Attagenus unicolor
Common Carpet Beetle	Anthrenus scrophulariae
Varied Carpet Beetle	Anthrenus verbasci
Furniture Carpet Beetle	Anthrenus flavipes
Dermestid Beetle	Dermestes maculatus
Larder Beetle	Dermestes lardarius
Odd beetle	Thylodrias contractus
Cigarette Beetle	Lasioderma serricorne
Drugstore Beetle	Stegobium paniceum
Sawtoothed Grain Beetle	Oryzaephilus surinamensis
Foreign Grain Beetle	Ahasverus advena
Powder-post Beetle	subfamily: Lyctinae
Shiny spider Beetle	Gibbium aequinoctiale
unknown beetle	Order: Coleoptera
Silverfish	Lepisma saccharina
Firebrat	Thermobia domestica
Springtail	Order: Collembola
Book Lice	Liposcelis sp.
American Cockroach	Periplaneta americana
Oriental Cockroach	Blatella orientalis
Western Drywood Termite	Incisitermes minor
Subterranean Termite	Rhinotermitidae
House Mouse	Mus domesticus
Norway Rat	Rattus norvegicus
Other
Unknown

IPM Attributes (in addition to tracking trap location and pest name):

• Life Stage

Life Stage	Definition
egg	age_class code table
larva	age_class code table
adult	age_class code table
unknown	age_class code table

• Risk Category

risk category	definition
incidental/low	no direct damage but may be a food source for damaging pests
predator/medium	no direct damage but feeds on dead insects and may indicate presence of damaging pests
indicator/high	traditional museum pest that may signal a problem (leaks, unsealed entry points) or cause direct damage to collections
unknown	risk level unknown

We may also want to add pests detected and treatments that link directly to Parts (via part_attributes?) for those pests or signs of pests found directly on objects and not in traps:

• Pests Detected (also include related fields for pest_species, detected_date and detected_notes)

Pests Detected	Definition
frass	excrement
eggs	eggs
casings	shed larval skins
clippings	detached fur or feather
exit holes	bore holes
webbing	silken structure
live	live larva or adults found
damage	grazing marks or areas of loss on object(s)

• Treatment (also include fields for treatment_begin_date, treatment_end_date, treatment_agent, treatment_notes)

Treatment	Definition
low temperature	use of lethal cold temperatures, freezing
high temperature	use of lethal warm temperatures, such as solar bagging
anoxic	use of a low-oxygen environment to kill pests, such as  oxygen scavengers or a controlled atmosphere (CO2, nitrogen, argon chamber)
chemical	pesticides, fumigation
mechanical	lethal trapping

I'm just dumping thoughts...not a request at this point would like to discuss.

Originally posted by @ebraker in #2515 (comment)

[dustymc]

@ebraker all agreed in principle, but I'm not there on the approach yet.

Most of this works with cataloged items, and that works whether you set out to build an IPM approach or just happen to have an entomologist wandering around the building. I think it's just a much more powerful approach that also happens to be less work and results in more, and more accessible, data.

We have a place for common name.

We have various flavors of "life stage."

Risk category is new but seems useful (and extends beyond bugs - could be useful for weeds in a bot garden or mammals in the dumpster). Maybe a new classification term, or a new classification (like we do with CITES data).

treatments that link directly to Parts

is broadly useful. I'm pretty sure it's part attributes, what the data look like is still sorta fuzzy to me. See also #1908

"pests detected" is parts; the recent work of the paleo folks regarding trace parts will be useful for eg exit holes.

We've talked about "looked for {taxa}, didn't find any" a few times, but I'm not sure if there's a single great approach to this yet. The parasitologists (ecologists, etc.) should find this useful and probably have clever things to contribute.

The last treatment table would just be containers in my happy little fantasy world - this bag of uncataloged rats was (via accn barcode) scanned into that barcoded freezer (argon chamber, vat of bleach, whatever), and here's the temp (O2, salinity, whatever) log (in container environment). I'm not sure anyone's that organized, but I think we all care about the same things and fleshing this out should be useful for non-IPM 'treatments' as well.

Some discussing the details, some minor and non-structural (I think) data-shuffling, perhaps a bit of UI (all of which are broadly useful), a new report or something, and this becomes something that just happens from your normal activities instead of something new that requires extra work, is deeply integrated into all the normal Arctos data (eg, you'd inherit taxonomic changes, relationships, etc. from the entomologists) and the data become useful for much more than just IPM. Yay everybody?!

[ebraker]

Hmmm, I'm not sure I'm on board with a voucherless IPM collection. Entering catalog records is a lot of work, whether from data entry or via bulkloading, and entering IPM records using the full suite of data entry options feels like a lot of additional unnecessary steps (especially for a non-permanent collection). If I have 28 traps that I check each month, and each trap averages 4 species of arthropod, that makes for a minimum of 1344 records annually. Given the amount of unknown arthropods that show up in traps, we'd generate a good chunk of records with "Arthropoda" or "Insecta" that would likely never get better IDs (either bug gets discarded, or record would be accompanied by a photo of hard to ID crumpled desiccated bug). This system could get expensive if collections are paying per record. I also question if this model would intuitively bring everything into one place the way I imagine an IPM module would.

Instead, a simplified table: date checked, agent, trap number (already tied in to container hierarchy), pest species (drop down), count, life stage, risk category, remarks, and the capability to add multiple rows in order to represent different species/life stages from the same trap would suffice (112 records annually using the parameters above). The most important aspect would be the ability to easily generate reports or graphs by pest species, trap number, building, room, floor, risk category etc. so we can see what is happening with the pest population over time and detect spikes in activity. Seems like this could be a stand-alone module, or a built out container environment table.

If we go with the catalog record model, then container environment seems like it might work for treatment. If we move away from a catalog record-based model, I think pest detection would be best in part_attributes with a nested treatment table so it is easy to see how the infestation issue was addressed without too much digging. In this case, it would be cool if the IPM module could pull in affected parts to give users a total view of pest activity - from monitoring to damaged specimens/objects to treatment tasks.

It would be great to have media in this module - we could even have an internal Arctos crowd sourcing option if folks want help with IDs (akin to/using the bad data dashboard).

[dustymc]

voucherless IPM collection

Certainly not a requirement; you could catalog that crumpled desiccated bug (which probably still has DNA), and those bad photos might make perfect sense to the right entomologist (or not...). In some cases you might just catalog the trap.

a simplified table:

... which could just write to the bulkloader, which is designed to accommodate customized entry apps.

would likely never get better IDs

If that's all the precision you need, Arctos is happy with that. Maybe they'll be useful to someone who'll identify them at some point.

It also seems like it would be useful to have stuff cataloged in case it turns out to be important later, but I suppose you'll have plenty of material for identification if that happens.

pest detection would be best in part_attributes

IPM stuff aside, there's a functional difference. One's recording something for a cabinet, the other's recording the same thing for all 18000 mosquito-parts in the cabinet. There are bulkloaders, but selecting specific parts tends to bet tricky.

have media in this module

I don't think that would be problematic - Media is designed to hook random things together.

reports or graphs by pest species

That's more problematic - if this was done in strings then it'll quickly get confusing as the taxonomists do their thing, if it's not then - well, I'm not sure, build something that looks a lot like cataloged item, but isn't called cataloged item, so we can hook into taxonomy (maybe via not-identification, with not-identification-agents and ...).

could get expensive

That's an administrative issue which I can't address, but I'd certainly encourage finding a model that accommodates this sort of thing. "I'd like to use the cool features of Arctos but it'll run my bill up too much" is NOT something I ever want to see!

intuitively bring everything into one place

I want to say 'just UI' but yea, writing "pretty" code to simple structures is easier than writing to complex structures.

I'm not suggesting anything other than considering the possibilities. If this is just a simple table and nobody cares about deeper taxonomy and such then we can do that. If it's going to require a bunch of linkages that already exist in other forms, and could serve here, then maybe we should just use them. I do think an "IPM module" would be a fabulous addition, whatever form it takes.

[Jegelewicz]

Possible to have a single IPM collection for all Arctos collections to use? Other Identifiers could allow us to find just "our" stuff (although ideally the barcoded traps would do that...). It's a service of Arctos - included in the fee you already pay.

We could do some serious publication if we could get several collections to use it correctly....

[dustymc]

single IPM collection for all Arctos

I don't see any technical problem with that.

service of Arctos - included in the fee you already pay.

I'd support something like that, however the collection(s) are arranged.

[campmlc]

I agree that creating a separate catalog for IPM, while perhaps theoretically useful from a data model perspective, is not a practical option for overworked collection managers struggling to get specimens and specimen data curated and digitally available. We need something that will make managers' lives easier,; adding yet more data entry and bulkloading does not fall into that category. What we need is a module or plugin, ideally integrated within Arctos and Arctos object tracking.

…

On Tue, May 12, 2020 at 6:10 PM dustymc ***@***.***> wrote: * [EXTERNAL]* voucherless IPM collection Certainly not a requirement; you could catalog that crumpled desiccated bug (which probably still has DNA), and those bad photos might make perfect sense to the right entomologist (or not...). In some cases you might just catalog the trap. a simplified table: ... which could just write to the bulkloader, which is designed to accommodate customized entry apps. would likely never get better IDs If that's all the precision you need, Arctos is happy with that. Maybe they'll be useful to someone who'll identify them at some point. It also seems like it would be useful to have stuff cataloged in case it turns out to be important later, but I suppose you'll have plenty of material for identification if that happens. pest detection would be best in part_attributes IPM stuff aside, there's a functional difference. One's recording something for a cabinet, the other's recording the same thing for all 18000 mosquito-parts in the cabinet. There are bulkloaders, but selecting specific parts tends to bet tricky. have media in this module I don't think that would be problematic - Media is designed to hook random things together. reports or graphs by pest species That's more problematic - if this was done in strings then it'll quickly get confusing as the taxonomists do their thing, if it's not then - well, I'm not sure, build something that looks a lot like cataloged item, but isn't called cataloged item, so we can hook into taxonomy (maybe via not-identification, with not-identification-agents and ...). could get expensive That's an administrative issue which I can't address, but I'd certainly encourage finding a model that accommodates this sort of thing. "I'd like to use the cool features of Arctos but it'll run my bill up too much" is NOT something I ever want to see! intuitively bring everything into one place I want to say 'just UI' but yea, writing "pretty" code to simple structures is easier than writing to complex structures. I'm not suggesting anything other than considering the possibilities. If this is just a simple table and nobody cares about deeper taxonomy and such then we can do that. If it's going to require a bunch of linkages that already exist in other forms, and could serve here, then maybe we should just use them. I do think an "IPM module" would be a fabulous addition, whatever form it takes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2677 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBH2FKLCKXKDGFPGMPDRRHQO7ANCNFSM4M7DZXAA> .

[ebraker]

Obviously just speaking for me here, but I don't think linking to taxonomy is critical for an IPM module. Since my treatment approach is almost certainly going to be freezing, I essentially just want to derive a general categorization - tolerable pest vs concerning pest - to guide my actions. Knowing the ID of what bug is in my trap is a step on the way to what I really want to know, which is what threats to my collection or archives does the pest pose, or what housekeeping issues can it indicate. So maybe this warrants another attribute, food_source:

Food Source	Definition
protein	feeds on protein sources including keratin, e.g. skin, leather, feather, horn, hair, silk, wool
cellulose	feeds on cellulose sources including paper, basketry, dried plants, grains
starch	feeds on starch sources including paper, coated paper, and book bindings
mold	feeds on mold, attracted to damp spaces
wood	feeds on wood, often spends larval stage boring inside wooden objects
unknown

I think a report/graphing capability would be pretty critical for the module so that personnel can detect pest activity deviating from baseline levels and determine tolerance thresholds.

Cataloging crumpled, appendage-less bugs pulled from sticky traps sounds....er... aspirational ;) Happy to take a quick phone photo though!

[Jegelewicz]

Cataloging crumpled, appendage-less bugs pulled from sticky traps sounds....er... aspirational Happy to take a quick phone photo though!

It seems like we could make something like this work

... which could just write to the bulkloader, which is designed to accommodate customized entry apps.

We should think big here but aim for simple, if that makes sense.

You catalog the contents of the trap with a simplified data entry form. Use the A {string} and add all of the taxa that you see in the trap identified to the best of your ability. The barcode on the trap provides the locality. You enter began and ended dates the trap was out, add the part "whole organism" if you plan to save the trap, or add no part if you trash it, and attach a a photo.

No more work than entering the info in a spreadsheet, but it is now cataloged in Arctos IPM collection. Searchable by everyone (trying to figure out what something is in your bird drawer? Maybe someone else has seen and ID'd one...) We could start to really say something about what pests tend to show up in what collections under what conditions. In time, we could transition from collection managers to museum collection scientists with real data and reproducible results.

[dustymc]

easier...bulkloading does not fall into that category.

Having just rebuilt the mess for PG, that's somewhere on my radar. The system was designed for lots of custom screens, we're all using the most complex screen possible. I'm not quite sure what to do about that, but I think we at least have to stop making the one shared app more complicated.

my treatment approach is almost certainly going to be freezing,

That's one of the use cases for which accn-containers and container environment was developed. It's potentially important for more than IPM (eg, "gee, this looks like it was frozen, it's not useful for THAT anymore"...). That could be implemented as a pretty simple system - the minimum's something like one reusable barcode and one entry into container environment.

I don't think I'm quite grasping how that's IPM and not just another attribute of the parts which got frozen; I know why we freeze stuff, I'm just struggling to see how we'd make the link between that and checking the cabinet that material will be scanned into (in 6 months) for boll weevils (a year later) in the IPM module.

another attribute, food_source

I thought we had that (someone was hatching insects) but I can't find it.

report/graphing capability would be pretty critical

Agreed, in any implementation.

think big here but aim for simple

Thanks, that's what I'm trying to say! A module will have limited capacity, and changes will almost certainly require code. That may be fine - lots of things work like that. Integrating cataloged records could do much more, which may or may not be useful to current or future users.

You catalog the contents of the trap with a simplified data entry form. Use the A {string} and add all of the taxa that you see in the trap identified to the best of your ability. The barcode on the trap provides the locality. You enter began and ended dates the trap was out, add the part "whole organism" if you plan to save the trap, or add no part if you trash it, and attach a a photo.

And that could be implemented as a few checkboxes.

I'm still not advocating for anything in particular, I don't think I'm capable of predicting what we'll wish we did in a few years in this case, just getting it out there....

[lin-fred]

I see the recording process in two ways.

A module that lets you walk around to each trap and record whats on that trap: insects/pest indication, location, began/end date, and who (at minimum). In this case the insect taxon could be selected from restricted vocab, and an option to type in an A string. Then you hop trap to trap, and hit a button that says upload/save for each one.

Second way is a bulkload style, where you collect all of your traps and put all of this information in at once, and then upload it all.

I think both are critical ways because everyone has different abilities when doing IPM (technology, access to internet, different protocols).
I think a vocab restricted Taxonomy is needed, I don't want free hand typos. But the A string option would be there if someone needed something customized?

[DerekSikes]

It might interest this thread that I've been cataloging misc live arthropods in our museum for the last 18 years - many from sticky traps. I've recently worked with a student to analyze this fauna. See attached poster. A publication is hopefully on its way based on this work as well. I suppose I'm making the argument that the critters living inside a museum can be just as interesting for science as those living outside and shouldn't be treated differently as specimens.
Sikes_Proof 2.pdf

[campmlc]

That's amazing, Derek! Wonder if we could integrate this with some sort of citizen science platform for cataloging things in people's homes in a specific Arctos portal. This would be like Teresa's shared IPM portal. If this can be done through Arctos tools that make IPM tasks easier rather than more difficult for Arctos users (especially non-arthropod collections managers!) I'd be interested.

…

On Wed, May 13, 2020 at 9:46 AM DerekSikes ***@***.***> wrote: * [EXTERNAL]* It might interest this thread that I've been cataloging misc live arthropods in our museum for the last 18 years - many from sticky traps. I've recently worked with a student to analyze this fauna. See attached poster. A publication is hopefully on its way based on this work as well. I suppose I'm making the argument that the critters living inside a museum can be just as interesting for science as those living outside and shouldn't be treated differently as specimens. Sikes_Proof 2.pdf <https://github.com/ArctosDB/arctos/files/4623068/Sikes_Proof.2.pdf> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2677 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBGS2GZ7XEFD6I3P423RRK6DVANCNFSM4M7DZXAA> .

[dustymc]

Thanks @DerekSikes - it's good to see that the idea of IPM data being useful for more than IPM isn't entirely fantasy!

citizen science platform

I'm not sure it could be fully automated, but the authorities for building a data entry screen are available as services, the bulkloader is available as an API, and Arctos obviously has a public UI. That's just leaves a "manager" approving records.

[DerekSikes]

There's already a multi-year citizen project in iNaturalist called "never home alone: the wildlife of our homes" https://www.inaturalist.org/projects/never-home-alone-the-wild-life-of-homes feel free to join & add observations! I'm doing so & also trying to make each observation into a museum specimen (a lot easier to say than do!)

…

-Derek

On Wed, May 13, 2020 at 8:06 AM dustymc ***@***.***> wrote: Thanks @DerekSikes <https://github.com/DerekSikes> - it's good to see that the idea of IPM data being useful for more than IPM isn't entirely fantasy! citizen science platform I'm not sure it could be fully automated, but the authorities for building a data entry screen are available as services, the bulkloader is available as an API, and Arctos obviously has a public UI. That's just leaves a "manager" approving records. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2677 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFNUM3PBP65INE3HVDZG2LRRLASFANCNFSM4M7DZXAA> .

-- +++++++++++++++++++++++++++++++++++ Derek S. Sikes, Curator of Insects Professor of Entomology University of Alaska Museum 1962 Yukon Drive Fairbanks, AK 99775-6960 [email protected] 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

[campmlc]

Very cool! I will definitely join. But I don't have access to an Arctos collection to deposit vouchers, virtual or otherwise, even though I have bugs in alcohol on my kitchen counter. To my knowledge iNat doesn't allow for catalog numbers or guids to be entered?
If we did have a shared IPM or public portal, would we have multiple collections with permissions to mark to load?

[Jegelewicz]

But I don't have access to an Arctos collection to deposit vouchers, virtual or otherwise, even though I have bugs in alcohol on my kitchen counter.

I suggest you try working with @lin-fred

To my knowledge iNat doesn't allow for catalog numbers or guids to be entered?

You can create fields in iNat, so this can be done.

[ebraker]

Very cool Derek.

I am still leaning towards a module. My guess is that many non-Ento collections will not have the resources, capacity or shelf space to create physical IPM collections, though I think there is opportunity for those folks who catalog trap contents to easily relate specimen records to the module. I sort of feel that creating trap contents as specimen records gets away from the utility of an IPM module, especially when thinking about how to efficiently query and view results (e.g., visualize the pests I've caught over the past three years by area of the collections space by risk category by species by season by food source) - obviously doable through Search, but clunky, especially in having to traverse between search results and object tracking. If folks are set on the catalog record model, then maybe we can come up with a way to pull them into a module so we can play with them a bit more, though it still doesn't alleviate the time burden involved in entering full records.

Use the A {string} and add all of the taxa that you see in the trap identified to the best of your ability.

How to relate attributes to individuals when four species are on the trap? Seems we'd want individual records, unless we are able to map life cycle, risk category etc. to each individual found on a trap.

I like the idea of simple form, checkboxes (that relate to taxonomy if people feel we need it), and a shared module where we can harness the power of the crowd, whether inside or outside of Arctos.