Forums

Lucian Smith wrote:

> And it's a valid concern. Once a package is vetted, who does the work to
> implement a reader? If only one reader is written, assuming it's not
> libSBML, what good did it do, since the point of SBML is to be a model
> exchange format? If it does manage to get into libSBML, how can we be
> sure that downstream users will use the version of libSBML with the
> package and not without?


Hello Lucian,

I believe part of those concerns have been discussed quite a while ago. For
several years now, we have agreed that before becoming part of the official
SBML Level 3, a package must be supported by two independent tools. This
has several advantages, including benchmarking packages before committing,
and ensuring support. Who does the work of implementing a reader is who
needs the package.

> Here's my proposal, which is easy for me to make because I don't have to
> code it

Why? What you propose is part of the community wiki I believe.

> but here it is anyway: I think there should be an 'L3 Packages'
> page that provides information on each package's status:
>
> - What state the proposal itself has reached
> - An estimate of the 'complexity' of the package; basically, how
> relatively difficult it would be to add support for it.
> - Who (if anyone) is working on a libSBML package for it, and what
> their ETA is on that.
> - Who (if anyone) is working on non-libSBML support for the
> package, and their ETA.
> - A list of programs that support the package (if any)--this would
> probably be a reference to the program on the big SBML support
> list.

That is a very good suggestion. And we can probably modify the table on the
page:
http://sbml.org/Community/Wiki
For that purpose.

> That said, to get back to the 'groups' package: since Mike is proposing
> it, and since he's in charge of the libSBML group, and since the package
> itself doesn't sound too complicated to begin with, I think it won't take
> a ton of persuasion to get him to add the package to the to-do list for
> his developers (as long as he still has $$ for them, of course), and I
> wouldn't expect an unreasonable amount of time before libSBML would
> support it.

I believe there is a fundamental misconception about libSBML development.
The development of libSBML was initiated and mostly (this is an euphemism)
done by the SBML-team, thanks to grants obtained by Mike, and in particular
the current NIH grant which funds Mike at Caltech, Sarah at the EBI and
Akiya in Keio. And it is very sensible that Mike and Sarah keep the
leadership and coordinate the effort. However, libSBML is a Free Software
and its development a community effort. I hope this community aspect will
increase with time (we already see it with the Java version) and that Sarah
will receive the help of many hands. In particular people proposing a
package should develop support for it in libSBML. This is what we started
to do with the packages multi and quali.

And this is also why the modular aspect of L3 is so important. The core is
common to all, but the packages will evolve, be extended, be replaced etc.
and similarly for their libSBML support. Carefully crafted modularity of
spec/software/funding/responsibilities is the only way to ensure robustness
of support.

If people want features, they have to be ready to invest time/energy/money.

Cheers

--
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/


____________________________________________________________
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