Problems with the ontologies, and some glyph names

[adrienrougny]

The ontologies in section 3.3 "The conceptual model" mix glyphs and concepts, which doesn't seem correct.
Indeed, in those ontologies, nodes are classes of glyphs, and arcs is_a relationships shared among concepts (and not glyphs): For example, in Figure 3.1, the Process and Omitted process classes refer to the process and the omitted process glyphs respectively (as they are subclasses of the SBGNGlyph class), and the Omitted process class is a subclass of the Process class. In a given map, all instances of the omitted process glyph are not instances of the process glyph (simply because the glyphs are different), but in terms of biological concepts, all instances of omitted processes are instances of processes (i.e. a process is an omitted process). Hence the relationship Omitted process is_a Process only holds if those classes refer to the biological concepts (and not to the glyphs used to represent these concepts).
In general, I believe an ontology organizing the relationships shared between glyphs is not interesting, because its structure would have to be horizontal: all classes of processes (referring to the process glyph, the omitted process glyph, the association glyph, etc.) would have to be sister classes (i.e. share the same parent class); and it would be the same for all other types of glyphs (modulations, EPNs, etc.). That is of course not the case for ontologies organizing the represented concepts (see SBO).

Another related issue is whether the process glyph can replace any other type of process glyph (the omitted process glyph, the dissociation glyph, etc.), i.e. whether the process glyph can be used to represent any process (and possibly losing some information doing so), or not. The same question arises for the modulation glyph. I also believe that, interestingly, it is relevant for the unspecified entity glyph. The alternatives are illustrated in the following PDF.

Finally, it would be good to rename the process glyph and the modulation glyph: currently, when talking of "process grlyphs", we do not know if we're talking about "all instances of the process glyph" or all instances of glyphs that represent processes (i.e. all instances of the process glyph, together with those of the dissociation, association, ..., glyphs). In Stuart's version of the specification L1V2, the process glyph was renamed to the generic process glyph. The same could be done for the modulation glyph.

[amazein]

This should be discussed via [sbgn-discuss], voted on etc. For L1V2 we should act on what we already have so we can do it quickly. If you would like to change names of the glyphs in L1V2 we should start the discussion via [sbgn-discuss] soon. I think we can postpone this. I agree, there are inconsistencies there, they should be fixed, but they are not critical for the use of the notation.

On the topic itself, I understand the motivation for renaming the process glyph. On the other hand, generic process assumes specific processes. if in the future we remove association and dissociation glyphs, there would not be any specific processes over which we would have generic process. This might not be a problem though.

For modulation, stimulation, catalysis and inhibition arcs, the term could be regulatory arcs?

[adrienrougny]

I agree it's no urgent matter and it can be postponed (that's why I hadn't assign any milestone to it), and even discussed later. I just had to write it before forgetting it.

For the generic process, even without the association and dissociation, wouldn't the omitted process and uncertain process still represent specific kind of processes?

[amazein]

Yes, generic process sounds good, even without association and dissociation.

[hasanbalci]

Apparently, there are a few questions to answer in this issue:

• Differentiation of glyphs and concepts in Section 3.3.
• Can the process glyph replace any other type of process glyphs?
• Renaming the process glyph and modulation glyph. Currently the term "generic process" is used in section 2.6 Process Nodes.

[draeger]

While I see the intentions behind it, I am not yet fully convinced. For instance, the process node can be used instead of any of those specific ones. The same is true for the modulation arc, and in the end also for the label. Please also keep in mind the consequences with respect to related standards, such as the SBML layout extension if any. Most symbols also correspond to specific SBO terms, which are are also hierarchically organized. When one is changed, the other should match it as well.

[adrienrougny]

I will split the conceptual model into two figures to solve the issue of mixing glyphs and concepts in the ontology. If they are ok we integrate them in the spec. The other issues related to the conceptual model will be solved later.

[adrienrougny]

conceptual_model.gv.pdf
glyph_model.gv.pdf
Two draft models for the concepts and the glyphs, represented using Visual OWL (notation for representing owl ontologies).
The models could be split or represented with a different layout (they are made with graphviz, so other types of layouts can easily be applied to them). TODO: represent abstract class with italics; make SBO terms as links.

[adrienrougny]

TODO Adrien: put the source files

[cannin]

2024-Nov-14: @tczauderna and @cannin discussed. The existing conceptual model does have issues. @cannin and @tczauderna are supportive of

1. only keeping the glyph model type figure that @adrienrougny suggested
2. no need to have extra attributes on the figure
3. to include both arcs and nodes in one figure (if it can be laid out nicely)

we also looked at what tools to use; one option is yEd that exports SVG and to have the glyph connections stored as a CSV file (easy to convert to some other format) as a backup if it needs to be redrawn again

[adrienrougny]

The GraphViz source files:
conceptual_model.gv.txt
glyph_model.gv.txt
A GML version of the glyph model with a layout, that can be opened in yED:
glyph_model_with_layout.gml.txt

[hasanbalci]

A few points to consider on glyph model figure:

• Maybe we can group multimer nodes under a parent node named "multimer node" (similar to subunits, and in this way, we can also reduce the number of nodes at level 3 for a better layout.)
• Should we use "simple chemical multimer" or "multimer of simple chemicals"? The first one seems more appropriate to me.
• Should we add "clone marker" as a child node of "auxiliary unit/decorator"?
• "equivalence operator" can be included under the "logical operator node" as we categorize it as logical operator in the spec.
• "terminal" -> "submap terminal"

[cannin]

Imperfect, but less wide. +1 on grouping multimers. Edited with yEd

glyph_model_with_layout_yed.graphml.txt

[adrienrougny]

Nice graph!

• Also ok for grouping multimers.
• I prefer multimer of simple chemicals (it's the Systems BIology Ontology term), but in the spec the glyph is named "simple chemical multimer", so maybe we should stick with it (or change the names of multimers in the spec)
• Yes clone marker could be a child of auxiliary unit, although it is not really a node
• Ok for having the equivalence operator as a logical operator node, since it is like that in the spec. But the equivalence operator is actually not a logical operator in the logical sense, so we could think of modifying the spec and having the equivalence operator as an individual node
• Terminal->Submap terminal ok

On the graph, we could highlight all abstract classes, either with a specific color (like SBGN node, glyph, arc), or by italicizing the label, for example.

[hasanbalci]

I tried to improve layout and applied some of the points above.

glyph_model_with_layout_yed_v2.graphml.txt

[adrienrougny]

Looks great!

[adrienrougny]

Could we add a subunit multimer node for symmetry?

[hasanbalci]

@ugurdogrusoz and I went through the glyph model diagram and this is what we came up with. For this version we decided to keep it to show only inheritance (is-a) relationships. Adding other relations (like has-a) would make the graph too complicated. In future versions, a separate graph showing other relations can be added if desired.

sbgn_glyph_model.graphml.txt

[adrienrougny]

Looking at the model, we need to harmonize the names for multimers (as pointed out above):
Currently, we have:

• names of multimer glyphs as "macromolecule multimer", "simple chemical multimer", ...
• names of multimer subunits as "multimer of macromolecules subunit", "multimer of simple chemicals subunit", ...
• SBO terms mentioned in the spec as "multimer of macromolecules", "multimer of simple chemicals", ...

I would harmonize based on the SBO terms, that is:

• change the names of the multimer glyphs to "multimer of macromolecules", "multimer of simple chemicals"

and:

• change the name of the abstract "mutimer of subunits" class to "multimer subunit"

[adrienrougny]

Changes above would look like this:
sbgn_glyph_model.graphml.txt
sbgn_glyph_model.pdf

[hasanbalci]

@adrienrougny I agree, otherwise it seems inconsistent. I uploaded this last one to the overleaf. We may consider changing the naming of these multimers in the spec as well, as you suggested before.

Ugur and I also considered changing the following section headers in the spec to be consistent with the other headers: Logical operators -> Logical operator nodes and Encapsulation -> Encapsulation node. Let's discuss this in the meeting.