Specifications should clarify how model sources are intended to work with COMBINE archives

[jonrkarr]

The sources of models in SED-ML files in COMBINE archives are generally described relative to the location of the SED-ML file (e.g., ../models/model.xml). This is key for COMBINE archives to be self-contained. BioModels, JWS Online, and others do this. The SED-ML specifications acknowledges this practice for data generators. However, the SED-ML specifications for models (2.2.4, page 30) primarily mentions URIs which primarily focus on MIRIAM identifiers. I think this specifications should be edited to acknowledge and illustrate this practice.

Where the community diverges

The real issue is that there's divergence in the community about how to point to model files in nested subdirectories in COMBINE archives. There's at least two interpretations:

• Sources should be equal to locations in OMEX manifests (i.e. relative to the root of the parent COMBINE archive of the SED-ML file)
  • I'm informed that jLibSED-ML follows this (Ion confirms that VCell follows this; presumbably iBioSim and SBSCL do too)
  • Sources should be relative to SED-ML files
  • My interpretation is that the SED-ML specifications hint in this direction (2.2.2, page 26)
  • The only examples I could find in the SED-ML test suite (from JWS) follow this convention
  • JWS follows this convention
  • The COMBINE archive showcase illustrates this convention
  • BioSimulators utils follows this convention
  • I believe COPASI has switched to this convention

Other key resources don't appear to express an opinion

• COMBINE specifications -- no discussion; delegated to individual formats
• Files are directly nested under the root directory
  • SED-ML example
  • BioModels
  • SED-ML web tools

Proposed resolution

SED-ML follow the relative path convention

Proposed edits to the SED-ML specifications

I propose this section of the SED-ML specifications be edited to recognize the practice of local file paths relative to the location of the SED-ML file.

• Add ~1-2 sentence about this to section 2.2.4
• Point to one of the example SED-ML files that illustrates this

Implications for the rest of the ecosystem

jLibSED-Ml (and downstream) should be encouraged to embrace this convention.

[fbergmann]

Just to clarify what COPASI is doing, if the user chooses to export a SED-ML file to a certain location, an SBML file model[unique_number_in_dir].xml will be placed into that location and the SED-ML file will be placed right next to it (and referenced directly). If an OMEX archive is exported from COPASI, depending on the options chosen that OMEX archive will contain SBML / COPASI / SED-ML files / experimental data in a directory structure depending on the kind of data, with relative references from the archive root to these files. (i.e the SED-ML file from the sedml folder will refer to the SBML file in ../sbml/).

[matthiaskoenig]

I am resolving all (relative) paths relative to the location of the SED-ML file. I am not handling the case of absolute paths (because these do not make sense in the context of a COMBINE archive). When writing COMBINE archives from sbmlsim I add all models in ./models and all datasets in ./datasets/.

On Tue, Apr 6, 2021 at 9:42 AM Frank Bergmann @.***> wrote:

Just to clarify what COPASI is doing, if the user chooses to export a SED-ML file to a certain location, an SBML file model[unique_number_in_dir].xml will be placed into that location and the SED-ML file will be placed right next to it (and referenced directly). If an OMEX archive is exported from COPASI, depending on the options chosen that OMEX archive will contain SBML / COPASI / SED-ML files / experimental data in a directory structure depending on the kind of data, with relative references from the archive root to these files. (i.e the SED-ML file from the sedml folder will refer to the SBML file in ../sbml/).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SED-ML/sed-ml/issues/136#issuecomment-813903042, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAG33OWKROOFN2EW253HAQTTHK3NHANCNFSM42FU24FQ .

-- Matthias König, PhD. Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt Universität zu Berlin, Institute of Biology, Institute for Theoretical Biology https://livermetabolism.com @.*** https://twitter.com/konigmatt https://github.com/matthiaskoenig Tel: +49 30 2093 98435

[luciansmith]

This is now incorporated into the draft spec with the following addition:

There are three typical ways to identify a model with the \element{source} attribute: by relative path, by identifier, or by URL.

An example for the definition of a model via a relative path URI is given in Listing~\ref{lst:source0}. The example defines one model \code{m1} with the model \concept{\element{source}} available from \val{oscillator.xml} in the same directory or location as the SED-ML file. A \element{source} value of \val{./oscillator.xml} would accomplish the same thing more explicitly, with \val{./} being shorthand for 'the current directory'.

\begin{myXmlLst}{The SED-ML \code{source} element, using the URI scheme}{lst:source0} <model id="m1" name="repressilator" language="urn:sedml:language:sbml" source="oscillator.xml">

[MODEL PRE-PROCESSING]

\end{myXmlLst}

I'm closing this, but feel free to comment if you have a wording suggestion.