Model DB Related Specifications
Introduction
Models created by users can be stored in a model database if the models satisfied certain criteria. Models in the repository are uniquely identified database ID (db-id). Users can download models from the database and use them to build a new model. Because traces of reusing models provide interesting ontological information, insilicoML can keep history of modules by recording db-id which provide clues to pursue history of models. The main idea to trace the history of modules is to let every module in a model keep information indicating “who involved me”.
Here a term “insilico model” or simply “model” represents an entire insilicoML file which includes meta-information as well as modules.
<is:track> <is:involved db-id="this" date="2008-06-06"/> </is:track>
Submit a New Model to Model Database
When a user create a model from scratch (without using any existing models), all modules involved in the model do not have database ID (db-id) but module ID (module-id) given as 16 byte UUID. Before the user submits the model to the database server, the root module of the model must be encapsulated.
When a module is created in a model in process of creation, information that indicates that “this module is involved in this model” is described as a property of the module as follows;
where “this” is given instead of db-id since the current model does not have db-id yet.
When the model is uploaded in the database, the database server assigns a db-id to the model. More precisely the db-id is assigned to a capsule module which encapsulates the root module of the model. At the same time a value “this” in track tag is replaced by the newly assigned db-id. Note that the db-id is unique across models stored in the data base.
Use Models in the Database to Create a New Model
Users can download models from the database and use them to create a new model. Assume that a user downloads two models; model-A and B. Let model-A have db-id=1 and includes three modules with module-id=a1, a2 and a3. Similarly let model-B have db-id=2, and includes two modules with module-id=b1 and b2. And the user creates a new model C.
Add Models in the Database to a New Model
A user can add model-A and B to create a new model C to use model-A and B as functional modules. At this moment model-A and B are encapsulated.
In modules in model-A and B, a new track/involved property is appended with values db-id=”this” date=”2008-06-06” (date of creation). Since modules in model-A and B have already at least one record of involved (added when they were created), the track section of modules in model-A and B will be as like
<is:track> <is:involved db-id="this" date="2008-06-06"/> <is:involved db-id="26" date="2007-10-17"/> </is:track>
If a user wants to edit inside of model-B, the user needs to decapsulate model-B. Once a model is decapsulated, the db-id of the model is removed. Since the db-id is assigned to the capsule module encapsulating the root module of the model, and the capsule module disappears by decapsulation. However, each module which was in model-B still keeps involved information in track tag. On the contrary, unless a model which has db-id is not decapsulated, the model keeps its db-id.
Decapsulation of a model implies that the model is edited by users after it is downloaded from the database. There is no guarantee that the downloaded model and model in the database are identical. Thus db-id is removed from the model by decapsulation. In a simplest case, let us suppose that a user downloads a model, and edits it. And the user wants to resubmit the edited model to the database. Then the model is registered as a new arrival (though track is kept in modules) in the database, and given a new db-id.
