Forums

Several people raised the issue of including several layouts for one
model. This is a point we actually had not thought about so far, but we
agree, that it might be a good idea.
We potentially see two possibilities to include several layouts in one
model:


The first possibility would be a small extension to the draft we
mentioned. In <listOfNodes> for <Specie> we would define all nodes that
are needed for all the different layouts. Which would effectively leave
it unchanged in respect to our current proposal (This implies that only
<SpeciesReference>s are to be displayed. If people would like to
display Species without a Reaction, each node would have to have a
display attribute which represents an enumeration of all the layouts,
it takes part in.). For the <layout> tag in Compartment as well as for
the <connector> tag in Reaction and the <edge> tag in SpecieReference,
we would include a new attribute called "layoutID", which would hold a
unique id of the layout for which the element has been defined.
E.g. for a <SpecieReference> this could look like this

<SpecieReference>
....
<edge nodeRef="3" layoutID="1"/>
<edge nodeRef="5" layoutID="2"/>
....
</SpecieReference>

The advantage of this version is that only a small overhead is produced
and only small changes to the current draft are needed.
The disadvantage would be that it would not be very human readable if
many layouts would be included in a model.



The second version would be more along the lines of Andrew Finney and
John Wagners proposal to take the layout information out of the model
and put it all in a seperate tag, lets call it view, after the model
definition.
In this version the different layouts would be seperated in individual
tags (e.g. <view id="1">).
Each layout element would also have to have some reference to the model
element it belongs to. This reference would probably have to be
different depending on wether we talk about sbml level 1 or level 2. In
level 1, we could just use the name attribute since it is unique
throughout the model.
In sbml level 2, we have the SId on most elements. But what about
<SpeciesReferences>, they do not have an SId of their own, so how would
they be referenced? So far we have not been able to come up with any
reasonable solution for that.
This second approach would not be much different from the first
approach, the layout information would just be moved to a different
place in the file. The will probably enhance readability, but on the
other hand produce some more overhead since the corresponding elements
in the model must be referenced somehow, which is not even trivial for
all elements.


After presenting the possibilities as we see them, we would very much
like to get some feedback on what other people think and on how the
problem with the missing ids for <SpeciesReference> tags in sbml level
2 could be overcome in order to be able to implement the second
approach.


Ralph



On Dienstag, Mai 27, 2003, at 08:18 Uhr, Wagner,John wrote:

> Ralph,
> I think we should start by agreeing on a basic layout ML (call it
> Level A, if you like) that is flexible enough that it could be further
> modified, but I don't think that should necessarily be our stopping
> point; rather, it should then serve as the basis for further defining
> additional features that people feel are needed. Thus, I am calling
> them "revisions" (see below).
>
> I do not dislike what your group has done, in broad terms. However,
> the display markup must be removed from the model's individual
> elements, and put in a section all by itself. This is not only a matter
> of aesthetics, it's necessary so that your approach can be modified
> to include multiple views (something many tools must have). Andrew
> did this one way, adding to the <model> element another list, the
> <listOfViews> I think he called it. I have taken a different approach,
> (go here and click on FutileCycle-0.xml):
>
> http://caboy.uchc.edu/wagner/Science/VirtualCell/SBML-DWG/Default.htm
>
> I have called this DWG revision 0 in the expectation that this will
> be modified over time (as we hash things through) to an actual
> working group "revision" (what you called "level"). For now, it's
> ONLY a dartboard--something to throws darts at. You will find
> that content-wise, it's similar to your approach, but with the
> diagramming markup removed from the individual model elements
> and put into a completely separate section. You will also see that
> so far, I've only put in (x, y) coordinates, whereas your group also
> tracks width and height. I am of the opinion that we should do
> (x, y, w, h), I just wanted to get agreement from those who don't
> currently track (w, h) that they'd be willing to go with an (x, y, w,
> h)
> approach and simply convert using x + w/2, y + h/2. If so, then I
> would propose to add w and h attributes to compartmentGlyphs
> and speciesGlyphs, if not others. Also, should the <diagram>
> element have x, y, w and h?
>
> I think once we have massaged this into a working and accepted
> baseline level, at that point we can start discussing what more we
> want--shapes, fonts, colors, whatever. I'd just like to first get to a
> baseline revision that has DWG consensus as "this is the bare minimum
> we want/need" before throwing in bells and whistles.
>
> John
>
>
>
> -----Original Message-----
> From: Ralph Gauges [mailto:ralph.gauges@eml.villa-bosch.de]
> Sent: Tue 5/27/2003 4:40 AM
> To: Wagner,John
> Cc: sbml-discuss@caltech.edu
> Subject: Re: [sbml-discuss] DWG math display?
>
>