Menu
▾
▴
#286 Add description of which SBO branch applies to SBMLDocument
closed
nobody
5
2017-12-06
2015-07-06
No
Noted by Andreas:
In table 6, we list the SBO branches that different SBML elements may use SBO terms from. However, the SBMLDocument itself is not on this list. We could add it to the list, both for L2v5 and for L3v2.
From Andreas: "The SBML element is missing in this list. I propose to add it here and that it may be annotated with terms from the "modeling framework" branch of SBO. BTW, this is directly usable for models in L3V1 with FBC to indicate how the file is intended to be used. Here it could be similar."
I favor this too.
The modeling framework branch was used for the sbo term on the 'model' element until SBML L2v4, and you can see it's defined that way in the L2v3 spec. In v4, Nicolas Le Novère argued that the 'model' sbo term should explain what the model is. I can't remember the complete details, but I think at the time we decided the attempt to use modeling framework wasn't working out because no one used the information, and perhaps also that the information belonged outside the model entirely.
But now there are reasons to use it, so I agree.
The one downside of putting it on sbmldocument is that when using model composition, it is the 'model' element that is referenced and not the document, which makes it unclear how this info might propagate in a desirable way. Perhaps a solution can be found for that too.
There is already a way of seeing if a Document contains elements of (or makes use of) any SBML "modelling framework(s)" - the Document namespace declarations.
However, I could live with this.
In general I tend to agree with Nicolas that "modelling framework" should not be used on Model. In my opinion, this is not part of a model description and something like SED-ML is better equipped to deal with.
However, this would not distinguish whether a stochastic or deterministic simulation was intended, for example in the case of a model with no SBML namespace declaration (or even with such declarations, come to think of it).
I do agree, however, that modeling framework was the wrong SBO term to use on the Model element.
I disagree. I think modeling framework is an important annotation for SBML. When you construct a model, you have a modeling framework in mind. It may be possible to learn this by careful examination of the model, but why make it so difficult. A good example is the whole cell model where you have many models each using different modeling frameworks. It is useful to know which one is the intended framework, so you can simulate the sub-model using the write methodology. This is not as someone pointed out the job of SED-ML. The intended modeling framework is part of the model and independent of how it is analyzed. SED-ML should be used to describe the precise analysis algorithm used, but SBML must indicate the modeling framework that the modeler intended.
Last edit: Lucian Smith 2015-07-10
I think that putting the modeling framework SBO term on the document will work out fine, even for hierarchical models, because you can put hierarchical models in an arbitrary number of other documents, should you really want different modeling frameworks per submodel. This might even work out better, since then you'll have a complete document per framework, making it simpler to send each document to each different simulator.
While this is the approach that iBioSim takes (namely, one model per document), I don’t think it is good for exchange. Right now when we export a model, we use model definitions, so we can create one file to send around. Therefore, I strongly prefer modeling framework on model. I don’t mind it also being on document to say all models are of that framework, but I don’t want this to be the only place it can go.
Note, we are currently using modeling framework on model to implement a hybrid simulator for models like the whole-cell model.
Chris
Last edit: Lucian Smith 2015-07-10
In that case, I think the modeling framework for the document would be 'mixed'. You could describe what that means more specifically in annotations.
Given that we have to submit the l2v5 spec today to JIB, and given that people can already use the SBMLDocument SBO term as described here, even without explicit mention in the spec, I am changing this issue to be L3v1-only, and dropping the issue from l2v4.
I guess there are two things here: one suggestion to suggest that 'modeling framework' to be applied to the SBML document itself (there is currently no restriction on it at all, making this a possibility, but pointing it out makes it more likely to be usefully exchanged). The other suggestion is that we allow the Model itself to be either 'occurring entity representation' or 'modeling framework'. The latter would be particularly useful for the Whole Cell model in particular, and other mixed-framework models who want to store the whole model in a single file (which you can do with comp and the ModelDefinition element).
I'm kind of inclined at this point to allow both suggestions, but I don't have a good sense if that could potentially mess someone up who is currently relying on 'Model' being 'occurring entity representation'.
How would someone make use of an SBO term from occurring entity representation on Model? I get the idea of a composite process, but would you represent the entire Model with a reaction symbol or something? However, this use to me only makes sense in comp models. Actually, in this case, it would make more sense to put it on the subModel as it would allow you to say how you wanted the subModel to be depicted.
I guess the real question is if anyone is currently using SBO term on Model for anything but framework.
Last edit: Lucian Smith 2016-01-05
The terms from the modeling framework branch are actually used within the SBO terms of the mathematical expression branch themselves. This came from the very initial design of SBO, one of its "raison d'etre" being to specify if a kinetic law was intended within a deterministic or stochastic context (sic) (at that time, we were not very knowledgeable on those issues, and mixed up stochastic and discrete, deterministic and continuous).
Chris, the entire model represented by a symbol would be an SBGN submap.
I would favor using the model element. It does not break anything and allow new uses. As Lucian, I think that a composite model using different frameworks for distinct submodels benefits from using several documents. It facilitates enormously the build of archive and simulation using several tools.
Again, one can always set the granularity at the level of the kineticLaw using the terms there.
I think the original issue has been slightly submerged here.
Andreas pointed out that the the table indicating the main type of SBO term that should be assigned did not include the sbml component . He suggested that 'modling framework' would be the appropriate term.
I agree with that - and it seems like other do too.
Is there now a question as to whether 'occuring entity representation' is teh correct term for a Model component ?
Yes, that is indeed the point. I would like modeling framework to be an alternative for Model component. This is absolutely needed in hybrid hierarchical models. While one can say that using multiple documents is preferred in this case, I don’t think we should restrict people to use multiple document models. It should always be possible to exchange a single file. If we only allow framework on document, then this would not be possible.
Last edit: Lucian Smith 2016-01-22
This is a good point--at this point, it'll be cleaner to break out the question about Model to a separate issue. I'll go ahead and do that, and close this one as agreed
As for exchanging only one file, you can always bundle all your SBML documents in a COMBINE archive.
When it comes to hybrid modelling, you should use appropriate SBO terms on the math containing elements. These SBO terms contain a MathML element with a DefinitionURL pointing to the relevant modelling framework term. If some are missing, we need to add them.
If push comes to shove, you can use SBO in annotations (I know, I know ...)
But as a user, if you are not bothered to have an SBO term on an SBML element that can take values from two branches, it probably means we are overspecifying. It is not like the reaction/reactant/kineticLaw where the SBO terms are all interlinked.
We don’t yet support COMBINE archive.
Perhaps though we may run into conflicts with needing the SBO term for something else.
Less ideal but a workaround.
I think the problem is there is one SBO term slot. In SBOL, every place where an ontology term can be used, we made it a list. This does cause some issues in exchange in dealing with potentially conflicting terms, but it does add flexibility. Anyway, I’m not advocating this change to SBML right now. I would just like Model’s SBO to be allowed to come from two branches.
Last edit: Lucian Smith 2016-01-22
NL: When it comes to hybrid modelling, you should use appropriate SBO terms on the math containing elements. These SBO terms contain a MathML element with a DefinitionURL pointing to the relevant modelling framework term. If some are missing, we need to add them.
CM: Perhaps though we may run into conflicts with needing the SBO term for something else.
I did not get this point. Which SBO term? The one on KineticLaw or the one on Model? What something else?
I guess on KineticLaw it is not a big problem. We probably won’t need it for something.
The problem with this approach is that it would not be so easy to work with. In our current hybrid simulator that we developed for the whole cell project, we look for a model with an SBO term of FBA and we send that model to our FBA solver, other models go to the kinetic solvers. If we put this on the math, then we would need to examine every part of the model in detail to find which parts to send where. Furthermore, FBA models do not have kinetic laws, typically. Of course, they have other indicators that they are FBA reactions such as bounds, but again this type of element by element check is tedious.
I agree that in some cases, it might be nice to have a very fine grain hybrid model, but for a coarse one like the one I described, it is more convenient to have on the Model.
Last edit: Lucian Smith 2016-01-22
Chris, would it work for you to put a modeling framework term on the Submodel object?
I don’t think this is correct. This would make it so the referencing model was in charge of saying what the model framework is which makes no sense to me.
Actually, I think we have this backwards. I think the occurring entity representation branch makes a lot more sense on SubModel than Model. If the goal is to indicate what the model behaves like, such as for hierarchical diagrams, then it makes the most sense to indicate this in the diagram instantiating it, so it can be shown in the top level diagram properly.
Last edit: Lucian Smith 2016-01-22
Well, as an example, it would allow the same model to be instantiated twice, once in a deterministic framework and once in a stochastic framework. Besides, I didn't ask if it was correct, I asked if it would work ;-)
I don’t think you would typically want to do this as a stochastic and deterministic model would usually be different. However, allowing for this by “also” allowing modeling framework on SubModel is okay, though I would argue Occurring Entity Representation should be allowed here as well for all the arguments being made for it.
As for whether it would work or not, technically yes, practically no. Let’s assume you have a file that includes only ModelDefinitions. Perhaps this is a library of useful models that you want to send someone. I believe this is one of the use cases that you used to talk about for comp. Now, assume some Models are FBA and others not. There are no SubModels to indicate this, and there is only one SBMLDocument element.
I would like to turn this discussion around. What is the downside of including ModelingFramework as an alternative branch for Model/ModelDefinition’s SBO term?
Last edit: Lucian Smith 2016-01-22
Yes Chris, but most models do not have a submodel. That was actually part of my modularity proposal in 2007. A monolithic model would have been model with only one module (submodel)
http://sbml.org/Events/Other_Events/SBML_Composition_Workshop_2007/Modularity_In_Core
So, whatever we decide regarding the use of modeling framework in the model element, we need to keep the occuring entity there (aka pathway, composite process etc.). The question is not to switch from "occuring entity" to "modelling framework" but from "occuring entity only" to "occuring entity or modelling framework".
Last edit: Nicolas Le Novère 2016-01-22