Code Table Request - rename part attribute remaining volume to part amount

[Jegelewicz]

Goal

remaining volume - Amount of tissue or extract remaining in a vial. Used to help assess whether sampling will use up the material.

is causing heartburn for incoming collections. Why wouldn't you just record various amounts and let the dates tell you what the current amount is?

Context

In addition - remaining volume is actually being recorded as a weight (which I think explains why we have a non-volume unit - mg in the volume units code table).

Table

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

Proposed Value

part amount

amount

Proposed Definition

The amount of the part

Attribute Extras

Attribute data type

number+units

Attribute units

if numerical values should be accompanied by units, provide a link to the appropriate units table.

new code table ctamount

Part preservation attribute affect on "tissueness"

none

Priority

Helpful Actions

• [ ] Add the issue to the Code Table Management Project.

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

@ArctosDB/arctos-code-table-administrators @happiah-madson @falco-rk @dustymc is this actually what we discussed? I'm at the end of my list of to-dos and my brain is kinda used up

Teresa's brain part amount | 0 | 2023-10-04 17:10:00 MDT

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). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example._

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

• [ ] Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition. URLs should be included as text, separated by spaced pipes. Do not include HTML in definitions.

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.

[Jegelewicz]

I have to say, the more I think about this, the more I can see the need for two separate things

part weight part volume

but I'll let others weigh in here.

[campmlc]

I agree that there are two types of measurements here currently crammed into one part attribute. This is because we have "tissue" chunks which we measure in mg or g, and we also have fluids such as blood or serum or DNA extractions that are measured in volume units. It is very useful to have "remaining" information to track how much is subsampled and how much is left after a given loan on a given date, but the value and units of what is "remaining" depends on whether the material is solid or liquid. I hesitate to split into two because to enter or search would require a priori knowledge of the nature of the sample. And to make matters more confusing, we have "liver" samples from the 1970s that were ground into a liquid for protein gel electrophoresis - and most of the time, we don't know that what the state of these older samples is until we defrost for subsampling.

[happiah-madson]

We can get over the 'remaining' part but I am having a hard time with the term being "volume" when it also includes weights.

[falco-rk]

I'm happy with it being 1 thing or 2 things

[dustymc]

Users clearly get lost in the menus. Unless there some compelling reason for two THINGs, I think the simplicity of one THING is near-always better. I can't see any possible functional differences, and one of the possible two has already been hijacked for dual use. Two just seems like clutter here. Emphatic support for part amount as discussed from me.

[campmlc]

Agree with using one part attribute. Maybe "volume/mass" or "amount remaining"? Or at the very least, how about just "amount"? I'll have to put "remaining after loan" in remarks.

[dustymc]

My support is for the proposed value; this needs to remain functionally acceptable and clearly disambiguated from https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecpart_attribute_type#container_volume (unless that can be removed as nonsensical, in which case I'd support 'amount').

[happiah-madson]

We have been trying to decide if we should add 'container_volume' to our 'standard' data input. Is it a useful field? Do other poeple use it?

[dustymc]

container_volume

Strongly suggest keeping that in containers. https://handbook.arctosdb.org/documentation/container.html#width-height-and-length

[campmlc]

container volume is useful for designating the volume of the container itself, for example, for a 2 ml cryovial or a 4 ml cryovial, which require different box and rack sizes and inventory systems. It does need to be distinguished from the amount of sample in a container. My concern with part amount is that it isn't clear either to anyone looking at the value or anyone entering the data whether that refers to the initial amount or the remaining amount on a given time. I use "remaining volume" as it currently exists recording both mass and volume to indicate how much of a consumable sample remains after each loan subsample, to know when a sample hits the threshhold beyond which we do not loan (we do not loan the last of a sample, usually 25mg of tissue, except in extreme, and curatorially authorized, circumstances, when no other alternative exists.)

[dustymc]

on a given time

Attributes have dates and remarks.

[campmlc]

Yes, assuming everyone understands what that means and uses it consistently. The attribute value itself is much less clear in the proposed case.

[campmlc]

Example: I have a cryovial of liver which has a container volume of 2 ml, but which was originally filled with 100 mg of liver. It has been subsampled for 25mg 3 times. I would like to record that the container volume is 2ml, the original part amount was 75mg on X date, and the "remaining amount" is 50 mg on Y date. This vial is associated with a subsampled part for loan which contains "part amount" 25 mg on Y date. In other cases, for blood or serum loans, I use ml to designate the volume of both the subsampled amount and the remaining volume in the parent vial.

[happiah-madson]

I can be flexible. We're coming from a system where we have "sample weight" and "sample volume" on our tissue parts as two different fields. And in our DNA extract table we have "initial volume", "volume consumed", and "volume remaining" to try and track the use of the material. Because we already track the person who does the sampling, DNA extraction, and loan, I'm not too worried about using the 'agent,' 'date,' and 'remarks' fields, as that will be the best place to capture most of this information. But I can also empathize with the clarity of "remaining" (which is also why it wigs me out to use it for an 'initial' volume of weight).

[campmlc]

In the parts download table that I use as the primary tool to manage samples for loan, the part attribute for a given part currently appears as " remaining volume = 1mL" in the display. This is extremely helpful in reviewing parts that would be suitable or not for a loan. Note that in this tool and download, there is no part attribute metadata for date etc. If we switch to "part amount", it will not be clear whether that is the original amount, the remaining amount, etc. This is my concern. I promised to send a file of the parts download earlier. Attached here, with a couple of fields redacted.

partFlatDownload (85).zip

[dustymc]

Existing UI should never influence data organization. (And there's an open request to redo that part of the UI anyway.)

I don't understand this objection at all. We have "container volume" and - what? The unspecified which remains?!

[happiah-madson]

Note that in this tool and download, there is no part attribute metadata for date etc. If we switch to "part amount", it will not be clear whether that is the original amount, the remaining amount, etc. This is my concern.

Ah, that clarifies your concern! @dustymc how easy would it be to add those fields to part downloads?

[campmlc]

Yet changes to the UI are incredible difficult to accomplish, require huge amounts of discussion, time and effort to get right, and rarely resolve all issues to address everyone's needs. Hence my objection, since we've already gone through multiple massive UI changes over the last 9 months that have caused enormous problems and disruptions to workflows in my institition.

[campmlc]

Any solution, to be usable, cannot involve JSON.

[dustymc]

how easy

https://github.com/ArctosDB/arctos/issues/6806 - probably pretty trivial if I had an actionable use case/functional requirements.

[Jegelewicz]

@ArctosDB/arctos-code-table-administrators discussed this today and believe the best path forward is

part amount - a free text description of the quantity of part available part weight - a number plus weight unit that provides the weight of the part part volume - a number plus volume unit that provides the volume of the part

mg should be removed from the units of volume code table.

[dustymc]

Splitting "what's left" sorta seems like an unnecessary complication, but I'm OK with it if the collections are, and it would let us keep code tables clean which is nice. Anything that resolves the current volume-with-weight-units nonsense....

part amount

I think I'd need a compelling use case for that one - seems somewhere between condition and the other condition at the moment.

[Jegelewicz]

Data that I need to get loaded awaiting resolution of this issue.

OGL_bulkload_parts_Samples_2023-10-04.csv

Can we proceed with what @ArctosDB/arctos-code-table-administrators suggested?

part amount - a free text description of the quantity of part available part weight - a number plus weight unit that provides the weight of the part part volume - a number plus volume unit that provides the volume of the part

mg should be removed from the units of volume code table.

[dustymc]

I would still like some compelling use case for making this three times more complicated that it looks to me like it needs to be.

[Jegelewicz]

So you are 100% happy with combining the units of weight and units of volume code tables? Or leaving the weird weight one in volume? Because we have to leave the weirdness there if we want to have a single "part amount" attribute. I am tired of nonsensical code tables - either we are measuring weight or we are measuring volume and the off placement of mg makes me uneasy. Or we combine them and let someone record weight with units of mL.

[campmlc]

I support splitting weight and volume into two part attributes with separate code tables. However, Given that our current UI doesn't capture part attribute dates in loan forms, and given the importance of knowing remaining volume etc for loan processing, I would request that we do the simplest thing and keep remaining volume as a part attribute with volume unit code table and add remaining mass as a separate part attribute with a mass unit code table. I personally don't need part amount.

[dustymc]

100% happy with combining

Yes, that's what was checked off and what was described - the information comes in sometimes with one and sometimes with the other, no reason to have to look in 17 places to find the right one. (Or I've misremembered the conversation with @falco-rk and @happiah-madson ....)

leaving the weird weight one in volume

No.

combine them and let someone record weight with units of mL.

I suppose people can pick whatever they want, but I'd like to think that most will use a weight-thing when they've got a weight and the volume-thing when they've got that - or at least that they're more likely to get lost in a bunch of THINGS than they are in a few heterogeneous values in the one THING.

[falco-rk]

I don't like calling something "remaining volume" when we only have a weight. Its confusing and will be forgotten because it doesn't make sense. I'm happy with either splitting them into two attributes or keeping them combined but called something like "remaining amount".

[dustymc]

"remaining amount".

Yep, that's what I thought we'd settled on and what was proposed. (Err, maybe just 'amount' - don't think anyone's measuring anything that's not left and it's attached to parts...)

[falco-rk]

maybe just 'amount'

yeah, that is fine with me, too

[campmlc]

It would certainly be simpler and easier for data entry to combine mass and volume units to a single code table with one part attribute "remaining amount" or " amount remaining", but we will likely get occasional units mixup. I can go either way. I do prefer we keep the term remaining in there because this is a value that changes over time for consumable parts, and to explicitly indicate it's function is to document that.

[campmlc]

We don't loan samples under 25 mg without curator approval, hence our need for this attribute.

[campmlc]

So can we go with a "remaining amount" and a combined code table?

[dustymc]

remaining

There's always a definition and timestamp, I can see no reason to make this less useful (eg to paleo collections) by adding an unnecessary word.

[campmlc]

So can we get the part attribute metadata to show up in Parts Download? We need to know the latest amount on the most recent date recorded. For context: We measure the amount that is cut for a subsample (usually 25mg or 50 mg or 0.5mL), and we also measure how much is left as remaining volume in g, mg, or mL every time a sample is subsampled for a loan. Both of these values are on our datasheets, and need to be distinguished. If we just have "amount" as the term, it will be very confusing for our students to understand what to put in data entry. The amount of the subsample? The amount left? And the most recent remaining amount is important to in order for collection managers to decide if a sample is fit for purpose and can be loaned, since our policy is not to loan the last of a sample except under extenuating circumstances, and this requires an additional administrative approval step. So having these data clearly visible and understood as meaning "remaining volume" is important and relevant for MSB DGR.

[Jegelewicz]

I want to make this really clear. Merging the weight units and volume units code tables will mean that people can select mL and µL for the weight attribute. How often do we think that is going to happen and do we care?

[dustymc]

people can select mL and µL for the weight attribute.

No?!

[Jegelewicz]

we also measure how much is left as remaining volume in g, mg, or mL

only one of those is a volume measurement and you cannot use g with remaining volume

Mixing up weight and volume makes me wonder why we don't just have a single "units" table. Oh sure you'll get weights in mm - but those can be flagged and fixed later. This is a data quality issue that we can cut off at the pass, or we can fix later and I will say that we are not that great at fixing things later because nobody has the time. Why should we do things twice when we can just do them right the first time?

[campmlc]

Just to clarify and hopefully avoid adding to the confusion here - I understand that we cannot use g or other mass units with the part attribute remaining volume. Hopefully that is what we are going to fix. I support either of two options in the following order: 1) the simplest: keep a single attribute as "remaining amount" , convert all current"remaining volume" to it, and use a single combined units table. Yes, we will get mL used instead of mg. But as you say, these can be identified and fixed, and ultimately, it is the collections' problem to vet their data. Especially in this case, because this part attribute is primarily for curatorial use - how much is there, how much can be loaned, what size container does it need, etc. This is by far the simplest solution for data entry, at a cost of some unit accuracy, but I'm willing to pay that cost for the increase in usability. 2) We keep remaining volume for volume units and create remaining mass for mass units. I prefer the term mass because it is technically more correct in the context of the scientific application and the units we are using and also shorter. We have two part attributes, with separate units code tables. Users will have to know that there are two options and two code tables, where previously there had been one - we will need some good documentation and redirects for the error messages.

[campmlc]

The third option - just using "amount" - will lead to confusion in my collection and probably widespread misuse, as we track different kinds of "amounts", and because the current UI, especially loan forms, do not provide the metadata needed to distinguish the values as they change over time. Since this is primarily a curatorial part attribute, I'm curious who so far outside of consumable tissue collections is or will be using it? We are recording these data daily - especially as they pertain to how much material is remaining for loan, so we definitely have need for a solution that works for our collection type.

[falco-rk]

I am happy with any of the options suggested above. I would choose separate attributes for volume and mass if it was completely up to me, but it doesn't matter too much for our data.

[dustymc]

choose separate attributes for volume and mass

I apparently have misremembered that conversation, I think that takes us back to https://github.com/ArctosDB/arctos/issues/6801#issuecomment-1846296497 (minus the 'part' - that's the only thing this can possibly be attached to - and minus the free-text option unless there's some compelling use case, please).

Might be better to kill this and start over with those two requests, but if possible can we first resolve this 'remaining' thing?

different kinds of "amounts"

That's not what your examples have suggested. I don't think you're recording non-remaining amounts (???? surely this isn't right, but apparently there's some other type of thing somewhere out there that needs specified ????), you're just recording amount at time for various parts, same as anyone would do for any situation. If you're doing something else I don't understand it.

current UI, especially loan forms

Those issues should be prioritized, and current UI should NEVER influence discussions of structure.

will be using it

I don't have a time machine, so I always prefer to keep the options open.

especially as they pertain to

Knowing the amount might be useful for all sorts of things, from loaning teensy bits of tissues to figuring out if a part plus an estimate of a pallet's weight is likely to overload the forklift. I just can't understand why this must be limited to your particular use case, rather than being designed to be useful to most anyone.

[Jegelewicz]

This request is not going to be resolved. Closing in favor of two new part attributes.