#334 Add appendix on 'mathematically complete' models

[Lucian Smith]

It has always been true that one can create valid SBML models that are mathematically incomplete, and do not have enough information in them to simulate. It might be nice to add an appendix that describes how to tell if a model is mathematically complete or not, and therefore ready to simulate. It could also talk about what different tools choose to do with incomplete models (from 'provide defaults' to 'use NaN' to 'refuse to do anything').

[Lucian Smith]

From Andreas (https://sourceforge.net/p/sbml/sbml-specifications/332/?page=1):

"Just one remark: there could always be packages that redefine or extend elements and give meaning where it would otherwise be lacking. For instance, if a reaction has upper bound = lower bound = value > 0, but lacks a kinetic law, its flux could be interpreted as being that constant value, even though the core model would lack kinetic information.

Furthermore, an "isSimulateble" function would need to take the context / the simulation framework into account. Different rules may apply depending on how the model is going to be simulated. For instance, kinetic laws have now become totally irrelevant in FBC scenarios since local parameters are no longer used.

It might therefore be difficult to write such a check function in general and we would need to specify exactly what it should check and under which circumstances."

[Lucian Smith]

And, reply from Chris:

"I get your point. It would certainly depend on what we mean by “is simulatable”. It could be narrowed to be “is a SBML core simulatable model”, namely when reduced to SBML core that it is complete with respect to ODE simulation. This would include comp/arrays (with static arrays), since you could flatten and check. It would not include models with say Spatial/FBC/Multi/Qual etc. These packages would need their own “is <blank> type simulatable” checks."

[Sarah Keating]

I dont think SBML needs to consider trying to apply an isSimulatable type function. In terms of what different tools do with respect to missing information this may also be a tool dependent functions (as well as contxet/framework dependent.)

I'm not sure it is even a best practice. If we wanted to include some sort of algorithm for 'how to tell is a basic ode model has all the required information' I would suggest an appendix.

[Lucian Smith]

Still need more discussion on this proposal.

I think Sarah's modifications are good ones: any section should indeed be an appendix, and would simply describe how to tell if a model was 'mathematically complete', or some such phrase.

Useful addition to the spec? Not useful addition to the spec?

Actually, I'm not sure if Sarah is in favor of adding this to the spec or not; her post is 'if we do, it should look like this' and I agree, but she may or may not be in favor, in the end, of actually adding it.

(Either way, a function could be added to libsbml that does this; if this proposed appendix is added, it probably should, but even if the proposed appendix is not added, it still could be.)

[Brett Olivier]

I agree with Sarah, to me SBML should be as tool and framework neutral as possible so "isSimulatable" is an appendix ... if anywhere.

If at all I would then (based on Chris' idea) prefer something like "isXMinimalComplete" where X is "core", "qual", "fbc" etc. which would enable arbitrary set(s) of validation rules to be applied to the model that would ensure all the elements are in place for a specific modelling type.

Going beyond this, IMHO, is problematic as it becomes equivalent to FBC's "strict" attribute, an approach that comes with a bunch of its own problems.

[Andreas Dräger]

I agree with Brett (remark: these isXMinimal... functions should then be described in the appendix of respective packages).

[Andreas Dräger]

I should have mentioned: If people want them at all because there is not a strong tendency specification-wise. I am somwhat neutral if this should be included or not, maybe a question to the community.

[Brett Olivier]

On reflection I think it is a waste of resources to even try and add something useful to the spec.

My suggestion would be to develop this as a separate document/webpage and, possibly, refer to it from the spec somewhere.

[Dagmar Waltemath]

I agree with Brett again - I do not think this should be part of the core spec. And it should not be something that delays the publication of the spec. It can be listed as additional material on the web page.

[Lucian Smith]

My take on the current state of this issue is that we have two 'no' votes (Brett and Dagmar), and one neutral vote (Andreas). Sarah's comments could be taken either way, I think, we haven't heard from Nicolas. Sarah and Nicolas, could you weigh in and say whether you're pro, anti, or neutral on this issue?

[Sarah Keating]

My view was if people felt we should do it; it ought to be an appendix BUT I do not think it is a necessary thing. So as a straight forward Yes/No I vote No.

[Lucian Smith]

OK, that makes 3 editors in agreement that we should not include this in the official spec, with none opposing, so I'm closing the issue. Thanks, everyone!