Where do simulations and computational models live in COB

[cmungall]

Examples:

• climate model
• reaction-diffusion model
• metabolic model
• simulated membrane (https://github.com/DominikMartinat/membrane_ontology)

I think this should go under IAO:0000030 ! information content entity and these should be largely treated the same way we would treat a computer program that can be executed with different parameters, outputs recorded etc. Should we just document this, and leave specific classes to IAO?

For discussion of how to represent what the model is a model-of, I would open a new issue.

[wdduncan]

I agree that they are best represented as a child of ICE. Perhaps we might want to shortcut relation between the simulation code (as an ICE) and the things results from when a computer executes the code, if such a shortcut relation does not already exist.

[bpeters42]

We have things like 'software' in IAO, and they fit well with what you are saying about 'models'. Thus they should go under 'plan specification' - which can be executed as a process (with inputs and outputs and parameters). In this case inputs and outputs would be information. We had worked on models as part of IAO/OBI, and have the leftover class 'prediction' in OBI which would be a subtype of model execution. We got scared back in the days of models because it wasn't clear what a model that simulates a hypothetical (e.g. non-standard physics) would be 'about'. That is a concern that we have dropped everywhere else, and we should do so again (but OBI should revisit and update that 'prediction' class if we integrate models. - Bjoern

…

On Wed, Dec 11, 2024 at 6:29 AM Chris Mungall ***@***.***> wrote: Examples: - climate model - reaction-diffusion model - metabolic model - simulated membrane ( https://github.com/DominikMartinat/membrane_ontology) I think this should go under IAO:0000030 ! information content entity and these should be largely treated the same way we would treat a computer program that can be executed with different parameters, outputs recorded etc. Should we just document this, and leave specific classes to IAO? For discussion of how to represent what the model is a model-of, I would open a new issue. — Reply to this email directly, view it on GitHub <#289>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJX2IU5MUDBBWMLCQ5MXGD2FBD57AVCNFSM6AAAAABTNTV4FSVHI2DSMVQWIX3LMV43ASLTON2WKOZSG4ZTGMJTHA3DCOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Bjoern Peters Professor La Jolla Institute for Immunology 9420 Athena Circle La Jolla, CA 92037, USA Tel: 858/752-6914 Fax: 858/752-6987 http://www.liai.org/pages/faculty-peters

[wdduncan]

I would be okay with it as a sub class of plan specification, except the definition has language about plan specifications being concretized as a realizable entity.

I wrote a paper arguing why I don't think this make sense, and there is a long github issue about this topic. So, I can't support it being a subclass of plan specification at the moment.