[traits.build workflow] Add "time" category of traits, in addition to "categorical" and "numeric"?

[yangsophieee]

Currently dataset_test fails when substitutions for time variables (e.g. flowering_time, fruiting_time) exist, because of this line looking for whether values are found within the trait definitions.

I can think of several easy ways to fix this: if the values only contain "n" and "y" then you don't check for the trait definitions (implemented here).

This made me think about this line in process.R which specifically codes for the traits flowering_time and fruiting_time. But this isn't very generalisable to other databases if they want to make their own time traits. I wonder if it's worth making a new "time" category of traits, in addition to "categorical" and "numeric". What do you think @ehwenk?

[ehwenk]

I've previously thought about having a separate trait category for flowering_time, etc. for similar reasons. Because when I've added a new time-trait (recruitment_time), you're right, I then had to tweak code (I think for building the dictionary ontology). And it probably should have been added to this list as well.

The specific test you referenced searches for N's and Y's only, which is specific to time.

But a separate problem with the time traits is that they are categorical traits for which the allowable trait values aren't listed. That could be true to non-time traits - given the trait recruitment_time isn't causing any errors, it seems we've already adapted the traits.build workflow to handle instances where categorical traits don't have set values. Maybe this is actually only a problem for the code to build the APD, in which case I guess it is fine to require a fix.

@dfalster what do you think? Is it a time category we should consider adding or a factor (or other word) category for traits without set values. Or nothing?