Approach for 'none'

[aclayton555]

This issue follows this service desk ticket: https://sagebionetworks.jira.com/browse/HTAN-409

Following initial investigation and consultation with FAIR, Amy notes, "we talked about this issue in the greater context of using “none” and the consensus is that we should avoid using none as a string in general. We have some ideas on how we can better handle this, but can we consider avoiding it for the next HTAN iteration?

As of April 2024, Adam notes, "We currently have 17 occurrences of none (case insensitive) in our data model."

This issue to track two actions (may be split into sep tickets):

1. engage with FAIR on strategy and approach for none types
2. evaluate use-of and remove use of none in the HTAN data model
3. Based on outcomes of 1 and 2, remove use of none in the HTAN data model

My impression is that 1 and 2 can be conducted in parallel, and will confirm how exactly we proceed with 3.

[aclayton555]

Consider this for 24-5 sprint and determine what needs to be done now to alleviate any blockers for contributors vs longer term fixes in renewal.

See also Adam's latest comments in this similar Jira ticket: https://sagebionetworks.jira.com/browse/HTAN-401

[adamjtaylor]

This is also an issue in HTAN-469.

I'm going to make a PR to add unfixed as an attribute for Fixative type to unblock

[aclayton555]

FYI @thomasyu888

[thomasyu888]

This won't be necessary: Sage-Bionetworks/schematic#1553. We will support None soon. Here are the other values to watch for that will automatically turn the value from the string to a blank value

“ “, “#N/A”, “#N/A N/A”, “#NA”, “-1.#IND”, “-1.#QNAN”, “-NaN”, “-nan”, “1.#IND”, “1.#QNAN”, “”, “N/A”, “NA”, “NULL”, “NaN”, “None”, “n/a”, “nan”, “null“.

[thomasyu888]

@aclayton555 None is now supported post 24.12.1 schematic release. I'll let you close the ticket.

[aclayton555]

TO-DO for HTAN2 Data Model - are there any attributes that were changed from 'none' that should be changed back? Rather than doing this, more likely that we will just consistently adopt 'None' going forward since we no longer need to avoid it. I will discuss with the team before closing. We should surface this to the broader DCC so that they remember to include 'None' in upcoming RFCs rather than the other null values that are still problematic