Forums

I was focusing on tool developers rather than users because a user doesn't
care how the data is stored, only *that* it's stored. All three options
provide ways to store this data, so I would argue that a user wouldn't
care.

But you're right that there is more to the story than simply what I
outlined--there's a sense in which putting attributes in core is
perscriptive, and encourages developers to implement things that
they otherwise might not. If this data truly needs to be exchanged and
tool developers are dragging their feet, this could be the push they need
to implement it.

-Lucian

* Bruce Shapiro <bshapiro@caltech.edu> [2012-07-13 19:28] writes:
> I would argue that this algorithm is perhaps itself a bit too stiff, but I
> am put off by the words "would implement it" and that it depends on tool
> developers and not tool users. Measurements always have an uncertainty in
> biology and both experimentalists and referees will feel a lot more
> comfortable if we show that we are taking this into account at the very
> core of our models. Whether or not something goes into the core should
> depend on (a) how important it is to biological modelling and (b) how far
> its effects will propagate into the implementation. (b) should only be of
> secondary importance, because if (a) is really, truly central, then we
> should do whatever it takes to get this into the core.
>
> To make it clear ... my vote is for the core .. no matter what it takes.
>
>
>
>
>
> On Fri, Jul 13, 2012 at 10:55 AM, Lucian Smith <lpsmith@spod-central.org>wrote:
>
> > I think you did a good job of enumerating the disadvantages; perhaps I can
> > have a go at enumerating the advantages?
> >
> > * Nicolas Le Novere <lenov@ebi.ac.uk> [2012-07-12 17:10] writes:
> > > The big question is the package to which those attribute should belong
> > to:
> > > 1) core (remember those are optional attributes)?
> > > 2) distrib?
> > > 3) another package? (at some point it was suggested to develop a stat
> > > package, for instance to extend the MathML).
> > >
> > > All solutions have their appeal, and all solutions have their drawbacks.
> > >
> > > 1) is harder to implement due to the stiffness of the core, and the
> > > perception that the burden will be high on all shoulders.
> >
> > The advantage of putting it into core is that the burden would be less on
> > those that *do* want to implement it.
> >
> > One implication of the 'stiffness of the core' disadvantage is timing: it
> > may take longer to put this in core than it would be to put it in a
> > package. However, given how long it's taken to get other packages up and
> > running, I'm not sure exactly what the difference is, here.
> >
> > My feeling on this one is that the disadvantages slightly outweigh the
> > advantages, but it's pretty close. The difference could be shifted if
> > there were a large number of tools ready to add this feature.
> >
> > > 2) will tie the attributes to distrib, and therefore they will only be
> > > accessible to tools understanding distrib.
> >
> > The advantage would be that it would be easier for tool writers who were
> > already planning to implement distrib.
> >
> > I think this is my favorite, simply because my impression is that the tool
> > writers who would implement these attributes are indeed the ones who would
> > be more likely to implement distrib as a whole. Again, I could be
> > persuaded otherwise with feedback from tool developers.
> >
> > > 3) will force the creation of a new package, with all the management
> > > hassle, but would make easier future independent evolutions (i.e. adding
> > > median).
> >
> > The advantage would be that it would be easier for developers who wanted
> > to add these attributes but nothing else.
> >
> > My feeling on this is that we should only do it if there is a large
> > subsection of people who want to implement just these attributes but
> > nothing else. I don't think this is the case?
> >
> > Overall, which choice we go with should boil down to the relative sizes of
> > these three populations:
> >
> > A) The tool developers who won't do anything with these attributes.
> > B) The tool developers who would implement these attributes but not
> > 'distrib'
> > C) The tool developers who would implement these attributes plus 'distrib'
> >
> > and I guess:
> >
> > D) The tool developers who would implement the rest of 'distrib' but not
> > these attributes.
> >
> > (I'm guessing the population of D is zero?)
> >
> > If A >> C >> B, which is my impression, that would argue for option 2,
> > rolling it into 'distrb'.
> >
> > If A >> B >> C, that would argue for option 3, creating a new small
> > package.
> >
> > If A ~= C + B, that would argue for option 1, rolling it into core.
> >
> > -Lucian
> >
> > ____________________________________________________________
> > 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
> >
> >
>
>
> --
> Bruce E Shapiro PhD
> Biological Network Modeling Center
> California Institute of Technology
> M/C 139-74, 1200 E California Blvd
> Pasadena, CA 91125
> http://bnmc.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