Are the models/metadata/simulation-results in any sort of Version Control System (Subversion comes to mind)?
By including VCS tags in the text of the model/metadata/simulation- results, then whenever these files are read/printed, the version number and date can be also displayed. With a version control system, it would also be possible for a user to be inspecting/using one (slightly older) version while a newer version of the simulation is being created. Also, the 'history' of a document can be displayed from the vcs- metadata, along with a log of all changes to a document. Simulation results can be declared 'stale' at some time delay or count older than the current version and deleted if storage space is a scarce resource. Bob G On Dec 4, 2006, at 03:36, Matt wrote: >>> (peter wrote) >>> >>> 2. Need ability to edit metadata on website models –e.g. for >>> sensible >>> defaults on time integration parameters and graphical > > We need to be very careful to preserve a relationship between a > simulation and the data obtained from it. I see a problem occurring > where we have metadata describing a simulation which is bound to a > model, and a graphical output (or set of data points) that are > supposed to represent the output of this simulation, which is also > bound to the model. There is only an implicit relation between the two > such that updating the simulation metadata now produces an > inconsistency with the graphs (or associated data points) of results. > > I think we need to think about in the simulation metadata: > > 1) uniquely identifying simulations (an rdf ID within the model). > 2) referencing the model uri this simulation is referring to (there > shouldn't be anything stopping the simulation metadata being picked up > and processed in isolation of the model) > 3) binding graphs of results to the simulation and not the model. > 4) changing the metadata of a simulation needs to force a version > change (or variant) in a similar way to models so that a mismatch > between graphs or result sets can be detected. > > > This part of the discussion thread seems to belong on CellML > discussion now. > > cheers > Matt > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
