Object Preparation Reporting

[Jegelewicz]

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. In paleo, there is a lot of documentation around preparation that we would like to have associated with the catalog record.

Describe what you're trying to accomplish Display all that is known about an object, and to manage and integrate preparation data with agents (people, organizations), transactions (loans, accessions, permits), object tracking (barcodes , RFID tags) , and usage (publications, projects, citations)

Describe the solution you'd like A "module" for tracking specimen preparation more detailed than what is currently allowed in object tracking and that would be easily accessed from the object record.

Describe alternatives you've considered Use media to link to documents elsewhere or keep the information in a spreadsheet or Google Sheet.

Additional context We would like to make Arctos a total collection management solution so that we don't have information in several different databases.

Note - the NMMNH Prep Lab Manager has created a Google Form to capture the information of interest for their lab.

Priority Please assign a priority-label.

[campmlc]

This could be similar to a LIMS plugin? @ccicero @KyndallH ?

[Jegelewicz]

See also #2450 and https://github.com/ArctosDB/arctos/issues/1908#issuecomment-573099209

[Jegelewicz]

NMMNH is working on a Google Form to hash out details for paleo prep stuff. I am moving our conversation from email to here so that everyone can see what we are up to.

Real quick,

I looked at the settings on google forms and you are allowed to set up to 10 photos (at a predetermined max file size) to attach to each question of the form. So if there are 3 questions that allow for attaching photos than it looks like it allows you to attach 30 pictures to the record max (as long as its not bigger than the set total size limit for each record).

Also, this is what the google spreadsheet looks like when filled out - https://docs.google.com/spreadsheets/d/14KwuToYpHwNwdfdoB0OLe_fkT6FN3sRGCYCfmikhBno/edit#gid=1515079988​ It attaches a link for pictures to a google folder for each question that houses all the photo responses for that specific question. It may be necessary to format the picture file names so that we can locate them easily later. The responses tab on the google form also shows statistics for each question, which could be interesting.

Going to talk to Charles today about ideas for inputting the records

Justy

Looking at Justy’s form, the information I’d want in Arctos is: Consolidated Y/N Preparator(s) Notes on Storage and Handling

Additional information would be added to the in-house loan Date material received Date material returned

Nicole Volden

I would think about adding to this-

on arctos : Authorized by ​latest photo/specimen placed in housing​

maybe in the inhouse loan we could add : housing/type mold y/n cast y/n

Justy

[Jegelewicz]

I like the results sheet, but I hope there won't be may things you throw on the ground :-)

I suggest that any fields with people names be a pick list so that we don't have to decide if JA and J Alicea are the same person also, if we match the names to the Arctos agent names, they will be easier to transfer into Arctos later.

In addition to Consolidated Y/N, I would think that the type/method of consolidation would be important? It feels like a preservation attribute with controlled values like

Paraloid B-72 Paraloid B-72 in Acetone Paraloid B-72 in Ethanol Cyanoacrylate putty epoxy

The question I have is do we need to delineate between consolidation, adhesive, infill and surface finish or can all of the things in these fields just be added as "preservation" attributes (multiple preservation attributes are allowed)?

It seems that we will also need a new part attribute

housing - custom storage solution for the object

that would be controlled by a code table with values like

archival cradle ethafoam tray

for both preservation and housing, the details field could go into the attribute remark.

[Nicole-Ridgwell-NMMNHS]

The question I have is do we need to delineate between consolidation, adhesive, infill and surface finish.

It depends on how detailed we want this module to be. We had talked about having most of the info in a linked document and only having fields for thinks we might want to search for. I included just consolidation rather than adhesive or infill because consolidation (which includes surface coating) can cover all or a large portion of the fossil and thus can prevent the possibility of chemical analyses. Whereas adhesive joins and infill are more discrete, thus you can just analyze whatever part of the fossil isn't directly next to the join/infill.

[dustymc]

Yes this is very much the same data a LIMS/FIMS would deal with. There have been a LOT of discussions about that stretching back 15 years or so; I am not at all confident that there's some usable Arctos "module" that could work for everyone, or perhaps even beyond (maybe within!) a single lab.

We might try to find the resources that would let us build custom modules, but it's not clear to me that could DO anything that can't be done in your personal LIMS-like-thing. (And there are a bunch of commercial companies already building LIMS systems.)

Arctos can handle the loan-bits and the details of the parts on both sides of the loan. What happens during the loan could be attached to the loan as Media. The google sheet is fine, the google sheet as CSV would be much more stable, some app that uses the google sheet as a DB could even work.

The important part of that will be using good identifiers for the "LIMS-parts" so that they can confidently be linked back to the Arctos-parts. (Seems like a decent use for GUID-bearing barcodes - eg, ARKs.)

Or maybe that's all close enough to irrelevant for paleo collections if you're generally sending out "the specimen" and not one of the 38 liver samples from the specimen.

If the "LIMS" has good IDs and some sort of sane structure+vocabulary (Arctos code tables are available via the API) then writing a script that'll produce things that Arctos can consume should be trivial. I don't think this not being "part of Arctos" necessarily means it has to be any less-linked than if it was.

new part attribute...housing

That's just the parent container, no?

Arctos can use those drive URLs for Media, but there's a pretty strong chance Google will kill them or they'll disappear with the user or something. Suggest just uploading to Arctos, or finding some more-stable home for them.

[aliceajusty]

So a few things:

I understand it would be easier to have a pick list for preparators, however that idea doesnt work very well in a lab setup like the NMMNHS, or atleast where its headed. What I mean is in a lab like the AMNH or the FLMNH where there is a set number of preparators (<5) and only a handful of volunteers this is straight forward. However, in a place like the DMNS or NMMNHS, where volunteer groups are (or will be) large (>150@DMNS) and constantly revolving, with new volunteers being trained on a continuous basis, you would almost need to constantly update this pick list just for it to stay current or to not make the list unwieldy. I dont think this will be sustainable in the long term. I agree that some system will be needed to deal w this (maybe format this field and limit entries to complete first and last names).

As far as preservation consolidation, its a little counter intuitive, but for the purposes of researchers it doesnt really matter what consolidation technique you use, the important thing to know is whether its consolidated or not, as the result is the same. The main point of putting down whether something is consolidated at all is specific to chemical analyses of fossil material, where the solvent can destroy or contaminate material for these analyses. The only other reason I can think of is for a person subsequently preparing the same specimen to have a heads up of whats already in the specimen (ie if it has to be removed). The archival grade consolidants we most use in the lab SHOULD NOT be affecting this as the whole point of them being archival grade is that they should be inert, therefore not interacting w anything at all. That takes out the importance of the B72 specific designation. What is actually important here is if the material was ever infused w the SOLVENT (alcohol or acetone n this case) in the consolidant. A yes/no designation would be all thats needed to cover this. It doesnt matter which solvent is used because they both damage dna and ruin chemical analyses equally. The same can be said of the other consolidants like cyanoacrylate (crazy glue). If the specimen has been infused w it (normally thru consolidation), it will not be a good candidate for chemical analysis. Gluing fossil elements together does not infuse the specimen as its usually relegated to the edges you are gluing together rather than being slathered all over the specimen, although almost anything thats been glued, is likely to have been consolidated, since if it didnt need consolidant, it wouldnt have broken in the first place. Like Nicole said, if the specimen is consolidated at all, everything else is kind of negligible or secondary.

I believe the question of delineation is part of this. If I understand what you are saying correctly, on the record would be a "consolidant y/n" field and then a separate side list of preservation attributes like

"Consolidant - cyanoacrylate adhesive - B-72 in ethanol infill - epoxy putty surface finish - B72 in ethanol" or just

"cyanoacrylate, B-72 in ethanol, epoxy putty" as descriptive attributes

I think that would be cool, but the important thing would be that you know at a glance it has consolidant at all. I agree w Nicole, that maybe if you are interested in the specifics you would just look at the full prep record, which should be attached anyway.

I also agree with Dusty that google drive housing this stuff should, at best, be a temporary solution. We need to be able to house the media in some place more permanent. Ive definitely moved thru enough institutions at this point to know that things really do easily disappear w the user.

And the housing should only be considered a parent container if you can describe what the container is. I would think that, for example, most wet biology collections assume a plastic cylinder "jar" as the parent container, but this is rarely the case in paleo so, if theres no way to specify this in the record, it should be made a separate (fossil specific) field. I guess you could also put it in the arctos record as parent container y/n and then, again, go to the attached prep record for specifics. I think it depends more on whether the prep records will be an integrated part of the specimen record on arctos or if we will be attaching them thru a different format, like google forms.

[dustymc]

pick list for preparators

Not sure if there'd be social issues, but from the technical perspective I could throw up an Agent API pretty quickly.

describe what the container is

http://handbook.arctosdb.org/documentation/container.html

integrated part of the specimen record on arctos or if we will be attaching them thru a different format

@Nicole-Ridgwell-NMMNHS got this above: the answer is usually in "who cares?" (which of course isn't always predictable). If there's some data that would be usefully searchable (by potential borrowers, or for curatorial reason, or ...) then structuring it to support that is likely worthwhile. If it's only interesting after the specimen has been located, then an attachment is probably sufficient.

[Jegelewicz]

pick list for preparators

Not sure if there'd be social issues, but from the technical perspective I could throw up an Agent API pretty quickly.

I think we could connect the Google form to an API but I wouldn't want volunteers to have to scroll thru hundreds of names - it would be interesting to experiment with this though, even if it was just as a test case for connecting an Arctos API to a Google Form. Think of the data entry possibilities if people could use Google forms to customizes their data entry.....

describe what the container is

http://handbook.arctosdb.org/documentation/container.html

This will be a decision for @Nicole-Ridgwell-NMMNHS I can see advantages in assigning a barcode to a cradle - then you know what cradle goes with what and you can keep track of the cradle and the object separately. The cradle could still be in its storage location (barcode scanned to the shelf), while the object might be on exhibit (scanned to display case). We can just create a new container type "archival cradle" and add all the deets about the cradle from the prep catalog to the container remarks for each container of this type.

[aliceajusty]

Sorry, not sure what an agent API does, but if it works for making the names field easier to handle, Im fine w it.

This container field would work for me. Idk if it might be necessary to add a few terms for the types of housings: Half Jacket Ethofoam Tray Archival Clamshell Archival Cradle Plastic Box Gel cap

If it's only interesting after the specimen has been located, then an attachment is probably sufficient.

I think its more likely that someone will look at the prep record after finding the specimen than someone look for a specimen based on its prep

[dustymc]

scroll thru hundreds

good use case for autocomplete. Or have your volunteers grab an ORCID, add it to Arctos, and use it to reunite the data. There are lots of possibilities that don't end up with "John Doe" meaning 54 different things!

[Jegelewicz]

Agree on the autocomplete - would need to play around to see if the form would do it.

[Jegelewicz]

This container field would work for me. Idk if it might be necessary to add a few terms for the types of housings: Half Jacket Ethofoam Tray Archival Clamshell Archival Cradle Plastic Box Gel cap

I'm guessing ethnology and collections might use some of these and there are definitely some stuff in gel caps everywhere as well. Box already exists, "plastic" could be added to the container description, same goes for tray.

I think barcoding these things would pay off in the long run.

[AJLinn]

ethnology and collections might use some of these

Everything that we have that goes in a box ("custom made archival enclosure or support" is what we call it in the EH realm usually) in EH has an "archival cradle" - we just don't track the preparation in this way. Not saying we wouldn't/couldn't but just don't right now. Seems like we've discussed this with UAM:Art in our part attribute future code table for preservation need or something... I don't have time to find the issue right now as I'm nearly late for a meeting! Maybe someone can find it? @krgomez ?

[Jegelewicz]

This maybe? https://github.com/ArctosDB/arctos/issues/1908

[Nicole-Ridgwell-NMMNHS]

I think we could connect the Google form to an API but I wouldn't want volunteers to have to scroll thru hundreds of names

I could create an agent group for our fossil preparators - could an API just pull that group?

This will be a decision for @Nicole-Ridgwell-NMMNHS I can see advantages in assigning a barcode to a cradle

I think assigning barcodes to cradles or any custom-made housing is a great idea! To simplify things, I would just add the following container types:

Cradle Cavity Mount

I can create a new issue for these.

[aliceajusty]

For my purposes:

archival cradle = cradle cavity mount = ethofoam tray

if one term is preferred over the other, Im fine w that.

[Jegelewicz]

cradle and cavity mount are nice and generic, the rest can go in the container description (ethafoam tray, etc.)

[dustymc]

Tabling - file CT request (probably for specimen part attribute) if this is still of interest.

[Nicole-Ridgwell-NMMNHS]

I think an in-house loan with preparation documentation attached will be sufficient. We may need a new transaction agent = preparator, but I'll open a separate issue for that when I'm preparing to add that data.