Internalize functionality into COPASI itself (obviating the need for this repository) about biosimulators_copasi HOT 7 CLOSED

The problem is KISAO there is no support for software dealing with it. Something like libKISAO is needed for applications to handle SED-ML properly.

from biosimulators_copasi.

Exporting information about the algorithms and parameters used doesn't require the whole ontology or a library. This just requires information about the terms which correspond to each COPASI method and parameter, which has to be looked up manually.

Where the ontology is needed is to execute SED-ML documents involving similar algorithms (e.g., substitute LSODA for CVODE). There are various libraries for working with OWL files that can be used to query for similar algorithms. I think the standardization around the OWL format and querying OWL files minimizes the need for a specific library for KiSAO. The old Java libKiSAO is just a thin wrapper over an OWL library. We added a Python KiSAO package which is similarly a thin layer over an OWL library.

from biosimulators_copasi.

Exporting the KiSAO terms is no problem. Loading and finding similar/equivalent parameters or method will be. As long as the second is not provided by a dynamic link library we will probably not be able to support it. This means this repository/effort will have to do the mapping and provide COPASI with a feasible final mapping.

from biosimulators_copasi.

@shoops we wrote such code 3 month ago, easy if using OWL converted to OBO; @danv61 made it generic so it literally takes only a few lines to change to adapt for COPASI (or any other simulator); it is Java though

from biosimulators_copasi.

Ion points out another path through a substantially equivalent format which also does not yet require a specific library for KiSAO. Additional formats that OWL files can be converted to include ttl and JSON-LD.

Some potential libraries for working with ontologies files

• cowl
• owl-cpp
• RDF libraries
• JSON-ld libraries

from biosimulators_copasi.

Some of the points you mentioned could indeed be added to COPASI, but not all of it. Given that the user interface will only work with one model at a time there will always be a need for handling multiple models, and as this is possible using the copasi API, this repository (or an implementation in one of the language bindings or corc/basico) will be needed going forward.

What we will do in the future will be to im/export the new KISAO terms created for the COPASI methods and their parameters. This did not make it into 4.31 but will be in the version afterwards.

As pointed out in #46, it does make sense to provide a utility function that given a plot specification and for that matter report specification, collects the output that would have been plotted / written to a report available to the caller.

from biosimulators_copasi.

Closing because COPASI does not intend to do this.

from biosimulators_copasi.