Model Representation

Jummp aims to be format agnostic in it's design and implementation. Nevetheless certain assumptions are made about the file structure of models imported and exported from the infrastructure. This is reflected in how models are stored in Version Control System (VCS), their representation as Grails DOM objects, as well as the behaviour of services using model files.

Model Representation in VCS

The VCS Manager associates a list of files with a VCS id (revision number in case of SVN, sha1 hash in git). This ID is stored in the Revision.vcsID field. Each repository is stored in a separate folder, specified by the Model.vcsIdentifier field. This field is required for any calls to VcsManager.

Model Representation in Grails

Models have the following domain objects associated with them: Model, Revision and Repository File. Each model can have many revisions, and each revision can have many repository files. Repository File contains metadata about the files stored in the model directory. This metadata will be useful for the planned evolution of the system, where additional files are generated from originally submitted model files. The system can then present users with a filtered representation of the model directory.

Model Validation and Parsing

Currently, Jummp supports validation of SBML models. A list of files corresponding to a revision is considered valid if any one of them is valid Sbml. This is far from ideal. To test each file, the system makes web-service lookups to jsbml. This may be slow and failure prone, depending on the performance of the web-service. Furthermore, we may need to support model formats that represent the model with multiple files (importing from components for example). It may be the case therefore that no one of the files alone is valid. This will be addressed in future versions of the system.

For the present, the system assumes one file in the model directory is the "model". If there are multiple Sbml files in the directory, the SbmlService will select the first returned in the list of files, as the model. This leads to non-deterministic behaviour, as the order of files returned for a directory is not always the same. Therefore, storage of multiple model files in the model repository is presently discouraged.