Internalize functionality into COPASI itself (obviating the need for this repository)

[jonrkarr]

@shoops @fbergmann @pmendes I'm creating a separate thread for the discussion that @shoops initiated in #46.

Helllo Jonathan,

I think a better approach would be to let COPASI read the SED-ML directly. The problem I see is that if SED-ML asks for plot and you are running CopasiSE tor any language bindings he plot will not be generated. I think I have an idea on how to circumvent that. I will talk with @fbergmann about it.

Stefan

I would also greatly prefer to use COPASI directly -- this would be easier to maintain and lead to making COPASI's handling of SED-ML consistent with the SED-ML specs and other tools (in part through using our test suite to check COPASI). In fact, my preference is to internalize this command-line interface and Docker image into the COPASI repository so the COPASI team has control over this and can maintain it, release it, etc. At that point, this repository could be deleted. Ideally all tools would follow this path.

This purpose of this repository was to enable us to prototype handling of SED-ML consistent with the SED-ML specifications more quickly than we could by trying to help build/fix similar functionality in COPASI itself.

Capabilities of the current approach

This library does have capabilities for the other features of SED-ML such as below. This is imported from another library.

• Model resolution (e.g., URLs, URI fragments, MIRIAM ids)
• Model changes
• Repeated tasks
• Algorithm substitution utilizing relationships in KiSAO
• Reports -- including saving metadata in HDF5, multidimensional reports
• Plots

Rationale for current approach

We haven't used COPASI due to several points of divergence from the SED-ML specifications and various bugs. I didn't investigate every issue in detail. Some of this may only affect SED-ML export, and some of this may have been resolved since I first evaluated this.

• COPASI supports SED-ML L2
• COPASI ignores most KiSAO information
• KiSAO terms didn't even exist yet for several COPASI methods
• From what I could tell, COPASI has limited support for model changes
• COPASI appears to ignore namespaces for model changes and variables; as a result COPASI appears to have limited support for XPaths
• COPASI has bugs in exporting repeated tasks
• Based on what I've seen from SED-ML exported from COPASI,
  • It seemed that COPASI has issues with ids of SED-ML objects (e.g., not unique)
  • COPASI seems to confuse the ids and names of model variables in XPaths
  • Sometimes duplicate SED-ML objects are exported
  • Sometimes required attributes such as labels of reports are missing
• Exported time course sometimes differ from that in COPASI files
• COPASI's validation appears to ignore many issues with SED-ML files

Similarities of the current approach to COPASI to our approaches to tellurium, VCell, and other tools

For similar reasons, we haven't fully used tellurium's SED-ML handling either. We've posted issues about a number of issues and missing features. VCell was also in a similar situation -- multiple points of divergence from SED-ML and other tools, and lack of support for some features which felt were key. We've also posted a variety of issues for VCell. We've had to approach all other tools the same because they either have no, minimal, or divergent support for SED-ML.

[shoops]

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.

[jonrkarr]

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.

[shoops]

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.

[moraru]

@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

[jonrkarr]

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

[fbergmann]

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.

[jonrkarr]

Closing because COPASI does not intend to do this.