Meeting Minutes 4 October 2002 So what's going on with 1.1??

Get the PDF!

Contents

• 1  Introduction
• 2  More on the Dot Notation/Model Attribute Discussion
• 3  The Catalyst in a Reversible Reaction
• 4  Use of XLink in <import_model>?

1  Introduction

"So what's been happening with version 1.1 of the CellML Specification?" I hear you asking. Well, it's been a very busy past few months, but no need to worry. We haven't forgotten about our proposed changes. I've set up some new examples to suss out what changes need to be made to the Specification, we've been delving further into the dot notation/model attribute discussion, and along the way other issues have popped up. I'll discuss it all here.

2  More on the Dot Notation/Model Attribute Discussion

I put the question to the experts (see xml-dev thread), and they were a bit divided themselves. Some recommended using namespaces, which, in the end, would be similar to using the dot notation except with a colon separator (see Figure 1). Others thought that use of the model attribute is fine: "controlling interpretation of one attribute by means of another can be an effective descriptive technique at times."

<model xmlns="http://www.cellml.org/cellml/1.0#" xmlns:example="http://www.example.com/sample_model.xml">

  <import_model name="example" uri="http://www.example.com/sample_model.xml" />

  <component name="what_you_want">
    <variable name="A" units="example:meter_per_cm2" />
  </component>
</model>

Figure 1 Use of namespaces for importing models. You still need the uri attribute because specifying the namespace only gives you a unique naming mechanism. In this case, the units, "meter_per_cm2", are to be found in "http://www.example.com/sample_model.xml" because the example prefix tells us this. However, a processor does not import the sample_model.xml but only extends the units value to "http://www.example.com/sample_model.xmlmeter_per_cm2".

There's now agreement among Team CellML to use the model attribute.

3  The Catalyst in a Reversible Reaction

One interested CellMLer pointed out the flaw in the following statement (taken from the documentation for the Bhalla-Iyengar EGF pathway):

The value of the role attribute specifies the participation of the species when the reaction is proceeding in the direction specified by the value of the direction attribute. The direction attribute may take values of "forward", "backward", and "both". Its value defaults to "forward" if omitted, as it has been in this binding reaction. The fact that the reaction is reversible implies that a species that is a reactant in the forward direction is a product in the backward direction and that a species that is a product in the forward direction is a reactant in the backward direction. No such assumptions are made about species that act in other roles.

He points out that a catalyst (activator, etc.) in the forward direction must be a catalyst in the backward direction. Well, who are we to challenge the laws of thermodynamics? We do agree with him. According to Melanie, by far the most knowledgeable in the group in this area, by making no assumptions, the modeller is allowed to simplify reactions. The example used was the reactions involving phosphatase/kinase catalysis. It is true that these are two separate reactions, but generally biologists refer to the set of reactions as a single reaction. No assumption is made for qualitative purposes.

Because the CellML Specification does not explain itself at all, we will not add a clarifying statement to the CellML Specification. However, I did notice while researching the topic that the Specification 1.0 does not say anything about how the processor should treat species acting in other roles. I will add the following sentence to Section 7.5.1:

No such assumptions should be made of species acting in the other roles.

I will also add the clarifications necessary to the Bhalla-Iyengar EGF pathway documentation.

4  Use of XLink in <import_model>?

Poul had me look into the use of XLink. XLink has href and title attributes that squarely correspond with the uri and name attributes we've used up until now. I think the only reason we would use XLink is to enable XML-capable applications to understand that there is a link between the importing and imported models without understanding the rest of the CellML code. Since it's been a goal of CellML from the start to use pre-existing languages, this is a fairly convincing reason to use XLink.

In the XML community there are plenty of detractors of XLink, so many, in fact, that there has been a similar hyperlink language laid out by W3C members called HLink. Because there is dissension among the W3C about hyperlink languages, I'm almost hesitant to use XLink. However, the TAG, Technical Architecture Group, chaired by the father of the Internet himself, Tim Berners-Lee, has given their approval of XLink, so it'll probably be around for a while. The new <import_model> element would be as shown in Figure 2.

<model xmlns="http://www.cellml.org/cellml/1.0#" xmlns:xlink="http://www.w3.org/1999/xlink">
  <import_model xlink:href="http://www.example.com/component.xml" xlink:title="alias" />
</model>

Figure 2 Use of XLink on the <import_model> element.

I think it's up to us to indicate how the XLink attributes are treated by CellML processing software. There is an optional xlink:show attribute with a value of "embed" that we might want to consider using. According to the XLink spec, the "embed" attribute value is for presentation only and does not "dictate permanent transformation of the starting resource." Thus, the "embed" attribute value could suggest that the imported model becomes a new instance of the model but won't have the original importing model modified in any way.