Workshop notes 2018

Notes from the Web Lab workshop 2018

• Rename 'result' and 'experiment' to 'prediction' in data model
• Dataset gets used for prediction, experimental data, inferred parameters
  • Though Prediction extends this with Model & Protocol (version) links
  • ExperimentalData also has a Protocol (version) link
    • We might want to make this update-able? Only if fits haven't been run yet? Because you don't want to have to upload data again whenever you tweak the protocol to match it better, or have multiple copies of the raw data files when the metadata about a Dataset changes
    • Or should a Dataset be able to link to multiple Protocols, and then when you create a fit you choose which one?
    • Does it make sense to have versions of Datasets? Certainly things like Figshare consider a Dataset immutable, and any changes (even purely metadata ones) result in a new DOI.
    • I feel like a new Protocol should be able to link to existing Datasets without having to create new versions thereof
  • Inferred parameters link to the fitting spec, and hence (but also directly?) to the model, experimental data, and protocol
  • So probably need one common base Dataset class and three concrete subclasses
• Fitting
  • A FittingSpec is NOT just a special protocol
  • Needs a reference to a Dataset (and via that a Protocol version, or directly a Protocol version) and a Model version
    • Link to versions or entities? A FittingResult needs to link to versions...
  • Use actual pints code (more or less) as the spec, but create simple cases from GUI
    • May also need a simple file with the data as given in the GUI? So can clone via GUI (see below). Though how do you keep these in sync? Or delete simple file if Pints code changed? Or...
  • Need to think about the guided GUI, e.g. how to select relevant data/proto, which parameters to fit, how to fit params that might not be annotated normally (see paper)
  • Need to store (in fitting result) and optionally be able to specify (in fitting spec) RNG seed
  • The Dataset used should be able to set model (& protocol?) parameters directly if their values were measured
    • This might reduce the need to have many different variations on protocols, e.g. different pacing frequencies. The downside is that you couldn't then use these naturally to compare forward simulations of a model.
    • Need to match based on ontology term, with a checkbox provided to allow the user to decide whether to accept the Dataset's value?
  • Do we allow versions of FittingSpecs?
    • If they're stored essentially as Pints code, this lets you see the code and edit to customise beyond what the GUI gives
    • Can use the existing Entity as a base class, and similar views etc.
  • Given a previous fitting, want to be able to apply the same process to a new Model / Dataset -> taking you to the guided GUI with most things preset
    • So need to be able to see a list of all FittingSpecs we can base on
    • This could be another clone UX flow?
    • Should this be a button direct from a fitting result?
  • From a fitting result, want to be able to create clone(s) of the model with parameters drawn from the distribution
  • Prioritise designing & implementing these based on concrete use cases
• Entity View changes
  • When viewing a protocol we still want the 'Fittings' button, to see fittings that used that protocol version
  • Want to be able to clone an existing model/protocol
    • Perhaps by default the matrix view should not show these clones? But can hover/right click to get an option to show clones for a single entity, similarly to showing multiple versions of an entity.
    • Keep a reference to the original in the clone's DB model (and list of clones on the original)
    • For protocols, we might want a short-cut action to clone and just change an input value (so can quickly create say a different pacing frequency)
• Displaying data
  • The 'default' matrix shouldn't show data or fitting results, just forward simulations as now
  • We should be able to get from a Protocol to see Datasets linked to it
    • Have a 'Relevant datasets' button which shows a list?
  • We should be able to compare simulation results against relevant data easily
    • A 'Compare... Results with experimental data' button to get to a matrix view with both Datasets and Predictions so can set up comparisons?
      • At present the comparison view knows things are 'the same' and go on the same graph if they have the same file name. This will need extending so you can have a more flexible mapping between (parts of) a Dataset and specific protocol outputs
    • Do we need to allow selecting Datasets that aren't explicitly linked to the Protocol?
• Annotation
  • The RDF pulled from Dataset, Model, etc. should be used to show a link to the reference paper in the entity view
  • Will have separate triple store that Django can talk to, possibly Virtuoso (PMR uses this)
    • Need to be careful with configuration
    • Could also look at Neo4J, or rdflib can use postgres as store
  • Use datacite ontology to make citing things in Web Lab easier
  • Use identifiers.org; also FMA, OPB
• Ontology design
  • Probably do need to make our own, in OBO or OWL format
  • is or isVersionOf are reasonable ways to annotate; can also look at hasProperty and isProperty