KiSAO migrated to GitHub

4 views
Skip to first unread message

Jonathan Karr

unread,
Mar 25, 2021, 1:53:07 AM3/25/21
to sed-ml-...@googlegroups.com
Following our discussion this week, I migrated KiSAO to GitHub to make it easier to request changes:
https://github.com/SED-ML/KiSAO

Please use issues for small changes. If you'd like larger changes, please either use Protege to edit the ontology and submit your revision via a pull request or describe the changes you'd like as a table in an issue.

I can start a new section for independent and dependent output variables of algorithms (symbols). Are there any additional symbols that are key to add at this point?
  • kinetic (e.g., SBML)
    • time (urn:sedml:symbol:time)
    • concentration
    • amount
  • flux balance (e.g., SBML-fbc)
    • (objective) value
    • flux
    • reducedCosts
    • shadowPrices
    • minFlux
    • maxFlux
  • logical (e.g., SBML-qual)
    • step?
    • level
Jonathan

Frank Bergmann

unread,
Mar 25, 2021, 5:06:03 AM3/25/21
to sed-ml-discuss
I think we should also add: 

- particle number
- particle number rate


Potentially i could also see: 

- initial value (param, compartments)
- initial amount / concentration / particle number 

if we wanted to distinguish those from the transient ones. 

Frank

Matthias König

unread,
Mar 25, 2021, 6:19:35 AM3/25/21
to sed-ml-...@googlegroups.com
Yes, the initial parameters, concentrations, ... would also be helpful.
This would allow to easily calculate changes relative to baseline/initial values.
E.g. to normalize
S1_norm1 = S1(t)/S1(t=0)
S1_norm2 = (S1(t)-S1(t=0))/S1(t=0)
This often happens in analysis but is currently difficult to handle.

particleNumber should definitly be in there.

--
You received this message because you are subscribed to the Google Groups "sed-ml-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sed-ml-discus...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sed-ml-discuss/b5e24655-ad70-47a3-bdf3-3ad3f3da4e8cn%40googlegroups.com.


--
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
koni...@googlemail.com
https://github.com/matthiaskoenig
Tel: +49 30 2093 98435

Jonathan Karr

unread,
Mar 25, 2021, 1:26:18 PM3/25/21
to sed-ml-...@googlegroups.com
I can include particle number.

Regarding initial conditions, I think this needs a little more discussion.
  • Data generators for initial conditions would have different shapes than other data generators. This could create the need to keep track of the implied dimensionality of each KISAO term for dependent/independent variables.
  • Including separate terms for initial conditions would double the number of necessary terms.
  • Inevitably, this would lead to the desire to have yet more terms for final conditions, midpoints, starts/ends of other types of dimensions, etc.
  • I think of "initial" as a slice of the specific dimension (time), rather than something that indicates a particular dependent or independent variable of the output of a simulation.
How about yet an additional section of KiSAO for slices of dimensions? Then SED-ML needs a specific way of using such terms either in mathematical expressions for data generators or with sedml:variable. The latter might be a better choice. This could be captured by another attribute to sedml:variable (e.g., slice): <variable target="..." symbol="..." slice="..." />.
  • start
  • end
  • initial
  • final
Jonathan

Jonathan Karr

unread,
Mar 25, 2021, 6:18:59 PM3/25/21
to sed-ml-...@googlegroups.com
I start to add the above to KiSAO. Thoughts on this organization?

One issue is the Jacobian. Do you want to be able to think of the Jacobian as a single output? or specify particular partial derivatives? The former is more semantically meaningful, but the latter seems more consistent with the current SED-ML scheme of data generators to me.

image.png

Jonathan

Lucian Smith

unread,
Mar 25, 2021, 6:50:00 PM3/25/21
to sed-ml-...@googlegroups.com
Getting the entire Jacobian at once is definitely a common operation, and I think should be supported directly.  Getting elements from the Jacobian could also be supported, though I don't know if that's the best design or not.

Basically, I think we should definitely do:

  <variable id="jacobian" symbol="[kisao Jacobian]' modelReference="mod1"/>

And could either use the same KiSAO term to get Jacobian elements:

  <dependentVariable id="jacobian_S1_J1" symbol="[kisao Jacobian]' modelReference="mod1" target="S1" target2="J1"/>

or use a different KiSAO term to get Jacobian elements:

  <dependentVariable id="jacobian_S1_J1" symbol="[kisao Jacobian element]' modelReference="mod1" target="S1" target2="J1"/>

(Or not provide Jacobian element access at all?  Anyway.)

-Lucian



Jonathan Karr

unread,
Mar 25, 2021, 7:22:14 PM3/25/21
to sed-ml-...@googlegroups.com
That's what I intended. I wanted to bring this up for discussion since we're introducing outputs with different dimensions.

Frank Bergmann

unread,
Mar 26, 2021, 10:20:35 AM3/26/21
to sed-ml-...@googlegroups.com
I've been thinking of the slice construct, and for me it just does not quite work. When proposing these terms, i was thinking about variables that area already being kept / calculated by simulation tools. In that way it is not really a slicing of the data, but telling which aspect of an entity to access. So while it may seem cumbersome to add terms like: 

- initialConcentration
- initialAmount
- initialParticleNumber
- initialValue (for parameters / compartments) or even initialVolume / initialSize (for compartments that would be synonyms of initialValue)

For me that seems more reasonable than a slice construct. 

I agree the slice construct could be mapped to that, but i would prefer a term for the former. 

cheers
Frank

P.S: final would just be a synonym for end?


Frank Bergmann

unread,
Mar 26, 2021, 10:30:26 AM3/26/21
to sed-ml-discuss
In the good tradition to replying to one's own post. Just to clarify my concerns. If we went with the slice construct, then rate, / particle rate / rateOfChange are just as valid a slice as initial / final. But again, it is for me stretching the term 'slice' it would work, but i dont see any advantage to just using the term directly. 

Frank

Jonathan Karr

unread,
Mar 30, 2021, 6:52:48 AM3/30/21
to sed-ml-...@googlegroups.com
I saw rates as different than slices. But, I agree that these are often derived quantities. Ideally, we wouldn't have ontology terms for every combination. However, I'm hesitant to suggest that we should try to use combinations of KiSAO terms to describe the intended targets of SED-ML variables. Same with (e.g, hybrid) algorithms. I was comfortable with ontology terms for rates. But, I thought slicing could be done without more KiSAO terms.

I don't have a strong opinion either way. I just wanted to bring this up so we all have a chance to weigh in before we start to lock on a particular design. The one thing I would point out is that the more KiSAO terms we use, the more need there will be to community which KiSAO terms each tool recognizes. This is because KiSAO terms have to be provided and interpreted. They are not metadata like SBO terms in SBML. BioSimulators can capture this information. It would become more critical that the community use BioSimulators or something with similar capabilities to share this information.

Jonathan

Reply all
Reply to author
Forward
0 new messages