You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, data that are best described with free text can only be provided as metadata_columns, which means that they cannot be grouped in with trait_sets. This use of "metadata" is a bit confusing from the point of view of someone writing a config file, and especially for large config files it would really help to be able to group traits by context or biology rather than by data type.
One possible solution (from the point of view of config file as user interface---I don't know how things are actually implemented) would be to have format: text analogous to format: float and format: integer. All of those could then be intermixed within any trait_set.
Further following this logic, perhaps continuous_trait_columns and categorical_trait_columns could be dispensed with altogether, with format or some other per-trait field designating their type (numeric [either continuous/float or discrete/integer], categorical, or text). This idea comes from the same place as issue #132 : as a user, what I care about are the traits and their biological contexts (relationships to other traits) rather than their data types.
The text was updated successfully, but these errors were encountered:
Currently, data that are best described with free text can only be provided as
metadata_columns
, which means that they cannot be grouped in withtrait_sets
. This use of "metadata" is a bit confusing from the point of view of someone writing a config file, and especially for large config files it would really help to be able to group traits by context or biology rather than by data type.One possible solution (from the point of view of config file as user interface---I don't know how things are actually implemented) would be to have
format: text
analogous toformat: float
andformat: integer
. All of those could then be intermixed within anytrait_set
.Further following this logic, perhaps
continuous_trait_columns
andcategorical_trait_columns
could be dispensed with altogether, withformat
or some other per-trait field designating their type (numeric [either continuous/float or discrete/integer], categorical, or text). This idea comes from the same place as issue #132 : as a user, what I care about are the traits and their biological contexts (relationships to other traits) rather than their data types.The text was updated successfully, but these errors were encountered: