Request - part condition should be NULLable

[RJSS8]

Help us understand your request (check below):

• [ x ] bulkload changes (to Agents, Identifiers, etc that are not already available as a bulkloading tool)

Describe what you're trying to do

So I tried loading records and parts through the main bulkloader, but I don't have any information regarding their actual condition so what I technically would need to due would be something like "good", which is generic and may not be accurate or check or ask for the collections to check their parts to get accurate values which would slow the loading of records
Couldn't this be nullable, and when I get that information, then update it.

[ewommack]

I just put unchecked for parts I don't have an accurate condition for yet. So when I am bulkloading, most parts have unchecked in the field. It is free text, so you can put whatever you want to show that you haven't looked at the part yet.

[dustymc]

I believe NULL is always the correct value for 'no information is available' (or "whatever you want to show that you haven't looked at the part yet.") and strongly support that part of this request. I don't think there are any technical reasons not to proceed with this, and suggest we do so.

unchecked

Much of the data in this field is just a verbose spelling of NULL (that one comes from an old UI), which makes the important bits hard to find!

arctosprod@arctos>> select condition, count(*) from specimen_part group by condition order by count(*) desc limit 10;
  condition   |  count  
--------------+---------
 unchecked    | 3919928
 good         | 1172746
 not recorded |  477309
 intact       |  421854
 unknown      |  337813
 very good    |  128005
 excellent    |  127883
 n/a          |   88740
 3            |   77946
 complete     |   58231
(10 rows)

There are also 441 ways of spelling "unchecked" at the moment:

...

 tract; unchecked
 unch4
 unchcecked
 unchceked
 unchcked
 unchcompleteecked
 uncheccked
 unchechecked
 uncheched
 uncheck
 uncheckced
 uncheckd
 uncheckded
 unchecke
 unchecked
 ; unchecked
 unchecked.
 unchecked]
 Unchecked
 Unchecked.
 UNCHECKED
 unchecked1
 unchecked, 1 partial
 unchecked2
 uncheckeid
 uncheckked
 unchedked
 uncheecked
 unchekced
 uncheked
 uncut, unchecked
 untanned; unchecked
 upper and low jaw; unchecked
 upper crania only, unchecked
 upper tooth row; unchecked
 with antlers; unchecked
 with horns; unchecked
 young in alcohol; unchecked
(441 rows)

then update it.

I have much less enthusiasm for this part of the request. specimen_part.part_condition can only be structurally viewed as a static fact - which is just not true, but tradition and resources probably require it to exist anyway, and that's probably fine as long as it's documented/viewed as the 'second class' data it is. https://arctos.database.museum/info/ctDocumentation.cfm?table=ctpart_attribute_type#condition_report is much more capable of expressing reality - things change over time, different people see different details (geneticist vs. morphologist), different evaluations might say the same thing at different levels of detail, etc., etc. Adding this determination when more data become available is strongly preferable to updating specimen_part.part_condition, and those data are probably less likely to be lost in the clutter when specimen_part.part_condition is NULL.

[RJSS8]

Im fine with your recommendation, @dustymc, the updating of information might pertain to attributes of other fields. And there is already a condition report free text field for unique "part conditions".

[ewommack]

Nope I wouldn't support changing it to NULL at all. Having nothing written in that field tells me absolutely nothing. Having unchecked in there tells me I haven't actually gone and looked yet. Those are two different things in curatorial.

I actively update condition when we send parts out on loan, or when we get them back from a loan. I'm not saying you would update it Dusty, I'm saying the collection updates it.

Several of those things you have in your table that you think might be the same as NULL are definitely not.
If something is marked as excellent or very good I would expect the part to be in good condition. For intact that would tell me the part (what ever it is) that tells me the part is all present.

Perhaps you could have it not be a required field, but I know I actively use it to include notes for collection work.

[RJSS8]

Removing the requirement of it being a required field would also solve this issue, in my particular situation.

[ewommack]

This needs to be moved to AWG Issues discussion. With SPNHC going on at the moment, most of AWG is not going to be paying attention, and this is a change that will affect all collections on Arctos.

[dustymc]

have it not be a required field

That's what's being proposed. There's no change beyond that on the table. Nothing about that change would have any influence on how anything needs to be done. All that follows is non-technical discussion/suggestion.

---

nothing written in that field tells me absolutely nothing

Yes, that's precisely what NULL means, and I am 100% sure the intent behind much of the existing data.

tells me I haven't actually gone and looked

That's a completely legitimate use case (and possibly the one place where the metadata-bearing attribute is truly overkill), but also not universal. (This used to be controlled and a very old UI used to provide a default....)

actively update condition when we send parts out on loan

That is very common, but also not what I'd recommend: The part attribute which carries metadata ("on this date according to that person....") and preserves previous condition reports is a better tool for this job, and collections might consider adopting that as part of their protocols.

might be the same as NULL are definitely not.

That's fine, I'm still not proposing to do anything and if you read something into...

not recorded | 477309
unknown | 337813
n/a | 88740

... then great.

[mkoo]

have it not be a required field

That's what's being proposed. There's no change beyond that on the table. Nothing about that change would have any influence on how anything needs to be done. All that follows is non-technical discussion/suggestion.

Seems clear so please move to dev @dustymc . Solves Renato's issue but works for others too