Forums

Hello Stefan,

sorry for confusing you ... all I wanted to ensure, is that use cases that we have now where one would like to iterate through all rules of the model would still work as before.

In the scheme lucian and you suggest, asking for all rules would also give me initial assignments and event assignments, and would thus change my expectation. An initial assignment simply is no rule!

Anyway ... i guess the next thing to work out would be the unification of specifying the target attribute, which right now is:

Initial Assignment: symbol
Assignment Rule / Rate Rule / Event Assignment: variable

if all of them are supposed to be 'assignments' then this might have to change.

Cheers
Frank

On May 14, 2010, at 6:57 AM, Stefan Hoops wrote:

> Hello Frank,
>
> To be honest the double inheritance you suggest confuses me.
>
> We currently have the following instantiated elements
> 1) AlgebraicRule
> 2) RateRule
> 3) AssignmentRule
> 4) InitialAssignment
> 5) EventAssignment
>
> Common to all of them is that they have a Math element therefore I
> agree with Lucian that all of them should be derived from some base
> class (lets call) is Rule and not from 2 as you suggest.
>
> Except the AlgebraicRule all other have a target SId thus from the
> data structure we should derive them from 1 base class which itself is
> derived from Rule. Therefore we end up with exactly what Lucian
> suggested:
>
> Rule
> -> AlgebraicRule
> -> Assignment
> -> RateRule
> -> AssignmentRule
> -> InitialAssignment
> -> EventAssignment
>
> This does not include the difference of semantics which is actually
> not part of the schema (neither XSD nor RelaxNG) and thus should not be
> mingled with the object structure.
>
> You still have rule-ness and assignment-ness, you also do not have any
> interface problems as the interface to the four assignments is the same
> as they all provide a target SId. The rule interface is also the same as
> all 5 provide access to the Math element.
>
> Thanks,
> Stefan
>
>
> On Thu, 13 May 2010 11:30:57 -0700
> Frank Bergmann <fbergman@u.washington.edu> wrote:
>
>> fine i give up ... what i meant is this:
>>
>> http://cl.ly/8b0be9ce2f09627cb0a6
>>
>> you get all the goodness of the 'rule-ness' so people that used the
>> concept till now don't have to change a thing, and you still have the
>> benefits of 'assignment-ness' that people want to take advantage
>> of ... (people fearing this would look almost like multiple
>> inheritance ... and would be un-implementable, don't: think in terms
>> of interfaces and all the worries go away)
>>
>> Cheers
>> Frank
>>
>>
>>
>> On May 13, 2010, at 10:26 AM, Lucian Smith wrote:
>>
>>> I couldn't follow Frank's ASCII art; is this what he's suggesting?
>>>
>>> Rule
>>> ==AlgebraicRule
>>> ==Assignment
>>> ====RateRule
>>> ====AssignmentRule
>>> ====InitialAssignment
>>> ====EventAssignment
>>>
>>> If so, it's OK insofar as it goes, but I don't see why we need to
>>> preserve the concept of a 'Rule' in the first place--the only
>>> commonality that I can see is that the three (AlgebraicRule,
>>> RateRule, AssignmentRule) all have the word 'Rule' in the name.
>>>
>>> -Lucian
>>>
>>> * Mike Hucka <mhucka@cds.caltech.edu> [2010-05-13 18:04] writes:
>>>> I like this idea. It would only minimally disrupt the current
>>>> class structure, and introduce a superclass that might help
>>>> package writers.
>>>>
>>>> What are other people's opinions?
>>>>
>>>> MH
>>>>
>>>>
>>>> On 27 Apr 2010, at 9:45 AM, Frank Bergmann wrote:
>>>>
>>>>>>
>>>>>> If we want a common base that is fine with me byt I
>>>>>
>>>>> I would prefer one ...
>>>>>
>>>>>>> would then like it to be:
>>>>>>>
>>>>>>> Assignment
>>>>>>> == Rule
>>>>>>> ==== AssignmentRule
>>>>>>> ==== AlgebraicRule
>>>>>>> ==== RateRule
>>>>>>> == InitialAssignment
>>>>>>> == EventAssignment
>>>>>>
>>>>>> You cannot do that because the AlgebraicRule does not have a
>>>>>> variable. So
>>>>>> you do not inherit anything.
>>>>>>
>>>>>
>>>>> Well ... then we need two abstract classes, in that case we
>>>>> won't loose what we have now (a concise way of talking about all
>>>>> rules).
>>>>>
>>>>> |---- AlgebraicRule
>>>>> Rule ------ |---- AssignmentRule --- |
>>>>> |---- RateRule --- |
>>>>> |----
>>>>> Assignment
>>>>> InitialAssignment --- |
>>>>> EventAssignment --- |
>>>>>
>>>>>
>>>>> Frank
>>>>>
>>>>>
>>>>>>> This is only because end users really could work only with the
>>>>>>> 'rule'
>>>>>>> objects. On the other hand I have no attachments to
>>>>>>> 'AlgebraicRule' either.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Frank
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: sbml-discuss-bounces@caltech.edu [mailto:sbml-discuss-
>>>>>>>> bounces@caltech.edu] On Behalf Of Nicolas Le novère
>>>>>>>> Sent: Tuesday, April 27, 2010 6:40 AM
>>>>>>>> To: SBML Discussion List
>>>>>>>> Subject: [sbml-discuss] assignments
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I would like to bring an issue for specification developers.
>>>>>>>> That will
>>>>>>>> not
>>>>>>>> affect SBML support or usage. So everyone not concerned with
>>>>>>>> spec writting,
>>>>>>>> you can leave :-)
>>>>>>>>
>>>>>>>> At the moment, there is an abstract class in SBML definition,
>>>>>>>> called
>>>>>>>> Rule.
>>>>>>>> This class is a functional one (a semantic one), and is used
>>>>>>>> to create
>>>>>>>> the
>>>>>>>> concrete classes AssignmentRule, RateRule and AlgebraicRule.
>>>>>>>>
>>>>>>>> At the same time, there are in the SBML core four classes
>>>>>>>> with the same
>>>>>>>> syntax, that are used for a similar purpose:
>>>>>>>>
>>>>>>>> InitialAssignment
>>>>>>>> AssignmentRule
>>>>>>>> RateRule
>>>>>>>> EventAssignment
>>>>>>>>
>>>>>>>> Those construct share the same goal, to assign a value to
>>>>>>>> something, or
>>>>>>>> the
>>>>>>>> evolution of something. Although the attribute used to point
>>>>>>>> to the something varies, symbol or variable, the something is
>>>>>>>> the same, that
>>>>>>>> is a
>>>>>>>> species, a speciesReference, a compartment or a parameter.
>>>>>>>>
>>>>>>>> The abstract classes are not seen by the end users, and are
>>>>>>>> mostly constructs used to reduce redundancy in the
>>>>>>>> specification of the language.
>>>>>>>> Therefore, I think a good alternative to the current:
>>>>>>>>
>>>>>>>> Rule
>>>>>>>> == AssignmentRule
>>>>>>>> == RateRule
>>>>>>>> == AlgebraicRule
>>>>>>>> InitialAssignment
>>>>>>>> EventAssignment
>>>>>>>>
>>>>>>>> Would be:
>>>>>>>>
>>>>>>>> AlgebraicRule
>>>>>>>> Assignment
>>>>>>>> == AssignmentRule
>>>>>>>> == RateRule
>>>>>>>> == InitialAssignment
>>>>>>>> == EventAssignment
>>>>>>>>
>>>>>>>> The effect is mild on the core, but propagate on the various
>>>>>>>> packages.
>>>>>>>>
>>>>>>>> For instance, writing the package multi, we're now
>>>>>>>> multiplicating the
>>>>>>>> sections, UML diagrams and examples because the four
>>>>>>>> assignments can
>>>>>>>> affect
>>>>>>>> subpools (SpeciesTypeInstances) in addition of regular species.
>>>>>>>>
>>>>>>>> (Whether we want to keep AlgebraicRule in SBML core is
>>>>>>>> another story
>>>>>>>> ...)
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI,
>>>>>>>> Wellcome- Trust
>>>>>>>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:
>>>>>>>> +441223494521
>>>>>>>> Fax:
>>>>>>>> 468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT
>>>>>>>> email)
>>>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
>>>>>>>> @lenovere
>>>>>>>>
>>>>>>>>
>>>>>>>> ____________________________________________________________
>>>>>>>> To manage your sbml-discuss list subscription, visit
>>>>>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>>>>>>
>>>>>>>> For a web interface to the sbml-discuss mailing list, visit
>>>>>>>> http://sbml.org/Forums/
>>>>>>>>
>>>>>>>> For questions or feedback about the sbml-discuss list,
>>>>>>>> contact sbml-team@caltech.edu
>>>>>>>
>>>>>>> ____________________________________________________________
>>>>>>> To manage your sbml-discuss list subscription, visit
>>>>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>>>>>
>>>>>>> For a web interface to the sbml-discuss mailing list, visit
>>>>>>> http://sbml.org/Forums/
>>>>>>>
>>>>>>> For questions or feedback about the sbml-discuss list,
>>>>>>> contact sbml-team@caltech.edu
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI,
>>>>>> Wellcome- Trust
>>>>>> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:
>>>>>> +441223494521
>>>>>> Fax:
>>>>>> 468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT
>>>>>> email)
>>>>>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/,
>>>>>> @lenovere
>>>>>>
>>>>>>
>>>>>> ____________________________________________________________
>>>>>> To manage your sbml-discuss list subscription, visit
>>>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>>>>
>>>>>> For a web interface to the sbml-discuss mailing list, visit
>>>>>> http://sbml.org/Forums/
>>>>>>
>>>>>> For questions or feedback about the sbml-discuss list,
>>>>>> contact sbml-team@caltech.edu
>>>>>
>>>>> ____________________________________________________________
>>>>> To manage your sbml-discuss list subscription, visit
>>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>>>
>>>>> For a web interface to the sbml-discuss mailing list, visit
>>>>> http://sbml.org/Forums/
>>>>>
>>>>> For questions or feedback about the sbml-discuss list,
>>>>> contact sbml-team@caltech.edu
>>>>
>>>> ____________________________________________________________
>>>> To manage your sbml-discuss list subscription, visit
>>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>>
>>>> For a web interface to the sbml-discuss mailing list, visit
>>>> http://sbml.org/Forums/
>>>>
>>>> For questions or feedback about the sbml-discuss list,
>>>> contact sbml-team@caltech.edu
>>> ____________________________________________________________
>>> To manage your sbml-discuss list subscription, visit
>>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>>
>>> For a web interface to the sbml-discuss mailing list, visit
>>> http://sbml.org/Forums/
>>>
>>> For questions or feedback about the sbml-discuss list,
>>> contact sbml-team@caltech.edu
>>
>> ____________________________________________________________
>> To manage your sbml-discuss list subscription, visit
>> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>>
>> For a web interface to the sbml-discuss mailing list, visit
>> http://sbml.org/Forums/
>>
>> For questions or feedback about the sbml-discuss list,
>> contact sbml-team@caltech.edu
>
>
> --
> Stefan Hoops, Ph.D.
> Senior Project Associate
> Virginia Bioinformatics Institute - 0477
> Virginia Tech
> Bioinformatics Facility II
> Blacksburg, Va 24061, USA
>
> Phone: (540) 231-1799
> Fax: (540) 231-2606
> Email: shoops@vbi.vt.edu
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbml-team@caltech.edu

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu