Forums

I agree with John that IDs should be put into SBase with all the
implications that this may have.
Leaving out IDs from units now will most probably lead to someone
coming up with an example why units need IDs within two weeks after it
was decided that they don't need any.
I also never saw the listOf.. structures as subclasses of SBase! Is
this mentioned anywhere in the specification?

Ralph




On Donnerstag, Juni 5, 2003, at 05:56 Uhr, Wagner,John wrote:

> Okay, now I see why IDs shouldn't be put into SBase. :)
> I'm actually in favor of it, too, but I'm betting a significant
> number of others won't be. So...
>
> I guess minimally, for diagrams we could use ID fields in
> SpeciesReference, ModifierSpeciesReference and, possibly,
> KineticLaw. However, Unit already has name, and it is used
> as a primary key, so it's a very good candidate for an ID
> field--the only difference being that it must be unique across
> the whole model. Also, models will probably benefit from
> an ID field in the context of model composition (and from
> being required as opposed to optional).
>
> But, I see no reason at all for lists to have them (I didn't think
> about these structures being subclassed from SBase), and I
> see no reason for <unit> or <sbml> elements to have them.
>
> So maybe it would just be easier to go and stick them into
> everything that *needs* them?
>
> But, as I said, I actually lean toward sticking them into SBase.
>
> John
>
>
>
> -----Original Message-----
> From: Michael Hucka [mailto:mhucka@caltech.edu]
> Sent: Wed 6/4/2003 9:59 PM
> To: SBML Discussion List
> Cc:
> Subject: Re: [sbml-discuss] DWG: multiple layouts
>
>
>
> JWagner> I don't see why SID isn't put into SBase (the
> JWagner> primary key argument would imply it belongs
> JWagner> here). I say let's put it into SBase in Level 2.
>
> I'm actually in favor of this. (I assume also that this
> would involve putting the 'name' field on SBase, since the
> 'id' and 'name' fields go hand in hand.)
>
> However, before doing this, everyone should think about some
> of the implications:
>
> * The following substructures currently don't have ids or
> names because they are subordinate to other structures
> that *do* have ids.
>
> - Unit
> - AlgebraicRule, AssignmentRule, RateRule
> - SpeciesReference, ModifierSpeciesReference
> - KineticLaw
> - EventAssignment
>
> Remember that ids have to be unique across the whole
> model. Under this proposed change to SBML, even unit
> definitions would have to have unique id's like this:
>
> <listOfUnitDefinitions id="u1">
> <unitDefinition id="mmls">
> <listOfUnits id="u2">
> <unit id="u3" kind="mole" scale="-3"/>
> <unit id="u4" kind="litre" exponent="-1"/>
> <unit id="u5" kind="second" exponent="-1"/>
> </listOfUnits>
> </unitDefinition>
> </listOfUnitDefinitions>
>
> Note the added id's on listOfUnitDefinitions, listOfUnits,
> and the <unit...> elements. The point in particular is
> that nothing can refer to the <unit ...> elements, but
> this change to SBML would force software to generate the
> id's in some way. Same for Rules, KineticLaw, etc.
> Further, it will bloat a model definition with more
> identifiers that have to be hashed and processed.
>
>
> * If SBase included SId, then the listOf___s would also gain
> id and name fields. But these correspond to array
> containers. It seems strange to give ids and names to
> array containers. (Admittedly, though, this has already
> happened with 'notes', 'annotation' and 'metaid'.)
>
>
> * It is currently the case that SId is a required field in
> all places where is used, *except* on the Model structure,
> where it is only an optional field. (The reason is simply
> that there's no construct within a model that can refer to
> the model's id, unlike the ids of species and other
> components.) If SBase adopts SId, it would need 'id' to
> be required everywhere, including Model.
>
>
> * The top-level Sbml structure (which defines the <sbml ...>
> tag) is currently also derived from SBase. Under this
> proposal, it too would require an id, unless an exception
> were made.
>
>
> There may be other interactions that haven't come to mind.
>
> --
> Mike Hucka, Ph.D. mhucka@caltech.edu
> Control and Dynamical Systems, MC 107-81 tel: +1.626.395.6911
> Caltech, Pasadena, CA 91125, USA fax: +1.702.554.3067
>
>
>
>
>