doricon
commented
11 months ago Thanks Claire for bringing this back to everyone's attention! We will likely have to deal with this at some not-too-distant point. A few haphazard thoughts, off hand:
-We should really think about whether all of these non-state recordings actually add needed info to a description. For example, I go back and forth on whether recording "Not applicable" is any more useful than just not recording anything (like I would never want to record NA for every tooth character after already recording the leaf as non-toothed). For the example described for Areolation, choosing the "present" state but no further substate implicitly means that any further detail for that character is not determinable. Having a lot of indeterminate, NA, or not observed recordings would make description output long without added useful info. Personally, I just want to see what's known, not the potentially infinite unknown! :)
-But, even considering the above, sometimes those records are useful, even just for yourself to know that you looked at it (this is pretty much the only thing I have used those for). The way that our description entry form records character instances, I feel less like I need this? maybe, time will tell!
-With the current architecture, we wouldn't want non-states like indeterminate to be a state node because that would presumably make search and matching algorithms really messy or complicated (e.g., you don't want to match or not match OTUs/specimens based on sharing the "indeterminate" state). Of course, if it is not difficult to rule those out, then having them as a state could be on-the-table.
-Otherwise, I wonder if it is possible to have these non-state options record as a property of a character instance (basically a field that has these non-state options in a drop down). That would sidestep the issue of creating a state node that's not a state for a character. It's not clear to me though whether you can have a character instance that doesn't point to a state.
-I think we will hear from folks at the hackathon about this if it is something folks care about :)
Andrew and Doug, if you read this, skip to last paragraph first.
We have had lots of conversations about states and how strict we should be with them. Totally get that we want to be scientifically accurate in what we call states. Also totally get that this is preventing us from recording other important information...so far.
One thing to consider is that PBot schemas are data entry tools, not treatises. Precedent has been set (MLA) that the schema tool is not as particular about recording states and non-state information. However, that doesn't mean we have to follow a loose precedent. So...
What if we use something like check boxes for non-state information such as not observed, not-applicable, indeterminate? Those node properties can be identified as not states in reports (based on their name) but still be gathered within the character state data for reporting.
One option is to have check boxes at the character level, in some cases only part of the state hierarchy can be observed while the fine detail is not observed. So we need to think this out. How can we implement "checkbox" in the Create character instance box universally--so all in one place/less work for Doug.
Areolation might be an example to think about. You're in the Create Character Instance: Areolation box. You can tell areolation is present, but have so little of it and can't pick a particular substate. Could the user select present and click the indeterminate "checkbox" which would be interpreted as reporting researcher confirms that areolation is present but detail below that is indeterminate on that specimen?
Feedback, other ideas? This issue needs to be addressed in the current implementation of PBot AFTER HackAThon, but in a way that won't drive Andrew and Doug batty :)