MathML Viewer widget: allow for the custom rendering of a variable using TeX

[agarny]

Right now, A_b_c_d_e will be rendered as a succession of subscripts. However, for some models (Bond graph models), it's common to use superscripts and subscripts. So, something like A_b_c could have b rendered as a superscript and c as a subscript. Note that we probably want to stick to _ as the delimeter since it is part of the CellML name set of characters.

[agarny]

My current proposal is described at #2744 (comment). @dbrnz and @nickerso, is that something that would work for you?

[agarny]

We might want to look at https://github.com/goldsborough/latexpp, even though it's not active anymore.

[nickerso]

adding a new "extension" element like rendering has no migration path to CellML 2, so not keen on seeing that added as it will inevitably increase the burden of eventually migrating OpenCOR CellML 2. Using annotations with the same information could work as it would allow them to be saved in place in the CellML 1.x models OpenCOR currently handles and have a clear migration path forward to CellML 2. Since users should never be editing the raw CellML, the fact that its serialized in RDF/XML shouldn't matter.

[agarny]

adding a new "extension" element like rendering has no migration path to CellML 2, so not keen on seeing that added as it will inevitably increase the burden of eventually migrating OpenCOR CellML 2. Using annotations with the same information could work as it would allow them to be saved in place in the CellML 1.x models OpenCOR currently handles and have a clear migration path forward to CellML 2. Since users should never be editing the raw CellML, the fact that its serialized in RDF/XML shouldn't matter.

Fair enough. Ok, so we could do something like this:

• Use the current behaviour for something like:

<variable name="A_my_superscript_my_subscript" initial_value="10" units="dimensionless"/>

• Use the rendering TeX-based annotation for something like:

<variable name="A_my_superscript_my_subscript" initial_value="10" units="dimensionless" cmeta:id="my_unique_id">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:opencor="http://www.opencor.ws/">
    <rdf:Description rdf:about="#my_unique_id">
      <opencor:rendering>
        A^{my\_superscript}_{my\_subscript}
      </opencor:rendering>
    </rdf:Description>
  </rdf:RDF> 
</variable>

In the CellML Text view, we could have that rendering information expressed as follows:

var{my_unique_id} A_my_superscript_my_subscript: dimensionless {init: 10} rendered as A^{my\_superscript}_{my\_subscript};

@nickerso and @dbrnz, is that something you would be happy with?

[agarny]

Ping @nickerso and @dbrnz.

[nickerso]

I wonder if we are looking at this in the wrong way. @agarny's suggested solution looks reasonable if we want to simply let people provide a specific way to render a variable name in the built-in math viewer using LaTeX, which is nice to have but not something that we'd be wanting to support long term.

I wonder if a more sustainable path forward is to explore a more explicit break from the current 1:1 mapping between the OpenCOR text format and CellML. Something would enable more of the semantics to be described "easily" by users, giving a more meaningful rendering of variable's in the internal math viewer but also giving knowledge that could be useful outside of OpenCOR.

For example, instead of:

var{my_unique_id} A_my_superscript_my_subscript: dimensionless {init: 10} rendered as A^{my\_superscript}_{my\_subscript};

how hard would it be to instead do:

var{my_unique_id} A_my_superscript_my_subscript: dimensionless {init: 10} is substrate my_superscript in compartment my_subscript;

and then serialising the additional knowledge as annotations. Would need to decide what the different type of is and in things could be and what happens when they are not present, but I think this puts us on a path to start capturing a lot more knowledge at time of model authoring rather than just a slightly different representation of the variable name. And will allow for the specific styling to be changed as needed, and potentially let the user define / choose their preferred styling.

[agarny]

This issue came about because the MathML viewer cannot currently render variable names in a way that is meaningful to bond graph modellers. However, we should be able to solve this problym by using TeX (and with the help of a library such as blahtex).

Now, I appreciate what you are suggesting with regards to giving knowledge to a variable, but I am not sure this is the best place to do it. Isn't annotation supposed to be stored in an external file (since people might want to annotate the same thing in different ways)? Also, could we come up with some semantic information that accounts for the different ways we might want to render the name of a variable in the MathML viewer?

Otherwise, in your example, I can't see A being mentioned anywhere in is substrate my_superscript in compartment my_subscript. Does it mean that it would be dropped in the rendering because it's not relevant to the variable's semantic information?

[nickerso]

Otherwise, in your example, I can't see A being mentioned anywhere in is substrate my_superscript in compartment my_subscript. Does it mean that it would be dropped in the rendering because it's not relevant to the variable's semantic information?

Whoops! It could be inferred for some models based on the units, but agree that it needs to be specified.

I'm exactly thinking of the bond graph use-case here. Current convention is to have the solute/substrate as a superscript and compartment as a subscript. Sometimes also the type of energy as a subscript. Not that long ago, the convention was to have a combo solute,compartment subscript. Hardcoding the LaTeX would require these models to be changed in order to render according to a different convention. Capturing the semantics would allow the rendering to change with no need to change the models or annotations.

[agarny]

Hmm... so, we would have some semantic that is very much bond graph dependent?

Although this issue was created to help bond graph modellers, I don't think we want a solution that is bond graph specific.

[nickerso]

I agree, shouldn't be BG specific. But if you look at the use-cases to support with this kind of advanced rendering, it is generally the same across a large portion of models in PMR.

Just trying to think of ways to get something more useful than a bit of LaTeX code that is only ever going to be used in OpenCOR. While being concerned that providing a simple way to provide LaTeX for display in OpenCOR is going to rapidly populate a cohort of models that will need support going forward...

[agarny]

Ok then I am not sure what to suggest. I am not sure we want to spend too much time on this issue since we want to move to Web/Electron OpenCOR, so...?