This would allow updates to the base classes in in struct and enable the use of update functions to make it easier for users to upgrade old stored objects to the newer format.

At present a model can be trained and the the parameters changed before testing the model, or it contains outputs that do not correspond to the inputs. Providing an is_dirty check could print a warning if the inputs have changed and the outputs are accessed but the model hasn't been re-trained.

not currently causing an issue unless data is used to get data for chart examples.
change to...
dataset.data<- data.frame()
dataset.sample_meta
dataset.variable_meta

When wrapping other packages functionality the source should properly be acknowledged. A citations slot for struct objects would make this easier, and could be printed in the show output of an object.

this allows for them to be included in the structtoolbox package and they can also be PCB specific if desired

e.g. a histogram of fold changes could have an id for histogram and and id for fold change.

change this to model.sequence so that model.list can be used for applying the same processing to multiple models.

The batch number for QC samples should be included instead of the label "QC", otherwise SBC cannot be applied without extracting the batch number from the rownames.

Do we need a new class for this, or can be use the existing "model" class?
Doesn't quite fit with the 'train' then 'predict' flow?

• train to calc the test statistic, predict to get the p-values, rank apply fdr...

there should be a seq_in() method or allow then to be accessible by $ e.g. M$seq_in

e.g. this fails:

M = filter_smeta(...) +
    mv_feature_filter(..., predicted = flags) + 
    filter_by_name(... , 
        seq_in = 'names',
        seq_fcn(x) {
        ...}
    )
M = model_train(M,D)

For example
D$data_unit = "peak area"
Then charts etc can automatically correctly label axes.

A suite of tests is needed to test each class/function
Consider using testthat package (inc with devtools)

Add "see also" to stato object to link with other stato.ids. Include see also links in help page for object.

Currently preventing Forward selection using LOESS to find optimum.

Either change to model.predict
OR
specify S3 and S4 generics to allow use of predict.PCA for building model classes. Feels more messy for dev, but might be more user friendly.

rols enables access to the OLS API, which would ensure the returned responses are always up to date, and allow identifiers to be set from other ontologies.

chart objects could have standard options e.g. for title, subtitle, axis labels, axis limits etc. Then inherit params class for chart specific options.

The following code fails:

D = iris_DatasetExperiment
S = as.SummarizedExperiment(D)

Error in .nextMethod(x = x, name = name) : 
  "assay" is not valid for this object:DatasetExperiment

Functions 'predicted' and 'results' allow different outputs to be used as the input to the next model when using e.g. model.lists or chaining together iterators.

A better approach might be to create a 'mapping' class where the outputs from one object are explicitly assigned to the inputs of the next. This would allow more flexibility and streamline e.g. using VIP rank as inputs for Forward selection, and allow multiple outputs from one model as inputs to another. mappings can be auto-generated when creating an object if output names match input names, for example, but changed by the user for bespoke applications.

Unsure how this would work in galaxy environment.

Instead of including chart objects in model objects, create chart objects separately in workflow
e.g.
M = PCA()
chart.plot(M,'scores')

vs

M = PCA()
C= pca_scores_plot()
chart.plot(C)

There is currently no pass-through function to get the description of a chart assigned to model object see e.g. name functions